On Wed, 2009-03-25 at 14:33 +0100, Fabian Groffen wrote:
> 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 ?

i changed it to READONLY_EPREFIX in my patches. however the internal
variables are still called _ro_root, etc...

i think there is a small misunderstanding here: it is not possible to
specify more than one READONLY_EPREFIX per make.conf. so it is only
possible to build a one-dimensional chain of eprefixes (without circles,
etc.)

the syntax for READONLY_EPREFIX is
"READONLY_EPREFIX=/path/to/prefix:DEPEND,RDEPEND", so first the path and
seperated by a colon the list of allowed dependency types to be resolved
from there.

> 
> > > > 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
> bootstrap-prefix.sh' 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?

i thought about that before, but i need to do things a little different.
my startprefix looks like this:

 3 . "@GENTOO_PORTAGE_EPREFIX@"/sbin/functions.sh
 4 einfo "entering chained prefix @GENTOO_PORTAGE_EPREFIX@ ..."
 5 . "@GENTOO_PORTAGE_EPREFIX@"/etc/profile
 6 
 7 # if there is no local portage, foreign portage instances need to
know where to merge to.
 8 [[ -x "@GENTOO_PORTAGE_EPREFIX@"/usr/bin/emerge ]] || export
EPREFIX="@GENTOO_PORTAGE_EPREFIX@"
 9 
10 ${BASH} --noprofile
11 einfo "leaving chained prefix @GENTOO_PORTAGE_EPREFIX@ ..."

i need to --noprofile, since the bash i'm starting may not come from
EPREFIX, but one of the parents in the chain. since i want my profile as
the first one, which recurses down through the whole chain, i need to do
it like that... (btw. functions.sh is in my own EPREFIX, since i require
a baselayout installed in EPREFIX)

> 
> > 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?

i need it to inform a foreign portage where to merge to. as you can see
above i modified my startprefix to set EPREFIX only if no local portage
is found, so i removed the EPREFIX setting hunk from the baselayout
patch.

> 
[snip]
> > 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.

hmm.. i don't see any possible way to do this with env.d...? btw. the
recursion is partially because of env.d (or better profile.env), because
i want to "merge" prefix environments down through the whole chain.
since i can change the prefixes involved in the chain, i need to do this
as dynamic as possible to catch any change. so i think i'm stuck at
recursing (which is ok, since if you're chaining so many eprefixes that
startup is slowed noticeable, it's your own fault :) it takes the
flicker of an eye to start the prefix here with the chain (on a rather
old IBM thinkpad, gentoo linux).

Cheers, Markus

> 
> > > > 	* 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.
> 
>