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: Tue, 07 Apr 2009 08:27:33
Message-Id: 1239092435.27222.23.camel@localhost
In Reply to: Re: [gentoo-alt] portage prefix chaining support by Michael Haubenwallner
On Mon, 2009-04-06 at 19:29 +0200, Michael Haubenwallner wrote:
> Needless to say that "first EPREFIX" could be empty - it would be a > Gentoo Linux box then, most likely the developer's desktop.
i quick-and-dirty tried this once, and it seems to work - can't make promises though ;)
> > How that could work: > *) Each EPREFIX does have its private compiler wrapper, adding its own > path list (include, linktime, runtime).
that wrapper is implemented already in sys-apps/prefix-chain-utils. although at the moment it is activated (by installing gcc-config) only if _not_ specifying --minimal to prefix-chain-setup. gcc-config requires a local portage instance to be installed. also the asumption here is, that if --minimal is given the target EPREFIX will be some sort of "cross" EPREFIX (like winnt fex), which uses a compiler from somewhere which knows how to handle the target prefix correctly.
> *) Each EPREFIX does have its private etc/profile, which calls its > parent's etc/profile and prepends its own PATH (at least), to become > useable.
this one is implemented in baselayout already, as you have seen in my patch... note that the "parent" prefix does not need any modification for prefix-chaining to work (so it does not need to know anything about it - as it is the case with EROOT=/ - since, of course, portage-main does not know... :)). although when setting up a --minimal prefix-chain, at least portage has to have USE="prefix-chaining" to be able to merge to EPREFIX while paying attention to READONLY_EPREFIX'es. baselayout will get USE=prefix-chaining from prefix-chain-setup anyway, and only the local baselayout needs to know - so nothing to keep in mind here.
> > Now for cross-prefix: > Although it should be possible, there is no real need to have portage > installed in each of the EPREFIXes. Instead, use $EPREFIX to tell > portage which EPREFIX actually to manage, meaning what to start with for > dependency-tree calculation. > Eventually, there could be a wrapper around emerge and portageq in each > EPREFIX to avoid the need to have the environment variable being set.
As of now, EPREFIX is set only if there is no local portage installed, which means that portage needs to be told where to merge to. Also this works around another problem: currently my wrapper around parity (the winnt compiler) adds $EPREFIX paths to the compiler and linker command line from the environment. Since parity is installed *somewhere* (in any other prefix in the chain), and does not know about EPREFIX at merge time, i can see no other way to do it ATM - any ideas?
> > And the portage instance in use does know where to use its $BASH and $MV > from - known as BPREFIX already.
if DEPENDs are taken from another prefix, portage does _not_ know, since they are not installed locally - but grobian fixed that already, so nothing to worry about. in the end it shouldn't matter *where* bash and mv are taken from, as long as they are there :) and since portage normally DEPENDS on those things, they should be guaranteed to be merged somewhere in the EPREFIX chain - so i can't imagine a setup where bash and mv could be taken from somewhere outside the chain (i.e. gentoo main, or even worse: some other system (interix, ...?)).
> > Don't want to talk about cross- or multilib-compiling here yet.
cross- in the sense i'm needing it for winnt is implemented just by not merging gcc-config and a local portage to the chained prefix. this - as i said above - requires the "cross" compiler to be able to handle the target prefix (listen to $EPREFIX (?), etc.), since there is no local wrapper adding EPREFIX paths. Cheers, Markus
> > We already know that even it is ambitious, it is not ambiguous. > > /haubi/