Re: [gentoo-dev] The fallacies of GLEP55

[Richard Freeman <rich0@gentoo.org>]

Ciaran McCreesh wrote:
> On Thu, 14 May 2009 20:06:51 +0200
> Patrick Lauer <patrick@gentoo.org> wrote:
>> Let EAPI be defined as (the part behind the = of) the first line of
>> the ebuild starting with EAPI=
> 
> Uh, so horribly utterly and obviously wrong.
> 
>     inherit foo
>     EAPI=4
> 
> where foo is both a global and a non-global eclass that sets metadata.
> 

This seems to come up from time to time but I don't see how this is a 
problem that GLEP 55 solves.  If the rule is "first line of the ebuild 
starting with EAPI=" and the ebuild is as you suggest above, then the 
EAPI is 4 (without any regard whatsoever to what might be in "foo").

The counterargument seems to be that eclasses should be able to modify 
EAPI behavior.  However, if you want to do this then you DEFINITELY 
don't want to put the EAPI in the filename - unless you want eclasses to 
start renaming the ebuilds to change their EAPIs and then trigger a 
metadata regen.

This seems to be a case where a problem is proposed, with a solution. 
Somebody proposes an alternate solution and the complaint is raised that 
it doesn't handle situation X.  However, the original proposed solution 
doesn't handle situation X either, so that can hardly be grounds for 
accepting it over the alternate.

I'm actually more in favor of an approach like putting the EAPI in a 
comment line or some other place that is more "out-of-band".  Almost all 
modern file formats incorporate a version number into a fixed position 
in the file header so that it is trivial for a program to figure out 
whether or not it knows how to handle the file.  Another common approach 
is to put a header-length field and add extensions to the end of a 
header, so that as long as you don't break past behavior you could 
create a file that is readable by older program versions (perhaps with 
the loss of some metadata that the older version doesn't understand). 
Just look up the UStar tar file format or the gzip file format for 
examples.   Of course, such file formats generally aren't designed to be 
human-readable or created with a text editor.

The same applies to executables.  It is impossible from the filename to 
tell if /bin/bash is in a.out or ELF format, or if it is a shell script. 
  Instead a simple standard is defined that allows the OS to figure it 
out and handle it appropriately.  If you try to run an ELF on some 
ancient version of linux it doesn't crash or perform erratic behavior - 
it will simply tell you that it doesn't understand the file format 
(invalid magic number).

In any case, I'm going to try to restrain myself from replying further 
in this thread unless something genuinely new comes up.  When I see 26 
new messages in my gentoo-dev folder I should know by now that somebody 
has managed to bring up GLEP 55 again...  :)