On 18-12-2007 10:03:56 +0000, Ciaran McCreesh wrote: > > 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.
Just to have it spelt out, what you suggest here is that EAPI has a single value, a word or a number, that refers to a set of "features and rules", if I understand correctly. With this way of using EAPI I fail to see why EAPIs aren't orderable. Even with the example you gave in the previous mail, it looks like a perfect succession of EAPIs. However, I realise that this discussion is stricktly said off-topic for the GLEP at hand, as this stuff hasn't been dealt with in the main tree (yet). In the end I guess it's a matter of opening up a new can of worms, or trying to keep it simple and see how far you'll get with it. -- Fabian Groffen Gentoo on a different level -- [EMAIL PROTECTED] mailing list
