| 1 |
On Wed, 27 Jul 2011 16:30:08 +0200 |
| 2 |
Chí-Thanh Christopher Nguyễn <chithanh@g.o> wrote: |
| 3 |
|
| 4 |
> Donnie Berkholz schrieb: |
| 5 |
> > Eclasses still shouldn't break backwards compatibility — that |
| 6 |
> > hasn't changed in the past 5 years, despite what a very small |
| 7 |
> > minority of devs appears to think. This has been a huge PITA for |
| 8 |
> > python.eclass in particular, which has broken tons of my ebuilds |
| 9 |
> > for no particular reason. (And no, a 30-day warning is not an |
| 10 |
> > excuse for breaking anything.) If you need to edit an eclass for |
| 11 |
> > EAPI/API changes anyway, updating the inherit line to "python-2" |
| 12 |
> > instead of "python" isn't a big deal. In the general sense, I think |
| 13 |
> > changing the API in arbitrary ways based on the EAPI in use is just |
| 14 |
> > plain confusing, and it should go into a new version-bumped eclass |
| 15 |
> > instead. |
| 16 |
> |
| 17 |
> I think making the eclass behave differently on new EAPIs is not a |
| 18 |
> bad way to deprecate old functions. It will not break any existing |
| 19 |
> ebuilds. Only if you touch the ebuild and change the EAPI things may |
| 20 |
> break, but then the ebuild has your attention anyway. |
| 21 |
|
| 22 |
That's one thing. Renaming variables and changing their formats |
| 23 |
is another one. |
| 24 |
|
| 25 |
> And there is no real disadvantage over a python.eclass that dies on |
| 26 |
> EAPI 4 and a python-2.eclass that dies on EAPI <=3 |
| 27 |
|
| 28 |
What I'd prefer instead, is a python.eclass that just behaves in EAPI 4 |
| 29 |
like usual, and a new python-r1.eclass which has a clean API |
| 30 |
(and possibly supports EAPIs 2+ or so). |
| 31 |
|
| 32 |
-- |
| 33 |
Best regards, |
| 34 |
Michał Górny |
Archives