1 |
On 31-03-2009 09:41:17 +0200, Markus Duft wrote: |
2 |
> On Tue, 2009-03-31 at 09:21 +0200, Fabian Groffen wrote: |
3 |
> > On 30-03-2009 14:03:04 +0200, Markus Duft wrote: |
4 |
> > > After looking at the heap of ruins my prefix-chaining was turned into in |
5 |
> > > just _one_ day (*grr* ;)), i'm just about to fix it again :) i'd say, we |
6 |
> > > could think about doing this unconditionally in [portage|portage |
7 |
> > > ebuild]. |
8 |
> > |
9 |
> > If you unconditionalise as patch, you'll find your patch removed when it |
10 |
> > breaks. I'm currently in Germany for work, so I can't guarantee I can |
11 |
> > look into it. |
12 |
> |
13 |
> ok. for the moment i'll leave it conditional for prefix-chaining then. |
14 |
> maybe we can look at it again when you're back. |
15 |
|
16 |
I'm a bit concerned about the design of things here. |
17 |
|
18 |
Initially, we had "cross-prefix", where Portage's EPREFIX could be |
19 |
changed at runtime. This means Portage could "manage" another prefix, |
20 |
ideally meant to clone -- bootstrap using an existing Prefix from a |
21 |
location where you don't want to have it (read-only CD?). |
22 |
I don't know how far this actually got, but I know Portage does |
23 |
cross-prefix some things if you have EPREFIX set. |
24 |
|
25 |
For this |
26 |
EPREFIX became the *Target* Prefix, and |
27 |
BPREFIX became the *Build* Prefix, as in from the called Portage |
28 |
That means Portage will always look for stuff it works with (like bash, |
29 |
sed, etc.) from its own Prefix (BPREFIX), and just operate on stuff |
30 |
(vdb, install location, etc.) in its EPREFIX. Normally these two are |
31 |
the same. |
32 |
|
33 |
|
34 |
Now your chaining patches. |
35 |
|
36 |
Apparently you take the total opposite direction now, where you first |
37 |
have a Portage in EPREFIX (how you got it is questionable), and within |
38 |
this Portage you expect it to take stuff it works with (bash, sed) from |
39 |
a different location, let's call it CPREFIX. |
40 |
|
41 |
While this is a different approach, it just conflicts with the first |
42 |
approach, which is implemented and effectuated throughout the tree. |
43 |
|
44 |
I see your patches affecting multiple places where you revert our |
45 |
assumption that Portage should always take stuff from it's own Prefix. |
46 |
In short, I'm not happy with that. I keep asking myself, and now to |
47 |
you, why one would want to have a Portage instance that is crippled in |
48 |
the sense that it is not self-sufficient, and has to rely for the most |
49 |
critical things on "external" binaries. In other words, what was wrong |
50 |
with the initial approach of cross-prefix, which is very similar to how |
51 |
cross-compiling (with root) works? |
52 |
|
53 |
I don't want to kill all of your work, but I do want to make clear to |
54 |
you why I am so hesitant for all of your changes. Conceptually, I |
55 |
believe cross-prefix was sound and clear. Now this prefix-chaining is |
56 |
like a whole new world that seemingly has some dirty concepts that I |
57 |
find hard to accept. |
58 |
|
59 |
|
60 |
|
61 |
-- |
62 |
Fabian Groffen |
63 |
Gentoo on a different level |