On Wed, 25 Feb 2009 00:21:23 +0200 Petteri Räty <betelge...@gentoo.org> wrote: > 3) EAPI in locked down place in the ebuild
There's a less extreme variant on this that's slightly cleaner, and with appropriate weaseling is also less messy. Simply add the following very carefully worded additional requirement for future EAPIs, and retroactively impose it upon current ones: If EAPI is to be set, it must be set strictly before any global scope command or package manager defined function is called. Once set, EAPI must not be set to a different value. Then, the migration path is as follows: * Fix existing violations (including ones in overlays). Wait a while until everyone's synced. * Get package managers to make use of these stricter requirements to avoid barfing ickily when using things with future EAPIs with different global scope rules. * Wait a year. New EAPIs can come out in the mean time, but they can't change global scope behaviour. * Use that year to migrate to the key=value cache format with a second, package-manager-only versioned variable that lets package managers check cache validity even for unsupported EAPIs so long as there aren't any cache validation rule changes. * Change global scope behaviour in new EAPIs at will, but not versioning rules. Note that this is functionally equivalent to Brian's eapi as a function proposal, but much less messy. It's also as powerful for the package manager as fixed-position, but less inflexible. So if you must go with something other than GLEP 55, along with all the restrictions and mess that doing so imposes, this is the one to pick... -- Ciaran McCreesh
signature.asc
Description: PGP signature
