[gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Duncan]

Piotr Jaroszyński <peper@g.o> posted
200712172320.01988.peper@g.o, 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

-- 
gentoo-dev@g.o mailing list