| 1 |
Hi, |
| 2 |
|
| 3 |
On 2009/05/17, Piotr Jaroszyński <peper@g.o> wrote: |
| 4 |
> I have just updated GLEP 55 [1], hopefully making it a bit clearer. |
| 5 |
|
| 6 |
In the GLEP, you raises the following argument against the "Easily |
| 7 |
fetchable EAPI inside the ebuild" class of solutions: |
| 8 |
|
| 9 |
> Performance decrease comes from the fact that with version format |
| 10 |
> changes in the picture package managers need EAPI to parse the |
| 11 |
> ebuild's version. That means that merely picking the best version |
| 12 |
> of a package requires loading EAPI (from cache or the ebuild) for |
| 13 |
> each available ebuild. |
| 14 |
|
| 15 |
This argument is wrong imho. Future EAPIs can't be allowed to |
| 16 |
introduce backward-incompatible changes to the versions ordering |
| 17 |
rules, or they would make the PM behavior ill defined. Or, more |
| 18 |
precisely, if a PM adopts an EAPI with such a change, it has to drop |
| 19 |
support for the older incompatible ones. Let's take a very simple |
| 20 |
example: |
| 21 |
- eapi X says "_p is equal to _p0" |
| 22 |
- eapi Y says "_p is greater than any _pN" |
| 23 |
--> of "foo-1_p1 with EAPI=X" and "foo-1_p with EAPI=Y", what is |
| 24 |
the "best" version? |
| 25 |
|
| 26 |
So, basically, we are, and will stay, in a situation such that there |
| 27 |
is a complete order relation beetween all the version strings |
| 28 |
supported by at least one of the EAPIs implemented by the PM, and all |
| 29 |
the versionning rules of this EAPIs match this order relation. |
| 30 |
|
| 31 |
As a consequence, the algorithm for picking best version of a package |
| 32 |
can be as simple as the following: |
| 33 |
1- among all ebuilds filenames, filter out the ones with unrecognized |
| 34 |
version string |
| 35 |
2- among the remaining ones, parse and sort versions (sure, would |
| 36 |
actually be done together with step 1, for performances reasons) |
| 37 |
3- get metadatas for the best one (generate or pick in cache), and |
| 38 |
check its EAPI that it is a supported one, and also that the version |
| 39 |
string is allowed in this EAPI |
| 40 |
4- loop on step 3 if EAPI check failed |
| 41 |
|
| 42 |
It is as fast as the algorithm GLEP55 promotes, but in the case you're |
| 43 |
using an old package manager and there is really a lot of ebuild |
| 44 |
updates you skip because of unsupported EAPI (here you still fetch |
| 45 |
their metadata, but not with GLEP55). But i don't see it as a nominal |
| 46 |
case. |
| 47 |
|
| 48 |
|
| 49 |
Thanks, |
| 50 |
-- |
| 51 |
TGL. |
Archives