From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1S7047-00046q-TU for garchives@archives.gentoo.org; Mon, 12 Mar 2012 07:53:12 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 4E54FE09B6; Mon, 12 Mar 2012 07:52:47 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id E2569E0965 for ; Mon, 12 Mar 2012 07:52:12 +0000 (UTC) Received: from [192.168.1.33] (219.Red-2-137-8.dynamicIP.rima-tde.net [2.137.8.219]) (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 BA52B1B4054 for ; Mon, 12 Mar 2012 07:52:11 +0000 (UTC) Subject: Re: [gentoo-dev] Deprecate EAPI1? From: Pacho Ramos To: gentoo-dev@lists.gentoo.org In-Reply-To: <1331467306.11661.2.camel@belkin4> References: <1331467306.11661.2.camel@belkin4> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-oi0iddgCsKrzo8C+dbIq" Date: Mon, 12 Mar 2012 08:52:06 +0100 Message-ID: <1331538726.3456.1.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: 02c90807-ed80-41fd-8fea-e722dd683301 X-Archives-Hash: 5cf4adcbac1b75a391f467cd44738c86 --=-oi0iddgCsKrzo8C+dbIq Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable El dom, 11-03-2012 a las 13:01 +0100, Pacho Ramos escribi=C3=B3: > After reading previous discussion: > http://help.lockergnome.com/linux/gentoo-dev-Deprecate-EAPIs--ftopict5305= 67.html >=20 > Looks like preventing NEW commits from using eapi1 (via repoman) could > be done without major issues. This could even being done also for eapi2 > as it's close enough to eapi3, but I don't have a strong opinion about > eapi2 deprecation (personally, I try to always use latest eapi if eclass > allows me to do so). >=20 > Any thoughts on this? >=20 > Thanks Well, the reasons for me preferring to not allow *new* ebuilds to use eapi1 is to try to move to use things like, for example, src_prepare/src_configure phases. I guess that phases were included for some "technical" reasons and, then, I think we should try to use them if possible install of still adding NEW ebuilds using old eapi0/1 way of doing things --=-oi0iddgCsKrzo8C+dbIq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iEYEABECAAYFAk9dqyYACgkQCaWpQKGI+9SEwQCgiG7Z8e/HpkBphJLbGW6L3KAo Mq4AniHNWdVjVUr6pf470A7ayxAOIc+4 =Pp1Y -----END PGP SIGNATURE----- --=-oi0iddgCsKrzo8C+dbIq--