Re: [gentoo-alt] prefix chaining

[Fabian Groffen]

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

> 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

Ok.

> 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