Piotr Jaroszyński <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Mon, 17 Dec 2007 23:20:01 +0100:
> Let's call the EAPI included in the ebuild filename the pre-source EAPI, > and the EAPI set inside the ebuild the post-source EAPI. Given these > two, the final EAPI used by the ebuild can be established by following > these steps: > > * If the pre-source EAPI is not set it defaults to 0. > * If the pre-source EAPI is not recognised it is returned > immediately. > * If the post-source EAPI is not set, it defaults to the > pre-source EAPI. > * post-source EAPI is returned. > > The above process should be only used to generate the metadata cache. > Should the pre-source EAPI be unsupported the cache entry cannot be > generated. > > Ebuilds with unsupported EAPIs are masked. > > QA tools should consider it an error for both EAPIs to be set explicitly > to different values. Package managers may warn, but must use the > post-source EAPI in such cases. Up until that last quoted paragraph above, I had an entirely different idea of where this was headed. It's either incredibly stupid, or it's great outside-the-box thinking that just might be useful. Might as well ask or I'll never know. =8^) Put directly, what is stopping us from actually allowing DIFFERENT pre- source and post-source EAPI values? Here's the thinking. In the various PM discussions I've seen, it hasn't been unusual to see remarks about (previously) waiting for support in stable, and now about EAPI incompatibility, simply due to /parsing/ the ebuild. This could offer a way around the problem, by separating initial parsing/dependency EAPI and actual build/merge EAPI. The pre-source EAPI could state the EAPI support required to properly /source/parse/ the ebuild and generate the dependency tree, etc, while allowing the post- source EAPI to be different then allows additional flexibility in actual build/merge required EAPI. We'd then have two choices in terms of declaring pre-source support (as opposed to post-source, full merge support). 1) Simply that a compatible pre-source EAPI shouldn't blow up if sourced while calculating dependencies or the like -- the ebuild may be safely sourced and it shouldn't negatively affect the dependency tree for unrelated packages, but dependencies for that specific package may or may not be correct. -OR- 2) That a compatible pre-source EAPI package, when sourced, should allow generation of a reasonably reliable dependency tree for the package in question, presumably including a PM upgrade as part of that dependency tree. If we chose policy one, because unsupported pre-source EAPIs are explicitly NOT to be parsed, it would allow any arbitrary package format change as may eventually be found necessary, including breaking the bash- parsable assumption, if at some point that is found convenient. Conversely, supported pre-source EAPIs could at least be depended upon not to break the PM or dependency resolution for other branches of the dependency tree. As the ebuild was parsed, if a different post-source EAPI were found, a notice would be printed that said package couldn't be merged with the existing package manager, but the other branches of the update/merge would proceed, allowing the incompatibility for that package to be resolved later. If we chose policy two and pre-source and post-source EAPIs differed, part of the dependency tree for that package should include a PM supporting the post-source EAPI, in which case the other (post-source EAPI compatible) branches could be merged, then the required post-EAPI PM (presumably an upgrade, remember, this would ONLY occur if the two EAPIs differed so it wouldn't happen in the general case) would be merged, that specific package dependency tree branch recalculated post PM upgrade, and then that package merged. So the difference between policies for the user would be policy one would generally require a manual PM change intervention, while policy two could at least in theory (absent explicit blockers, etc) be handled entirely automatically. Policy two has stricter requirements for developers, however, and would thus be easier to break. OK, so it's off the wall, but tell me, is it useful and implementable, or just stupid? -- 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 -- [EMAIL PROTECTED] mailing list
