* [gentoo-user-de] Bug in Portage oder "PEBCAC"..? @ 2013-11-18 21:23 Christian Bricart 2013-11-18 22:00 ` assabajanischer_hinterwaeldler 2013-11-19 5:15 ` Johann Schmitz 0 siblings, 2 replies; 8+ messages in thread From: Christian Bricart @ 2013-11-18 21:23 UTC (permalink / raw To: gentoo-user-de 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [gentoo-user-de] Bug in Portage oder "PEBCAC"..? 2013-11-18 21:23 [gentoo-user-de] Bug in Portage oder "PEBCAC"..? Christian Bricart @ 2013-11-18 22:00 ` assabajanischer_hinterwaeldler 2013-11-18 22:16 ` Luis Ressel 2013-11-19 5:15 ` Johann Schmitz 1 sibling, 1 reply; 8+ messages in thread From: assabajanischer_hinterwaeldler @ 2013-11-18 22:00 UTC (permalink / raw To: gentoo-user-de 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [gentoo-user-de] Bug in Portage oder "PEBCAC"..? 2013-11-18 22:00 ` assabajanischer_hinterwaeldler @ 2013-11-18 22:16 ` Luis Ressel 2013-11-18 22:20 ` Luis Ressel 0 siblings, 1 reply; 8+ messages in thread From: Luis Ressel @ 2013-11-18 22:16 UTC (permalink / raw To: gentoo-user-de [-- Attachment #1: Type: text/plain, Size: 129 bytes --] Ich könnte mir vorstellen, dass irgendwas à la echo "x/y::gentoo > overlay/profiles/package.mask" funktioniert. Gruß, Luis [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 966 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [gentoo-user-de] Bug in Portage oder "PEBCAC"..? 2013-11-18 22:16 ` Luis Ressel @ 2013-11-18 22:20 ` Luis Ressel 0 siblings, 0 replies; 8+ messages in thread From: Luis Ressel @ 2013-11-18 22:20 UTC (permalink / raw To: gentoo-user-de [-- Attachment #1: Type: text/plain, Size: 68 bytes --] Entschuldige bitte, hatte die ursprüngliche Mail nur überflogen... [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 966 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [gentoo-user-de] Bug in Portage oder "PEBCAC"..? 2013-11-18 21:23 [gentoo-user-de] Bug in Portage oder "PEBCAC"..? Christian Bricart 2013-11-18 22:00 ` assabajanischer_hinterwaeldler @ 2013-11-19 5:15 ` Johann Schmitz 2013-11-19 18:38 ` Christian Bricart 1 sibling, 1 reply; 8+ messages in thread From: Johann Schmitz @ 2013-11-19 5:15 UTC (permalink / raw To: gentoo-user-de -----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----- ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [gentoo-user-de] Bug in Portage oder "PEBCAC"..? 2013-11-19 5:15 ` Johann Schmitz @ 2013-11-19 18:38 ` Christian Bricart 2013-11-19 19:03 ` Johann Schmitz (ercpe) 0 siblings, 1 reply; 8+ messages in thread From: Christian Bricart @ 2013-11-19 18:38 UTC (permalink / raw To: gentoo-user-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----- ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [gentoo-user-de] Bug in Portage oder "PEBCAC"..? 2013-11-19 18:38 ` Christian Bricart @ 2013-11-19 19:03 ` Johann Schmitz (ercpe) 2013-11-19 21:22 ` Christian Bricart 0 siblings, 1 reply; 8+ messages in thread From: Johann Schmitz (ercpe) @ 2013-11-19 19:03 UTC (permalink / raw To: gentoo-user-de -----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----- ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [gentoo-user-de] Bug in Portage oder "PEBCAC"..? 2013-11-19 19:03 ` Johann Schmitz (ercpe) @ 2013-11-19 21:22 ` Christian Bricart 0 siblings, 0 replies; 8+ messages in thread From: Christian Bricart @ 2013-11-19 21:22 UTC (permalink / raw To: gentoo-user-de -----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----- ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2013-11-19 21:22 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-11-18 21:23 [gentoo-user-de] Bug in Portage oder "PEBCAC"..? Christian Bricart 2013-11-18 22:00 ` assabajanischer_hinterwaeldler 2013-11-18 22:16 ` Luis Ressel 2013-11-18 22:20 ` Luis Ressel 2013-11-19 5:15 ` Johann Schmitz 2013-11-19 18:38 ` Christian Bricart 2013-11-19 19:03 ` Johann Schmitz (ercpe) 2013-11-19 21:22 ` Christian Bricart
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox