1 |
Rich Freeman <rich0@g.o> wrote: |
2 |
|
3 |
> If I thought that bumping the EAPI would make my life as a maintainer |
4 |
> easier I'd just do it - I wouldn't need a policy to tell me to do it. |
5 |
|
6 |
It is not only so much a question of whether it helps you as a |
7 |
maintainer but more whether it helps the user. And this is the case |
8 |
for all EAPIs which currently exist. |
9 |
|
10 |
I am surprised that nobody mentioned the following example: |
11 |
|
12 |
One of the arguments to introduce the user-patching code into EAPI=5 |
13 |
was that it should work for all packages - not randomly on some but |
14 |
not on others. So if in the course of time not all packages are |
15 |
bumped to at least EAPI=5, this goal cannot be reached by introducing |
16 |
the feature into the EAPI. |
17 |
|
18 |
> If I did think that bumping the EAPI wasn't worth the hassle, and yet |
19 |
> I was told that I'd be banned as a dev for not doing so anyway, then |
20 |
> obviously I'm going to do the minimum necessary to comply with policy, |
21 |
> which means changing the EAPI line of the ebuild and only changing |
22 |
> other lines as required to get the thing to build and comply with PMS. |
23 |
|
24 |
This is sufficient for 99% of the ebuilds. |
25 |
|
26 |
> So, while all those benefits you named are "enabled" few would |
27 |
> actually be realized. |
28 |
|
29 |
For current EAPIs, most benefits are realized just by bumping EAPI. |
30 |
For instance, the improved error checking (i.e. dying on certain problems) |
31 |
happens automatically and might reveal problems which were hidden before. |
32 |
|
33 |
Also, for EAPI=5, other packages (possibly from overlays) can make use |
34 |
of slot dependencies from your packages. |
35 |
|
36 |
OK, for changing from setup tests for USE dependencies and USE_REQUIRE |
37 |
may require some extra coding (though not much), but again it is |
38 |
the _user_ who will gain from it a lot. |
39 |
|
40 |
So in any case, for the _user_ an EAPI bump is (with the current EAPIs) |
41 |
always a benefit. This should be worth to establish the policy currently. |
42 |
|
43 |
If this happens to be different in some hypothetical future EAPIs, |
44 |
this policy can be modified later, correspondingly: It is easy to |
45 |
change this policy later on, but hard to bump the whole tree later on. |
46 |
|
47 |
Martin Väth |