| 1 |
On Friday 09 October 2009 00:22:26 Petteri Räty wrote: |
| 2 |
|
| 3 |
> >> across a case that couldn't be done with EAPI 2 yet. Granted the atoms |
| 4 |
> >> can be a bit cleaner with EAPI 3 but considering how much zmedico slacks |
| 5 |
> >> in implementing it, it's best to do migrating now with EAPI 2 than EAPI |
| 6 |
> > |
| 7 |
> > Comments like these are not acceptable. Zac works his tail off on |
| 8 |
> > portage. Please refrain from such comments in the future. |
| 9 |
> > -Jeremy |
| 10 |
> |
| 11 |
> He has said himself that he is not especially interested in implementing |
| 12 |
> EAPI 3 so slack at least to me seems like a good term. |
| 13 |
|
| 14 |
I'm not sold on it either. Most devs barely know the difference between |
| 15 |
different EAPIs (just extrapolating from the many questions I see e.g. on IRC) |
| 16 |
(and I think they shouldn't have to know because we should be using one EAPI |
| 17 |
only, but that's just my random opinion) |
| 18 |
|
| 19 |
Most ebuilds are still EAPI0 - rough count gives me: |
| 20 |
|
| 21 |
EAPI 0 - 19654 |
| 22 |
EAPI 1 - 1651 |
| 23 |
EAPI 2 - 5497 |
| 24 |
|
| 25 |
And that's with all the "forced" migrations for features like use-deps or the |
| 26 |
removal of built_with_use. So unless there's some "strongly needed" features |
| 27 |
there's no need for it. I can't remember any feature in the EAPI 3 list that |
| 28 |
really looked useful to me, so not adding it now now now doesn't bother me at |
| 29 |
all. Just causes more confusion for no real benefit. So who cares if it is |
| 30 |
delayed by a few timeunits, there's much more important stuff to do. |
Archives