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).
with the current situation i would end up with a path like this:
but i want: (to find executable from prefixes before the system of
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
> > * 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