| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
On 19/11/13 19:38, Christian Bricart wrote: |
| 5 |
> Wenn ein Overlay sich dadurch auszeichnet, komplett transluzent |
| 6 |
> über dem Main-Tree zu liegen, dann muss ich *jede* Datei dort mit |
| 7 |
> *meinem* Inhalt mit einer Datei an der selben Stelle im Baum |
| 8 |
> überlagern können.. ;) |
| 9 |
|
| 10 |
Ein Overlay übersteuert ja auch den Tree, wie das Beispiel mit dem |
| 11 |
Versions-Mask zeigt. |
| 12 |
|
| 13 |
> kann sein, dass es einfach nicht konsistent durch die Tools gezogen |
| 14 |
> wurde(?) oder ich stimme dir zu, dass eix evtl. die PMS schon |
| 15 |
> weiter (oder falsch?) auslegt. aaaber: ich habe eix nur als |
| 16 |
> Beispiel genannt um die einfache Visualisierung alle Möglichkeiten |
| 17 |
> zu bekommen. Natürlich kommt aus dem "emerge -v foo/bar" auch die |
| 18 |
> gewünschte Version raus ;-) Nur die Warnung stört halt.. Also |
| 19 |
> irgendwie isses dann doch schon drin.. |
| 20 |
|
| 21 |
Ich habe im #gentoo-dev Channel gefragt: Es ist nicht in der PMS, |
| 22 |
daher kannst du es nicht benutzen. Es *kann* so implementiert sein |
| 23 |
(siehe eix), muss aber nicht. |
| 24 |
|
| 25 |
Evtl. bring das anheben des profile-format in der layout.conf deines |
| 26 |
Overlays was. Wobei du da vermutlich auf eapi-5-progress gehen müsstest. |
| 27 |
Wenn du das machst, wird aber jeder Bug-Report direkt als INVALID |
| 28 |
geclosed bevor du nicht auf eine stabile EAPI gegangen bist! |
| 29 |
|
| 30 |
> Das durch die Maskierung und De-Maskierung zu lösende Problem dabei |
| 31 |
> ist, dass oben genannte: es soll vermieden werden, dass durch |
| 32 |
> Unachtsamkeit unmodifizierte Pakete installiert werden. Oder anders |
| 33 |
> - Installation ist folgendermassen: - (eigenes) Stage4 auspacken (- |
| 34 |
> local Overlay ist dort vorkonfiguriert und kommt aus zentralem |
| 35 |
> GIT-Repo) - Pakete werden prinzipiell aus dem Main-Tree |
| 36 |
> installiert.. - ..oder sind (bei »kritischen« Paketen) |
| 37 |
> "abgesegnete" ebuilds und das ganze "zentral steuerbar" vom |
| 38 |
> Overlay-Mantainer ohne Notwendigkeit immer wieder in jede einzelne |
| 39 |
> lokale /etc/portage/ eingreifen zu müssen.. |
| 40 |
|
| 41 |
Aaah. Daher weht der Wind :) |
| 42 |
Aus Erfahrung kann ich dir nur davon abraten. Auf der Arbeit verwenden |
| 43 |
wir ausschließlich Gentoo und ziemlich schnell kam auch die Idee mit |
| 44 |
einem Overlay auf um 0day Version Bumps aus dem Weg zu gehen und |
| 45 |
"erprobte" (oder auch: hoffnungslos veraltete) Pakete installieren zu |
| 46 |
können. Wir haben dazu von den wichtigsten Paketen -r999 angelegt und |
| 47 |
alle anderen Version gemasked. Das hatte direkt mehrere Nachteile: |
| 48 |
|
| 49 |
- - Man wusste nachher nicht mehr, aus welcher Version die -r999 |
| 50 |
ursprünglich hervor gegangen ist. Es sei denn, man hat eine Liste |
| 51 |
gepflegt. |
| 52 |
- - Wenn sich keiner nonstop drum kümmert, bleiben die Systeme auf |
| 53 |
alten, verwundbaren Versionen zurück |
| 54 |
- - Nach und nach wandern mehr und mehr Pakete vom Tree ins Overlay aus |
| 55 |
Abhängigkeit zu anderen Paketen. Wer einmal ein PHP auf einer |
| 56 |
bestimmten Version halten will, merkt schnell welch Rattenschwanz an |
| 57 |
Dependencies da dran hängt. Nicht umsonst haben wir Rolling Releases |
| 58 |
und geben bis höchstens 1 Jahre eine "softe" Garantie, dass du dein |
| 59 |
System weitestgehend schmerzfrei updaten kannst. |
| 60 |
|
| 61 |
Im Endeffekt ist es einfacher und stressfreier die Systeme alle paar |
| 62 |
Monate mit World Update auf latest zu bringen als mit einem Overlay zu |
| 63 |
hantieren. |
| 64 |
|
| 65 |
|
| 66 |
> der Hintergrund ist eine "Mass-Deployment-Umgebung", welche bei |
| 67 |
> einigen Paketen (rein nur) für diese Umgebung sinnvolle |
| 68 |
> Erweiterungen/Modifikationen mitbringt. z.B. vorgefertigte |
| 69 |
> Konfigurationsdateien (/etc/conf.d/..), oder irgendwas anderes |
| 70 |
> unter ${FILESDIR}/.. im angepassten ebuild |
| 71 |
|
| 72 |
Auch hier kann ich aus schmerzhafter Erfahrung sagen, das ein patchen |
| 73 |
in den Ebuilds früher oder später zu Problem führt. Meistens ist es |
| 74 |
besser includes oder ähnliches zu deployen. |
| 75 |
|
| 76 |
|
| 77 |
Gruß, |
| 78 |
Johann |
| 79 |
|
| 80 |
-----BEGIN PGP SIGNATURE----- |
| 81 |
Version: GnuPG v2.0.22 (GNU/Linux) |
| 82 |
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ |
| 83 |
|
| 84 |
iQEcBAEBAgAGBQJSi7YSAAoJEKCEBkJ3xQHtXUQIAKKYfNT/CbT4TlIp6dRQXSmi |
| 85 |
RYOirnGTxRBi4SJTJDIpP05Nl2SLhwazd1Bw33z08QfpipT7xf8XcV4EpkLlzpTQ |
| 86 |
iKrY8h+/4TyU3MD3i2DnoUnCkhFZgXU9/eh5qv6s9zO/kmEXq+mIWRVSWX8Z9eiU |
| 87 |
zIjO8Ls2/+jAAfbTrQHyIF4ll8zW6bITuUIp5mw0ExQQbPrj16seVg4AppjCcLr+ |
| 88 |
ulFFK0TiG7p8ZSm7BCmalRGNhHAqC9sLTxtYgpX7OaPwRWwEiuceIZtKybktKXQ2 |
| 89 |
D493Jb4wD+lou2fAUkKODzdTF/lRzeWY4VmwsD/zq6s5Ji37Xf5viG9g+FNGjEE= |
| 90 |
=QSs8 |
| 91 |
-----END PGP SIGNATURE----- |
Archives