Re: [gentoo-dev] GLEP 55 updated

[Ciaran McCreesh <ciaran.mccreesh@googlemail.com>]

[-- Attachment #1: Type: text/plain, Size: 1474 bytes --]

On Sun, 17 May 2009 20:40:37 +0200
Thomas de Grenier de Latour <tom.gl@free.fr> wrote:
> This argument is wrong imho.  Future EAPIs can't be allowed to 
> introduce backward-incompatible changes to the versions ordering 
> rules, or they would make the PM behavior ill defined.  Or, more 
> precisely, if a PM adopts an EAPI with such a change, it has to drop
> support for the older incompatible ones.

Not exactly true. It means that EAPI version rules have to be mappable
onto a single larger superversion format in such a way that they have a
total order.

> 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.

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.

> 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.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]