| 1 |
On 03/11/12 21:52, Rich Freeman wrote: |
| 2 |
> On Sun, Mar 11, 2012 at 9:28 AM, Patrick Lauer <patrick@g.o> wrote: |
| 3 |
>> I'd deprecate eapi2 too, we don't need 5 flavours around when we |
| 4 |
>> effectively only want to support one (and eapi0 in a few places) |
| 5 |
>> |
| 6 |
>> I wouldn't mind having a deprecation timeline for eapi3 too (now +6 |
| 7 |
>> months maybe?), but there's no need to rush things. |
| 8 |
> |
| 9 |
> Is there really much of a benefit to this? |
| 10 |
|
| 11 |
Let me phrase it like this: |
| 12 |
Can you list all differences between EAPI 1,2,3 and 4? |
| 13 |
|
| 14 |
It's a lot easier for everyone involved when you don't need to care |
| 15 |
about all the special cases (like src_prepare not running) because |
| 16 |
you've standardized on one EAPI for support |
| 17 |
|
| 18 |
(Legacy code can be slowly phased out or upgraded, but I don't want to |
| 19 |
remember if I can use slot-deps or use-deps and all those "irrelevant" |
| 20 |
details) |
| 21 |
|
| 22 |
> I guess for anybody who |
| 23 |
> runs scripts to mass-manipulate ebuilds it might be helpful, but I |
| 24 |
> think all the package managers planned on supporting all the EAPIs for |
| 25 |
> quite a while longer. |
| 26 |
|
| 27 |
That's orthogonal to the discussion - I think the goal is to reduce the |
| 28 |
amount of errors introduced by confusing features and making the |
| 29 |
documentation more streamlined ("Here's the EAPI you use" instead of "if |
| 30 |
you want to learn about eapi2 go to page 62. If you don't go to page 84") |
| 31 |
> |
| 32 |
> I can imagine that this will lead to quite a bit of churn with |
| 33 |
> updating ebuilds and especially eclasses. If a package doesn't |
| 34 |
> require a feature in a newer EAPI, what is the point? |
| 35 |
Eclasses are up-to-date as far as I remember, and it's just *new* things |
| 36 |
that get motivated to eapi3/4 - force-updating is silly |
Archives