On Tue, 18 Dec 2007 09:53:50 +0000 (UTC) Duncan <[EMAIL PROTECTED]> 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
signature.asc
Description: PGP signature
