Re: [gentoo-dev] GLEP 55 updated

[Ciaran McCreesh <ciaran.mccreesh@googlemail.com>]

[-- Attachment #1: Type: text/plain, Size: 2122 bytes --]

On Sun, 17 May 2009 21:57:40 +0200
Thomas de Grenier de Latour <tom.gl@free.fr> wrote:
> On 2009/05/17, Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> > 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?

Conceptually, you'd define a 'user' EAPI for those things, so you can
define it any way you want (including in such a way that the _p thing
works both ways depending upon the EAPI used for creating the thing
you're comparing it to -- for the user EAPI, you'd define it as being
_pUNSPECIFIED rather than _p0 or _pINFINITY and use the other side of
the comparison to decide the result). But yes, if you do something
silly like your example, things get very complicated.

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

Your previously stated restrictions are too strong, though. And when it
turns out a future change breaks those restrictions, we'd be back to
yet another extension change.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]