| 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. |
Archives