1 |
2009/7/8 Markus Duft <mduft@g.o>: |
2 |
> Also I couldn't think of a real use case where this would be absolutely |
3 |
> necessary. i admit that I'm slightly influenced by the use case here at |
4 |
> our company: we have one "system prefix", building upon that we have a |
5 |
> "framework prefix" and again, building upon that the "application |
6 |
> prefix". |
7 |
> the "system prefix" is shared upon all "framework prefixes". each |
8 |
> "framework prefix" is used by multiple "application prefixed" each of |
9 |
> them containing one final application. So we're perfect with a one |
10 |
> dimensional chain. (the "one dimensional" is from the POV of each |
11 |
> involved prefix, of course. looking at the whole picture we have this: |
12 |
> |
13 |
> s1 |
14 |
> | |
15 |
> +--+--+ |
16 |
> f1 f2 f3 |
17 |
> | | +--+ |
18 |
> | | | | |
19 |
> a1 a2 a3 a4 |
20 |
> |
21 |
> so, none of the applications (a1-a4) know of each other. those prefixes |
22 |
> are unrelated and each application has a one dimensional direct chain to |
23 |
> s1). |
24 |
> |
25 |
> could you describe your current and desired setup a little closer? would |
26 |
> be interesting... :) |
27 |
|
28 |
My intention is to use portage for easy installation of software, not |
29 |
supported by the IT department, at my university. The policy for such |
30 |
software is that each should be installed in its own directory, and |
31 |
that old versions should be kept for some time after an upgrade. To |
32 |
satisfy this policy I hope to be able to use chained prefixes. The |
33 |
idea is to build up a more or less minimal gentoo prefix installation |
34 |
with prefix chaining enabled, and to that add a bunch of scripts that |
35 |
wraps around portage for installing application in sush a way that |
36 |
each and every dependency is installed in its own prefix, and |
37 |
registered with the university software packaging system. |
38 |
|
39 |
I also would like to make use of dependencies from the host system |
40 |
provided by the OS (i.e. not manually installed by other users with |
41 |
right to install software) to avoid building libraries that already |
42 |
exist on the system. Finally te applications installed should be |
43 |
usable from the host OS without having to set additinal variables, |
44 |
which means that binaries has to be linked with -rpath to find the |
45 |
right libraries on runtime. |
46 |
|
47 |
So in more detail the set up will be (where $PHC is the root of the |
48 |
phc (software installation point) |
49 |
|
50 |
$PHC/gentoo-prefix -- gentoo prefix installation with portage, and set |
51 |
up to recognize libraries on the host OS (via |
52 |
/etc/portage/profile/package.provided) |
53 |
$PHC/${P} - minimal prefix which inherits the prefix of all immediate |
54 |
dependencies to the packages ${P} and contains ${P} emerged ans well |
55 |
as some control files for the university software packaging system. |
56 |
|
57 |
There will be other drectories in $PHC, possible ones with conflicting |
58 |
names, and the portage wrapper I'm writing will have to have a |
59 |
strategy for that as well. I'm incline to let the prtage wrapper be |
60 |
aware of any prefixes created with it, and trhe ebauilds installed in |
61 |
them to allow it to setup prefix chains including already built |
62 |
dependencies of earlier versions than the ones in the current portage |
63 |
tree, but I'm not sure if I'll bother since it mmay be good to build |
64 |
the latest version of the dependencies anyway. |
65 |
|
66 |
|
67 |
> |
68 |
>> |
69 |
>> I'm tempted to try to change this myself, but before I do I'd like to |
70 |
>> get some input on why it was made the way it is. A few things I've |
71 |
>> noticed about the chaining prefixes as they are now: |
72 |
>> 1) the prefixes are linked in with no particular order in portage, but |
73 |
>> follows the chain in /etc/profile. I'm not sure if the portage order |
74 |
>> makes any difference as I've very little experience with this yet, but |
75 |
>> I think that those prefixes should be included in order as well. |
76 |
> |
77 |
> what do you mean by "linked in with no particular order in portage"? |
78 |
> since the chaining is a strictly one dimensional chain (at least |
79 |
> ATM :)), the ordering is implicit. the top most prefix (it may or may |
80 |
> not contain it's own portage btw.) reads it's config, finds a readonly |
81 |
> prefix, reads that one's config, finds another one, etc. this way the |
82 |
> whole chain of configurations is built up during portage startup. hope |
83 |
> that was clear...? |
84 |
|
85 |
But aren't the search paths set in the PORTAGE_READONLY_EPREFIXS |
86 |
variable joined from a map, in which case the order the keys are |
87 |
entered to the map is not guaranteed to be the order the keys are |
88 |
joined? So while the prefixes are added to the map in order, the order |
89 |
is forgotten immediately, or am I missing something? |
90 |
|
91 |
> |
92 |
>> |
93 |
>> My idea on how branching prefixes could be done is similar to how the |
94 |
>> chaining prefixes work now, but with a little extra logic required to |
95 |
>> not include the same prefix more than once. |
96 |
> |
97 |
> so you want something like this?: |
98 |
> |
99 |
> a |
100 |
> | |
101 |
> +--+--+ |
102 |
> b c d |
103 |
> +--+ | |
104 |
> e | |
105 |
> +--+ |
106 |
> f |
107 |
> |
108 |
> where f inherits from *all* prefixes? |
109 |
|
110 |
Basically yes, but also, in the f config file it could include a |
111 |
reference to b as well. I'm not yet sure of what would be the best |
112 |
search order for joining paths, but I'm thinking standard left to rigt |
113 |
search order, so that the first prefix satisfied is searched first, |
114 |
and after thinking about it for a wile, I believe that a depth first |
115 |
search is in order, so that if f specifies prefixes "d e" and e "c b" |
116 |
it would first search d then a then e then c and finally b. |
117 |
|
118 |
> i guess there is a reason why |
119 |
> modern OO languages forbid multiple inheritance - it's a headache! :) |
120 |
> And still those languages are quite popular, and seemingly don't lack |
121 |
> any obvious big features. one of them is java, so lack of multiple |
122 |
> inheritance can't really hurt, can it? |
123 |
|
124 |
While I could probably do without multiple inheritnce, (for instance a |
125 |
very deep chain) it would add extra difficulties, in the event that a |
126 |
package were to be removed, and also increas the risk of linking to |
127 |
the wrong version, since a chain could have multiple version of the |
128 |
same package, as if a new package were installed, it would end up at |
129 |
the top of the chain, and the old package would still be inside the |
130 |
chain, whereas with branching prefixes I would never have more than |
131 |
one version of the same package in the chain (with possible exception |
132 |
of packages in the base prefix installation, or packages provided by |
133 |
the host OS via package.provided) |
134 |
|
135 |
Or I could cain each package only with the base prefix, and setup |
136 |
paths manually to other child prefixes, and add their packages to |
137 |
package.provided, but that feels more hackerish than having proper |
138 |
branched prefixes. |
139 |
|
140 |
> |
141 |
>> I think that changing the current inclusion to a breath first tree |
142 |
>> traversal with marking of already visited prefixes should work for the |
143 |
>> portage tree. When it comes to the environment I really don't see why |
144 |
>> it is made from /etc/profile recursively currently. Wouldn't it make |
145 |
>> more sence to have env-update simply source the profile.env of the |
146 |
>> parent prefix, and poin it with the env.d at the current level, and |
147 |
>> possible include a utility for recursively doing env-update in several |
148 |
>> prefix-chains if needed. At least that's the way I think would work |
149 |
>> the best when it comes to multiple readonly prefixes. Is there any |
150 |
>> reason why this wouldn't work? (Other than the fact that this would be |
151 |
>> a depth first inclusion instead of a breath first inclusion as I |
152 |
>> suggested for portage, if the order matters.) |
153 |
> |
154 |
> phew. IIRC it took me a few days to get that right in my head only, |
155 |
> without implementing it (implementation was done in a few minutes |
156 |
> actually) - thinking back to the problems i faced, the only one that |
157 |
> jumps to my mind right now was that a patched env-update would not |
158 |
> suffice because any of the parent prefix can change without us getting |
159 |
> any note of it. (however of course there are more problems of that kind, |
160 |
> like the parent prefix not knowing us, so he won't prevent unmerging |
161 |
> libraries the child prefix needs). |
162 |
|
163 |
Well, for my usecase it would be sufficient to have to run env-update |
164 |
again if I change a parent prefix. That is what envc-update is for |
165 |
anyway, take new changes into account, and it could be made enough |
166 |
torun env-update in one prefix, if env-update is made to do full |
167 |
recursion (as opposed to just ask the parents, which might not have |
168 |
ran env-update yet). |
169 |
|
170 |
> also, changing the type of inheritance (RDEPEND, DEPEND, PDEPEND) would |
171 |
> require an env-update call - one thing that for sure is forgotten at |
172 |
> least half of the time. |
173 |
|
174 |
well, I just say that I think it is cleaner than putting it in |
175 |
/etc/profile, which may be altered in the diferent prefixes, and |
176 |
possible could be made to break the prefix chain. If it were in |
177 |
/etc/profile.env on the other hand that would be OK, but I'd still be |
178 |
in favor of the environment not changing unless I manually run |
179 |
env-update. |
180 |
|
181 |
/Viktor |