On Tue, 24 Feb 2009 10:46:30 -0500
Richard Freeman <rich0@g.o> wrote:
> I will certainly concede that putting it inside the ebuild
> potentially breaks compatibility with existing package managers.
> That is certainly a downside to this approach.  However, none of the
> other objections that have been raised appear to hold water.

...and it means we can't change name or version rules.

...and it means over doubling the best possible time to work out a
dependency tree in the common case where the metadata cache is valid.

...and it means we can't make arbitrary format changes.

> And if backwards compatibility were a serious issue you could define
> a new ".ebuild2" file spec that incorporates the EAPI inside the file
> and current package managers would ignore it.  Then you're not
> changing the file extension every time a new EAPI comes along, and
> the need to do so could be handled via future GLEPs.

Developers already have to stop and think and consult the conveniently
available table of features for EAPIs. By splitting the EAPI concept in
two you're doubling the amount of data to be learnt.

-- 
Ciaran McCreesh