Donnie Berkholz schrieb:
Eclasses still shouldn't break backwards compatibility — that hasn't changed in the past 5 years, despite what a very small minority of devs appears to think. This has been a huge PITA for python.eclass in particular, which has broken tons of my ebuilds for no particular reason. (And no, a 30-day warning is not an excuse for breaking anything.) If you need to edit an eclass for EAPI/API changes anyway, updating the inherit line to "python-2" instead of "python" isn't a big deal. In the general sense, I think changing the API in arbitrary ways based on the EAPI in use is just plain confusing, and it should go into a new version-bumped eclass instead.
I think making the eclass behave differently on new EAPIs is not a bad way to deprecate old functions. It will not break any existing ebuilds. Only if you touch the ebuild and change the EAPI things may break, but then the ebuild has your attention anyway.
And there is no real disadvantage over a python.eclass that dies on EAPI 4 and a python-2.eclass that dies on EAPI <=3
Best regards, Chí-Thanh Christopher Nguyễn
