1 |
On 09/02/2012 12:52 PM, Vaeth wrote: |
2 |
> Rich Freeman <rich0@g.o> wrote: |
3 |
> |
4 |
>> If I thought that bumping the EAPI would make my life as a maintainer |
5 |
>> easier I'd just do it - I wouldn't need a policy to tell me to do it. |
6 |
> |
7 |
> It is not only so much a question of whether it helps you as a |
8 |
> maintainer but more whether it helps the user. And this is the case |
9 |
> for all EAPIs which currently exist. |
10 |
> |
11 |
> I am surprised that nobody mentioned the following example: |
12 |
> |
13 |
> One of the arguments to introduce the user-patching code into EAPI=5 |
14 |
> was that it should work for all packages - not randomly on some but |
15 |
> not on others. So if in the course of time not all packages are |
16 |
> bumped to at least EAPI=5, this goal cannot be reached by introducing |
17 |
> the feature into the EAPI. |
18 |
|
19 |
global epatch_user has a downside which I think was not even really |
20 |
discussed here unless I missed something. It could introduce many bogus |
21 |
bug reports which are caused by user-applied patches, cause it's easier |
22 |
now and you don't need to do it in an overlay. |
23 |
The maintainer will need to catch this and asking which repo the |
24 |
bugreporter did use is not sufficient. He will need the build log and |
25 |
check if user patches got applied there. |
26 |
|
27 |
Always talking about the benefit for the user and not the time |
28 |
developers have to spend on things does not catch the whole situation. |
29 |
|
30 |
>> If I did think that bumping the EAPI wasn't worth the hassle, and yet |
31 |
>> I was told that I'd be banned as a dev for not doing so anyway, then |
32 |
>> obviously I'm going to do the minimum necessary to comply with policy, |
33 |
>> which means changing the EAPI line of the ebuild and only changing |
34 |
>> other lines as required to get the thing to build and comply with PMS. |
35 |
> |
36 |
> This is sufficient for 99% of the ebuilds. |
37 |
|
38 |
PMS is a fraction of what is to consider when writing an ebuild. It does |
39 |
not include QA policies, gentoo policies and whatnot. |
40 |
|
41 |
> |
42 |
>> So, while all those benefits you named are "enabled" few would |
43 |
>> actually be realized. |
44 |
> |
45 |
> For current EAPIs, most benefits are realized just by bumping EAPI. |
46 |
> For instance, the improved error checking (i.e. dying on certain problems) |
47 |
> happens automatically and might reveal problems which were hidden before. |
48 |
|
49 |
dying on certain problems can be achieved without EAPI bump. |
50 |
|
51 |
> |
52 |
> Also, for EAPI=5, other packages (possibly from overlays) can make use |
53 |
> of slot dependencies from your packages. |
54 |
> |
55 |
> OK, for changing from setup tests for USE dependencies and USE_REQUIRE |
56 |
> may require some extra coding (though not much), but again it is |
57 |
> the _user_ who will gain from it a lot. |
58 |
> |
59 |
|
60 |
If a user wants/needs features of newer EAPIs, because he does some |
61 |
things in his overlay, he could probably open a bug report with a |
62 |
proposed patch to the ebuild which bumps the EAPI. |
63 |
|
64 |
Unless that's the case I would leave it to the developer if he needs |
65 |
those features or what EAPI he prefers. If a newer EAPI would fix a bug |
66 |
it might still be solvable without EAPI-bump. Again: leave it to the |
67 |
developer. |
68 |
|
69 |
This will create a useless annoyance and I can assure you that |
70 |
developers WILL ignore this policy/rule. What are you gonna do then? |
71 |
Just bump it on your own without asking? Take it up to devrel? |
72 |
It's not really worth it. |
73 |
|
74 |
The benefits have been stated and it's already advised that developers |
75 |
keep up with the latest EAPI, but you _cannot_ assume it anyway like |
76 |
some PMS contributors do. |