Re: [gentoo-alt] portage prefix chaining support

[Michael Haubenwallner]

On Thu, 2009-04-02 at 22:22 +0200, Fabian Groffen wrote:
> Now this prefix-chaining is like a whole new world that
> seemingly has some dirty concepts that I find hard to accept.

Seems it isn't really clear yet what we intend prefix-chaining for.

1) Developers are working on *many* projects on *one* machine.
2) Mostly for QA-reasons, sometimes for source incompatibilities due to
major version upgrades, these projects do have *few* different
requirements on the set of versions of common libraries they link
against (think "Enterprise").
3) In an ideal world, each project would consist of its own set of
versions of specific packages, where ebuilds would exist for.
4) Additionally, some developers are playing with brand new versions of
some of these common libraries within a complete instance of a project.

And they all need a basic set of unix tools (think "@system").

The idea (vision) of prefix-chaining now is:

1) Have "@system" and a few more utils (editors, autotools, etc.)
installed in the first EPREFIX.
2) Have the different sets of common library versions installed in
different second EPREFIXes, which all refer to the first EPREFIX for
DEPENDs (coreutils&co), and *many* projects link against.
3) Have the different sets of versions of specific packages installed in
the third EPREFIX, which *one* projects link against.
4) Have the one brand new version of the common library (and its reverse
dependencies) installed in a fourth EPREFIX for the one developer
playing with, using DEPEND and the rest of RDEPEND from third, second,
first EPREFIX.

Needless to say that "first EPREFIX" could be empty - it would be a
Gentoo Linux box then, most likely the developer's desktop.

How that could work:
*) Each EPREFIX does have its private compiler wrapper, adding its own
path list (include, linktime, runtime).
*) 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.

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.

And the portage instance in use does know where to use its $BASH and $MV
from - known as BPREFIX already.

Don't want to talk about cross- or multilib-compiling here yet.

We already know that even it is ambitious, it is not ambiguous.

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level