On Wed, 2009-03-25 at 11:36 +0100, Fabian Groffen wrote:
> On 23-03-2009 16:24:35 +0100, Markus Duft wrote:
> > Hi,
> > 
> [snip] 
> > 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.
> 
> I don't understand what this is exactly necessary for.  Can you give the
> use-case scenario and how it solves what problem?

ok, i even have more than one (!) use case ;):

1) as a replacement for the cross-prefix stuff i did. if i want to
   sort-of-cross-compile (but can execute things in any of the places
   i'm roaming around) - for example building windows native; i need
   to be able to resolve dependencies from "somewhere". of course i
   didn't have '/' in mind, because that's not gentoo on windows.
   with this patch i can build a "chain" of prefixes as deep as i like
   it to be. so i can install all interix stuff in one prefix, and
   the use the things from there to resolve dependencies for winnt
   packages. that's my main use-case.
2) even on other systems, haubi and i plan to use this feature to
   break up our "toolsbox" (the big bunch of packages required to
   make our software build/work) into several (two so far) parts:
   a "system" part - containing the basics (python, compiler, etc.),
   and a second "other-things" part, which contains company-specific
   packages only. still no thoughts on where to draw the line between
   those two though.
3) to test packages; i can bootstrap a chained prefix with my new
   prefix-chain-setup package within a minute on linux, and then mess
   around with a (complete) prefix, install packages, etc. for exmaple
   this can also be used for portage development, without the risk of
   shooting yourself by temporarily destroying portage. you can simply
   unmask a new version in the chained prefix (which consists of 4
   installed packages after bootstrap (!)), and do it there. if you mess
   up, rm -rf and re-bootstrap (again, under 1 minute for this).

> 
> > 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.
> 
> sofar it sounds extremely hackish

actually it isn't :) it's just that the "parent" prefix does not have
any knowledge of it's "children". the thing works only in one direction:
i can tell a prefix to "take this other prefix, and look at what is
installed there; if you find something usefull, use it!". of course
there is no mechanism of preventing the "parent" of unmerging that
package afterwards, maybe breaking a package in the "child".
This is just a thing to keep in mind when working with chaining.

> 
> > 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?)
> 
> -#!@GENTOO_PORTAGE_EPREFIX@/bin/bash
> +#!/usr/bin/env bash
> 
> why is that necessary to be changed in gcc-config?

because in a chained prefix, there is no bash. it has to be taken from
the parent prefix, which has one.

> 
> > i'll summarize the changes i have done:
> > 
[snip]
> 
> For that it must be clear first what the objective of this all is.
> Also, have you talked to solar, slomosomething and sleipir?  They are
> working on a thing for cross-compiling, where this might come close to.

i have submitted the patch for comments and suggestions to portage-dev@,
but there was nobody interested. i did not poke somebody explicitly
though.

[snip] 
> > 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.
> 
> sounds like there should be a better way to set eprefix then, because
> killing a prefix is sort of a fixed case of an eprefix change, and makes
> it only useful with a Gentoo host.

yeah, maybe it would be better to just make the vartree things take an
argument "prefix", which contains EPREFIX normally, and only in my case
nothing.

the thing here is, that this has nothing to do with gentoo hosts. my
"readonly eroot" in this case is something like "/my/gentoo/prefix"; i
want to look at var/db there. say EPREFIX is "/my/chained/prefix" in
this case - then vartree would go and poke
"/my/gentoo/prefix/my/chained/prefix/var/db" which of course doesn't
exist - thus i have to (just in my case) omit EPREFIX from the paths to
be able to read outside of EPREFIX.

> 
> > 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?
> 
> hmmm, yeah.  You are not going to tell me you did all of this just
> because you want to reuse stuff from an Gentoo Linux host, do you?  That
> sounds like an extreme corner-case to me.
> 

hehe - nope, but you should know now, after reading the above :)

Cheers, Markus

> 
>