On Mon, 23 Feb 2009 09:28:06 -0500 Richard Freeman <ri...@gentoo.org> 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
signature.asc
Description: PGP signature
