Rich Freeman <ri...@gentoo.org> wrote:
If I thought that bumping the EAPI would make my life as a maintainer easier I'd just do it - I wouldn't need a policy to tell me to do it.
It is not only so much a question of whether it helps you as a maintainer but more whether it helps the user. And this is the case for all EAPIs which currently exist. I am surprised that nobody mentioned the following example: One of the arguments to introduce the user-patching code into EAPI=5 was that it should work for all packages - not randomly on some but not on others. So if in the course of time not all packages are bumped to at least EAPI=5, this goal cannot be reached by introducing the feature into the EAPI.
If I did think that bumping the EAPI wasn't worth the hassle, and yet I was told that I'd be banned as a dev for not doing so anyway, then obviously I'm going to do the minimum necessary to comply with policy, which means changing the EAPI line of the ebuild and only changing other lines as required to get the thing to build and comply with PMS.
This is sufficient for 99% of the ebuilds.
So, while all those benefits you named are "enabled" few would actually be realized.
For current EAPIs, most benefits are realized just by bumping EAPI. For instance, the improved error checking (i.e. dying on certain problems) happens automatically and might reveal problems which were hidden before. Also, for EAPI=5, other packages (possibly from overlays) can make use of slot dependencies from your packages. OK, for changing from setup tests for USE dependencies and USE_REQUIRE may require some extra coding (though not much), but again it is the _user_ who will gain from it a lot. So in any case, for the _user_ an EAPI bump is (with the current EAPIs) always a benefit. This should be worth to establish the policy currently. If this happens to be different in some hypothetical future EAPIs, this policy can be modified later, correspondingly: It is easy to change this policy later on, but hard to bump the whole tree later on. Martin Väth
