Gentoo Archives: gentoo-dev

From: "Petteri Räty" <betelgeuse@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Turning eclasses upside down with new EAPIs (the python eclasses)
Date: Wed, 27 Jul 2011 14:42:19
Message-Id: 4E302358.90408@gentoo.org
In Reply to: Re: [gentoo-dev] Turning eclasses upside down with new EAPIs (the python eclasses) by "Chí-Thanh Christopher Nguyễn"
1 On 27.07.2011 17:30, Chí-Thanh Christopher Nguyễn wrote:
2 > Donnie Berkholz schrieb:
3 >> Eclasses still shouldn't break backwards compatibility — that hasn't
4 >> changed in the past 5 years, despite what a very small minority of
5 >> devs appears to think. This has been a huge PITA for python.eclass in
6 >> particular, which has broken tons of my ebuilds for no particular
7 >> reason. (And no, a 30-day warning is not an excuse for breaking
8 >> anything.) If you need to edit an eclass for EAPI/API changes anyway,
9 >> updating the inherit line to "python-2" instead of "python" isn't a
10 >> big deal. In the general sense, I think changing the API in arbitrary
11 >> ways based on the EAPI in use is just plain confusing, and it should
12 >> go into a new version-bumped eclass instead.
13 >
14 > I think making the eclass behave differently on new EAPIs is not a bad
15 > way to deprecate old functions. It will not break any existing ebuilds.
16 > Only if you touch the ebuild and change the EAPI things may break, but
17 > then the ebuild has your attention anyway.
18 >
19
20 I agree there's no problem with small deprecations with new EAPIs as
21 long as they are handled properly (it doesn't break backwards
22 compatibility) so that ebuilds authors notice they must change things.
23 If the eclass turns into a wholly different thing then it should rather
24 be a new eclass.
25
26 Regards,
27 Petteri

Attachments

File name MIME type
signature.asc application/pgp-signature