1 |
On Thu, 2009-04-02 at 22:22 +0200, Fabian Groffen wrote: |
2 |
[snip] |
3 |
> |
4 |
> I'm a bit concerned about the design of things here. |
5 |
> |
6 |
> Initially, we had "cross-prefix", where Portage's EPREFIX could be |
7 |
> changed at runtime. This means Portage could "manage" another prefix, |
8 |
> ideally meant to clone -- bootstrap using an existing Prefix from a |
9 |
> location where you don't want to have it (read-only CD?). |
10 |
> I don't know how far this actually got, but I know Portage does |
11 |
> cross-prefix some things if you have EPREFIX set. |
12 |
|
13 |
Hm - no. What you describe works out of the box i think. the portage in |
14 |
prefix-launcher does all this. Cross-prefix added the capability to |
15 |
(while managing EPREFIX) merge into BPREFIX. This works only for DEPEND. |
16 |
|
17 |
prefix-chaining does nearly the same as cross-prefix, and the only user |
18 |
visible difference is, that portage can not merge DEPENDs into BPREFIX. |
19 |
that functionality made the portage patch for it a few times bigger. |
20 |
also haubi seems to feel that merging to BPREFIX is somewhat wrong, so i |
21 |
think prefix-chaining is the "better" cross-prefix. |
22 |
|
23 |
Let me bring an example: if xx DEPENDed on yy and RDEPENDed on zz, |
24 |
emerge xx would result in: |
25 |
|
26 |
normal: |
27 |
xx, yy, zz merged in EPREFIX, BPREFIX may be used for some |
28 |
executables, since it is in PATH (set by portage via |
29 |
DEFAULT_PATH). |
30 |
|
31 |
cross-prefix: |
32 |
xx and zz merged into EPREFIX, yy merged into BPREFIX |
33 |
executables may be taken from either EPREFIX or BPREFIX, |
34 |
since both are set. there is no possibility to install |
35 |
portage in a "child" EPREFIX, since this would make it |
36 |
forget about what was the BPREFIX (thats where i want to |
37 |
take DEPENDs from). |
38 |
|
39 |
prefix-chaining: |
40 |
xx merger in EPREFIX. yy and zz depends on settings in |
41 |
make.conf if DEPEND and RDEPEND would both be set to be |
42 |
chained, both would be taken from a chained prefix |
43 |
(attention: not BPREFIX, since i'm able to have a local |
44 |
portage, which still knows about "parent" prefixes). If |
45 |
they are not installed in any of the (possibly multiple) |
46 |
parent prefixes, portage tries to install them locally. |
47 |
If one of them is masked for the current ARCH/profile, |
48 |
portage will refuse to install the package. (as opposed |
49 |
to cross-prefix, where portage (for DEPENDs only) would |
50 |
allow to merge the package into BPREFIX if it is unmasked |
51 |
there. |
52 |
|
53 |
> |
54 |
> For this |
55 |
> EPREFIX became the *Target* Prefix, and |
56 |
> BPREFIX became the *Build* Prefix, as in from the called Portage |
57 |
> That means Portage will always look for stuff it works with (like bash, |
58 |
> sed, etc.) from its own Prefix (BPREFIX), and just operate on stuff |
59 |
> (vdb, install location, etc.) in its EPREFIX. Normally these two are |
60 |
> the same. |
61 |
> |
62 |
|
63 |
yep, right. |
64 |
|
65 |
> |
66 |
> Now your chaining patches. |
67 |
> |
68 |
> Apparently you take the total opposite direction now, where you first |
69 |
> have a Portage in EPREFIX (how you got it is questionable), and within |
70 |
> this Portage you expect it to take stuff it works with (bash, sed) from |
71 |
> a different location, let's call it CPREFIX. |
72 |
|
73 |
hm. you're partially right here. _if_ i install a portage instance in |
74 |
EPREFIX (which i don't need to - especially when for example merging |
75 |
into a "cross" prefix (interix -> winnt comes to my mind again ;)), |
76 |
where i want only things compiled for $CHOST), then i'm taking things |
77 |
from any parent prefix. but i think this is ok, because at least one of |
78 |
the parent prefixes (which are guaranteed to be in path) _has_ to have |
79 |
all this, since it has to be a fully fledged prefix (or maybe gentoo |
80 |
linux at EROOT=/ at some point.). The only point where i had to change |
81 |
things regarding this was the bash/mv issue introduced lately. i solved |
82 |
this via the ebuild where i symlink bash and mv to the currently |
83 |
available bash/mv - if you bootstrap right, this _has_ to be the bash |
84 |
and mv from the local prefix - otherwise an emerge -e world was missing. |
85 |
if it is a chained prefix, the tools from any parent are used - which i |
86 |
think is ok. |
87 |
the other thing i recently (yesterday) patched was synching. for that i |
88 |
introduced a little helper function, allowing to take required exes from |
89 |
a parent readonly prefix too, but the default is still EPREFIX - i just |
90 |
added some fallback. also, this can _not_ take executables from |
91 |
_somewhere_ but only from EPREFIX, and the well known readonly prefixes. |
92 |
so if there are no readonly prefixes, behaviour is exactly the same. |
93 |
|
94 |
> |
95 |
> While this is a different approach, it just conflicts with the first |
96 |
> approach, which is implemented and effectuated throughout the tree. |
97 |
> |
98 |
> I see your patches affecting multiple places where you revert our |
99 |
> assumption that Portage should always take stuff from it's own Prefix. |
100 |
> In short, I'm not happy with that. I keep asking myself, and now to |
101 |
> you, why one would want to have a Portage instance that is crippled in |
102 |
> the sense that it is not self-sufficient, and has to rely for the most |
103 |
> critical things on "external" binaries. In other words, what was wrong |
104 |
> with the initial approach of cross-prefix, which is very similar to how |
105 |
> cross-compiling (with root) works? |
106 |
|
107 |
as i said above, cross-prefix was exactly the same, except that portage |
108 |
could merge into BPREFIX (and that it was impossible to merge portage |
109 |
into EPREFIX without breaking it (because this portage would not have |
110 |
known about the "parent" anymore)). prefix-chaining simply works the |
111 |
other way round - each EPREFIX knows it's parents (always, regarless of |
112 |
localness of portage), as opposed to cross-prefix wher you had to tell |
113 |
portage "this is your child, merge there". as for paths beeing fixed to |
114 |
EPREFIX, both are the same. |
115 |
|
116 |
> |
117 |
> I don't want to kill all of your work, but I do want to make clear to |
118 |
> you why I am so hesitant for all of your changes. Conceptually, I |
119 |
> believe cross-prefix was sound and clear. Now this prefix-chaining is |
120 |
> like a whole new world that seemingly has some dirty concepts that I |
121 |
> find hard to accept. |
122 |
> |
123 |
|
124 |
hehe. haubi and me spent a reasonable amout of time discussing all this, |
125 |
and we're pretty sure that this is a very good (if not the best) |
126 |
approach to solving what we're trying to do (and what we require, of |
127 |
course). the cross-prefix thing was a _really_ big and nearly |
128 |
unmaintainable patch, since it chained the way a ROOT worked - and hell |
129 |
yes, root is a word that is used often in portage code ;). |
130 |
prefix-chaining is much slimer, and it is nearly the same. |
131 |
|
132 |
actually, one can do the same with chaining as with cross-prefix, by |
133 |
giving prefix-chain-setup the --minimal flag, which makes it omit |
134 |
portage and gcc-config, and just merge baselayout and |
135 |
prefix-chain-utils. |
136 |
|
137 |
sorry - i'm not too good in explaining - i'm just jumping around too |
138 |
much. maybe haubi can further clearyfy all this a little? thanks... |
139 |
|
140 |
Cheers, Markus |
141 |
|
142 |
> |
143 |
> |