| 1 |
Patrick Lauer schrieb: |
| 2 |
> On 03/11/12 21:52, Rich Freeman wrote: |
| 3 |
>> On Sun, Mar 11, 2012 at 9:28 AM, Patrick Lauer <patrick@g.o> wrote: |
| 4 |
>>> I'd deprecate eapi2 too, we don't need 5 flavours around when we |
| 5 |
>>> effectively only want to support one (and eapi0 in a few places) |
| 6 |
>>> |
| 7 |
>>> I wouldn't mind having a deprecation timeline for eapi3 too (now +6 |
| 8 |
>>> months maybe?), but there's no need to rush things. |
| 9 |
>> |
| 10 |
>> Is there really much of a benefit to this? |
| 11 |
> |
| 12 |
> Let me phrase it like this: |
| 13 |
> Can you list all differences between EAPI 1,2,3 and 4? |
| 14 |
> |
| 15 |
> It's a lot easier for everyone involved when you don't need to care |
| 16 |
> about all the special cases (like src_prepare not running) because |
| 17 |
> you've standardized on one EAPI for support |
| 18 |
> |
| 19 |
> (Legacy code can be slowly phased out or upgraded, but I don't want to |
| 20 |
> remember if I can use slot-deps or use-deps and all those "irrelevant" |
| 21 |
> details) |
| 22 |
|
| 23 |
You dont have to. The suggested EAPI for new ebuilds is already the |
| 24 |
latest one and you are free to use that. |
| 25 |
|
| 26 |
On the other side, if someone wants to use some other EAPI for whatever |
| 27 |
reason, why should he not be allowed to do so? He has to maintain it and |
| 28 |
any EAPI changes. |
| 29 |
|
| 30 |
Additionally, an ebuild with a lower EAPI may already exist for a long |
| 31 |
time, this would force the dev to convert it to a newer EAPI to be |
| 32 |
allowed to add it to the main tree, also the existing ebuild works just |
| 33 |
fine. |
| 34 |
|
| 35 |
-- |
| 36 |
|
| 37 |
Thomas Sachau |
| 38 |
Gentoo Linux Developer |
Archives