On Friday 15 May 2009 05:44:47 Richard Freeman wrote: > Ciaran McCreesh wrote: > > On Thu, 14 May 2009 20:06:51 +0200 > > > > Patrick Lauer <patr...@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... :)
If I understand the problem GLEP 55 is trying to solve correctly, it stems from portage's assumption that an unknown EAPI is equal to EAPI 0. Could that assumption be changed to an unknown EAPI is equal to the latest supported EAPI. Now I understand that this change would have to wait until all the ebuilds in the portage tree correctly define their EAPI, but would the idea be technically feasible at least excluding EAPI0 ebuilds? I think it would be if all EAPIs are forward compatible up until the EAPI declaration in the ebuild.
