1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA1 |
3 |
|
4 |
Am 19.11.2013 06:15, schrieb Johann Schmitz: |
5 |
> Moinsen, |
6 |
|
7 |
tach auch, |
8 |
|
9 |
> |
10 |
>> soweit so gut - emerge an sich funktioniert schon mal korrekt |
11 |
>> und meine Version aus dem local Overlay überstimmt die selbe |
12 |
>> Version aus dem main-Tree.. |
13 |
> |
14 |
> Bei gleichen Version wird das Paket aus dem Overlay verwendet, da |
15 |
> der Inhalt deiner PORTDIR_OVERLAY das PORTDIR überlagert (wie der |
16 |
> Name schon sagt). |
17 |
|
18 |
genau - halt bitte diesen Gedanken fest, dass: |
19 |
"PORTDIR_OVERLAY das PORTDIR überlagert (wie der Name schon sagt)." ;) |
20 |
|
21 |
> |
22 |
>> # echo "app-foo/bar::gentoo" > |
23 |
>> /usr/local/portage/profiles/package.mask # echo |
24 |
>> "app-foo/bar::meins" > |
25 |
>> /usr/local/portage/profiles/package.unmask |
26 |
> |
27 |
>> jetzt bekomme ich bei *jedem* emerge die Warnung(en): |
28 |
> |
29 |
>> --- Invalid atom in /usr/local/portage/profiles/package.mask: |
30 |
>> app-foo/bar::gentoo --- Invalid atom in |
31 |
>> /usr/local/portage/profiles/package.unmask: app-foo/bar::meins |
32 |
> |
33 |
> Weil afaik in der package.mask keine Repository Constraints |
34 |
> erlaubt sind. In der Manpage steht bei package.mask: "one DEPEND |
35 |
> atom per line". Ein DEPEND besteht aus CP und Version/(Sub)Slot; |
36 |
> kein repository. Dort wird zwar auch von atoms als Einträge |
37 |
> geredet, mir ist aber noch nie ein Repository in *.mask |
38 |
> untergekommen. |
39 |
|
40 |
..weil es innerhalb vom Main-Tree (Repository: "gentoo") auch keinen |
41 |
Sinn macht, weil man: |
42 |
a) vom Main-Tree aus nicht alle beliebigen sonst noch benamte Overlays |
43 |
der Welt kennen kann |
44 |
b) es keinen Sinn macht, sich als Main-Tree über ein Overlay |
45 |
hinwegzusetzen ;-) weil der Sinn ist ja genau eben andersrum.. |
46 |
|
47 |
und ich müsste auch erstmal in den diversen Laymans schauen, ob ich |
48 |
überhaupt ein Overlay finde, welches package.{un}mask mitbringt ;) |
49 |
|
50 |
> |
51 |
> Wenn man darüber nachdenkt, macht es auch Sinn: |
52 |
> |
53 |
> - Vom Tree aus "ignorieren" wir Overlays. Wir versuchen zwar |
54 |
> weitestgehend kompatibel zu sein, aber am Ende des Tages ist der |
55 |
> Overlay Maintainer für die Kompatibilität verantwortlich. - In |
56 |
> einem Overlay übersteuert die gleiche Version die aus dem Tree |
57 |
> (weil in PORTDIR_OVERLAY) - In Overlay A Ebuilds aus Overlay B |
58 |
> masken ist schon ein sehr außergewöhnlicher Spezialfall. Es gibt |
59 |
> sicherliche Use-Cases aber im Zweifelsfall muss der User |
60 |
> entscheiden was er installieren will. |
61 |
|
62 |
...kommen wir nun zum festgehaltenen Gedanken zurück: |
63 |
Wenn ein Overlay sich dadurch auszeichnet, komplett transluzent über |
64 |
dem Main-Tree zu liegen, dann muss ich *jede* Datei dort mit *meinem* |
65 |
Inhalt mit einer Datei an der selben Stelle im Baum überlagern |
66 |
können.. ;) |
67 |
|
68 |
> |
69 |
>> ... aber: es funktioniert wie gewollt! und "eix" zeigt das sogar |
70 |
>> richtig an.. |
71 |
> |
72 |
> Das kommt glaube ich eher durch eine weite Auslegung der PMS. Ich |
73 |
> habe da jetzt gerade nicht reingeschaut (zu wenig Kaffee), ich |
74 |
> könnte mir aber vorstellen, dass das nicht explizit definiert ist |
75 |
> ob RC's erlaubt sind. |
76 |
|
77 |
die Möglichkeit von Repository-/Overlay-Namen sind noch nicht so alt.. |
78 |
kann sein, dass es einfach nicht konsistent durch die Tools gezogen |
79 |
wurde(?) oder ich stimme dir zu, dass eix evtl. die PMS schon weiter |
80 |
(oder falsch?) auslegt. |
81 |
aaaber: ich habe eix nur als Beispiel genannt um die einfache |
82 |
Visualisierung alle Möglichkeiten zu bekommen. |
83 |
Natürlich kommt aus dem "emerge -v foo/bar" auch die gewünschte |
84 |
Version raus ;-) Nur die Warnung stört halt.. |
85 |
Also irgendwie isses dann doch schon drin.. |
86 |
|
87 |
> |
88 |
>> Also die Warnungen beomme ich ja weg, indem ich in die overlay |
89 |
>> package.mask nur "app-foo/bar" (ohne ::gentoo) reinschreibe und |
90 |
>> dann in *jedem* lokalen /etc/portage/package.unmask dann |
91 |
>> "app-foo/bar::meins" wieder freischalte.. aber das ist ja |
92 |
>> unschön ;-) |
93 |
> |
94 |
> Entweder das, oder du machst es über die Versionen: |
95 |
> |
96 |
> <app-foo/bar-1.0 |
97 |
>> app-foo/bar-1.0 |
98 |
> |
99 |
> Das haut dir alle Versionen ungleich 1.0 raus, und die 1.0 in |
100 |
> deinem Overlay wird ja sowieso vor der Tree-Version genommen. |
101 |
|
102 |
es war eben genau der Hintergrund *jede* Version (sprich: also eben |
103 |
*ohne* $PV) aus einem bestimmten Tree zu masken um nicht drauf |
104 |
achtzugeben, wann der Main-Tree das Overlay durch höhere Version |
105 |
überstimmt (und dann gepaart mit Unachtsamkeit die falsche Version |
106 |
auf's System kommt - die dann zugegebenermassen neuer ist, aber die |
107 |
Änderungen aus dem Overlay nicht mitdrin hat) |
108 |
|
109 |
> Sauberer fände ich es allerdings, ein -r1 draus zu machen und ggf. |
110 |
> Patches auf b.g.o. einzureichen, damit alle was davon haben :) |
111 |
|
112 |
..das hält ja auch nur bis im Main-Tree die -r2 auftaucht ;) |
113 |
|
114 |
und zum Thema b.g.o: |
115 |
|
116 |
der Hintergrund ist eine "Mass-Deployment-Umgebung", welche bei |
117 |
einigen Paketen (rein nur) für diese Umgebung sinnvolle |
118 |
Erweiterungen/Modifikationen mitbringt. z.B. vorgefertigte |
119 |
Konfigurationsdateien (/etc/conf.d/..), oder irgendwas anderes unter |
120 |
${FILESDIR}/.. im angepassten ebuild |
121 |
|
122 |
Das durch die Maskierung und De-Maskierung zu lösende Problem dabei |
123 |
ist, dass oben genannte: es soll vermieden werden, dass durch |
124 |
Unachtsamkeit unmodifizierte Pakete installiert werden. |
125 |
Oder anders - Installation ist folgendermassen: |
126 |
- - (eigenes) Stage4 auspacken |
127 |
(- local Overlay ist dort vorkonfiguriert und kommt aus zentralem |
128 |
GIT-Repo) |
129 |
- - Pakete werden prinzipiell aus dem Main-Tree installiert.. |
130 |
- - ..oder sind (bei »kritischen« Paketen) "abgesegnete" ebuilds |
131 |
und das ganze "zentral steuerbar" vom Overlay-Mantainer ohne |
132 |
Notwendigkeit immer wieder in jede einzelne lokale /etc/portage/ |
133 |
eingreifen zu müssen.. |
134 |
|
135 |
(und um es vorweg zu nehmen - ja.. ich kenne [und nutze] Puppet und |
136 |
Konsorten ;-) [hier] keine Option ;) ) |
137 |
|
138 |
Danke auf jeden Fall schonmal |
139 |
Christian |
140 |
-----BEGIN PGP SIGNATURE----- |
141 |
Version: GnuPG v2.0.22 (GNU/Linux) |
142 |
|
143 |
iEYEARECAAYFAlKLsCMACgkQDTcHuUk6x7uUFACcDNHKiHRqzosYuBIUKlUNNevp |
144 |
x3oAoKL77+3ns/mYTBqFfxonGVXMkdAw |
145 |
=tpCV |
146 |
-----END PGP SIGNATURE----- |