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 F0568138010 for ; Sat, 20 Oct 2012 14:09:57 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8E15AE062B; Sat, 20 Oct 2012 14:09:47 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 9380EE060F for ; Sat, 20 Oct 2012 14:09:11 +0000 (UTC) Received: from [192.168.178.20] (p548D3FCC.dip.t-dialin.net [84.141.63.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: tommy) by smtp.gentoo.org (Postfix) with ESMTPSA id 4027833D78F for ; Sat, 20 Oct 2012 14:09:10 +0000 (UTC) Message-ID: <5082B07C.2030805@gentoo.org> Date: Sat, 20 Oct 2012 16:09:00 +0200 From: Thomas Sachau User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Firefox/15.0.1 SeaMonkey/2.12.1 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] Re: [RFC] Drop EAPI=0 requirement for system packages. References: <20121012125315.33500bbb@sera-17.lan> <20121012211023.592e82a1@gentoo.org> <20121013082820.75d280a1@sera-17.lan> <20121016234230.3b79a2fe@gentoo.org> <1350495278.2447.33.camel@belkin4> <20121017220707.02c6f5ac@gentoo.org> <1350575341.2447.40.camel@belkin4> <1350587136.2447.47.camel@belkin4> <1350667312.12879.11.camel@belkin4> <20121019145105.4927316b@gentoo.org> <1350670155.12879.22.camel@belkin4> <20121019154733.31b2284c@gentoo.org> <1350675125.12879.44.camel@belkin4> <5081AD7B.1040100@gentoo.org> <1350676398.12879.50.camel@belkin4> <5081BA9E.2080907@gentoo.org> <1350713099.12879.54.camel@belkin4> In-Reply-To: <1350713099.12879.54.camel@belkin4> X-Enigmail-Version: 1.4.4 OpenPGP: id=211CA2D4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE293D8CB90808BD9FB1F0559" X-Archives-Salt: e11c91ae-27a7-428f-9d58-50bd97e6d2a3 X-Archives-Hash: 553b093193f787a42fc2e9d92aac34f4 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE293D8CB90808BD9FB1F0559 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Pacho Ramos schrieb: > El vie, 19-10-2012 a las 22:39 +0200, Thomas Sachau escribi=C3=B3: >> Pacho Ramos schrieb: >>> El vie, 19-10-2012 a las 21:43 +0200, Thomas Sachau escribi=C3=B3: >>>> Pacho Ramos schrieb: >>>>> I volunteer to do whatever conversions you want for every ebuild I = find >>>>> if I have time... what prevents me from doing it is to commit that >>>>> changes to ebuilds not maintained by me and not knowing if develope= rs >>>>> agree on using latest eapi if possible. A more general solution (or= >>>>> policy) needs to be worked as, otherwise, tree won't be moved to la= test >>>>> eapi ever because we would need to: >>>>> - Periodically send bugs + patches >>>>> - Ask for permission to commit >>>>> >>>>> And that for every eapi bump >>>>> >>>> >>>> Either an ebuild has a responsive maintainer, which you can ask frie= ndly >>>> to bump the EAPI because of feature X you would like to use or there= is >>>> no maintainer, in which case you are free to touch/bump or last rite= the >>>> ebuild. >>>> >>>> So i still dont see any need or requirement for a policy to >>>> force/require all devs to always use or switch to the latest avaidab= le >>>> EAPI. As already written in this thread, it would just mean less new= >>>> ebuilds and less version bumps with such a policy. And i also prefer= >>>> more work done with older EAPI versions around then less ebuilds/new= >>>> versions with latest EAPI. >>>> >>> >>> Seriously, what people is still having problems with handling eapi4? = If >>> there are doubts about its usage, they should be asked and resolved >>> instead of ignored keeping ebuilds with older eapis. The only eapi th= at >>> probably adds no advantage for a lot of ebuilds is eapi3, but that is= >>> not the case for eapi4 for example, that includes changes that should= be >>> incorporated by most packages in the tree, some of them introduced by= it >>> and others inherited from older eapis. >>> >>> What is the advantage of using eapi2 over eapi4 for example? What "ha= rd >>> to learn" change was included in eapi4 over eapi2? >>> >> >> This is not about "having problems with handling eapi-X", this is just= >> about limited time and the choice where to spend that time. If you do >> just a version bump, you often dont have to touch the ebuild at all, >> just copy, test, commit and be happy. If you additionally require an >> EAPI bump, this means to carefully check the ebuild, adjust it to the >> new EAPI and additionally check, that the expected haviour is also the= >> one that happens. While doing this, i could also have fixed another bu= g >> or have done another version bump. And that was already expressed in m= y >> first response. I nowhere claimed to have problems with EAPI bumps, ju= st >> that they require additional time, so reducing the amount of time left= >> to create new ebuilds/fix bugs/do version bumps. And with the choice, = i >> prefer the new ebuilds/fixed bugs/version bumps over an ebuild switche= d >> to a new EAPI. >> >> So my question to you: What is the advantage of using ${NEW_EAPI} over= >> using ${OLDER_EAPI}, when the ebuild does the same and the result is t= he >> same? >> >=20 > I already explained the advantages, simply take a look to: > http://devmanual.gentoo.org/ebuild-writing/eapi/index.html >=20 > to see that, for example, --disable-dependency-tracking won't be used b= y > default for older eapis. The same will occur with eapi5 and > --disable-silent-rules or running tests in parallel. >=20 > That time you think you are saving, will be need to be lost if, for > example, some QA policy appears in the future to move to try to run > tests in parallel when possible, or force verbose output. >=20 Please remember, that not every package out there does use an autotools based build system, we also have custom configure scripts, custom makefiles, things like cmake, qmake or even completly different things like ant based build systems for java. All those build systems wont benefit neither from --disable-dependency-tracking nor from --disable-silent-rules. Also, as already pointed out, a package, which currently exists may be unmaintained and useless in the future, so if i dont do the work now and remove the then unneeded package later, i did not spend any additional time for this change. Your requirement would either mean wasted time or another open bug until the package gets removed. Beside that, i did ask you about the case, where "the ebuild does the same and the result is the same". And you did not answer my question, why an EAPI-bump in such cases should be done. And finally, as already pointed out by Rich, you should not talk about any specific EAPI you like/prefer/want to be used everyhwere, but instead about the issue you want to solve. So just point out the issue and ask the maintainer to fix it. If he uses a newer EAPI, good. If he uses another solution, which also fixes the issue, also good. We should not discuss about a specific way to solve some issues, since this is the maintainers choice. Our goal should instead be to fix as many issues as possible with our limited amount of time we have for Gentoo. --=20 Thomas Sachau Gentoo Linux Developer --------------enigE293D8CB90808BD9FB1F0559 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iJwEAQECAAYFAlCCsIIACgkQG7kqcTWJkGcApgP/R3V+3Fja2AprJla+M6AjNs/G fx51eMS50p4SFpZRj5BvpZ4N0NZNVInXUqqi0EmeO4iEx11ZFRcDw383Fi8uVL5m auiFnxsDIn6GgpXPl7zgfasXlIrrJxduyiZdZwMzvNcQTCZWAn4IK9i2OkxGkfYr HSsCIcRermu7GcdXfyk= =clKr -----END PGP SIGNATURE----- --------------enigE293D8CB90808BD9FB1F0559--