Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-alt
Navigation:
Lists: gentoo-alt: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-alt@g.o
From: Markus Duft <mduft@g.o>
Subject: Re: portage prefix chaining support
Date: Fri, 03 Apr 2009 09:04:39 +0200
On Thu, 2009-04-02 at 22:22 +0200, Fabian Groffen wrote:
[snip]
> 
> 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

> 
> 



Replies:
Re: portage prefix chaining support
-- Fabian Groffen
Re: portage prefix chaining support
-- Markus Duft
References:
portage prefix chaining support
-- Markus Duft
Re: portage prefix chaining support
-- Fabian Groffen
Re: portage prefix chaining support
-- Markus Duft
Re: portage prefix chaining support
-- Fabian Groffen
Navigation:
Lists: gentoo-alt: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: portage prefix chaining support
Next by thread:
Re: portage prefix chaining support
Previous by date:
Re: portage prefix chaining support
Next by date:
Re: portage prefix chaining support


Updated Jun 17, 2009

Summary: Archive of the gentoo-alt mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.