Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

[Ciaran McCreesh]

On Wed, 25 Feb 2009 00:21:23 +0200
Petteri Räty <betelgeuse@g.o> 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