On 25-03-2009 10:43:51 +0100, Markus Duft wrote:
> 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 != /
> 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.
> 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):
> * 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
This is bad, and I would call it a blocker.
> * 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).
> * 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
I don't feel good about this, and I think it will break.
Gentoo on a different level