Michał Górny schrieb: > On Wed, 27 Jul 2011 16:30:08 +0200 > Chí-Thanh Christopher Nguyễn <chith...@gentoo.org> wrote: > >> 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. > > That's one thing. Renaming variables and changing their formats > is another one. > >> 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 > > What I'd prefer instead, is a python.eclass that just behaves in EAPI 4 > like usual, and a new python-r1.eclass which has a clean API > (and possibly supports EAPIs 2+ or so). >
I fully support the idea of just adding EAPI-4 support to the python eclass without any API changes and doing those changes in e.g. python-r1 eclass. It was already very frustrating, when the python eclass created additional changes per EAPI, same for those forced EAPI moves. You should never need to learn the new behaviour of an eclass, just because you want to change the EAPI in your ebuild. Such changes should be done in a new eclass, which both means a clean start and no compromise due to existing behaviour in the python eclass and less trouble for users of such eclass, since they only have to know the normal EAPI changes. Just because Arfrever did such things to the python eclass, it still is no good idea and should not be continued.
signature.asc
Description: OpenPGP digital signature
