| 1 |
On Wed, Aug 31, 2005 at 11:55:40AM +0200, Paul de Vrieze wrote: |
| 2 |
> pps. For being able to state that one eclass/ebuild is compatible with two |
| 3 |
> (overlapping) formats I also argue to make EAPI a space separated list of |
| 4 |
> supported API's. As an example for why this would make sense take for |
| 5 |
> example the depend.apache eclass. This eclass is compatible with both the |
| 6 |
> proposed EAPI1 as the current EAPI0 as it does not use/provide |
| 7 |
> src_compile. Writing separate eclasses with just different EAPI versions |
| 8 |
> is rather pointless, so allowing a list of supported ones makes sense. I |
| 9 |
> do realise that this makes things a bit harder as first the EAPI of an |
| 10 |
> ebuild(including it's eclasses) must be decided, and only then might |
| 11 |
> proper parsing be possible to happen. |
| 12 |
|
| 13 |
Preferred solution (imo) for such a case is eapi defined prior to the |
| 14 |
inherit iff the eclass is capable of multiple eapi levels. |
| 15 |
|
| 16 |
It's effectively the same thing, but allows for the ebuild/eclass |
| 17 |
authors to have total control over it, and doesn't require a second |
| 18 |
duff eclass. |
| 19 |
|
| 20 |
Regarding having the eclass specify compatible eapi versions, and |
| 21 |
portage somehow tracking ebuild eapi and comparing the two (and |
| 22 |
bailing if the containment test fails), not much for. Reasoning is |
| 23 |
thus- new eapi3 is available, ebuild dev bumps (fex) apache so that |
| 24 |
it uses eapi3; if the eclass limits to <3, the ebuild *cannot* use the |
| 25 |
eclass. Need a duplicate eclass, or the ebuild gets the eclasses code |
| 26 |
jammed into it, or (I really don't like this case) eclass gets eapi3 |
| 27 |
tagged in, despite the fact the eclass may not be eclass compatible |
| 28 |
without the ebuild doing a little dance (for eapi0/1, defining it's |
| 29 |
own src_configure and src_compile fex). |
| 30 |
|
| 31 |
Or the ebuild is kept at eapi2, till eapi3 is available in the eclass, |
| 32 |
slightly saner approach, but also effectively adoption of new eapis |
| 33 |
due to the fact that you cannot localize the build up of eapi3 |
| 34 |
compatibility crap in the ebuild, then port it into the eclass (then |
| 35 |
marking the eclass as explicitly eapi3 compatible). |
| 36 |
|
| 37 |
Eclass templates I prefer to keep as flexible as possible; granted |
| 38 |
people can shoot themselves in the foot, but that's always the case |
| 39 |
(add a safety to the gun, they'll find the safety and maybe gutshot |
| 40 |
themselves instead while playing with the safety :). Point I'm |
| 41 |
getting at is that artificial limiters people find a way around, with |
| 42 |
the workaround being usually a helluva worse then what the limitation |
| 43 |
is trying to block. |
| 44 |
|
| 45 |
Imo, at least. |
| 46 |
Either way, it's something that once applied, cannot be reversed; |
| 47 |
would rather leave it loose, then tighten it down the line if people |
| 48 |
seem chronically apt to screw it up. |
| 49 |
~harring |
Archives