1 |
On Wed, 2009-03-25 at 12:00 +0100, Fabian Groffen wrote: |
2 |
> On 20-03-2009 11:35:09 +0100, Markus Duft wrote: |
3 |
> > i'll try and explain what i want in the first place: i'm porting things |
4 |
> > to native windows. since windows isn't too cooperative, i'm unable to |
5 |
> > merge most things (and with other things, i simply don't want to), and |
6 |
> > thus i need to take those things from somewhere else (more or less the |
7 |
> > complete @system). I _am_ able to build all those things for interix |
8 |
> > (which is the host system in the windows case). So what i want is a |
9 |
> > setup of two prefix instances with a certain relation to each other: the |
10 |
> > native windows prefix should be able to recognize installed packages |
11 |
> > from the other instance, and resolve dependencies by eventually using |
12 |
> > the other .../var/db/... |
13 |
> |
14 |
> Since Windows and Interix seem to be two different things to me, can you |
15 |
> explain why in this case Portage can resolve the dependencies from the |
16 |
> Interix system to use for the Windows system? What dependencies are we |
17 |
> talking about? Build tools? Libraries? Runtime dependencies? |
18 |
|
19 |
i'm using it to resolve DEPEND atoms only. of course my notion of valid |
20 |
DEPENDs and RDEPENDs is influenced by this, and i'm alergic against |
21 |
RDEPEND=$DEPEND and such :) since it doesn't work in this setup. however |
22 |
right now most things i need don't make too much problems. |
23 |
|
24 |
> |
25 |
> > This could be (and is) quite usefull for all other platforms too. For |
26 |
> > exmaple i could use prefix chaining on a linux box. I could create a |
27 |
> > prefix containing a base system, and then for testing of |
28 |
> > i-don't-know-whatever, i could create another small prefix inheriting |
29 |
> > all installed packages from the other one. this way new prefixes can |
30 |
> > stay very slim, but still the "parent" prefix is not altered on merges. |
31 |
> |
32 |
> That potentially is useful, in the case where you want to upgrade a |
33 |
> critical system package and test it out or something. Can't think of an |
34 |
> example other than Portage itself for the moment, though. (And that one |
35 |
> can be hairy, for instance if the vdb format changes NEEDED -> |
36 |
> NEEDED.ELF.2) |
37 |
|
38 |
++ :) |
39 |
|
40 |
> |
41 |
> > one issue not handled by the current patch is, that prefixes can have |
42 |
> > different CHOST/ARCH/... (which is the case with x86-interix and |
43 |
> > x86-winnt for example). |
44 |
> |
45 |
> Then how does it work for you? |
46 |
|
47 |
as i said, i'm using DEPENDs only from the other prefix with the |
48 |
different CHOST/ARCH. this works, since on interix i can execute windows |
49 |
binaries, and vice versa (limited). |
50 |
|
51 |
the patch i proposed here and on gentoo-alt@ (btw. i have a fixed |
52 |
version lying around since a few minutes ...) allows the user to set |
53 |
which atoms should be resolve-able from the chain. for exmaple for |
54 |
windows i'm doing this in /my/winnt/prefix/etc/make.conf: |
55 |
|
56 |
READONLY_EROOT=/my/interix/prefix:DEPEND |
57 |
|
58 |
on linux, if both prefixes are x86-linux for example i could to |
59 |
in /my/prefix/two/etc/make.conf: |
60 |
|
61 |
READONLY_EROOT=/my/prefix/one:DEPEND,RDEPEND |
62 |
|
63 |
(btw. this forces PDEPENDs to merge in /my/prefix/two. i guess most of |
64 |
the time this makes sense, since with a PDEPEND from a lib, i want the |
65 |
PDEPEND package to link against this lib... you know what i mean? of |
66 |
course PDEPEND can still be added to the above list...) |
67 |
|
68 |
(btw2. the name READONLY_EROOT is discussed on gentoo-alt@ already, so i |
69 |
won't comment on it beeing cool/uncool here... ;) ) |
70 |
|
71 |
Cheers, Markus |
72 |
|
73 |
> |
74 |
> |