Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Fabian Groffen]

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
-- 
gentoo-dev@g.o mailing list