Re: [gentoo-dev] GLEP 55 updated

[Thomas de Grenier de Latour <tom.gl@free.fr>]

Hi,

On 2009/05/17, Piotr Jaroszyński <peper@gentoo.org> wrote:
> I have just updated GLEP 55 [1], hopefully making it a bit clearer.

In the GLEP, you raises the following argument against the "Easily 
fetchable EAPI inside the ebuild" class of solutions:

> Performance decrease comes from the fact that with version format 
> changes in the picture package managers need EAPI to parse the 
> ebuild's version.  That means that merely picking the best version
> of a package requires loading EAPI (from cache or the ebuild) for 
> each available ebuild.

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

So, basically, we are, and will stay, in a situation such that there 
is a complete order relation beetween all the version strings 
supported by at least one of the EAPIs implemented by the PM, and all
the versionning rules of this EAPIs match this order relation.

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
 2- among the remaining ones, parse and sort versions (sure, would 
actually be done together with step 1, for performances reasons)
 3- get metadatas for the best one (generate or pick in cache), and 
check its EAPI that it is a supported one, and also that the version
string is allowed in this EAPI
 4- loop on step 3 if EAPI check failed

It is as fast as the algorithm GLEP55 promotes, but in the case you're
using an old package manager and there is really a lot of ebuild 
updates you skip because of unsupported EAPI (here you still fetch 
their metadata, but not with GLEP55).  But i don't see it as a nominal
case. 


Thanks,
--
TGL.