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?
