On Mon, Feb 23, 2009 at 09:38:06AM +0100, Tiziano M??ller wrote:
> > What is proposed in glep-55 seems to aim to solve both issues at the 
> > same time (it isn't stated) by switching file extension every time the 
> > eapi is changed. This is slightly against the principle of the least 
> > surprise and apparently is disliked by enough people to lead the 
> > situation to be discussed in the council.
> > 
> 
> Instead of switching file extension every time the eapi is changed you
> could also increment it only when a new EAPI breaks sourcing the ebuild
> compared to the requirements of the prior EAPI.
> (This way you'd in fact split EAPI into a major- and a minor-version.)

Complicates the implementation (annoying), but more importantly 
negates one of the features of g55- being able to tell via the 
extension if the manager supports that EAPI.

Honestly, the issue isn't breaking sourcing (literally unable to 
source it) of the ebuild as much as sourcing it *wrong*- simplest 
example, new metadata key is added in eapi 1.3, compliant 
implementations have to pull that key out of the env and put it in the 
cache.  Sourcing on the surface, would succeed- but the results would 
be worthless (it'd basically be similar to the situation now).

~brian