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