[oe] [PATCH] Allow % as wildcard in the end of PREFERRED_VERSION_pkg

[Richard Purdie]

On Tue, 2009-09-15 at 09:11 +0100, Phil Blundell wrote:
> On Mon, 2009-09-14 at 00:43 +0200, Martin Jansa wrote:
> > +def isPreferredVersion(pe, pv, pr, preferred_e, preferred_v, preferred_r):
> > +    """
> > +    Check if the version pe,pv,pr is the preferred one.
> > +    If there is preferred version defined and ends with '%', then pv has to start with that version after removing the '%' in the end,
> > +    """
> >  
> > +    if (pv == preferred_v or (preferred_v != None and preferred_v.endswith('%') and pv.startswith(preferred_v[:len(preferred_v)-1]))):
> > +        if (pr == preferred_r or preferred_r == None):
> > +            if (pe == preferred_e or preferred_e == None):
> > +                return true
> > +    return false
> > +    
> 
> I'm not totally comfortable that this patch is semantically well-formed.
> If you start allowing wildcards then the idea of "the preferred version"
> becomes somewhat ill-defined since, obviously, the wildcard might match
> any number of files.  I'm not quite sure what the problem is that you
> are trying to solve, but my initial reaction is that (whatever the
> problem is) it would probably be better solved another way.

I can see what this patch is driving at as I've been in this position
before and its ugly. By default you usually want git recipes to have the
lowest preference. You then usually want to have some "bleeding" distro
config which changes those recipes to the default and selects them.
Raising their default preference and overriding any other
PREFERRED_VERSION is harder than it looks requiring two lines of config
whereas with the patch it allows this operation to be made easier and
works more as you'd expect.

On the other hand I do have doubts about the strange syntax which
doesn't match anything else we use and is a valid concern. The multiple
git recipes issue is an interesting one and I don't know how that would
work or whether we'd see it in practise.

That point in the code is a hotpoint and we need something low overhead
(i.e. not regexp) which this patch is.

I am seriously tempted to add something though as there is a missing
chunk of control here...

Cheers,

Richard