Gentoo Archives: gentoo-alt

From: Markus Duft <mduft@g.o>
To: gentoo-alt@l.g.o
Subject: Re: [gentoo-alt] prefix chaining
Date: Wed, 25 Mar 2009 13:21:44
Message-Id: 1237983571.28894.10.camel@localhost
In Reply to: Re: [gentoo-alt] prefix chaining by Fabian Groffen
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
> >


Subject Author
Re: [gentoo-alt] prefix chaining Fabian Groffen <grobian@g.o>