1 |
On Wednesday 31 August 2005 14:58, Brian Harring wrote: |
2 |
> On Wed, Aug 31, 2005 at 11:55:40AM +0200, Paul de Vrieze wrote: |
3 |
> > pps. For being able to state that one eclass/ebuild is compatible |
4 |
> > with two (overlapping) formats I also argue to make EAPI a space |
5 |
> > separated list of supported API's. As an example for why this would |
6 |
> > make sense take for example the depend.apache eclass. This eclass is |
7 |
> > compatible with both the proposed EAPI1 as the current EAPI0 as it |
8 |
> > does not use/provide src_compile. Writing separate eclasses with just |
9 |
> > different EAPI versions is rather pointless, so allowing a list of |
10 |
> > supported ones makes sense. I do realise that this makes things a bit |
11 |
> > harder as first the EAPI of an ebuild(including it's eclasses) must |
12 |
> > be decided, and only then might proper parsing be possible to happen. |
13 |
> |
14 |
> Preferred solution (imo) for such a case is eapi defined prior to the |
15 |
> inherit iff the eclass is capable of multiple eapi levels. |
16 |
> |
17 |
> It's effectively the same thing, but allows for the ebuild/eclass |
18 |
> authors to have total control over it, and doesn't require a second |
19 |
> duff eclass. |
20 |
> |
21 |
> Regarding having the eclass specify compatible eapi versions, and |
22 |
> portage somehow tracking ebuild eapi and comparing the two (and |
23 |
> bailing if the containment test fails), not much for. Reasoning is |
24 |
> thus- new eapi3 is available, ebuild dev bumps (fex) apache so that |
25 |
> it uses eapi3; if the eclass limits to <3, the ebuild *cannot* use the |
26 |
> eclass. Need a duplicate eclass, or the ebuild gets the eclasses code |
27 |
> jammed into it, or (I really don't like this case) eclass gets eapi3 |
28 |
> tagged in, despite the fact the eclass may not be eclass compatible |
29 |
> without the ebuild doing a little dance (for eapi0/1, defining it's |
30 |
> own src_configure and src_compile fex). |
31 |
|
32 |
If the eclass get's ported to eapi3 then all hell breaks loose (probably) |
33 |
as there are many ebuilds (some in the user's overlays and out of our |
34 |
control) that expect it to be eapi2. If the port was the case of just |
35 |
specifying eapi3 by the merit of being compatible to both (the change |
36 |
being outside the region of the eclass) this is unneeded. |
37 |
|
38 |
Further there is a simple scheme for using EAPI as a list: |
39 |
|
40 |
- portage specifies EAPI=0 before loading the ebuild: |
41 |
- ebuild specifies EAPI="eapi1 eapi2 0" |
42 |
- at inherit the current EAPI gets stored and EAPI is set to EAPI=0 |
43 |
- the eclass is sourced. |
44 |
- The eclass specifies EAPI="eapi1 0" |
45 |
- inherit finished the sourcing of the ebuild and compares EAPI_STORED |
46 |
with EAPI and keeps the common elements. Now EAPI="eapi1 0". Other |
47 |
eclasses might now be imported as if 'import a b c d' means 'import a' |
48 |
'import b' etc.. |
49 |
- After the ebuild is finally sourced completely EAPI has a value. This |
50 |
EAPI value is then masked with the supported EAPI levels. If the masking |
51 |
results in an empty list while the original list had items portage must |
52 |
be updated. If the original list was allready empty the ebuild is |
53 |
invalid. Finally if the masked list results in more than 1 atom, portage |
54 |
uses some internal list to select the best EAPI. This preference system |
55 |
could very well be internal to portage. |
56 |
|
57 |
A feature that could be added would be that inherit would bail out as soon |
58 |
as the EAPI list is empty, and the ebuild can allready be seen as |
59 |
invalid. |
60 |
|
61 |
> Or the ebuild is kept at eapi2, till eapi3 is available in the eclass, |
62 |
> slightly saner approach, but also effectively adoption of new eapis |
63 |
> due to the fact that you cannot localize the build up of eapi3 |
64 |
> compatibility crap in the ebuild, then port it into the eclass (then |
65 |
> marking the eclass as explicitly eapi3 compatible). |
66 |
|
67 |
Many eclasses can be compatible with multiple versions, but some cannot. |
68 |
That's why I argue that eclasses should list all api's that they are |
69 |
compatible with. Suppose for arguments sake that for example api3 was an |
70 |
api that was soon found to be not such usefull, and too far a deviation |
71 |
from api4. Then api4 is introduced that takes most usefull features from |
72 |
api3, but gets a higher compatibility with api2. An eclass could then be |
73 |
compatible with api2 and api4 without any compatibility layer. |
74 |
|
75 |
> |
76 |
> Eclass templates I prefer to keep as flexible as possible; granted |
77 |
> people can shoot themselves in the foot, but that's always the case |
78 |
> (add a safety to the gun, they'll find the safety and maybe gutshot |
79 |
> themselves instead while playing with the safety :). Point I'm |
80 |
> getting at is that artificial limiters people find a way around, with |
81 |
> the workaround being usually a helluva worse then what the limitation |
82 |
> is trying to block. |
83 |
|
84 |
Alternatively one could put all responsibility in ebuild authors. This |
85 |
would however be a disaster waiting to happen as an eclass gets updated |
86 |
to suddenly becomming incompatible with an ebuild in the user's overlay |
87 |
or our own tree. |
88 |
|
89 |
> Imo, at least. |
90 |
> Either way, it's something that once applied, cannot be reversed; |
91 |
> would rather leave it loose, then tighten it down the line if people |
92 |
> seem chronically apt to screw it up. |
93 |
|
94 |
I just think that eclasses should specify what api they work with. If |
95 |
someone finds it does support their api of choice, but doesn't state so, |
96 |
well, that someone can just add the api of choice to the list. Way easier |
97 |
than even the fastest kludge. |
98 |
|
99 |
Paul |
100 |
|
101 |
-- |
102 |
Paul de Vrieze |
103 |
Gentoo Developer |
104 |
Mail: pauldv@g.o |
105 |
Homepage: http://www.devrieze.net |