1 |
On Mon, Feb 23, 2009 at 7:53 AM, Ciaran McCreesh |
2 |
<ciaran.mccreesh@××××××××××.com> wrote: |
3 |
> On Mon, 23 Feb 2009 08:43:09 -0700 |
4 |
> Steve Dibb <beandog@g.o> wrote: |
5 |
>> Plus, I don't really grasp the whole "we have to source the whole |
6 |
>> ebuild to know the EAPI version" argument. It's one variable, in one |
7 |
>> line. Can't a simple parser get that and go from there? |
8 |
> |
9 |
> Not true. This is entirely legal: |
10 |
> |
11 |
> In pkg-1.ebuild: |
12 |
> |
13 |
> EAPI="${PV}" |
14 |
> printf -v EAPI '%s' 4 |
15 |
> inherit foo |
16 |
> EAPI="2" |
17 |
> |
18 |
> In foo.eclass: |
19 |
> |
20 |
> EAPI="3" |
21 |
|
22 |
This is not legal, the devmanual[1] explicitly states that it is not |
23 |
legal to set EAPI in an eclass. If it was you would have an open and |
24 |
shut case for g55 (since you could set EAPI based on PV in an eclass |
25 |
and then inherit the eapi; requiring a bash parser). But its illegal, |
26 |
which makes your argument harder. |
27 |
|
28 |
A bad argument is EAPI based on some PV logic that you can copy across |
29 |
ebuilds that differ by version; which would fall into 'stupid' in my |
30 |
book. |
31 |
|
32 |
[1] http://devmanual.gentoo.org/ebuild-writing/eapi/index.html |
33 |
|
34 |
> |
35 |
> And in this case, the package manager has to know that EAPI=2, and it |
36 |
> has to use EAPI 2's behaviour for performing the inherit. |
37 |
> |
38 |
> In fact, it gets worse if you consider that future EAPIs will probably |
39 |
> allow per-package eclasses. So you could end up with this crazy |
40 |
> situation: |
41 |
> |
42 |
> In pkg-1.ebuild: |
43 |
> |
44 |
> require pkg |
45 |
> |
46 |
> In cat/pkg/pkg.eclass: |
47 |
> |
48 |
> EAPI="3" |
49 |
> |
50 |
> In global pkg.eclass: |
51 |
> |
52 |
> EAPI="2" |
53 |
|
54 |
Also illegal, but I assume here you intend to change the legality of |
55 |
things in your weird future example. |
56 |
|
57 |
> |
58 |
> So here you can't even use a faked pre-source EAPI. If you assume EAPI |
59 |
> 0 beforehand, the global pkg.eclass will be used, so EAPI will end up |
60 |
> as 2. But if you assume EAPI 3 beforehand, the per-pkg eclass will be |
61 |
> used, so the EAPI will end up as 3. |
62 |
> |
63 |
> It gets even crazier if you put EAPI="2" in the per-pkg eclass and |
64 |
> EAPI="3" in the global one instead... |
65 |
> |
66 |
> And whilst this is clearly a deliberate example of how to create |
67 |
> craziness, the only difference between this and the real world is that |
68 |
> the craziness is obvious here. The current rules really are this |
69 |
> complicated, and we can't retroactively fix them. |
70 |
> |
71 |
> -- |
72 |
> Ciaran McCreesh |
73 |
> |