[gentoo-dev] Re: Collecting opinions about GLEP 55 and alternatives

[Duncan]

Jacob Floyd <techgurufloyd+gentoo.lists@×××××.com> posted
4afbebfe0903090601r5759177bt98639c0c3a61b894@××××××××××.com, excerpted
below, on  Mon, 09 Mar 2009 07:01:21 -0600:

> Stick EAPI info in the Manifest. The Manifest stores metadata info about
> the ebuilds for security and validation purposes, why not add a string
> that determines which eapi to use? This then would be generated every
> time someone did an "ebuild foo-1.0.ebuild digest". To specify the eapi
> version, the developer would specify, as is now, EAPI="bla" in his
> ebuild, and grep or similar would be used to extract this when the
> digest is created.

So ultimately, you leave it in the ebuild, but duplicate it in the 
manifest... which has its own problems, one of which is that it 
ultimately falls back to getting the info from the ebuild so it has the 
same problems that does.

The problem with getting EAPI from the ebuild is that as currently speced 
in PMS, EAPI cannot be grepped, the ebuild must really be sourced to get 
it, because it may be changed in eclasses or set and repeatedly changed, 
etc.  And that doesn't really work going forward, because you end up 
needing to know the EAPI in ordered to source the ebuild properly to get 
it.  (It has only worked thus far because changes have been restricted to 
ensure it DOES still work, but that's not practical going forward as it 
really IS restrictive.)

By the time you fix that, you're back at one of the other 
implementations, effectively decreeing that the EAPI once set (or the 
EAPI major version, at least, in a major/minor EAPI versioning variant 
proposal) can't change and putting it either in the ebuild name/
extension, or in a location sufficiently nailed down in the ebuild that 
it can be scanned directly, line X, or whatever, or at /minimum/ 
narrowing the spec so that it must be early in the ebuild, before 
inherits, etc (there's a series of post by CiaranM with way more 
technical detail on exactly how the new requirement would have to be 
worded).

So putting it in the manifest but generated from the ebuild info really 
doesn't change the problem, leaving us precisely where we were before, 
except that it may be useful as a component of one of the other 
solutions, and has been proposed as such in a few of the suggested 
variants.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman