| 1 |
On 09:39 Wed 27 Jul , Michał Górny wrote: |
| 2 |
> As many of us already raged, the Python eclasses are delaying half a |
| 3 |
> year with support of EAPI=4. The reason for that is not actually the |
| 4 |
> lack of time or complexity of needed changes but willingness to use |
| 5 |
> the new EAPI as an excuse to turn the eclass API upside down. |
| 6 |
> |
| 7 |
> The question I'm raising here: should eclasses be actually allowed to |
| 8 |
> do *heavy* changes in their APIs in such cases? Or should the eclass |
| 9 |
> maintainers create a new eclass instead (python-r1.eclass or so)? |
| 10 |
|
| 11 |
Eclasses still shouldn't break backwards compatibility — that hasn't |
| 12 |
changed in the past 5 years, despite what a very small minority of devs |
| 13 |
appears to think. This has been a huge PITA for python.eclass in |
| 14 |
particular, which has broken tons of my ebuilds for no particular |
| 15 |
reason. (And no, a 30-day warning is not an excuse for breaking |
| 16 |
anything.) |
| 17 |
|
| 18 |
If you need to edit an eclass for EAPI/API changes anyway, updating the |
| 19 |
inherit line to "python-2" instead of "python" isn't a big deal. |
| 20 |
|
| 21 |
In the general sense, I think changing the API in arbitrary ways based |
| 22 |
on the EAPI in use is just plain confusing, and it should go into a new |
| 23 |
version-bumped eclass instead. |
| 24 |
|
| 25 |
-- |
| 26 |
Thanks, |
| 27 |
Donnie |
| 28 |
|
| 29 |
Donnie Berkholz |
| 30 |
Council Member / Sr. Developer |
| 31 |
Gentoo Linux |
| 32 |
Blog: http://dberkholz.com |
Archives