[bitbake-devel] PREFERRED_VERSION and wildcards

[Martin Jansa]

On Thu, Mar 15, 2012 at 12:53:27AM +0100, Andreas Oberritter wrote:
> 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.

Ah, OK.
 
> > 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.

Agreed, but if someone starts working on it, then we should discuss
first how to properly fix D_P across multiple layers, because I belive
that it's also in those 5 quoted lines.

Cheers,

> 
> Regards,
> Andreas

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.openembedded.org/pipermail/bitbake-devel/attachments/20120315/fadda3b9/attachment-0001.sig>