Re: PREFERRED_VERSION and wildcards

[Andreas Oberritter <obi@opendreambox.org>]

On 14.03.2012 23:54, Martin Jansa wrote:
> On Wed, Mar 14, 2012 at 10:34:59PM +0100, Andreas Oberritter wrote:
>> Hi,
>>
>> I just tried using wildcards, like it's done for gcc, e.g.:
>>
>> PREFERRED_VERSION_foo = "1.2%"
>>
>> Now, if I have two foo recipes, foo_1.2.1.bb and foo_1.2.3.bb, in the
>> same directory, then Bitbake always chooses 1.2.1 instead of the one
>> with the higher version number. Does bitbake always choose the first
>> matching version it can find? Is this a general limitation of wildcards,
>> or is this a problem that can get corrected? I'd expect it to choose the
>> highest matching version.
> 
> If you want highest then why do you specify P_V at all? or are those
> 1.2% foo with e.g. negative D_P? or is there 1.3 you don't want?

Yes, I'd like to prefer 1.2.x over higher versions, say 1.3.x, which
coexist in the same directory, i.e. prefer stable over development versions.

> It will use first provider which matches (in highest usable prio/D_P group).
> 
>     sortpkg_pn = sortPriorities(pn, dataCache, pkg_pn)
>     # Find the highest priority provider with a PREFERRED_VERSION set
>     (preferred_ver, preferred_file) = findPreferredProvider(pn, cfgData, dataCache, sortpkg_pn, item)
>     # Find the latest version of the highest priority provider
>     (latest, latest_f) = findLatestProvider(pn, cfgData, dataCache, sortpkg_pn[0])
> 
>     if preferred_file is None:
>         preferred_file = latest_f
>         preferred_ver = latest
> 
> It was added mostly to cover use case with e.g. 1.2+svnr1337 or 1.2+gitrCAFEBABE where 
> you don't care about exact revision, but you know that you want 1.2 from scm (and there
> is just one which matches).

I see. I must admit that I don't really understand how the code quoted
above works.

> See this thread for details:
> http://lists.linuxtogo.org/pipermail/bitbake-devel/2009-September/000458.html

OK, Now I understand the original intention, but its behaviour doesn't
seem to be what you'd intuitively expect. Well, at least not what I'd
expect. Would it be hard to extend the code to find the highest matching
version instead of the first one? This wouldn't have negative effects on
your use case.

Regards,
Andreas