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 D56E2138010 for ; Sat, 20 Oct 2012 15:16:07 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 12AD921C008; Sat, 20 Oct 2012 15:15:58 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id B2BE9E049A for ; Sat, 20 Oct 2012 15:15:25 +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 1CDF533D74E for ; Sat, 20 Oct 2012 15:15:23 +0000 (UTC) Message-ID: <5082C001.1020607@gentoo.org> Date: Sat, 20 Oct 2012 17:15:13 +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> <5082B07C.2030805@gentoo.org> <1350743387.12879.70.camel@belkin4> In-Reply-To: <1350743387.12879.70.camel@belkin4> X-Enigmail-Version: 1.4.4 OpenPGP: id=211CA2D4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig67E0FDB4A99C17CF1B95AC19" X-Archives-Salt: fc1d5046-4102-48de-9021-293acd3b7ee4 X-Archives-Hash: ff8b6f2b5ddd1a89282479836b2ca686 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig67E0FDB4A99C17CF1B95AC19 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Pacho Ramos schrieb: > El s=C3=A1b, 20-10-2012 a las 16:09 +0200, Thomas Sachau escribi=C3=B3:= >> 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 tha= t >>>>>>> changes to ebuilds not maintained by me and not knowing if develo= pers >>>>>>> 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 = latest >>>>>>> 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 fr= iendly >>>>>> to bump the EAPI because of feature X you would like to use or the= re is >>>>>> no maintainer, in which case you are free to touch/bump or last ri= te 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 avaid= able >>>>>> EAPI. As already written in this thread, it would just mean less n= ew >>>>>> ebuilds and less version bumps with such a policy. And i also pref= er >>>>>> more work done with older EAPI versions around then less ebuilds/n= ew >>>>>> 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 = that >>>>> 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 shou= ld 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 "= hard >>>>> to learn" change was included in eapi4 over eapi2? >>>>> >>>> >>>> This is not about "having problems with handling eapi-X", this is ju= st >>>> about limited time and the choice where to spend that time. If you d= o >>>> 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 th= e >>>> new EAPI and additionally check, that the expected haviour is also t= he >>>> one that happens. While doing this, i could also have fixed another = bug >>>> or have done another version bump. And that was already expressed in= my >>>> first response. I nowhere claimed to have problems with EAPI bumps, = just >>>> that they require additional time, so reducing the amount of time le= ft >>>> 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 switc= hed >>>> to a new EAPI. >>>> >>>> So my question to you: What is the advantage of using ${NEW_EAPI} ov= er >>>> using ${OLDER_EAPI}, when the ebuild does the same and the result is= the >>>> same? >>>> >>> >>> I already explained the advantages, simply take a look to: >>> http://devmanual.gentoo.org/ebuild-writing/eapi/index.html >>> >>> to see that, for example, --disable-dependency-tracking won't be used= by >>> default for older eapis. The same will occur with eapi5 and >>> --disable-silent-rules or running tests in parallel. >>> >>> 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. >>> >> >> Please remember, that not every package out there does use an autotool= s >> 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 a= nd >> remove the then unneeded package later, i did not spend any additional= >> time for this change. Your requirement would either mean wasted time o= r >> another open bug until the package gets removed. >=20 > If the package is unmaintained it won't probably have a revision bump > and, then, eapi won't change, if any other needs to fix another bug and= > also bumps eapi, that package will be enhanced, that is what really > matters. If it's broke because dev bumping it failed to bump the eapi, > lets fix it (or ask for help) to prevent him from doing that error > again. All are gains: package is improved and developer learns how to > handle new eapi Hope you dont mix threads, since i dont see any relation between a package being unmaintained, a revision bump and a changing EAPI. Beside that: A package not using the latest EAPI is not broken, please stop doing such claims. Additionally fixing an issue without also bumping the package to the latest EAPI is not an issue or error by itself either. >=20 >> >> 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. >=20 > What about the huge number of packages that would benefit from the bump= ? > Why ignore them because a few packages won't benefit. Think in changes > like src_configure phase addition, that most packages with benefit from= > it. Also, this is not about blindly forcing people to use latest eapi > without even evaluating what improvements they have, this is about, for= > example, forcing packages to use eapi4 because it includes a ton of > enhancements from eapi0 that most packages would benefit from. >=20 >> >> 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 shoul= d >> not discuss about a specific way to solve some issues, since this is t= he >> maintainers choice. Our goal should instead be to fix as many issues a= s >> possible with our limited amount of time we have for Gentoo. >> >> >=20 > I have already pointed multiple examples where bumping eapi will help t= o > improve things, not doing so because of that hypothetical problems you > think could occur only leads us to current situation: a ton of autotool= s > packages won't get --disable-silent-rules/--disable-dependency-tracking= > improvements because people doesn't even try to bump eapi, some more > packages will hide utilities failing but not dying because of using old= > eapis, inconsistent blockers handling around the tree due using > different eapis, packages still relying on dying in pkg_setup instead o= f > setting proper USE deps, packages still using dohard and dosed, html > files in /usr/share/doc being compressed because of old eapi usage, I > even noticed past week a package still using ebeep. I am not talking about hypothetical problems, i am talking about a real thing: my limited amount of free time i am able and willing to spend for Gentoo. And i prefer spending it on fixing real bugs over spending additional time to bump the EAPI just for fun. For the points you see issues with: - dont miss, that one can also add those configure options in an ebuild without the requirement to use the EAPI. -Utilities failing but not dying? Only certain helper functions will die with EAPI-4, nothing else. And if in doubt, just add a " || die" after every call and be done with it. So also not related to the EAPI. -blocker handling is done by the PM, not the ebuild, so if you have a patch for a better UI output, PM maintainers will probably happily apply it, when you provide it. -for a die in pkg_setup instead of a USE dependency: Both ways will prevent you from continuing, the second one only has a unified UI. -I dont see any real problem with dosed and dohard, they are just wrappers around sed and ln, so what would improve if someone replaces the wrappers with calls to the wrapped tools? We could continue forever with this examples, so i will shorten my point of view: If i want/need an option, i will add it to the ebuild. If an option i want requires a newer EAPI, i will use the newer EAPI. If the current EAPI does offer all i need, i wont spend any additional time on the EAPI bump. If you want to do it differently for the packages you maintain, fine. Just dont try to force your preferred EAPI-handling on everyone else. --=20 Thomas Sachau Gentoo Linux Developer --------------enig67E0FDB4A99C17CF1B95AC19 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/ iJwEAQECAAYFAlCCwAgACgkQG7kqcTWJkGdl7gQAyIvrFUEFjtlPmEQxeiQItQVM gqh/GUji2Kc/SqrDLlzBheS3im00GfnePqHotlaEGDB/U1H4M7AtQOBzyReLqqa4 FEtgIk2cKT0XgtcLcUxIQnDu4vvTv1aViqZVUiWKNjhXPV90SHdtjzT9HvnOdss1 oAisv9AtarECi7yYe8M= =h1mk -----END PGP SIGNATURE----- --------------enig67E0FDB4A99C17CF1B95AC19--