Gentoo Archives: gentoo-alt

From: Markus Duft <mduft@g.o>
To: gentoo-alt@l.g.o
Subject: Re: [gentoo-alt] portage prefix chaining support
Date: Fri, 03 Apr 2009 07:06:29
Message-Id: 1238742279.9245.41.camel@localhost
In Reply to: Re: [gentoo-alt] portage prefix chaining support by Fabian Groffen
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 >

Replies

Subject Author
Re: [gentoo-alt] portage prefix chaining support Markus Duft <mduft@g.o>
Re: [gentoo-alt] portage prefix chaining support Fabian Groffen <grobian@g.o>