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 1M5mUX-0007Id-It for garchives@archives.gentoo.org; Sun, 17 May 2009 19:57:49 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 57D20E0456; Sun, 17 May 2009 19:57:48 +0000 (UTC) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by pigeon.gentoo.org (Postfix) with ESMTP id 2A4E9E0456 for ; Sun, 17 May 2009 19:57:46 +0000 (UTC) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id EEC3AE08054 for ; Sun, 17 May 2009 21:57:43 +0200 (CEST) Received: from gromit (mal35-4-88-164-237-103.fbx.proxad.net [88.164.237.103]) by smtp6-g21.free.fr (Postfix) with ESMTP id BF1D6E081E3 for ; Sun, 17 May 2009 21:57:40 +0200 (CEST) Date: Sun, 17 May 2009 21:57:40 +0200 From: Thomas de Grenier de Latour To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] GLEP 55 updated Message-ID: <20090517215740.41069a04@gromit> In-Reply-To: <20090517194716.64c83328@snowcone> References: <20090517204037.3a7393c0@gromit> <20090517194716.64c83328@snowcone> 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=US-ASCII Content-Transfer-Encoding: 7bit X-Archives-Salt: b8a0e85e-9514-442f-aaae-2fa6d3483fce X-Archives-Hash: 8caa0310b338aff42a0e506ede2db41d On 2009/05/17, Ciaran McCreesh wrote: > > Let's take a very simple > > example: > > - eapi X says "_p is equal to _p0" > > - eapi Y says "_p is greater than any _pN" > > --> of "foo-1_p1 with EAPI=X" and "foo-1_p with EAPI=Y", what is > > the "best" version? > > You don't define it quite like that. You define it by mapping EAPI X > _p onto super-EAPI _p0, and EAPI Y _p onto super_EAPI _pINFINITY. > That way the ordering's well defined. I understand the idea, but I still don't think it's viable to allow such definitions, because there are too many contexts in which we manipulate pure version strings, without decorating them with an EAPI, and without reference to a concrete package from which we could get it. Take ">=bar/foo-1_p" as an "emerge" command line argument for instance, is my foo-1_p1.ebuild a candidate? > Although that's a fairly convoluted example, and not in line with > what's being proposed for future EAPIs. What we're after is the > ability to allow versions like 1.2.3-rc1. Right, and for this kind of reasonable future needs, it's easy enough to ensure enough backward compatibility so that we don't need to add the EAPI each time we talk about a version. > > 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 > > You don't know whether you recognise the version string until you know > the EAPI, though. Under my previously stated restrictions, you know: - which one can be rejected for sure (the ones not recognized by any of your implemented EAPI). - how to correctly order the remaining ones (even the incorrect ones which may remain and would be rejected only at step 4), and thus where to start to find the "best" correct one. Which is well enough. -- TGL.