Re: [gentoo-alt] portage prefix chaining support

[Markus Duft]

On Mon, 2009-04-06 at 19:29 +0200, Michael Haubenwallner wrote:
[snip]
> 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/