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 14:29:47
Message-Id: 1237990935.28894.43.camel@localhost
In Reply to: Re: [gentoo-alt] prefix chaining by Fabian Groffen
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 >' 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/ 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. 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.
> > 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. > >


Subject Author
Re: [gentoo-alt] prefix chaining Markus Duft <mduft@g.o>