From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 92321138010 for ; Sun, 2 Sep 2012 12:04:32 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id BE5C1E050E; Sun, 2 Sep 2012 12:04:07 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id D546BE032F for ; Sun, 2 Sep 2012 12:03:12 +0000 (UTC) Received: from [192.168.4.5] (blfd-5d82200b.pool.mediaWays.net [93.130.32.11]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: hasufell) by smtp.gentoo.org (Postfix) with ESMTPSA id EA1B233D8CC for ; Sun, 2 Sep 2012 12:03:11 +0000 (UTC) Message-ID: <50434AFB.9010503@gentoo.org> Date: Sun, 02 Sep 2012 14:03:07 +0200 From: hasufell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.6esrpre) Gecko/20120801 Thunderbird/10.0.6 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] EAPI usage References: In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Archives-Salt: 5934e5d5-99d0-493e-8281-c26982363ba0 X-Archives-Hash: bc40fbaf86d5a7be2e2446944d7dbc6c On 09/02/2012 12:52 PM, Vaeth wrote: > Rich Freeman 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. global epatch_user has a downside which I think was not even really discussed here unless I missed something. It could introduce many bogus bug reports which are caused by user-applied patches, cause it's easier now and you don't need to do it in an overlay. The maintainer will need to catch this and asking which repo the bugreporter did use is not sufficient. He will need the build log and check if user patches got applied there. Always talking about the benefit for the user and not the time developers have to spend on things does not catch the whole situation. >> 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. PMS is a fraction of what is to consider when writing an ebuild. It does not include QA policies, gentoo policies and whatnot. > >> 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. dying on certain problems can be achieved without EAPI bump. > > 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. > If a user wants/needs features of newer EAPIs, because he does some things in his overlay, he could probably open a bug report with a proposed patch to the ebuild which bumps the EAPI. Unless that's the case I would leave it to the developer if he needs those features or what EAPI he prefers. If a newer EAPI would fix a bug it might still be solvable without EAPI-bump. Again: leave it to the developer. This will create a useless annoyance and I can assure you that developers WILL ignore this policy/rule. What are you gonna do then? Just bump it on your own without asking? Take it up to devrel? It's not really worth it. The benefits have been stated and it's already advised that developers keep up with the latest EAPI, but you _cannot_ assume it anyway like some PMS contributors do.