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 1M5mr3-0002QX-Kn for garchives@archives.gentoo.org; Sun, 17 May 2009 20:21:06 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A1E97E0411; Sun, 17 May 2009 20:21:04 +0000 (UTC) Received: from mail-fx0-f171.google.com (mail-fx0-f171.google.com [209.85.220.171]) by pigeon.gentoo.org (Postfix) with ESMTP id 41E70E0411 for ; Sun, 17 May 2009 20:21:04 +0000 (UTC) Received: by fxm19 with SMTP id 19so2736096fxm.34 for ; Sun, 17 May 2009 13:21:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type; bh=AfLNOxo1TfQmoC4wdXCohvVPJCol063ALNsks+8PaL8=; b=EJPhxemZd60IRtnTEJJr2w+D5QBKnLp9C207Mb577BhfC9Q1gp1kwX2cYce2aL2y7N t47Ma1mc0tytyvdQAiDN2IJRHOZJtd8VLS6UCX8YpHhxdDkU3DfzlrbvAZELTDEs8DGc VTXqXUmd3Tir68HvlOJMiwmjS5R7eJNNuFvqA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; b=txUHiq3g3iYqLrSsl0zYFWSp6mOu0yXihS1P3ruy21WsadNvg+mMmHZH3gnZGrgval aoVql7VT8AgbwVNu78orMm8tawc2CyARrCScw2I8xNGdI9w3hBwWuJac61NE6I02GDwa onfeHtY3NM4/YU+VztuEDF0UFP8vFIugrnSyI= Received: by 10.204.117.141 with SMTP id r13mr5924719bkq.207.1242591663418; Sun, 17 May 2009 13:21:03 -0700 (PDT) Received: from snowmobile (92-235-187-79.cable.ubr18.sgyl.blueyonder.co.uk [92.235.187.79]) by mx.google.com with ESMTPS id b17sm6030205fka.37.2009.05.17.13.21.02 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 17 May 2009 13:21:03 -0700 (PDT) Date: Sun, 17 May 2009 21:20:56 +0100 From: Ciaran McCreesh To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] GLEP 55 updated Message-ID: <20090517212056.15e4ad52@snowmobile> In-Reply-To: <20090517215740.41069a04@gromit> References: <20090517204037.3a7393c0@gromit> <20090517194716.64c83328@snowcone> <20090517215740.41069a04@gromit> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.16.1; i686-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: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/EKemxB=hLF=mGfRVREXg0h6"; protocol="application/pgp-signature" X-Archives-Salt: 663def54-9f76-495a-9de2-45ad13a6de15 X-Archives-Hash: 16e33585b4bcf55f8b6fb27c26a8083a --Sig_/EKemxB=hLF=mGfRVREXg0h6 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sun, 17 May 2009 21:57:40 +0200 Thomas de Grenier de Latour wrote: > On 2009/05/17, Ciaran McCreesh wrote: > > 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. >=20 > 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 ">=3Dbar/foo-1_p" as an "emerge" command line argument for > instance, is my foo-1_p1.ebuild a candidate? Conceptually, you'd define a 'user' EAPI for those things, so you can define it any way you want (including in such a way that the _p thing works both ways depending upon the EAPI used for creating the thing you're comparing it to -- for the user EAPI, you'd define it as being _pUNSPECIFIED rather than _p0 or _pINFINITY and use the other side of the comparison to decide the result). But yes, if you do something silly like your example, things get very complicated. > > > 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 > >=20 > > You don't know whether you recognise the version string until you > > know the EAPI, though. >=20 > 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. Your previously stated restrictions are too strong, though. And when it turns out a future change breaks those restrictions, we'd be back to yet another extension change. --=20 Ciaran McCreesh --Sig_/EKemxB=hLF=mGfRVREXg0h6 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAkoQcasACgkQ96zL6DUtXhFpEgCfauakjVaw8EhyXS2Ves8oOvOS d3kAn2cQ3YoCLW9m000TNjgdeSmjimPd =V4zp -----END PGP SIGNATURE----- --Sig_/EKemxB=hLF=mGfRVREXg0h6--