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
Lists: gentoo-alt: < Prev By Thread Next > < Prev By Date Next >
To: gentoo-alt@g.o
From: Fabian Groffen <grobian@g.o>
Subject: Re: prefix chaining
Date: Wed, 25 Mar 2009 14:33:34 +0100
On 25-03-2009 13:19:31 +0100, Markus Duft wrote:
> > > for all these things i can say: they won't hurt anybody, as long as
> > > there is no READONLY_EROOT set in make.conf, which should not be the
> > > case ;) that's the trigger that activates all changes.
> > 
> > I think READONLY_EROOT is a bad name/starting point.  To make this
> > "feature" generic you should go from READONLY_ROOT I guess.  But I don't
> > see what ROOT has to do with Prefix chaining anyway.  From what you
> > wrote before it seems like you run stuff from READONLY_EROOT, which is
> > usually impossible/hard with ROOT != /
> hmm, maybe you're right. actually the whole thing has not too much to do
> with ROOT. i think the most correct one would be READONLY_EPREFIX, but
> i'm unsure if that would be a good name. suggestions?

Why is that a bad name?  It immediately makes clear to me what it is
about.  RO_EPREFIX=/prefix1:/prefix2:/prefixC ?

> > > etc/env.d/00basic:
> > > 	* added EPREFIX variable, since if the currently used portage
> > > 	  instance comes from a chained prefix, portage needs to be
> > > 	  explicitly informed of the EPREFIX. this should not disturb
> > > 	  anybody, since it can be overridden after starting the prefix
> > > 	  again...
> > 
> > This is bad, and I would call it a blocker.
> hm. the problem is the following: i can use a portage installed into
> another EPREFIX, which forces me to set EPREFIX for the "child" eprefix,
> if i want to use portage (i want to :)). instead of setting it in env.d
> i could set it in startprefix (that is a script installed by

Do you want to keep that startprefix synchronised with' one?  Perhaps you can call the bootstrap script's
function to generate the script with some changes here and there to
accomodate what you need?

> prefix-chain-utils, one of the new packages i'll add for
> prefix-chaining), and only if i'm unable to detect a local portage.
> would that help? that would eliminate EPREFIX in 99% of all cases, since
> the prefix-chain-setup script used to bootstrap a chained prefix
> installs portage, unless --minimal is given (which i will do for winnt
> chained prefixes - and maybe in the future for other cross-chained
> eprefixes (for example cross-multilib-abi on a linux system...?)). could
> you live with that?

The thing is, in principle I don't want EPREFIX to be set by the system
in the environment.  If you set it, you should know what you're doing,
since Portage "listens" to it.

Now my question is, where exactly do you need EPREFIX set?  Do you need
a foreign Portage to manage your local packages?  Do you need it to have
your local Portage call your foreign Portage?

> with the current situation i would end up with a path like this:
> /my/chained/eprefix/bin:...:/usr/bin:/bin:/my/parent/prefix/bin:...:/usr/bin:/bin
> but i want: (to find executable from prefixes before the system of
> course)
> /my/chained/eprefix/bin:...:/my/parent/prefix/bin:...:/usr/bin:/bin


> so only the last prefix in a chain (when there is no chain, the only
> EPREFIX in play behaves like the last of the chain - it actually is -
> the chain is just exactly one EPREFIX long :)) sets system wide dirs
> into PATH.

I wonder if it isn't better set by env.d entries which portage then
transforms into a profile.env, which avoids the scary recursive sourcing
(and shell startup slowdown) and also is less error prone.

> > > 	* the last hunk is for correctly setting the chained variables
> > > 	  which i listed above (PATH, MANPATH, etc.).
> > 
> > > If nobody has objections, i'll commit. i'll wait a few hours before
> > > committing.
> > 
> > I don't feel good about this, and I think it will break.
> what exactly will break? i tested it at least in i hope most relevant
> parts, to ensure that it doesn't break. however - of course - i can't
> promise.

Fabian Groffen
Gentoo on a different level

Re: prefix chaining
-- Markus Duft
prefix chaining
-- Markus Duft
Re: prefix chaining
-- Fabian Groffen
Re: prefix chaining
-- Markus Duft
Lists: gentoo-alt: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: prefix chaining
Next by thread:
Re: prefix chaining
Previous by date:
Re: [PREFIX] prefix keywords need to go (?)
Next by date:
Re: [PREFIX] prefix keywords need to go (?)

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.