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 1M5YQg-00019G-AC for garchives@archives.gentoo.org; Sun, 17 May 2009 04:56:54 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 377D0E0596; Sun, 17 May 2009 04:56:52 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 11C2EE0596 for ; Sun, 17 May 2009 04:56:52 +0000 (UTC) Received: from [192.168.1.110] (unknown [117.192.137.90]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id CF4C464390 for ; Sun, 17 May 2009 04:56:50 +0000 (UTC) Subject: Re: [gentoo-dev] The fallacies of GLEP55 From: Arun Raghavan To: gentoo-dev@lists.gentoo.org In-Reply-To: <20090516202141.1b8f44e5@snowmobile> References: <20090514225337.34df7dac@snowcone> <20090515194329.GA16382@linux1> <20090515204905.54aa6a5c@snowmobile> <20090516092710.GA3221@eric.schwarzvogel.de> <20090516151216.15efc792@snowmobile> <20090516153224.GA4964@eric.schwarzvogel.de> <20090516163421.32935cbc@snowmobile> <20090516154332.GA6646@eric.schwarzvogel.de> <20090516164903.261df865@snowmobile> <1242491708.7309.3.camel@peripatetic.hades> <20090516163908.GB11144@dodo.hsd1.nj.comcast.net> <1242492270.7309.6.camel@peripatetic.hades> <20090516174730.1d7dd5b7@snowmobile> <1242492844.7309.9.camel@peripatetic.hades> <20090516175931.7756060d@snowmobile> <1242493786.7309.17.camel@peripatetic.hades> <20090516185508.0fd02f0e@snowmobile> <1242501178.7309.126.camel@peripatetic.hades> <20090516202141.1b8f44e5@snowmobile> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-D/SaYUMqkn7nBl6c0LJZ" Date: Sun, 17 May 2009 10:26:31 +0530 Message-Id: <1242536191.19545.10.camel@peripatetic.hades> 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.26.1.1 X-Archives-Salt: 69f32b43-ea34-49a1-9c04-e2866c9633e8 X-Archives-Hash: 9cd02f7357c24a8958d38e1a91ef1daf --=-D/SaYUMqkn7nBl6c0LJZ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sat, 2009-05-16 at 20:21 +0100, Ciaran McCreesh wrote: [...]=20 > Can't do that. The package manager has to barf on unrecognised .ebuild > files. I assume the reasons are the same as below. > > If this is not viable, make an unrecognised version string cause the > > same fallback as an unsupported EAPI =3D> ignore the ebuild. Again, fas= t > > track to stable portage, and not so long after, you're done. >=20 > Again, no good. First, it means a year or more wait before doing > anything. Second, it removes a whole level of error checking. Third, it > means a package manager can't know what versions are available for a > package without generating metadata for every potential version. 1) Why a year? I'd say 4-6 months after portage goes stable is fine. 2) Replace the errors with warnings. And these need to exist only at 'repoman manifest' time, so they're not end-user-visible (and don't need to be). -- Arun 3) This is again, when the metadata is uncached, which is not the normal case and can be ignored. And the (minor) performance penalty in the cached case, if any, is not reason enough to make this change. --=-D/SaYUMqkn7nBl6c0LJZ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) iEYEABECAAYFAkoPmP8ACgkQ+Vqt1inD4uyATgCffjK0RisiRPxG/ziCAUqDPeF0 AZsAmgOstmHgr3gx7WTYMjTQqzDdMyY4 =ddUI -----END PGP SIGNATURE----- --=-D/SaYUMqkn7nBl6c0LJZ--