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