# umask eines Paketes im eigenen Profil

## LinuxTom

Hallo Leute,

nun ist es so, dass ich mir ein eigenes Profile angelegt habe, das auf beispielsweise ../10.0/desktop/kde/ verweist. Alles ok. Eigene Zusatzprogramme definiert: Ok. Nun will ich jedoch ein maskiertes Programm ins Profile aufnehmen. Wie kann ich das demaskieren? Im Profile, nicht in /etc/portage/packages.keywords?

Viele Grüße

Thomas

----------

## Genone

Um welches Paket geht es, bzw. durch welchen Mechanismus ist es maskiert (emerge "masked by:" Status)?

----------

## LinuxTom

In einem Fall geht es um "app-crypt/truecrypt/truecrypt-6.3a.ebuild". Da steht in der build drin:

KEYWORDS="~amd64 ~ppc ~x86"

Aber Du hast mich dann wohl mit Deiner Frage auf die richtige Idee gebracht. Ich muss dann das USE-Flag "amd64" (oder entsprechendes) demaskieren. Dann sollte es klappen. Ich hatte nicht an diesen Weg gedacht.   :Embarassed: 

Ich probiere es dann einfach mal aus.

----------

## Klaus Meier

~amd64 ist kein Use Flag. Bei dir steht in der make.conf entweder ACCEPT_KEYWORDS="~amd64" oder ACCEPT_KEYWORDS="amd64". Mit ersterem hast du ein testing System, mit dem anderen ein stable. Wenn du das änderst, dann baust du dein ganzes System neu.

----------

## LinuxTom

Und wie trage ich das dann in mein Profile ein, dass truecrypt installiert wird? Denn ein Unstable System will ich nicht haben. Bestimmte Pakete sind ok. Wie eben TrueCrypt.

----------

## Klaus Meier

Du trägst es nicht ins Profil ein sondern in die package.unmask.

----------

## LinuxTom

 *Klaus Meier wrote:*   

> Du trägst es nicht ins Profil ein sondern in die package.unmask.

 

Gibt es denn keinen anderen Weg? So dass ich das schon in meinem eigens erstellten Profil vordefinieren kann?

----------

## Klaus Meier

In den Profilen werden USE-Flags gesetzt und keine Pakete maskiert oder demaskiert.

----------

## Josef.95

 *Quote:*   

> Du trägst es nicht ins Profil ein sondern in die package.unmask.

 Sorry, aber das ist so nicht ganz richtig...

Ein Paket welches laut ebuild  masked by ~arch keyword maskiert ist wird normal in der package.keywords demaskiert. In der package.unmask hat das nichts zu suchen.

Und Pakete können sehr wohl schon im Profil maskiert sein, oder werden. Zb wenn ein amd64 no-multilib Profil verwendet wird, dann sind idR alle Pakete die die eben doch 32bit libs benötigen würden schon vom Profil her maskiert.

Aber ein Paket mit ~arch keyword generell im Profil zu demaskieren, davon würde ich eher abraten... (ich bin mir auch nicht sicher ob das überhaupt geht)

----------

## Klaus Meier

Sorry, ja, hab das mit Paketen verwechselt, die hardmasked sind.

----------

## LinuxTom

[quote="Josef.95"] *Quote:*   

> Aber ein Paket mit ~arch keyword generell im Profil zu demaskieren, davon würde ich eher abraten... (ich bin mir auch nicht sicher ob das überhaupt geht)

 

Ob ich das auf 6 Rechnern in /etc/portage/ mache oder bei einem Rechner im Profile, das von den 6 genutzt wird ist letztlich egal. Mein Profile soll das Paket halt zulassen.

Aber wo und wie geht das?

----------

## Klaus Meier

Josef hat es doch beschrieben:  *Quote:*   

> Ein Paket welches laut ebuild masked by ~arch keyword maskiert ist wird normal in der package.keywords demaskiert.

 

----------

## LinuxTom

Ja, ... wird normal ....

Aber verstanden habt ihr mich hoffentlich. Ich will meinen 6 Rechnern nur das Profil bekannt geben und nicht noch in /etc/portage/ etwas machen. Darum halt der Wunsch.

----------

## Josef.95

Es sollte wohl klappen wenn du in deinem eigenen Profil eine package.keywords (evtl. auch als Verzeichnis) anlegst und diese mit einem Symlink auf /etc/portage verlinkst. [ungetestet]   :Wink: 

/edit:

Ich hab es probiert, so würde es zb funktionieren 

```
# ls -l /etc/portage/package.keywords

lrwxrwxrwx 1 root root 34 2010-07-10 14:38 /etc/portage/package.keywords -> /root/profil-Name/package.keywords
```

----------

## LinuxTom

Danke. Darauf hätte ich auch selber kommen können. Ich werde es Anfang nächster Woche mal ausprobieren.

----------

## Genone

In neueren Versionen (weiss nicht genau seit wann) unterstützt Portage auch package.keywords in Profilen. Allerdings ist die Semantik etwas anders als bei /etc/portage/package.keywords: die Einträge ergänzen die KEYWORDS Variable im entsprechenden Ebuild statt der ACCEPT_KEYWORDS Variable in make.conf (s.a. Manpage), und es gibt keinen Standardwert.

----------

## LinuxTom

Das wäre ja das, was ich brauche, doch wieso steht das hier http://devmanual.gentoo.org/profiles/index.html nicht drin?

----------

## Genone

Weil Dokumentation nie 100% aktuell ist, und beim Devmanual weiss ich auch nicht ob das überhaupt noch aktualisiert wird.

----------

## LinuxTom

Danke.   :Very Happy: 

Im "man portage" steht es. hat sich inzwischen einiges geändert. Werde es mal durcharbeiten und ausprobieren.

----------

## mv

Eine andere Lösungmöglichkeit besteht darin, auszunutzen, dass /etc/portage/pakage.* auch Directories sein können: Man kann dann z.B. einen Link von /etc/portage/package.keywords/000-defaults in ein gemeinsam geteiltes Directory legen. Ein Vorteil besteht darin, dass Du dann z.B. von eix-test-obsolete informiert wirst, wenn Du den entsprechenden Eintrag nicht mehr brauchst.

----------

## Max Steel

Interresant wäre zu wissen ob man in /etc/portage/package.* als Files auch andere Files includen (sourcen) könnte...

----------

## Genone

 *Max Steel wrote:*   

> Interresant wäre zu wissen ob man in /etc/portage/package.* als Files auch andere Files includen (sourcen) könnte...

 

Nein, da die Directory Lösung die gleiche Funktionalität bietet, leichter zu handhaben und dabei flexibler ist.

----------

## LinuxTom

Danke erst einmal an alle. Ich habe es endlich geschafft. Das mit dem package.use im Profile-Dir klappt nicht, da ist ein kleiner Fehler in der Man-Page.

Nur jetzt ist das Sytem ein wenig groß.  :Wink:  Aber das ist beispielsweise nur bei einem GCC-Wechsel etwas nachteiliger.

Nun muss ich nur noch über eine sinnvolle Verteilung nachdenken. Habe da an Layman gedacht. Mal sehen.

----------

## LinuxTom

Gibt es nicht eine andere Möglichkeit als

```
emerge -e system && emerge -e world
```

Es sollte doch auch ein 

```
emerge -1 gcc binutils glibc && emerge -e world
```

 gehen. Oder was meint ihr?

----------

