Re: [gentoo-alt] prefix chaining

[Markus Duft]

On Wed, 2009-03-25 at 11:43 +0100, Fabian Groffen wrote:
> On 25-03-2009 10:43:51 +0100, Markus Duft wrote:
> > Hi!
> >
> > i'm done working on my prefix-chaining project for now. i have
> > (attached) patches ready for commit (and 2 new packages, but that should
> > not matter to anyone anyway :))
> >
> > the one is a newer version of the portage patch i submitted lately, and
> > the other one patches baselayout, so that prefix chaining can work.
> >
> > 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?

>
> > if there is no READONLY_EROOT, behaviour of all parts of portage and
> > baselayout should be exactly the same.
> >
> > ok to commit? maybe we could think about checking the portage patch into
> > the prefix-portage svn tree?
>
> Yes, but as I have indicated before, I like to understand what problem
> we're actually trying to solve here.  And more importantly, I'd like to
> introduce this stuff in trunk instead of prefix if it is of generic use.
> But I really can't tell for the moment.

this stuff doesn't make any sense without prefix support, so i guess it
wont make it into main until the prefix tree is merged there...

>
> > since i haven't commented on the baselayout patch yet, i'll do it here
> > (the portage patch is basically the same as the one i submitted lately,
> > with small improvements):
> >
> > 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
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?

>
> > etc/profile:
> > 	* the profile now sources all profiles (recursively) of all
> > 	  parent prefixes in the chain.
> > 	* if we are in a chained environment, some variables need
> > 	  speacial treatment, since i want some of the chained envs to
> > 	  be there in the current prefix. (PATH, MANPATH and in some
> > 	  cases PKG_CONFIG_PATH. others may come...)
> > 	* if we are in a chained environment, don't append /usr/.. and
> > 	  /... paths to PATH, unless we're the top level prefix in the
> > 	  chain (which behaves the same as if there where no chain).
>
> why?

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.

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

Cheers, Markus

>
>