1 |
Luca Barbato wrote: |
2 |
> Luca Barbato wrote: |
3 |
>> Ciaran McCreesh wrote: |
4 |
>>> Because your proposal addresses none of the underlying problems which |
5 |
>>> GLEP 55 was created to solve. |
6 |
> |
7 |
> let's get some numbers to have an idea of the dimension of the problem. |
8 |
> |
9 |
|
10 |
I just don't think those numbers tell us anything and that should be |
11 |
obvious from anyone who has read GLEP 55[1], we ain't really attempting |
12 |
to solve a problem that exists within the tree currently (well the bash |
13 |
issue does, in a way ). We are trying to solve issues that ware stopping |
14 |
the "tree" moving forward. Lets evaluate GLEP 55 in the problems it is |
15 |
attempting to solve. |
16 |
|
17 |
[1] |
18 |
Problem |
19 |
|
20 |
The current way of specifying the EAPI in ebuilds is flawed. In order to |
21 |
get the EAPI the package manager needs to source the ebuild, which |
22 |
itself needs the EAPI in the first place. Otherwise it imposes a serious |
23 |
limitation, namely every ebuild, using any of the future EAPIs, will |
24 |
have to be source'able by old package managers and hence there is no way |
25 |
to do any of the following: |
26 |
|
27 |
* Change the behaviour of inherit in any way (for example, to |
28 |
extend or change eclass functionality). |
29 |
* Add new global scope functions in any sane way. |
30 |
* Extend versioning rules in an EAPI - for example, addition of |
31 |
the scm suffix - GLEP54 [1]. |