It's me again talking about cross-prefix/prefix-chaining. the current
cross-prefix patch is mostly unmaintainable right now, sinec it's just
too big. so i decided to try a new approach, which patches portage to be
able to read the var/db/* tree of other portage instances, and take
configured dependency types from there.
what i mean is, that in etc/make.conf for one prefix installation i can
do something like "READONLY_EROOT=/some/other/prefix:DEPEND" or even
which will enable the prefix with this make.conf ro resolve any DEPEND
atom from the installed tree of that prefix.
of course i'm aware that this _might_ break things, if somebody decides
to unmerge packages from /some/other/prefix, but i guess there is no way
around that right now.
I need to create a chained-prefix-setup package or something like that,
and toolchain wrappers, but that's the next step after the portage patch
is done... (maybe i'll patch baselayout-prefix?)
i'll summarize the changes i have done:
* for correct readonly resolving, i need to know which kind
of DEPEND/RDEPEND/PDEPEND i'm working on. this is why i
need to memorize them as dep_type, and pass it through to
the readonly resolver functions.
the rest of the behaviour is exactly the same as before, so
this has absolutely no influence on functionality.
* i'm setting disp_parent on trees[root], since parent can
be None, and i want a consistent display of readonly packages
in the final merge list.
as before, this does not change behaviour in any way.
* when displaying the merge list, i'm now also displaying a
list of readonly packages, selected from another portage
instance's var/db tree.
this also has no effect on portage's behaviour
* i added code to memorize and parse readonly EROOT's from
make.conf, recursing into readonly prefixes. this means that
one can build a chain of prefixes (thus prefix chaining).
this keeps going as long as a make.conf it find's contains
a READONLY_EROOT line.
This still does not change portage's behaviour.
There is one pitfall here: for example think of this setup:
This will cause /my/prefix to resolve RDEPEND's from
/my/pp/prefix! this needs to be discussed, wether this is
ok, or wether only DEPEND's should be resolved, since from
/my/parent/prefix only DEPEND's are allowed.
* i added the logic for really reading the chained var/db trees
and resolving dependencies from there. this is two functions,
which on their own of course don't change portage's behaviour.
* i had to add the dep_type argument to the dep_check function
to be able to do correct readonly resolving. this on it's own
doesn't change anything, since there is a default value, so
any existing unmodified call will still work.
* if the dep_type is set (which should be the case during
relevant parts of dependency resolving), the only change thet
influences portage's behaviour comes into play: a call to the
readonly dependency resolving algorithm. this works by marking
packages as provided, just as if they where specified in
* the vartree class is used for readonly dependency resolution,
just as with the normal "local" var/db. this means i have to
somehow avoid EPREFIX beeing added to all the paths, since i
want to have only the path to the chained parent.
this is only in effect if the vartree is constructed with
kill_eprefix=True, which is only the case for readonly
vartrees, so it does not influence the rest of portage in
so far, so good. i hope i got all changes :)
BTW.: this enables a prefixed portage instance to resolve DEPENDS (or
anything you like) from /. this means on gentoo linux, most packages
could be taken from / and a prefix installation akts like an "extension"
to it. as i said above i still have to figure out the baselayout and
toolchain wrapper stuff :)