PREFERRED_VERSION and wildcards

PREFERRED_VERSION and wildcards

[Andreas Oberritter]

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.

Regards,
Andreas

Re: PREFERRED_VERSION and wildcards

[Martin Jansa]

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

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?

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

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

Cheers,

> 
> Regards,
> Andreas
> 
> _______________________________________________
> bitbake-devel mailing list
> bitbake-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/bitbake-devel

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: PREFERRED_VERSION and wildcards

[Andreas Oberritter]

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

Re: PREFERRED_VERSION and wildcards

[Martin Jansa]

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

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@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]