Re: [gentoo-user-de] Bug in Portage oder "PEBCAC"..?

[Christian Bricart <christian@bricart.de>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 19.11.2013 06:15, schrieb Johann Schmitz:
> Moinsen,

tach auch,

> 
>> soweit so gut - emerge an sich funktioniert schon mal korrekt
>> und meine Version aus dem local Overlay überstimmt die selbe
>> Version aus dem main-Tree..
> 
> Bei gleichen Version wird das Paket aus dem Overlay verwendet, da
> der Inhalt deiner PORTDIR_OVERLAY das PORTDIR überlagert (wie der
> Name schon sagt).

genau - halt bitte diesen Gedanken fest, dass:
 "PORTDIR_OVERLAY das PORTDIR überlagert (wie der Name schon sagt)." ;)

> 
>> # echo "app-foo/bar::gentoo" > 
>> /usr/local/portage/profiles/package.mask # echo 
>> "app-foo/bar::meins" >
>> /usr/local/portage/profiles/package.unmask
> 
>> jetzt bekomme ich bei *jedem* emerge die Warnung(en):
> 
>> --- Invalid atom in /usr/local/portage/profiles/package.mask: 
>> app-foo/bar::gentoo --- Invalid atom in 
>> /usr/local/portage/profiles/package.unmask: app-foo/bar::meins
> 
> Weil afaik in der package.mask keine Repository Constraints
> erlaubt sind. In der Manpage steht bei package.mask: "one DEPEND
> atom per line". Ein DEPEND besteht aus CP und Version/(Sub)Slot;
> kein repository. Dort wird zwar auch von atoms als Einträge
> geredet, mir ist aber noch nie ein Repository in *.mask
> untergekommen.

..weil es innerhalb vom Main-Tree (Repository: "gentoo") auch keinen
Sinn macht, weil man:
a) vom Main-Tree aus nicht alle beliebigen sonst noch benamte Overlays
der Welt kennen kann
b) es keinen Sinn macht, sich als Main-Tree über ein Overlay
hinwegzusetzen ;-) weil der Sinn ist ja genau eben andersrum..

und ich müsste auch erstmal in den diversen Laymans schauen, ob ich
überhaupt ein Overlay finde, welches package.{un}mask mitbringt ;)

> 
> Wenn man darüber nachdenkt, macht es auch Sinn:
> 
> - Vom Tree aus "ignorieren" wir Overlays. Wir versuchen zwar 
> weitestgehend kompatibel zu sein, aber am Ende des Tages ist der 
> Overlay Maintainer für die Kompatibilität verantwortlich. - In
> einem Overlay übersteuert die gleiche Version die aus dem Tree 
> (weil in PORTDIR_OVERLAY) - In Overlay A Ebuilds aus Overlay B
> masken ist schon ein sehr außergewöhnlicher Spezialfall. Es gibt
> sicherliche Use-Cases aber im Zweifelsfall muss der User
> entscheiden was er installieren will.

...kommen wir nun zum festgehaltenen Gedanken zurück:
Wenn ein Overlay sich dadurch auszeichnet, komplett transluzent über
dem Main-Tree zu liegen, dann muss ich *jede* Datei dort mit *meinem*
Inhalt mit einer Datei an der selben Stelle im Baum überlagern
können..  ;)

> 
>> ... aber: es funktioniert wie gewollt! und "eix" zeigt das sogar 
>> richtig an..
> 
> Das kommt glaube ich eher durch eine weite Auslegung der PMS. Ich
> habe da jetzt gerade nicht reingeschaut (zu wenig Kaffee), ich
> könnte mir aber vorstellen, dass das nicht explizit definiert ist
> ob RC's erlaubt sind.

die Möglichkeit von Repository-/Overlay-Namen sind noch nicht so alt..
kann sein, dass es einfach nicht konsistent durch die Tools gezogen
wurde(?) oder ich stimme dir zu, dass eix evtl. die PMS schon weiter
(oder falsch?) auslegt.
aaaber: ich habe eix nur als Beispiel genannt um die einfache
Visualisierung alle Möglichkeiten zu bekommen.
Natürlich kommt aus dem "emerge -v foo/bar" auch die gewünschte
Version raus ;-) Nur die Warnung stört halt..
Also irgendwie isses dann doch schon drin..

> 
>> Also die Warnungen beomme ich ja weg, indem ich in die overlay 
>> package.mask nur "app-foo/bar" (ohne ::gentoo) reinschreibe und 
>> dann in *jedem* lokalen /etc/portage/package.unmask dann 
>> "app-foo/bar::meins" wieder freischalte.. aber das ist ja
>> unschön ;-)
> 
> Entweder das, oder du machst es über die Versionen:
> 
> <app-foo/bar-1.0
>> app-foo/bar-1.0
> 
> Das haut dir alle Versionen ungleich 1.0 raus, und die 1.0 in
> deinem Overlay wird ja sowieso vor der Tree-Version genommen.

es war eben genau der Hintergrund *jede* Version (sprich: also eben
*ohne* $PV) aus einem bestimmten Tree zu masken um nicht drauf
achtzugeben, wann der Main-Tree das Overlay durch höhere Version
überstimmt (und dann gepaart mit Unachtsamkeit die falsche Version
auf's System kommt - die dann zugegebenermassen neuer ist, aber die
Änderungen aus dem Overlay nicht mitdrin hat)

> Sauberer fände ich es allerdings, ein -r1 draus zu machen und ggf. 
> Patches auf b.g.o. einzureichen, damit alle was davon haben :)

..das hält ja auch nur bis im Main-Tree die -r2 auftaucht ;)

und zum Thema b.g.o:

der Hintergrund ist eine "Mass-Deployment-Umgebung", welche bei
einigen Paketen (rein nur) für diese Umgebung sinnvolle
Erweiterungen/Modifikationen mitbringt. z.B. vorgefertigte
Konfigurationsdateien (/etc/conf.d/..), oder irgendwas anderes unter
${FILESDIR}/.. im angepassten ebuild

Das durch die Maskierung und De-Maskierung zu lösende Problem dabei
ist, dass oben genannte: es soll vermieden werden, dass durch
Unachtsamkeit unmodifizierte Pakete installiert werden.
Oder anders - Installation ist folgendermassen:
- - (eigenes) Stage4 auspacken
(- local Overlay ist dort vorkonfiguriert und kommt aus zentralem
GIT-Repo)
- - Pakete werden prinzipiell aus dem Main-Tree installiert..
- - ..oder sind (bei »kritischen« Paketen) "abgesegnete" ebuilds
und das ganze "zentral steuerbar" vom Overlay-Mantainer ohne
Notwendigkeit immer wieder in jede einzelne lokale /etc/portage/
eingreifen zu müssen..

(und um es vorweg zu nehmen - ja.. ich kenne [und nutze] Puppet und
Konsorten ;-) [hier] keine Option ;) )

Danke auf jeden Fall schonmal
  Christian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEARECAAYFAlKLsCMACgkQDTcHuUk6x7uUFACcDNHKiHRqzosYuBIUKlUNNevp
x3oAoKL77+3ns/mYTBqFfxonGVXMkdAw
=tpCV
-----END PGP SIGNATURE-----