On Fri, Aug 31, 2012 at 5:03 AM, Andreas K. Huettel <dilfri...@gentoo.org> wrote: > <rant> > Let's say, we as in Gentoo decide that we're completely sick of keeping all > that old code out there adjusted to newer and newer gcc versions that are more > and more critical towards minor details of the c++ standards. So, we declare > that gcc-4.5 has to be enough for everyone, we'll just keep it in tree forever > and dont bother anymore with all these superfluous "does not build with > gcc-4.7" bugs.
That is not an appropriate analogy, as I'm not suggesting that we refuse to support newer EAPIs. I'm just saying that packages shouldn't be bumped just for the sake of bumping them. > > Give me one non-trivial ebuild where you can absolutely guarantee that a bump > from EAPI=0 to EAPI=4 will not enable any improvements (in readability, > failsafe behaviour and code size for example). Suppose for the sake of argument that no such ebuild exists. I still maintain that there is little benefit from forcing an EAPI bump on new ebuilds. 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. The only reason you'd need a policy is if I as a maintainer figured that bumping the EAPI was more hassle than whatever benefits I get down the road from all those improvements. 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. So, while all those benefits you named are "enabled" few would actually be realized. > > Last point, if someday the tree contains ebuilds with 7-8 different EAPI's, > we'll have succeeded in generating an unmaintainable mess (tm). It will not be > any fun to look up things in PMS anew everytime you edit something. I suspect that most devs just edit things that they maintain, and that means that they can control how many EAPIs are in use in those ebuilds. Again, devs already have incentive to make their own lives earlier - we don't need to turn that into policy. I might see some benefit for devs who routinely modify stuff that they don't maintain, but that should generally be kept to a minimum anyway. If unsure how how to edit any particular ebuild, just file a bug! And if the package isn't maintained, then nobody will be bumping its EAPI anyway. Rich
