Hey guys

Just wanted to stop by and get some opinions on a patch i wrote for the
prefix branch.

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/...

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.

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

another thing is, that i plan to add some output in the merge list,
telling the user, which packages have been readonly-resolved from
another portage instance. right now the dependency is treated as if it
didn't exist.

all together, i'm pretty sure i did the one or the other forbidden thing
in my patch, but that's why i'm asking the guys-who-know it was hard
enough to read the portage source and get where i am, so i'm happy with
the result

Waiting for comments, suggestions, etc.

Thanks in advance,
Cheers, Markus

On Fri, 2009-03-20 at 11:35 +0100, Markus Duft wrote:
> Hey guys
>
> Just wanted to stop by and get some opinions on a patch i wrote for the
> prefix branch.

argh... managed to fail to attach the patch _again_ at least i
managed to add the output stuff i mentioned before to the patch in the
meantime. so this patch should be pretty much complete.

Thanks and Cheers, Markus

>
> 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/...
>
> 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.
>
> 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).
>
> another thing is, that i plan to add some output in the merge list,
> telling the user, which packages have been readonly-resolved from
> another portage instance. right now the dependency is treated as if it
> didn't exist.
>
> all together, i'm pretty sure i did the one or the other forbidden thing
> in my patch, but that's why i'm asking the guys-who-know it was hard
> enough to read the portage source and get where i am, so i'm happy with
> the result
>
> Waiting for comments, suggestions, etc.
>
> Thanks in advance,
> Cheers, Markus
>
>

On Fri, 2009-03-20 at 12:11 +0100, Markus Duft wrote:
> On Fri, 2009-03-20 at 11:35 +0100, Markus Duft wrote:
> > Hey guys
> >
> > Just wanted to stop by and get some opinions on a patch i wrote for the
> > prefix branch.
>
[snip]

Hey there. Seemingly nobody has any comments on this..? here's a
working version of the patch. i realized that the last one worked only
"by accident" maybe now, some comments (or questions)?

Thanks, Cheers, Markus

[snip]
> >
> > Waiting for comments, suggestions, etc.
> >
> > Thanks in advance,
> > Cheers, Markus
> >
> >

On Mon, 2009-03-23 at 08:27 +0100, Markus Duft wrote:
> On Fri, 2009-03-20 at 12:11 +0100, Markus Duft wrote:
> > On Fri, 2009-03-20 at 11:35 +0100, Markus Duft wrote:
> > > Hey guys
> > >
> > > Just wanted to stop by and get some opinions on a patch i wrote for the
> > > prefix branch.
> >
> [snip]
>
> Hey there. Seemingly nobody has any comments on this..? here's a
> working version of the patch. i realized that the last one worked only
> "by accident" maybe now, some comments (or questions)?

i'm eager to find out how many times i can forget to attach the patch

sorry for the noise

Cheers, Markus

>
> Thanks, Cheers, Markus
>
> [snip]
> > >
> > > Waiting for comments, suggestions, etc.
> > >
> > > Thanks in advance,
> > > Cheers, Markus
> > >
> > >
>
>

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?

> 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?


--
Fabian Groffen
Gentoo on a different level

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:

READONLY_EROOT=/my/interix/prefixEPEND

on linux, if both prefixes are x86-linux for example i could to
in /my/prefix/two/etc/make.conf:

READONLY_EROOT=/my/prefix/oneEPEND,RDEPEND

(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

>
>

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:
>
> READONLY_EROOT=/my/interix/prefixEPEND
>
> on linux, if both prefixes are x86-linux for example i could to
> in /my/prefix/two/etc/make.conf:
>
> READONLY_EROOT=/my/prefix/oneEPEND,RDEPEND
>
> (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 <solar@gentoo.org>
Gentoo Linux