On Mon, 23 Feb 2009 09:28:06 -0500
Richard Freeman <rich0@g.o> wrote:
> 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.

But we're still only talking maybe three new EAPIs a year.

> 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.

You're using "developers might do something really stupid" as an
argument? By that logic, the current setup sucks since someone might
make an EAPI called a'b"c\d , so developers might have to put weird
escaping in when specifying EAPI.

Also note that kdebuild went with .kdebuild-1, not .ebuild-kdebuild-1.
It's no leap to have slightly different extension rules for any project
that creates its own non-numerical EAPIs.

> I still don't see why we need to be encoding metadata in filenames. 

Because the metadata has to be known before the file can be used.

> 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.

Back when Perl 5 and PHP 5 were new, people often used extensions
like .php4 and .php5 to tell their webserver how to handle scripts...

> 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.

That doesn't work with existing packages or existing package managers.

> 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?

For the same reason versions and package names are already in the
filename.

-- 
Ciaran McCreesh