Hi,

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
"READONLY_EROOT=/some/other/prefix/with/the/same/CHOST:DEPEND,RDEPEND",
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:

_emerge/__init__.py:
	* 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

portage/__init__.py:
	* 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:
		/my/prefix/etc/make.conf:
			READONLY_EROOT=/my/parent/prefix:DEPEND
		/my/parent/prefix/etc/make.conf:
			READONLY_EROOT=/my/pp/prefix:DEPEN,RDEPEND
	  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
	  package.provided.

portage/dbapi/vartree.py:
	* 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 
	  any way.

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 :)

questions/comments?

Cheers, Markus