1 |
On Fri, 23 Oct 2009 11:24:27 +0300 |
2 |
Samuli Suominen <ssuominen@g.o> wrote: |
3 |
> So I was told Council needs to approve inheritance of eapi files from |
4 |
> parent profiles? |
5 |
|
6 |
As a full explanation of why this idea sucks, since some people have |
7 |
asked: |
8 |
|
9 |
You need to decide which way eapi inherits go. Are you saying that any |
10 |
profile directory with a parent using EAPI X is itself EAPI X? If so, |
11 |
the implications are: |
12 |
|
13 |
* that we can't change the format of the parent file ever (and we have |
14 |
done so in the past) |
15 |
|
16 |
* that it gets a lot harder to remove certain syntax in newer EAPIs. |
17 |
For example, say we want to replace =...* with ranged dependencies in |
18 |
EAPI 4. Then you can't change a profile directory to use EAPI 4 |
19 |
without checking that everything that uses that directory doesn't |
20 |
make use of =...*. |
21 |
|
22 |
Or are you saying that the package manager should use the eapi it picks |
23 |
up for any parents it follows? If so, the implications are: |
24 |
|
25 |
* that removing =...* in EAPI 4 (for example) becomes impossible, |
26 |
because it would be impossible to use that syntax in high level |
27 |
profiles that might be inherited by profiles using EAPI 4. |
28 |
|
29 |
Either way, putting eapi files in any directory that itself |
30 |
specifically needs it is a heck of a lot easier for everyone. |
31 |
|
32 |
On top of that, if you do change it, there's the usual year wait before |
33 |
you can use it, since current package managers don't inherit eapis. |
34 |
|
35 |
-- |
36 |
Ciaran McCreesh |