1 |
On Mon, 23 Feb 2009 08:43:09 -0700 |
2 |
Steve Dibb <beandog@g.o> wrote: |
3 |
> Plus, I don't really grasp the whole "we have to source the whole |
4 |
> ebuild to know the EAPI version" argument. It's one variable, in one |
5 |
> line. Can't a simple parser get that and go from there? |
6 |
|
7 |
Not true. This is entirely legal: |
8 |
|
9 |
In pkg-1.ebuild: |
10 |
|
11 |
EAPI="${PV}" |
12 |
printf -v EAPI '%s' 4 |
13 |
inherit foo |
14 |
EAPI="2" |
15 |
|
16 |
In foo.eclass: |
17 |
|
18 |
EAPI="3" |
19 |
|
20 |
And in this case, the package manager has to know that EAPI=2, and it |
21 |
has to use EAPI 2's behaviour for performing the inherit. |
22 |
|
23 |
In fact, it gets worse if you consider that future EAPIs will probably |
24 |
allow per-package eclasses. So you could end up with this crazy |
25 |
situation: |
26 |
|
27 |
In pkg-1.ebuild: |
28 |
|
29 |
require pkg |
30 |
|
31 |
In cat/pkg/pkg.eclass: |
32 |
|
33 |
EAPI="3" |
34 |
|
35 |
In global pkg.eclass: |
36 |
|
37 |
EAPI="2" |
38 |
|
39 |
So here you can't even use a faked pre-source EAPI. If you assume EAPI |
40 |
0 beforehand, the global pkg.eclass will be used, so EAPI will end up |
41 |
as 2. But if you assume EAPI 3 beforehand, the per-pkg eclass will be |
42 |
used, so the EAPI will end up as 3. |
43 |
|
44 |
It gets even crazier if you put EAPI="2" in the per-pkg eclass and |
45 |
EAPI="3" in the global one instead... |
46 |
|
47 |
And whilst this is clearly a deliberate example of how to create |
48 |
craziness, the only difference between this and the real world is that |
49 |
the craziness is obvious here. The current rules really are this |
50 |
complicated, and we can't retroactively fix them. |
51 |
|
52 |
-- |
53 |
Ciaran McCreesh |