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

[Ciaran McCreesh]

On Tue, 18 Dec 2007 10:36:30 +0100
Fabian Groffen <grobian@g.o> 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