On Sun, 17 May 2009 20:40:37 +0200 Thomas de Grenier de Latour <tom...@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
signature.asc
Description: PGP signature
