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