Douglas Anderson wrote:
> No one wants to be working with ebuild-29 or something like that in a
> few years and trying to figure out which feature came in which EAPI.
> Instead of bumping EAPI for each little change, save them up and bump
> no more than once a year or less, each bump bringing in some major new
> feature. 

I got the impression that if anything there is a desire to allow EAPIs 
to change more offen, and not less.  And these changes could become more 
dramatic.  I'm not sure this is actually a bad thing (within reason - we 
do need to have clear specifications for anything that hits production 
so that we don't have a package manager mess).

Also - keep in mind that EAPIs do not need to be numbers and are not 
ordered.  You could have ebuild-i_am_a_furry_monkey or 
ebuild-<bunch-of-stuff-in-unicode-that-maybe-your-terminal-displays>. 
Sure - hopefully the names will be more sensible and somewhat uniform, 
but we're not necessarily just talking about adding a number to the 
extension.

I still don't see why we need to be encoding metadata in filenames. 
PERL doesn't care what a file extension is, python doesn't care, bzip2 
doesn't care, tar doesn't care, gzip doesn't care, and even ld-linux.so 
doesn't care.  I'm sure that in at least some of these cases they end up 
parsing parts of the file twice - once to figure out what it is, and the 
second time to actually handle it.  I'm actually hard pressed to think 
of any unix-based software that uses the filename to store a mandatory 
file format versioning specifier of some kind.

This seems to me to be a solved problem.  You put a header in a file 
that tells you how to read the file.  Headers are split into fields and 
if a program doesn't know what to do with a field it ignores it (or if 
the header so instructs it doesn't even try to parse the file).  This 
should be easy to do and keep the file bash-compatible.  Just stick a 
comment line close to the top of the file and put whatever you want on 
it.  You could also stick something in metadata.xml (although this makes 
working with ebuilds outside of a repository more difficult).  You run 
the file through an algorithm to find out what the EAPI is, and then 
source it if appropriate.

Sure, if you make some major change analogous to switching from the .rpm 
to the .deb package format then maybe an extension change would make 
sense.  But, why expose the inner workings of the package file format to 
the filesystem?