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 1M5lHy-0005uG-IY for garchives@archives.gentoo.org; Sun, 17 May 2009 18:40:46 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 00D83E0383; Sun, 17 May 2009 18:40:45 +0000 (UTC) Received: from smtp3-g21.free.fr (smtp3-g21.free.fr [212.27.42.3]) by pigeon.gentoo.org (Postfix) with ESMTP id E5503E0383 for ; Sun, 17 May 2009 18:40:43 +0000 (UTC) Received: from smtp3-g21.free.fr (localhost [127.0.0.1]) by smtp3-g21.free.fr (Postfix) with ESMTP id 2A8648181D0 for ; Sun, 17 May 2009 20:40:40 +0200 (CEST) Received: from gromit (mal35-4-88-164-237-103.fbx.proxad.net [88.164.237.103]) by smtp3-g21.free.fr (Postfix) with ESMTP id 2EEE281812E for ; Sun, 17 May 2009 20:40:38 +0200 (CEST) Date: Sun, 17 May 2009 20:40:37 +0200 From: Thomas de Grenier de Latour To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] GLEP 55 updated Message-ID: <20090517204037.3a7393c0@gromit> In-Reply-To: References: X-Mailer: Claws Mail 3.7.1 (GTK+ 2.16.1; x86_64-pc-linux-gnu) 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 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: c5689e61-2957-4d9b-93e1-683aa3aa94d5 X-Archives-Hash: c28e42c69ca106f7d0bf8cd6b6336923 Hi, On 2009/05/17, Piotr Jaroszy=C5=84ski wrote: > I have just updated GLEP 55 [1], hopefully making it a bit clearer. In the GLEP, you raises the following argument against the "Easily=20 fetchable EAPI inside the ebuild" class of solutions: > Performance decrease comes from the fact that with version format=20 > changes in the picture package managers need EAPI to parse the=20 > ebuild's version. That means that merely picking the best version > of a package requires loading EAPI (from cache or the ebuild) for=20 > each available ebuild. This argument is wrong imho. Future EAPIs can't be allowed to=20 introduce backward-incompatible changes to the versions ordering=20 rules, or they would make the PM behavior ill defined. Or, more=20 precisely, if a PM adopts an EAPI with such a change, it has to drop support for the older incompatible ones. Let's take a very simple=20 example: - eapi X says "_p is equal to _p0" - eapi Y says "_p is greater than any _pN" --> of "foo-1_p1 with EAPI=3DX" and "foo-1_p with EAPI=3DY", what is the "best" version? So, basically, we are, and will stay, in a situation such that there=20 is a complete order relation beetween all the version strings=20 supported by at least one of the EAPIs implemented by the PM, and all the versionning rules of this EAPIs match this order relation. As a consequence, the algorithm for picking best version of a package can be as simple as the following: 1- among all ebuilds filenames, filter out the ones with unrecognized version string 2- among the remaining ones, parse and sort versions (sure, would=20 actually be done together with step 1, for performances reasons) 3- get metadatas for the best one (generate or pick in cache), and=20 check its EAPI that it is a supported one, and also that the version string is allowed in this EAPI 4- loop on step 3 if EAPI check failed It is as fast as the algorithm GLEP55 promotes, but in the case you're using an old package manager and there is really a lot of ebuild=20 updates you skip because of unsupported EAPI (here you still fetch=20 their metadata, but not with GLEP55). But i don't see it as a nominal case.=20 Thanks, -- TGL.