On Tue, 18 Dec 2007 10:36:30 +0100 Fabian Groffen <[EMAIL PROTECTED]> wrote: > On 18-12-2007 00:39:38 +0000, Ciaran McCreesh wrote: > > An EAPI is not limited to a numeric name. We could call the next > > EAPI "cabbage" if we wanted to. There're already various > > experimental EAPIs that don't use pure numbers (for example, > > "paludis-1"). > > > > (Sometimes I think the next EAPI *should* be called "cabbage", if > > only because it'll help disabuse people of the notion that EAPIs are > > orderable...) > > While I feel there has been given little to no attention to what > EAPI's really are and how they relate to each other, I prefer to go > this route myself as well. The EAPI "name" should represent the > feature(s) it adds.
EAPIs don't correspond to features either though. > However, because "features" need not to include previous ones (why > would they?), in the Prefix branch of Portage I implemented EAPI to > be a space separated list. I merely did this because EAPI=1 ebuilds > needed to be tagged as such in an EAPI="prefix" ebuild, and the > features EAPI="prefix" adds are ortogonal on the features EAPI=0 or > EAPI=1 ... provides. As a result I now have EAPI="prefix 1" ebuilds. > > Since you seem to argue here that EAPIs are not orderable, I get the > impression you imply these "combinations" of EAPIs to be desirable. > In that case, what would the extension of the ebuild be like? Combinations of features and rules is desirable. An EAPI can be thought of as a collection of said features and rules (and that's how EAPIs are worded in PMS, and largely how they're implemented in Paludis). But developers shouldn't really be picking and choosing at that level themselves -- adding new EAPIs that merely add one thing to a previous EAPI (as 1 did to 0) is cheap. Plus, we're back to the whole combination issue raised with eclasses. There's no guarantee that features from different EAPIs can be combined in any sensible way. For example (and I hope this doesn't happen...) EAPI 2 might add a new IDEPEND variable, and then EAPI 3 might replace *DEPEND with the single DEPENDENCIES + labels. You couldn't then say that you want both IDEPEND and DEPENDENCIES, since they're largely mutually incompatible. -- Ciaran McCreesh
signature.asc
Description: PGP signature
