| 1 |
On Sun, 17 May 2009 20:40:37 +0200 |
| 2 |
Thomas de Grenier de Latour <tom.gl@××××.fr> wrote: |
| 3 |
> This argument is wrong imho. Future EAPIs can't be allowed to |
| 4 |
> introduce backward-incompatible changes to the versions ordering |
| 5 |
> rules, or they would make the PM behavior ill defined. Or, more |
| 6 |
> precisely, if a PM adopts an EAPI with such a change, it has to drop |
| 7 |
> support for the older incompatible ones. |
| 8 |
|
| 9 |
Not exactly true. It means that EAPI version rules have to be mappable |
| 10 |
onto a single larger superversion format in such a way that they have a |
| 11 |
total order. |
| 12 |
|
| 13 |
> Let's take a very simple |
| 14 |
> example: |
| 15 |
> - eapi X says "_p is equal to _p0" |
| 16 |
> - eapi Y says "_p is greater than any _pN" |
| 17 |
> --> of "foo-1_p1 with EAPI=X" and "foo-1_p with EAPI=Y", what is |
| 18 |
> the "best" version? |
| 19 |
|
| 20 |
You don't define it quite like that. You define it by mapping EAPI X _p |
| 21 |
onto super-EAPI _p0, and EAPI Y _p onto super_EAPI _pINFINITY. That way |
| 22 |
the ordering's well defined. |
| 23 |
|
| 24 |
Although that's a fairly convoluted example, and not in line with |
| 25 |
what's being proposed for future EAPIs. What we're after is the ability |
| 26 |
to allow versions like 1.2.3-rc1. |
| 27 |
|
| 28 |
> As a consequence, the algorithm for picking best version of a package |
| 29 |
> can be as simple as the following: |
| 30 |
> 1- among all ebuilds filenames, filter out the ones with unrecognized |
| 31 |
> version string |
| 32 |
|
| 33 |
You don't know whether you recognise the version string until you know |
| 34 |
the EAPI, though. |
| 35 |
|
| 36 |
-- |
| 37 |
Ciaran McCreesh |
Archives