On 2009/05/17, Ciaran McCreesh <ciaran.mccre...@googlemail.com> wrote:
> > 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. I understand the idea, but I still don't think it's viable to allow such definitions, because there are too many contexts in which we manipulate pure version strings, without decorating them with an EAPI, and without reference to a concrete package from which we could get it. Take ">=bar/foo-1_p" as an "emerge" command line argument for instance, is my foo-1_p1.ebuild a candidate? > 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. Right, and for this kind of reasonable future needs, it's easy enough to ensure enough backward compatibility so that we don't need to add the EAPI each time we talk about a version. > > 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. Under my previously stated restrictions, you know: - which one can be rejected for sure (the ones not recognized by any of your implemented EAPI). - how to correctly order the remaining ones (even the incorrect ones which may remain and would be rejected only at step 4), and thus where to start to find the "best" correct one. Which is well enough. -- TGL.
