Duncan wrote:
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.
I think that it does address ONE aspect of the limitations of putting EAPI in the build - but not all.
One issue with EAPI in the build is figuring out what it is without sourcing the ebuild (possibly using a package manager that doesn't realize that it doesn't know how to source it).
If the developer of an ebuild prepares the manifest, then at least their package manager will know how to handle the ebuild and extract the EAPI. Now, that could still be messy if it needs to source the ebuild 3 ways before finding the one that delivers the correct EAPI. However, end-user package managers wouldn't need to source the ebuild to figure out the EAPI.
Potentially the developer could just manually put the EAPI in the manifest (or use a tool to do this). Obviously this is an extra step when adding ebuilds to the tree, but that would completely address the issues with sourcing builds.
Changing the manifest format of course creates backwards compatibility issues.
So, I wouldn't dismiss this idea out of hand - it isn't completely equivalent to the other options.
