Luca Barbato wrote:
> Luca Barbato wrote:
>> Ciaran McCreesh wrote:
>>> Because your proposal addresses none of the underlying problems which
>>> GLEP 55 was created to solve.
> 
> let's get some numbers to have an idea of the dimension of the problem.
> 

I just don't think those numbers tell us anything and that should be
obvious from anyone who has read GLEP 55[1],  we ain't really attempting
to solve a problem that exists within the tree currently (well the bash
issue does, in a way ). We are trying to solve issues that ware stopping
the "tree" moving forward.  Lets evaluate GLEP 55 in the problems it is
attempting to solve.

[1]
Problem

The current way of specifying the EAPI in ebuilds is flawed. In order to
get the EAPI the package manager needs to source the ebuild, which
itself needs the EAPI in the first place. Otherwise it imposes a serious
limitation, namely every ebuild, using any of the future EAPIs, will
have to be source'able by old package managers and hence there is no way
to do any of the following:

        * Change the behaviour of inherit in any way (for example, to
extend or change eclass functionality).
        * Add new global scope functions in any sane way.
        * Extend versioning rules in an EAPI - for example, addition of
the scm suffix - GLEP54 [1].