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 F2392138010 for ; Fri, 19 Oct 2012 17:22:43 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E04FE21C094; Fri, 19 Oct 2012 17:22:32 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 2C9BE21C087 for ; Fri, 19 Oct 2012 17:21:58 +0000 (UTC) Received: from [192.168.1.33] (230.Red-2-137-43.dynamicIP.rima-tde.net [2.137.43.230]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: pacho) by smtp.gentoo.org (Postfix) with ESMTPSA id 0645E33DA3E for ; Fri, 19 Oct 2012 17:21:56 +0000 (UTC) Subject: Re: [gentoo-dev] Re: [RFC] Drop EAPI=0 requirement for system packages. From: Pacho Ramos To: gentoo-dev@lists.gentoo.org In-Reply-To: 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> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-d9Mj6sPdi8AgS+jX5igt" Date: Fri, 19 Oct 2012 19:21:52 +0200 Message-ID: <1350667312.12879.11.camel@belkin4> 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 X-Mailer: Evolution 2.32.3 X-Archives-Salt: 601b403b-218e-4bc3-9578-051603330895 X-Archives-Hash: 750a5d40f51e2e91c01ad0b81b1c6bc8 --=-d9Mj6sPdi8AgS+jX5igt Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable El jue, 18-10-2012 a las 15:35 -0400, Rich Freeman escribi=C3=B3: > On Thu, Oct 18, 2012 at 3:05 PM, Pacho Ramos wrote: > > Personally I see no major difficult in moving to eapi4, what exact > > difficult are you (I mean people still sticking with eapi0/1) seeing? >=20 > It is harder than cp. :) >=20 > If I write a new ebuild I would always target the most recent EAPI. > However, if I'm just doing a revbump, why fix what ain't broken? >=20 > That is rhetorical. I do understand your logic. However, if it takes > me 15min to do something now, and it might take me 15min to do it > later, I'll take later every time since who knows if the package will > even be around later. >=20 > Rich >=20 >=20 It's not only about the difficulty problem (that I don't see so hard), it also about keeping packages behaving inconsistently around the tree due people keeping old eapis in their ebuilds: - What will occur if people is not forced to use eapi5 when "slot operator dependencies" are needed? Will people still need to already run revdep-rebuild for ages to be safer? - What about " --disable-silent-rules" eapi5 feature? Will we have part of the tree passing that option while other packages are still showing hidden output due old eapi usage? - What about src_test behavior? If packages are broken they should force -j1 for that packages... but if we don't push people to jump to last eapi, they will be tempted to simply skip the eapi bump to hide the problem. - Look to different blockers handling introduced in eapi2, if people keeps using older eapis, they will still make people to need to manually unmerge old package even if not needed. - Also look to packages still dying due unsatisfied USE dependencies instead of bumping to eapi >=3D2 and setting that deps properly. - And the different behavior of utilities dying, they will die on eapi4 but won't on older eapis and, then, that utils could still be not running at all but that being hidden. - Also the --disable-dependency-tracking parsing in eapi4, if it was added to run configure faster, that is nice, but packages still wanting to keep old eapi to not make the effort to bump it will still have a slower configure run. What I am trying to say is that, if we agree latest eapi is technically better, we need to try to get it used when possible (I mean, when, for example, eclasses are ported) for a "QA" reasoning. --=-d9Mj6sPdi8AgS+jX5igt Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEABECAAYFAlCBjDAACgkQCaWpQKGI+9TECACfXwxCg+j+0QfqAKrCMDTOCOrM 2eoAn1ftqi/7qC3mwLIq7z381FF7QSTd =P7NN -----END PGP SIGNATURE----- --=-d9Mj6sPdi8AgS+jX5igt--