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
On Thu, 2009-04-02 at 22:22 +0200, Fabian Groffen wrote:
> > I'm a bit concerned about the design of things here. > > Initially, we had "cross-prefix", where Portage's EPREFIX could be > changed at runtime. This means Portage could "manage" another prefix, > ideally meant to clone -- bootstrap using an existing Prefix from a > location where you don't want to have it (read-only CD?). > I don't know how far this actually got, but I know Portage does > cross-prefix some things if you have EPREFIX set.
Hm - no. What you describe works out of the box i think. the portage in prefix-launcher does all this. Cross-prefix added the capability to (while managing EPREFIX) merge into BPREFIX. This works only for DEPEND. prefix-chaining does nearly the same as cross-prefix, and the only user visible difference is, that portage can not merge DEPENDs into BPREFIX. that functionality made the portage patch for it a few times bigger. also haubi seems to feel that merging to BPREFIX is somewhat wrong, so i think prefix-chaining is the "better" cross-prefix. Let me bring an example: if xx DEPENDed on yy and RDEPENDed on zz, emerge xx would result in: normal: xx, yy, zz merged in EPREFIX, BPREFIX may be used for some executables, since it is in PATH (set by portage via DEFAULT_PATH). cross-prefix: xx and zz merged into EPREFIX, yy merged into BPREFIX executables may be taken from either EPREFIX or BPREFIX, since both are set. there is no possibility to install portage in a "child" EPREFIX, since this would make it forget about what was the BPREFIX (thats where i want to take DEPENDs from). prefix-chaining: xx merger in EPREFIX. yy and zz depends on settings in make.conf if DEPEND and RDEPEND would both be set to be chained, both would be taken from a chained prefix (attention: not BPREFIX, since i'm able to have a local portage, which still knows about "parent" prefixes). If they are not installed in any of the (possibly multiple) parent prefixes, portage tries to install them locally. If one of them is masked for the current ARCH/profile, portage will refuse to install the package. (as opposed to cross-prefix, where portage (for DEPENDs only) would allow to merge the package into BPREFIX if it is unmasked there.
> > For this > EPREFIX became the *Target* Prefix, and > BPREFIX became the *Build* Prefix, as in from the called Portage > That means Portage will always look for stuff it works with (like bash, > sed, etc.) from its own Prefix (BPREFIX), and just operate on stuff > (vdb, install location, etc.) in its EPREFIX. Normally these two are > the same. >
yep, right.
> > Now your chaining patches. > > Apparently you take the total opposite direction now, where you first > have a Portage in EPREFIX (how you got it is questionable), and within > this Portage you expect it to take stuff it works with (bash, sed) from > a different location, let's call it CPREFIX.
hm. you're partially right here. _if_ i install a portage instance in EPREFIX (which i don't need to - especially when for example merging into a "cross" prefix (interix -> winnt comes to my mind again ;)), where i want only things compiled for $CHOST), then i'm taking things from any parent prefix. but i think this is ok, because at least one of the parent prefixes (which are guaranteed to be in path) _has_ to have all this, since it has to be a fully fledged prefix (or maybe gentoo linux at EROOT=/ at some point.). The only point where i had to change things regarding this was the bash/mv issue introduced lately. i solved this via the ebuild where i symlink bash and mv to the currently available bash/mv - if you bootstrap right, this _has_ to be the bash and mv from the local prefix - otherwise an emerge -e world was missing. if it is a chained prefix, the tools from any parent are used - which i think is ok. the other thing i recently (yesterday) patched was synching. for that i introduced a little helper function, allowing to take required exes from a parent readonly prefix too, but the default is still EPREFIX - i just added some fallback. also, this can _not_ take executables from _somewhere_ but only from EPREFIX, and the well known readonly prefixes. so if there are no readonly prefixes, behaviour is exactly the same.
> > While this is a different approach, it just conflicts with the first > approach, which is implemented and effectuated throughout the tree. > > I see your patches affecting multiple places where you revert our > assumption that Portage should always take stuff from it's own Prefix. > In short, I'm not happy with that. I keep asking myself, and now to > you, why one would want to have a Portage instance that is crippled in > the sense that it is not self-sufficient, and has to rely for the most > critical things on "external" binaries. In other words, what was wrong > with the initial approach of cross-prefix, which is very similar to how > cross-compiling (with root) works?
as i said above, cross-prefix was exactly the same, except that portage could merge into BPREFIX (and that it was impossible to merge portage into EPREFIX without breaking it (because this portage would not have known about the "parent" anymore)). prefix-chaining simply works the other way round - each EPREFIX knows it's parents (always, regarless of localness of portage), as opposed to cross-prefix wher you had to tell portage "this is your child, merge there". as for paths beeing fixed to EPREFIX, both are the same.
> > I don't want to kill all of your work, but I do want to make clear to > you why I am so hesitant for all of your changes. Conceptually, I > believe cross-prefix was sound and clear. Now this prefix-chaining is > like a whole new world that seemingly has some dirty concepts that I > find hard to accept. >
hehe. haubi and me spent a reasonable amout of time discussing all this, and we're pretty sure that this is a very good (if not the best) approach to solving what we're trying to do (and what we require, of course). the cross-prefix thing was a _really_ big and nearly unmaintainable patch, since it chained the way a ROOT worked - and hell yes, root is a word that is used often in portage code ;). prefix-chaining is much slimer, and it is nearly the same. actually, one can do the same with chaining as with cross-prefix, by giving prefix-chain-setup the --minimal flag, which makes it omit portage and gcc-config, and just merge baselayout and prefix-chain-utils. sorry - i'm not too good in explaining - i'm just jumping around too much. maybe haubi can further clearyfy all this a little? thanks... Cheers, Markus
> >


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>