On Wednesday 31 August 2005 14:58, Brian Harring wrote: > 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).
If the eclass get's ported to eapi3 then all hell breaks loose (probably) as there are many ebuilds (some in the user's overlays and out of our control) that expect it to be eapi2. If the port was the case of just specifying eapi3 by the merit of being compatible to both (the change being outside the region of the eclass) this is unneeded. Further there is a simple scheme for using EAPI as a list: - portage specifies EAPI=0 before loading the ebuild: - ebuild specifies EAPI="eapi1 eapi2 0" - at inherit the current EAPI gets stored and EAPI is set to EAPI=0 - the eclass is sourced. - The eclass specifies EAPI="eapi1 0" - inherit finished the sourcing of the ebuild and compares EAPI_STORED with EAPI and keeps the common elements. Now EAPI="eapi1 0". Other eclasses might now be imported as if 'import a b c d' means 'import a' 'import b' etc.. - After the ebuild is finally sourced completely EAPI has a value. This EAPI value is then masked with the supported EAPI levels. If the masking results in an empty list while the original list had items portage must be updated. If the original list was allready empty the ebuild is invalid. Finally if the masked list results in more than 1 atom, portage uses some internal list to select the best EAPI. This preference system could very well be internal to portage. A feature that could be added would be that inherit would bail out as soon as the EAPI list is empty, and the ebuild can allready be seen as invalid. > 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). Many eclasses can be compatible with multiple versions, but some cannot. That's why I argue that eclasses should list all api's that they are compatible with. Suppose for arguments sake that for example api3 was an api that was soon found to be not such usefull, and too far a deviation from api4. Then api4 is introduced that takes most usefull features from api3, but gets a higher compatibility with api2. An eclass could then be compatible with api2 and api4 without any compatibility layer. > > 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. Alternatively one could put all responsibility in ebuild authors. This would however be a disaster waiting to happen as an eclass gets updated to suddenly becomming incompatible with an ebuild in the user's overlay or our own tree. > 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. I just think that eclasses should specify what api they work with. If someone finds it does support their api of choice, but doesn't state so, well, that someone can just add the api of choice to the list. Way easier than even the fastest kludge. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net
pgp7G5wqULXjx.pgp
Description: PGP signature
