1 |
On 12/31/2010 01:02 PM, Ulrich Mueller wrote: |
2 |
> Hi, |
3 |
> |
4 |
> after approval of EAPI 4, there are now 5 different EAPIs available, |
5 |
> and it's hard to remember what features are offered by which EAPI. |
6 |
> |
7 |
> So maybe it's about time that we deprecate EAPIs 0 and 1 for new |
8 |
> ebuilds. As a first step, a warning could be added to repoman that |
9 |
> would be triggered whenever a new ebuild with an EAPI less than 2 is |
10 |
> committed. |
11 |
> |
12 |
|
13 |
First we need to be sure that all relevant eclasses support upgrading to |
14 |
EAPI 2. As plenty of ebuilds are still in EAPI 0 it's likely that some |
15 |
eclasses are too. But I do second the idea of trying to limit the set of |
16 |
active EAPIs in the tree. Please open a repoman bug if there are no |
17 |
objections. |
18 |
|
19 |
> At a later time, the warning could be changed to an error. When most |
20 |
> of the tree has been updated to EAPI 2 or newer, we could also think |
21 |
> about actively converting the remaining ebuilds. (Currently this |
22 |
> doesn't look feasible though, as about half of the tree is still at |
23 |
> EAPI=0. [1]) |
24 |
> |
25 |
|
26 |
EAPI 0 might stick around for quite a while but for example deprecating |
27 |
EAPI 1 shouldn't be as hard. |
28 |
|
29 |
Regards, |
30 |
Petteri |