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 |