1 |
On Wed, 2009-03-25 at 14:33 +0100, Fabian Groffen wrote: |
2 |
> On 25-03-2009 13:19:31 +0100, Markus Duft wrote: |
3 |
> > > > for all these things i can say: they won't hurt anybody, as long as |
4 |
> > > > there is no READONLY_EROOT set in make.conf, which should not be the |
5 |
> > > > case ;) that's the trigger that activates all changes. |
6 |
> > > |
7 |
> > > I think READONLY_EROOT is a bad name/starting point. To make this |
8 |
> > > "feature" generic you should go from READONLY_ROOT I guess. But I don't |
9 |
> > > see what ROOT has to do with Prefix chaining anyway. From what you |
10 |
> > > wrote before it seems like you run stuff from READONLY_EROOT, which is |
11 |
> > > usually impossible/hard with ROOT != / |
12 |
> > |
13 |
> > hmm, maybe you're right. actually the whole thing has not too much to do |
14 |
> > with ROOT. i think the most correct one would be READONLY_EPREFIX, but |
15 |
> > i'm unsure if that would be a good name. suggestions? |
16 |
> |
17 |
> Why is that a bad name? It immediately makes clear to me what it is |
18 |
> about. RO_EPREFIX=/prefix1:/prefix2:/prefixC ? |
19 |
|
20 |
i changed it to READONLY_EPREFIX in my patches. however the internal |
21 |
variables are still called _ro_root, etc... |
22 |
|
23 |
i think there is a small misunderstanding here: it is not possible to |
24 |
specify more than one READONLY_EPREFIX per make.conf. so it is only |
25 |
possible to build a one-dimensional chain of eprefixes (without circles, |
26 |
etc.) |
27 |
|
28 |
the syntax for READONLY_EPREFIX is |
29 |
"READONLY_EPREFIX=/path/to/prefix:DEPEND,RDEPEND", so first the path and |
30 |
seperated by a colon the list of allowed dependency types to be resolved |
31 |
from there. |
32 |
|
33 |
> |
34 |
> > > > etc/env.d/00basic: |
35 |
> > > > * added EPREFIX variable, since if the currently used portage |
36 |
> > > > instance comes from a chained prefix, portage needs to be |
37 |
> > > > explicitly informed of the EPREFIX. this should not disturb |
38 |
> > > > anybody, since it can be overridden after starting the prefix |
39 |
> > > > again... |
40 |
> > > |
41 |
> > > This is bad, and I would call it a blocker. |
42 |
> > |
43 |
> > hm. the problem is the following: i can use a portage installed into |
44 |
> > another EPREFIX, which forces me to set EPREFIX for the "child" eprefix, |
45 |
> > if i want to use portage (i want to :)). instead of setting it in env.d |
46 |
> > i could set it in startprefix (that is a script installed by |
47 |
> |
48 |
> Do you want to keep that startprefix synchronised with |
49 |
> bootstrap-prefix.sh' one? Perhaps you can call the bootstrap script's |
50 |
> function to generate the script with some changes here and there to |
51 |
> accomodate what you need? |
52 |
|
53 |
i thought about that before, but i need to do things a little different. |
54 |
my startprefix looks like this: |
55 |
|
56 |
3 . "@GENTOO_PORTAGE_EPREFIX@"/sbin/functions.sh |
57 |
4 einfo "entering chained prefix @GENTOO_PORTAGE_EPREFIX@ ..." |
58 |
5 . "@GENTOO_PORTAGE_EPREFIX@"/etc/profile |
59 |
6 |
60 |
7 # if there is no local portage, foreign portage instances need to |
61 |
know where to merge to. |
62 |
8 [[ -x "@GENTOO_PORTAGE_EPREFIX@"/usr/bin/emerge ]] || export |
63 |
EPREFIX="@GENTOO_PORTAGE_EPREFIX@" |
64 |
9 |
65 |
10 ${BASH} --noprofile |
66 |
11 einfo "leaving chained prefix @GENTOO_PORTAGE_EPREFIX@ ..." |
67 |
|
68 |
i need to --noprofile, since the bash i'm starting may not come from |
69 |
EPREFIX, but one of the parents in the chain. since i want my profile as |
70 |
the first one, which recurses down through the whole chain, i need to do |
71 |
it like that... (btw. functions.sh is in my own EPREFIX, since i require |
72 |
a baselayout installed in EPREFIX) |
73 |
|
74 |
> |
75 |
> > prefix-chain-utils, one of the new packages i'll add for |
76 |
> > prefix-chaining), and only if i'm unable to detect a local portage. |
77 |
> > would that help? that would eliminate EPREFIX in 99% of all cases, since |
78 |
> > the prefix-chain-setup script used to bootstrap a chained prefix |
79 |
> > installs portage, unless --minimal is given (which i will do for winnt |
80 |
> > chained prefixes - and maybe in the future for other cross-chained |
81 |
> > eprefixes (for example cross-multilib-abi on a linux system...?)). could |
82 |
> > you live with that? |
83 |
> |
84 |
> The thing is, in principle I don't want EPREFIX to be set by the system |
85 |
> in the environment. If you set it, you should know what you're doing, |
86 |
> since Portage "listens" to it. |
87 |
> |
88 |
> Now my question is, where exactly do you need EPREFIX set? Do you need |
89 |
> a foreign Portage to manage your local packages? Do you need it to have |
90 |
> your local Portage call your foreign Portage? |
91 |
|
92 |
i need it to inform a foreign portage where to merge to. as you can see |
93 |
above i modified my startprefix to set EPREFIX only if no local portage |
94 |
is found, so i removed the EPREFIX setting hunk from the baselayout |
95 |
patch. |
96 |
|
97 |
> |
98 |
[snip] |
99 |
> > so only the last prefix in a chain (when there is no chain, the only |
100 |
> > EPREFIX in play behaves like the last of the chain - it actually is - |
101 |
> > the chain is just exactly one EPREFIX long :)) sets system wide dirs |
102 |
> > into PATH. |
103 |
> |
104 |
> I wonder if it isn't better set by env.d entries which portage then |
105 |
> transforms into a profile.env, which avoids the scary recursive sourcing |
106 |
> (and shell startup slowdown) and also is less error prone. |
107 |
|
108 |
hmm.. i don't see any possible way to do this with env.d...? btw. the |
109 |
recursion is partially because of env.d (or better profile.env), because |
110 |
i want to "merge" prefix environments down through the whole chain. |
111 |
since i can change the prefixes involved in the chain, i need to do this |
112 |
as dynamic as possible to catch any change. so i think i'm stuck at |
113 |
recursing (which is ok, since if you're chaining so many eprefixes that |
114 |
startup is slowed noticeable, it's your own fault :) it takes the |
115 |
flicker of an eye to start the prefix here with the chain (on a rather |
116 |
old IBM thinkpad, gentoo linux). |
117 |
|
118 |
Cheers, Markus |
119 |
|
120 |
> |
121 |
> > > > * the last hunk is for correctly setting the chained variables |
122 |
> > > > which i listed above (PATH, MANPATH, etc.). |
123 |
> > > |
124 |
> > > > If nobody has objections, i'll commit. i'll wait a few hours before |
125 |
> > > > committing. |
126 |
> > > |
127 |
> > > I don't feel good about this, and I think it will break. |
128 |
> > |
129 |
> > what exactly will break? i tested it at least in i hope most relevant |
130 |
> > parts, to ensure that it doesn't break. however - of course - i can't |
131 |
> > promise. |
132 |
> |
133 |
> |