Bug in Portage oder "PEBCAC"..?

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug in Portage oder "PEBCAC"..?

Christian Bricart
Servus,

bevor ich die grosse englische Bug-Runde eröffen... liegt's an Portage
oder an meiner Unfähigkeit..? ;-)

folgendes:
ich habe ein ebuild aus dem main Tree in mein lokales Overlay überführt
und möchte es (ausschliesslich!) dort weiterpflegen..
soll heissen: ich will generell dieses Paket wenn es aus dem  main-Tree
kommt maskieren und nur meine Versionen benutzen - auch wenn die Version
im main Tree neuer ist. Zusätzlich will ich diese Konfiguration nicht
immer auf jedem meiner Hosts in /etc/portage/package.{mask,unmask}
einrichten, sondern sie mit dem Overlay (<- ist zentral bei mir ein
GIT-Repo) mitbringen.

folgendes habe ich also gemacht:
- PORTDIR_OVERLAY="/usr/local/portage" in /etc/portage/make.conf
- aus /usr/portage/app-foo/bar-1.0.0.ebuild nach
/usr/local/portage/app-foo/bar-1.0.0.ebuild kopiert und geändert
- digest/manifest gebaut
- # echo "meins" > /usr/local/portage/profiles/repo_name

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..

Umd die oben gewünschte generelle Maskierung zu realisieren habe ich
folgendes versucht:

# 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

... aber: es funktioniert wie gewollt! und "eix" zeigt das sogar richtig
an..

Wenn ich diese [un]mask statt im profile Overlay in die
/etc/portage/package.[un]mask schreibe, dann geht's auch ohen Warnung
und auch korrekt...

In portage(5) steht:
  ..
  Repository Constraints
    Atoms  with  repository constraints have a '::' separator appended
    to the right side, followed by a repository name. Each repository
    name should correspond to the value of a repo_name entry from one
    of the repositories that is configured via the PORTDIR or
    PORTDIR_OVERLAY variables (see make.conf(5)).
  ..

also ist das doch eigentlich doch ein "valid atom", oder nicht..?

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 ;-)

ach so ja .. =sys-app/portage-2.2.7 ...

Meinungen dazu..?

Danke
  Christian



Reply | Threaded
Open this post in threaded view
|

Re: Bug in Portage oder "PEBCAC"..?

assabajanischer_hinterwaeldler
du kannst unterbinden, dass eine neue version mittels rsync
syncronisiert wird. dadurch werden keine neueren version von einem paket
mehr bezogen.
dazu muss folgendes in der make.conf vorhanden sein:
PORTAGE_RSYNC_EXTRA_OPTS="--exclude-from=/etc/portage/rsync_excludes"

alle dort aufgefuehrten dateien, werden nicht mehr synronisiert.
dabei wird 1 paket pro zeile definiert, wobei auch wildcards erlaubt
sind.
leider muss diese datei pro rechner verwaltet werden und kann meines
wissens nach nicht direkt im overlay hinterlegt werden.

soll das ganze doch direkt ueber das overlay verwaltet werden, hilft
wohl nur ein skript, dass automatisch die version im overlay anpasst.

nachdem ich grad nochmal nachgesehen habe, sind diese informationen auch
in der doku enthalten:
http://www.gentoo.de/doc/de/handbook/handbook-x86.xml?part=3&chap=5

hoff, dass entspricht dem, was du dir vorstellst

gruss
martin

Reply | Threaded
Open this post in threaded view
|

Re: Bug in Portage oder "PEBCAC"..?

Luis Ressel
Ich könnte mir vorstellen, dass irgendwas à la
echo "x/y::gentoo > overlay/profiles/package.mask" funktioniert.

Gruß,
Luis

signature.asc (985 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Bug in Portage oder "PEBCAC"..?

Luis Ressel
Entschuldige bitte, hatte die ursprüngliche Mail nur überflogen...

signature.asc (985 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Bug in Portage oder "PEBCAC"..?

Johann Schmitz (ercpe)
In reply to this post by Christian Bricart
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Moinsen,

> 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).

> # 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.

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.

> ... 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.

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

Johann.



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSivQFAAoJEKCEBkJ3xQHt6fUIAIL8uro/b5aCfyct/N6hdgXc
TIjKcPCf377xuXNhHYghPus8g1jx8xub+qkg1UEGQxzFCFTBZ5kZVD/XnGy7wPQD
FRapwMqbQ6mYeaVNwByID/I6qEStkoBHlu1fWUGwUXCt+1UvTipqpaJoor8DYEZp
Ra9R2vBXyw0uSni3kCdmMxtRI/qGiSR+DjobaveL9e2O+sVUvlSdbsctqHb89o/l
0fHJ3xlis8H1bvde2GEsGaEKwoDuF6meahmPnCpMAGQUlsc5xmrQSXnPnnzDqe2p
LtRadajttpeR4phD3qNslpT1yO1ma1FqPFTC0QO/I1yMC3WM2U72kLaXV3Wc5LU=
=arft
-----END PGP SIGNATURE-----

Reply | Threaded
Open this post in threaded view
|

Re: Bug in Portage oder "PEBCAC"..?

Christian Bricart
-----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-----

Reply | Threaded
Open this post in threaded view
|

Re: Bug in Portage oder "PEBCAC"..?

Johann Schmitz (ercpe)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 19/11/13 19:38, Christian Bricart wrote:
> 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..  ;)

