1 |
Okay, this thread has been going nowhere for too long, and it's blocking |
2 |
progress. It's time to make a decision and be done with it. |
3 |
|
4 |
I hereby christen the two variants of gentoo prefix "prefix guest" for the |
5 |
variant that has nongentoo include and library search paths and a nongentoo |
6 |
dynamic linker; and "prefix standalone" for which the dynamic linker and all |
7 |
search paths are strictly inside the prefix installation. |
8 |
|
9 |
I will introduce a single new USE flag, masked in nonprefix profiles and |
10 |
forced in prefix guest profiles, "prefix-guest"; this USE flag with codify |
11 |
exactly the two properties specified above. I have decided not to use a |
12 |
second USE flag for the alternative after all; a look through the tree has |
13 |
shown that this would be useful at exactly one place (toolchain.eclass) and |
14 |
nowhere else, and at that point it's just a waste of complexity. |
15 |
|
16 |
I will not use a USE_EXPAND variable, because there isn't really a (relevant) |
17 |
single setting that can take on multiple values across different prefix |
18 |
variants; rather, there is just the single deviation from normal gentoo |
19 |
system setups which may or may not apply to a given prefix variant, so a |
20 |
simple USE flag saying "this 'feature' is in effect" is the appropriate tool |
21 |
for the job. |
22 |
|
23 |
I will create profiles default/linux/$arch/13.0/prefix/{guest,standalone}, of |
24 |
which the first is a link to prefix/linux/$arch and the second is the new |
25 |
profile to be written. I will not for now name either the "default" prefix |
26 |
profile on linux archs per the name default/linux/$arch/13.0/prefix, as I |
27 |
think that choice is best delayed until after we have more experience with |
28 |
how well the two variants work in practice; naming one the default is easy, |
29 |
but changing this decision later on is hard without breaking compatibility. |
30 |
Thus, for now default/linux/$arch/13.0/prefix will stay empty. |
31 |
|
32 |
I will create a common base for the two variant profiles in features/prefix, |
33 |
with both variant profiles inheriting it. After all, the majority of profile |
34 |
hacks in the current prefix profiles would apply in full force in |
35 |
prefix-standalone. |
36 |
|
37 |
Unless there are any complaints, I'm planning to make all this a reality in a |
38 |
few days. |
39 |
|
40 |
Thoughts? |
41 |
|
42 |
-- Ruud |