On Wed, 2009-03-25 at 14:14 +0100, Markus Duft wrote:
> On Wed, 2009-03-25 at 12:00 +0100, Fabian Groffen wrote:
> > On 20-03-2009 11:35:09 +0100, Markus Duft wrote:
> > > i'll try and explain what i want in the first place: i'm porting things
> > > to native windows. since windows isn't too cooperative, i'm unable to
> > > merge most things (and with other things, i simply don't want to), and
> > > thus i need to take those things from somewhere else (more or less the
> > > complete @system). I _am_ able to build all those things for interix
> > > (which is the host system in the windows case). So what i want is a
> > > setup of two prefix instances with a certain relation to each other: the
> > > native windows prefix should be able to recognize installed packages
> > > from the other instance, and resolve dependencies by eventually using
> > > the other .../var/db/...
> > Since Windows and Interix seem to be two different things to me, can you
> > explain why in this case Portage can resolve the dependencies from the
> > Interix system to use for the Windows system? What dependencies are we
> > talking about? Build tools? Libraries? Runtime dependencies?
> i'm using it to resolve DEPEND atoms only. of course my notion of valid
> DEPENDs and RDEPENDs is influenced by this, and i'm alergic against
> RDEPEND=$DEPEND and such
since it doesn't work in this setup. however
> right now most things i need don't make too much problems.
> > > This could be (and is) quite usefull for all other platforms too. For
> > > exmaple i could use prefix chaining on a linux box. I could create a
> > > prefix containing a base system, and then for testing of
> > > i-don't-know-whatever, i could create another small prefix inheriting
> > > all installed packages from the other one. this way new prefixes can
> > > stay very slim, but still the "parent" prefix is not altered on merges.
> > That potentially is useful, in the case where you want to upgrade a
> > critical system package and test it out or something. Can't think of an
> > example other than Portage itself for the moment, though. (And that one
> > can be hairy, for instance if the vdb format changes NEEDED ->
> > NEEDED.ELF.2)
> > > one issue not handled by the current patch is, that prefixes can have
> > > different CHOST/ARCH/... (which is the case with x86-interix and
> > > x86-winnt for example).
> > Then how does it work for you?
> as i said, i'm using DEPENDs only from the other prefix with the
> different CHOST/ARCH. this works, since on interix i can execute windows
> binaries, and vice versa (limited).
> the patch i proposed here and on gentoo-alt@ (btw. i have a fixed
> version lying around since a few minutes ...) allows the user to set
> which atoms should be resolve-able from the chain. for exmaple for
> windows i'm doing this in /my/winnt/prefix/etc/make.conf:
> on linux, if both prefixes are x86-linux for example i could to
> in /my/prefix/two/etc/make.conf:
> (btw. this forces PDEPENDs to merge in /my/prefix/two. i guess most of
> the time this makes sense, since with a PDEPEND from a lib, i want the
> PDEPEND package to link against this lib... you know what i mean? of
> course PDEPEND can still be added to the above list...)
> (btw2. the name READONLY_EROOT is discussed on gentoo-alt@ already, so i
> won't comment on it beeing cool/uncool here...
> Cheers, Markus
While much of what you are talking about here mainly applies to prefix,
it looks to me from glancing over the code that you might of solved a
long standing problem in the embedded world with cross compiling via
portage. 222895 If that is the case, then I owe you a beer. one about
the size of a keg.
Ned Ludd <email@example.com>