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

[Tom Rini]

On Mon, 2010-02-22 at 14:10 +0100, Bernhard Reutner-Fischer wrote:
> 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?

Well, if we convert them all, that reduces the number of files to parse,
which is a good thing, yes?

-- 
Tom Rini <tom_rini at mentor.com>
Mentor Graphics Corporation