Jacob Floyd <techgurufloyd+gentoo.li...@gmail.com> posted 4afbebfe0903090601r5759177bt98639c0c3a61b...@mail.gmail.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
