1 |
On 25-03-2009 10:43:51 +0100, Markus Duft wrote: |
2 |
> Hi! |
3 |
> |
4 |
> i'm done working on my prefix-chaining project for now. i have |
5 |
> (attached) patches ready for commit (and 2 new packages, but that should |
6 |
> not matter to anyone anyway :)) |
7 |
> |
8 |
> the one is a newer version of the portage patch i submitted lately, and |
9 |
> the other one patches baselayout, so that prefix chaining can work. |
10 |
> |
11 |
> for all these things i can say: they won't hurt anybody, as long as |
12 |
> there is no READONLY_EROOT set in make.conf, which should not be the |
13 |
> case ;) that's the trigger that activates all changes. |
14 |
|
15 |
I think READONLY_EROOT is a bad name/starting point. To make this |
16 |
"feature" generic you should go from READONLY_ROOT I guess. But I don't |
17 |
see what ROOT has to do with Prefix chaining anyway. From what you |
18 |
wrote before it seems like you run stuff from READONLY_EROOT, which is |
19 |
usually impossible/hard with ROOT != / |
20 |
|
21 |
> if there is no READONLY_EROOT, behaviour of all parts of portage and |
22 |
> baselayout should be exactly the same. |
23 |
> |
24 |
> ok to commit? maybe we could think about checking the portage patch into |
25 |
> the prefix-portage svn tree? |
26 |
|
27 |
Yes, but as I have indicated before, I like to understand what problem |
28 |
we're actually trying to solve here. And more importantly, I'd like to |
29 |
introduce this stuff in trunk instead of prefix if it is of generic use. |
30 |
But I really can't tell for the moment. |
31 |
|
32 |
> since i haven't commented on the baselayout patch yet, i'll do it here |
33 |
> (the portage patch is basically the same as the one i submitted lately, |
34 |
> with small improvements): |
35 |
> |
36 |
> etc/env.d/00basic: |
37 |
> * added EPREFIX variable, since if the currently used portage |
38 |
> instance comes from a chained prefix, portage needs to be |
39 |
> explicitly informed of the EPREFIX. this should not disturb |
40 |
> anybody, since it can be overridden after starting the prefix |
41 |
> again... |
42 |
|
43 |
This is bad, and I would call it a blocker. |
44 |
|
45 |
> etc/profile: |
46 |
> * the profile now sources all profiles (recursively) of all |
47 |
> parent prefixes in the chain. |
48 |
> * if we are in a chained environment, some variables need |
49 |
> speacial treatment, since i want some of the chained envs to |
50 |
> be there in the current prefix. (PATH, MANPATH and in some |
51 |
> cases PKG_CONFIG_PATH. others may come...) |
52 |
> * if we are in a chained environment, don't append /usr/.. and |
53 |
> /... paths to PATH, unless we're the top level prefix in the |
54 |
> chain (which behaves the same as if there where no chain). |
55 |
|
56 |
why? |
57 |
|
58 |
> * the last hunk is for correctly setting the chained variables |
59 |
> which i listed above (PATH, MANPATH, etc.). |
60 |
|
61 |
> If nobody has objections, i'll commit. i'll wait a few hours before |
62 |
> committing. |
63 |
|
64 |
I don't feel good about this, and I think it will break. |
65 |
|
66 |
|
67 |
-- |
68 |
Fabian Groffen |
69 |
Gentoo on a different level |