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