Alistair Bush wrote:
> 4) Parsing the ebuild.  But what are we parsing?,  lets not limit
> ourselves to bash,  we might want to change languages completely.  If it
> is bash,  what version, what if EAPI is set multiple times,  what if its
> set in an eclass.

How do you do this if you're getting EAPI from the filename?  How do you 
set it multiple times?  How do you set it in an eclass if you're getting 
it from the filename?

It seems like when we're talking about just putting the EAPI in a 
comment line on line x of the ebuild we're barraged with 47 ways that it 
will limit us, but when we're talking about EAPI in the filename 
suddenly we're not concerned with those limitations.  If it helps maybe 
we need to split EAPI into two records - one that deals with how to 
fundamentally parse the file and find out the EAPI, and the other that 
implements everything else the EAPI does.

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.  An EAPI in a filename is a blob 
of text that needs to be parsed out in one particular way with one set 
of system calls.  An EAPI embedded in the file is a blob of text that 
needs to be parsed out in one particular way with one set of system calls.

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.  Or we could just delay 
implementation and clean up existing package managers and tell users to 
migrate.