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 1ABF8138010 for ; Thu, 18 Oct 2012 19:06:23 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8C298E019D; Thu, 18 Oct 2012 19:06:14 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 2FEA3E0158 for ; Thu, 18 Oct 2012 19:05:43 +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 071A933D92E for ; Thu, 18 Oct 2012 19:05:41 +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> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-m6NyOL/SiPcBDLByDf+e" Date: Thu, 18 Oct 2012 21:05:36 +0200 Message-ID: <1350587136.2447.47.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: a80be221-168a-4f1f-b47c-6c114633d25a X-Archives-Hash: d5ddad651d1c15ae84cfd1134ee3c88f --=-m6NyOL/SiPcBDLByDf+e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable El jue, 18-10-2012 a las 13:49 -0400, Rich Freeman escribi=C3=B3: > On Thu, Oct 18, 2012 at 11:49 AM, Pacho Ramos wrote: > > I didn't think eapi4 features were still "unfamiliar" to so many > > people... let's say, what about deprecating eapi1, 2 and 0 for newer > > ebuilds? Is eapi2 so unfamiliar also to not force it as older eapi for > > newer ebuilds (eapi3 changes look to be minor when compared with > > eapi2) ? >=20 > This still involves the issue that what would be simple ebuild bumps > turn into a need to make more substantial changes to an ebuild. But that changes will save us from needing to move a lot of ebuilds to newer eapis if some years later we decide to deprecate some of them. For example, if every package using eapi1 is forced to be bumped to newer eapi, we won't need to manually do that work in the future if we decide to deprecate old eapis. Also, it's probably better to force new ebuilds to use things like splitted configure phase instead of keeping with old eapi0/1 src_compile one, also the same for deprecated things like dosed and dohard. If there were valid reasons to ban then on newer eapi, I think it's better to not allow people to still use old eapi to skip that banning (or were they banned only for cosmetic reasons?) >=20 > And the concern still exists that a policy that says all new ebuilds > shall use EAPI foo might result in fewer new ebuilds. Sure, they'll > have new and shiny fooness, but arguably I'd rather have more packages > supported on older EAPIs then fewer packages supported on newer ones. >=20 > If migrating to newer EAPIs is so simple, why aren't more doing it alread= y? Personally I see no major difficult in moving to eapi4, what exact difficult are you (I mean people still sticking with eapi0/1) seeing? I have re-read http://devmanual.gentoo.org/ebuild-writing/eapi/index.html and I can't see anything specially hard :/=20 >=20 > Rich >=20 >=20 --=-m6NyOL/SiPcBDLByDf+e 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) iEYEABECAAYFAlCAUwAACgkQCaWpQKGI+9RmEwCfVEA1pQeSLK8o0ZNAuNKSgXDe t6QAnj8RbZyHfsc0r7TFpHMt/FoNZvnj =Gfbt -----END PGP SIGNATURE----- --=-m6NyOL/SiPcBDLByDf+e--