1 |
On Wed, 2009-03-25 at 11:36 +0100, Fabian Groffen wrote: |
2 |
> On 23-03-2009 16:24:35 +0100, Markus Duft wrote: |
3 |
> > Hi, |
4 |
> > |
5 |
> [snip] |
6 |
> > what i mean is, that in etc/make.conf for one prefix installation i can |
7 |
> > do something like "READONLY_EROOT=/some/other/prefix:DEPEND" or even |
8 |
> > "READONLY_EROOT=/some/other/prefix/with/the/same/CHOST:DEPEND,RDEPEND", |
9 |
> > which will enable the prefix with this make.conf ro resolve any DEPEND |
10 |
> > atom from the installed tree of that prefix. |
11 |
> |
12 |
> I don't understand what this is exactly necessary for. Can you give the |
13 |
> use-case scenario and how it solves what problem? |
14 |
|
15 |
ok, i even have more than one (!) use case ;): |
16 |
|
17 |
1) as a replacement for the cross-prefix stuff i did. if i want to |
18 |
sort-of-cross-compile (but can execute things in any of the places |
19 |
i'm roaming around) - for example building windows native; i need |
20 |
to be able to resolve dependencies from "somewhere". of course i |
21 |
didn't have '/' in mind, because that's not gentoo on windows. |
22 |
with this patch i can build a "chain" of prefixes as deep as i like |
23 |
it to be. so i can install all interix stuff in one prefix, and |
24 |
the use the things from there to resolve dependencies for winnt |
25 |
packages. that's my main use-case. |
26 |
2) even on other systems, haubi and i plan to use this feature to |
27 |
break up our "toolsbox" (the big bunch of packages required to |
28 |
make our software build/work) into several (two so far) parts: |
29 |
a "system" part - containing the basics (python, compiler, etc.), |
30 |
and a second "other-things" part, which contains company-specific |
31 |
packages only. still no thoughts on where to draw the line between |
32 |
those two though. |
33 |
3) to test packages; i can bootstrap a chained prefix with my new |
34 |
prefix-chain-setup package within a minute on linux, and then mess |
35 |
around with a (complete) prefix, install packages, etc. for exmaple |
36 |
this can also be used for portage development, without the risk of |
37 |
shooting yourself by temporarily destroying portage. you can simply |
38 |
unmask a new version in the chained prefix (which consists of 4 |
39 |
installed packages after bootstrap (!)), and do it there. if you mess |
40 |
up, rm -rf and re-bootstrap (again, under 1 minute for this). |
41 |
|
42 |
> |
43 |
> > of course i'm aware that this _might_ break things, if somebody decides |
44 |
> > to unmerge packages from /some/other/prefix, but i guess there is no way |
45 |
> > around that right now. |
46 |
> |
47 |
> sofar it sounds extremely hackish |
48 |
|
49 |
actually it isn't :) it's just that the "parent" prefix does not have |
50 |
any knowledge of it's "children". the thing works only in one direction: |
51 |
i can tell a prefix to "take this other prefix, and look at what is |
52 |
installed there; if you find something usefull, use it!". of course |
53 |
there is no mechanism of preventing the "parent" of unmerging that |
54 |
package afterwards, maybe breaking a package in the "child". |
55 |
This is just a thing to keep in mind when working with chaining. |
56 |
|
57 |
> |
58 |
> > I need to create a chained-prefix-setup package or something like that, |
59 |
> > and toolchain wrappers, but that's the next step after the portage patch |
60 |
> > is done... (maybe i'll patch baselayout-prefix?) |
61 |
> |
62 |
> -#!@GENTOO_PORTAGE_EPREFIX@/bin/bash |
63 |
> +#!/usr/bin/env bash |
64 |
> |
65 |
> why is that necessary to be changed in gcc-config? |
66 |
|
67 |
because in a chained prefix, there is no bash. it has to be taken from |
68 |
the parent prefix, which has one. |
69 |
|
70 |
> |
71 |
> > i'll summarize the changes i have done: |
72 |
> > |
73 |
[snip] |
74 |
> |
75 |
> For that it must be clear first what the objective of this all is. |
76 |
> Also, have you talked to solar, slomosomething and sleipir? They are |
77 |
> working on a thing for cross-compiling, where this might come close to. |
78 |
|
79 |
i have submitted the patch for comments and suggestions to portage-dev@, |
80 |
but there was nobody interested. i did not poke somebody explicitly |
81 |
though. |
82 |
|
83 |
[snip] |
84 |
> > portage/dbapi/vartree.py: |
85 |
> > * the vartree class is used for readonly dependency resolution, |
86 |
> > just as with the normal "local" var/db. this means i have to |
87 |
> > somehow avoid EPREFIX beeing added to all the paths, since i |
88 |
> > want to have only the path to the chained parent. |
89 |
> > this is only in effect if the vartree is constructed with |
90 |
> > kill_eprefix=True, which is only the case for readonly |
91 |
> > vartrees, so it does not influence the rest of portage in |
92 |
> > any way. |
93 |
> |
94 |
> sounds like there should be a better way to set eprefix then, because |
95 |
> killing a prefix is sort of a fixed case of an eprefix change, and makes |
96 |
> it only useful with a Gentoo host. |
97 |
|
98 |
yeah, maybe it would be better to just make the vartree things take an |
99 |
argument "prefix", which contains EPREFIX normally, and only in my case |
100 |
nothing. |
101 |
|
102 |
the thing here is, that this has nothing to do with gentoo hosts. my |
103 |
"readonly eroot" in this case is something like "/my/gentoo/prefix"; i |
104 |
want to look at var/db there. say EPREFIX is "/my/chained/prefix" in |
105 |
this case - then vartree would go and poke |
106 |
"/my/gentoo/prefix/my/chained/prefix/var/db" which of course doesn't |
107 |
exist - thus i have to (just in my case) omit EPREFIX from the paths to |
108 |
be able to read outside of EPREFIX. |
109 |
|
110 |
> |
111 |
> > so far, so good. i hope i got all changes :) |
112 |
> > |
113 |
> > BTW.: this enables a prefixed portage instance to resolve DEPENDS (or |
114 |
> > anything you like) from /. this means on gentoo linux, most packages |
115 |
> > could be taken from / and a prefix installation akts like an "extension" |
116 |
> > to it. as i said above i still have to figure out the baselayout and |
117 |
> > toolchain wrapper stuff :) |
118 |
> > |
119 |
> > questions/comments? |
120 |
> |
121 |
> hmmm, yeah. You are not going to tell me you did all of this just |
122 |
> because you want to reuse stuff from an Gentoo Linux host, do you? That |
123 |
> sounds like an extreme corner-case to me. |
124 |
> |
125 |
|
126 |
hehe - nope, but you should know now, after reading the above :) |
127 |
|
128 |
Cheers, Markus |
129 |
|
130 |
> |
131 |
> |