1 |
On Mon, 23 Feb 2009 09:28:06 -0500 |
2 |
Richard Freeman <rich0@g.o> wrote: |
3 |
> I got the impression that if anything there is a desire to allow |
4 |
> EAPIs to change more offen, and not less. And these changes could |
5 |
> become more dramatic. |
6 |
|
7 |
But we're still only talking maybe three new EAPIs a year. |
8 |
|
9 |
> Also - keep in mind that EAPIs do not need to be numbers and are not |
10 |
> ordered. You could have ebuild-i_am_a_furry_monkey or |
11 |
> ebuild-<bunch-of-stuff-in-unicode-that-maybe-your-terminal-displays>. |
12 |
> Sure - hopefully the names will be more sensible and somewhat |
13 |
> uniform, but we're not necessarily just talking about adding a number |
14 |
> to the extension. |
15 |
|
16 |
You're using "developers might do something really stupid" as an |
17 |
argument? By that logic, the current setup sucks since someone might |
18 |
make an EAPI called a'b"c\d , so developers might have to put weird |
19 |
escaping in when specifying EAPI. |
20 |
|
21 |
Also note that kdebuild went with .kdebuild-1, not .ebuild-kdebuild-1. |
22 |
It's no leap to have slightly different extension rules for any project |
23 |
that creates its own non-numerical EAPIs. |
24 |
|
25 |
> I still don't see why we need to be encoding metadata in filenames. |
26 |
|
27 |
Because the metadata has to be known before the file can be used. |
28 |
|
29 |
> PERL doesn't care what a file extension is, python doesn't care, |
30 |
> bzip2 doesn't care, tar doesn't care, gzip doesn't care, and even |
31 |
> ld-linux.so doesn't care. I'm sure that in at least some of these |
32 |
> cases they end up parsing parts of the file twice - once to figure |
33 |
> out what it is, and the second time to actually handle it. I'm |
34 |
> actually hard pressed to think of any unix-based software that uses |
35 |
> the filename to store a mandatory file format versioning specifier of |
36 |
> some kind. |
37 |
|
38 |
Back when Perl 5 and PHP 5 were new, people often used extensions |
39 |
like .php4 and .php5 to tell their webserver how to handle scripts... |
40 |
|
41 |
> This seems to me to be a solved problem. You put a header in a file |
42 |
> that tells you how to read the file. Headers are split into fields |
43 |
> and if a program doesn't know what to do with a field it ignores it |
44 |
> (or if the header so instructs it doesn't even try to parse the |
45 |
> file). This should be easy to do and keep the file bash-compatible. |
46 |
> Just stick a comment line close to the top of the file and put |
47 |
> whatever you want on it. |
48 |
|
49 |
That doesn't work with existing packages or existing package managers. |
50 |
|
51 |
> Sure, if you make some major change analogous to switching from |
52 |
> the .rpm to the .deb package format then maybe an extension change |
53 |
> would make sense. But, why expose the inner workings of the package |
54 |
> file format to the filesystem? |
55 |
|
56 |
For the same reason versions and package names are already in the |
57 |
filename. |
58 |
|
59 |
-- |
60 |
Ciaran McCreesh |