Ein Overlay übersteuert ja auch den Tree, wie das Beispiel mit dem
Versions-Mask zeigt.

> 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..

Ich habe im #gentoo-dev Channel gefragt: Es ist nicht in der PMS,
daher kannst du es nicht benutzen. Es *kann* so implementiert sein
(siehe eix), muss aber nicht.

Evtl. bring das anheben des profile-format in der layout.conf deines
Overlays was. Wobei du da vermutlich auf eapi-5-progress gehen müsstest.
Wenn du das machst, wird aber jeder Bug-Report direkt als INVALID
geclosed bevor du nicht auf eine stabile EAPI gegangen bist!

> 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..

Aaah. Daher weht der Wind :)
Aus Erfahrung kann ich dir nur davon abraten. Auf der Arbeit verwenden
wir ausschließlich Gentoo und ziemlich schnell kam auch die Idee mit
einem Overlay auf um 0day Version Bumps aus dem Weg zu gehen und
"erprobte" (oder auch: hoffnungslos veraltete) Pakete installieren zu
können. Wir haben dazu von den wichtigsten Paketen -r999 angelegt und
alle anderen Version gemasked. Das hatte direkt mehrere Nachteile:

- - Man wusste nachher nicht mehr, aus welcher Version die -r999
ursprünglich hervor gegangen ist. Es sei denn, man hat eine Liste
gepflegt.
- - Wenn sich keiner nonstop drum kümmert, bleiben die Systeme auf
alten, verwundbaren Versionen zurück
- - Nach und nach wandern mehr und mehr Pakete vom Tree ins Overlay aus
Abhängigkeit zu anderen Paketen. Wer einmal ein PHP auf einer
bestimmten Version halten will, merkt schnell welch Rattenschwanz an
Dependencies da dran hängt. Nicht umsonst haben wir Rolling Releases
und geben bis höchstens 1 Jahre eine "softe" Garantie, dass du dein
System weitestgehend schmerzfrei updaten kannst.

Im Endeffekt ist es einfacher und stressfreier die Systeme alle paar
Monate mit World Update auf latest zu bringen als mit einem Overlay zu
hantieren.


> 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

Auch hier kann ich aus schmerzhafter Erfahrung sagen, das ein patchen
in den Ebuilds früher oder später zu Problem führt. Meistens ist es
besser includes oder ähnliches zu deployen.


Gruß,
Johann

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSi7YSAAoJEKCEBkJ3xQHtXUQIAKKYfNT/CbT4TlIp6dRQXSmi
RYOirnGTxRBi4SJTJDIpP05Nl2SLhwazd1Bw33z08QfpipT7xf8XcV4EpkLlzpTQ
iKrY8h+/4TyU3MD3i2DnoUnCkhFZgXU9/eh5qv6s9zO/kmEXq+mIWRVSWX8Z9eiU
zIjO8Ls2/+jAAfbTrQHyIF4ll8zW6bITuUIp5mw0ExQQbPrj16seVg4AppjCcLr+
ulFFK0TiG7p8ZSm7BCmalRGNhHAqC9sLTxtYgpX7OaPwRWwEiuceIZtKybktKXQ2
D493Jb4wD+lou2fAUkKODzdTF/lRzeWY4VmwsD/zq6s5Ji37Xf5viG9g+FNGjEE=
=QSs8
-----END PGP SIGNATURE-----

Reply | Threaded
Open this post in threaded view
|

Re: Bug in Portage oder "PEBCAC"..?

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

Am 19.11.2013 20:03, schrieb Johann Schmitz (ercpe):

> On 19/11/13 19:38, Christian Bricart wrote: [..] Ich habe im
> #gentoo-dev Channel gefragt: Es ist nicht in der PMS, daher kannst
> du es nicht benutzen. Es *kann* so implementiert sein (siehe eix),
> muss aber nicht.
>
> Evtl. bring das anheben des profile-format in der layout.conf
> deines Overlays was. Wobei du da vermutlich auf eapi-5-progress
> gehen müsstest. Wenn du das machst, wird aber jeder Bug-Report
> direkt als INVALID geclosed bevor du nicht auf eine stabile EAPI
> gegangen bist!

wenn ich das im *Overlay* mache, dann kann ich doch eh keinen Bug
dagegen filen ;) oder wirkt sich das dann auch auf den main tree aus?

> [..] Im Endeffekt ist es einfacher und stressfreier die Systeme
> alle paar Monate mit World Update auf latest zu bringen als mit
> einem Overlay zu hantieren.

zuhause und auf meinen roots?: ja - mindestens wöchentlich manche
Systeme auf ~arch auch täglich..
im kommerziellen Umfeld..?: -ENOT_INVENTED_HERE

Grüsse
  Christian

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEARECAAYFAlKL1oQACgkQDTcHuUk6x7u4ggCg4utTYbOIsCunVioN9d7jZTjp
NFwAoNh0+IWh0NbjPiCuUwS54p+hMHxP
=fsgV
-----END PGP SIGNATURE-----