Re: [BBCLASSEXTEND BUG?] Not taking virtual:native provider into account?

[Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>]

On Mon, Feb 22, 2010 at 12:40:51PM +0000, Richard Purdie wrote:
>On Sun, 2010-02-21 at 17:40 +0100, Bernhard Reutner-Fischer wrote:
>> Hi,
>> 
>> I'm using bitbake 641e6cf3ec3ab4d26929cf4d2a3704ff07eed4d6 (current
>> HEAD) on HEAD of oe.
>> 
>> I'm adding:
>> $ cat recipes/git/git_1.7.0.bb 
>> require git.inc
>> SRC_URI[git.md5sum] = "c7553b73e2156d187ece6ba936ae30ab"
>> SRC_URI[git.sha256sum] = "a61e863944381c4f8231841f678f41f56b634bebca486a61005b35e5bcbb7c79"
>> DEPENDS = "openssl curl zlib expat"
>> RDEPENDS = "perl perl-module-file-path cpio findutils sed"
>> PR = "r0"
>> FILES_${PN}-dbg += "${libexecdir}/git-core/.debug"
>> BBCLASSEXTEND = "native"
>> 
>> (and add ";name=git" to the .tar in git.inc's SRC_URI)
>> and bake git-native and see:
>> DEBUG: adding .../recipes/git/git-native_1.6.0.4.bb to satisfy git-native
>> instead of
>> DEBUG: adding virtual:native:.../recipes/git/git_1.7.0.bb to satisfy git-native
>> which i get if i rm git-native_*
>> 
>> Assuming that the aboce recipe is correct in principle, this somehow
>> sounds like BBCLASSEXTEND'ed virtual:native never make it into
>> providers. What am i doing wrong?
>
>If a real git-native_xyz.bb exists it will be preferred to the
>BBCLASSEXTEND version.

Even if the BBCLASSEXTENDed version is higher than the
git-native_0.bb's? That doesn't sound too handy for i'd need to also
touch the old version :(

$ ls -1 recipes/git/*bb
recipes/git/git_1.6.0.4.bb
recipes/git/git_1.7.0.bb
recipes/git/git-native_1.6.0.4.bb

>I'm not sure why you'd want two versions?

For this git package i wouldn't want to, but there are alot of packages
that have numerous (legacy) versions used by some distros. I'd rather
not update all old recipes just because i happen to add a new,
cleaned-up version of a package. What do you think?