1 |
Ciaran McCreesh wrote: |
2 |
> On Thu, 14 May 2009 20:06:51 +0200 |
3 |
> Patrick Lauer <patrick@g.o> wrote: |
4 |
>> Let EAPI be defined as (the part behind the = of) the first line of |
5 |
>> the ebuild starting with EAPI= |
6 |
> |
7 |
> Uh, so horribly utterly and obviously wrong. |
8 |
> |
9 |
> inherit foo |
10 |
> EAPI=4 |
11 |
> |
12 |
> where foo is both a global and a non-global eclass that sets metadata. |
13 |
> |
14 |
|
15 |
This seems to come up from time to time but I don't see how this is a |
16 |
problem that GLEP 55 solves. If the rule is "first line of the ebuild |
17 |
starting with EAPI=" and the ebuild is as you suggest above, then the |
18 |
EAPI is 4 (without any regard whatsoever to what might be in "foo"). |
19 |
|
20 |
The counterargument seems to be that eclasses should be able to modify |
21 |
EAPI behavior. However, if you want to do this then you DEFINITELY |
22 |
don't want to put the EAPI in the filename - unless you want eclasses to |
23 |
start renaming the ebuilds to change their EAPIs and then trigger a |
24 |
metadata regen. |
25 |
|
26 |
This seems to be a case where a problem is proposed, with a solution. |
27 |
Somebody proposes an alternate solution and the complaint is raised that |
28 |
it doesn't handle situation X. However, the original proposed solution |
29 |
doesn't handle situation X either, so that can hardly be grounds for |
30 |
accepting it over the alternate. |
31 |
|
32 |
I'm actually more in favor of an approach like putting the EAPI in a |
33 |
comment line or some other place that is more "out-of-band". Almost all |
34 |
modern file formats incorporate a version number into a fixed position |
35 |
in the file header so that it is trivial for a program to figure out |
36 |
whether or not it knows how to handle the file. Another common approach |
37 |
is to put a header-length field and add extensions to the end of a |
38 |
header, so that as long as you don't break past behavior you could |
39 |
create a file that is readable by older program versions (perhaps with |
40 |
the loss of some metadata that the older version doesn't understand). |
41 |
Just look up the UStar tar file format or the gzip file format for |
42 |
examples. Of course, such file formats generally aren't designed to be |
43 |
human-readable or created with a text editor. |
44 |
|
45 |
The same applies to executables. It is impossible from the filename to |
46 |
tell if /bin/bash is in a.out or ELF format, or if it is a shell script. |
47 |
Instead a simple standard is defined that allows the OS to figure it |
48 |
out and handle it appropriately. If you try to run an ELF on some |
49 |
ancient version of linux it doesn't crash or perform erratic behavior - |
50 |
it will simply tell you that it doesn't understand the file format |
51 |
(invalid magic number). |
52 |
|
53 |
In any case, I'm going to try to restrain myself from replying further |
54 |
in this thread unless something genuinely new comes up. When I see 26 |
55 |
new messages in my gentoo-dev folder I should know by now that somebody |
56 |
has managed to bring up GLEP 55 again... :) |