Patrick Lauer schrieb: > On 03/11/12 21:52, Rich Freeman wrote: >> On Sun, Mar 11, 2012 at 9:28 AM, Patrick Lauer 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) You dont have to. The suggested EAPI for new ebuilds is already the latest one and you are free to use that. On the other side, if someone wants to use some other EAPI for whatever reason, why should he not be allowed to do so? He has to maintain it and any EAPI changes. Additionally, an ebuild with a lower EAPI may already exist for a long time, this would force the dev to convert it to a newer EAPI to be allowed to add it to the main tree, also the existing ebuild works just fine. -- Thomas Sachau Gentoo Linux Developer