Hi, On 2009/05/17, Piotr Jaroszyński <pe...@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.
