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). -- Best regards, Michał Górny
signature.asc
Description: PGP signature
