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

[Ciaran McCreesh]

On Tue, 18 Dec 2007 09:53:50 +0000 (UTC)
Duncan <1i5t5.duncan@×××.net> wrote:
> Put directly, what is stopping us from actually allowing DIFFERENT
> pre- source and post-source EAPI values?

That's effectively what happens when a package manager sources a
current EAPI=1 in a variable ebuild.

> 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).

There's no advantage to doing so. If you don't support the EAPI, the
only thing you can do is say that you don't support the EAPI.

> 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.

But all you get is the knowledge that the ebuild uses an unsupported
EAPI. Which you know already.

I should state this explicitly:

If an ebuild's EAPI isn't recognised by the package manager, the
package manager can't and mustn't "sort of" work with that ebuild;
there is no such thing as a "sort of supported" EAPI. The package
manager can either ignore the ebuild entirely or display it in some kind
of super fancy "masked due to EAPI" way -- and if it does the latter,
the *only* information the package manager has about the ebuild is that
its EAPI is unsupported. The package manager can't guess "ooh, well it
sets SLOT, so I can assume that SLOT means what I think it does" -- a
future EAPI might do something crazy like say that "if SLOT=dynamic, the
speshul pkg_slot function is used". The package manager can't even
assume that it knows what the unsupported EAPI's name really is or that
it knows what the unsupported package's version is.

> 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.

EAPIs aren't to specify the dependency tree.

There's the added problem that it breaks the concept of metadata cache.
That gets hairy.

> OK, so it's off the wall, but tell me, is it useful and
> implementable, or just stupid?

It's implementable. It would just be of no use.

-- 
Ciaran McCreesh