[OE-core] LOCALCOUNT increased twice when there are 2 layers with same git recipe

[Martin Jansa]

On Thu, Jun 09, 2011 at 10:24:59AM +0100, Richard Purdie wrote:
> On Thu, 2011-06-09 at 10:38 +0200, Martin Jansa wrote:
> > Hi,
> > 
> > I was wondering why I see gobject-introspection built on every image
> > build and it's because LOCALCOUNT is changing all the time.
> > 
> > OE om-gta02 at shr ~/shr-core $ find openembedded-core/ -name gobject-introspection\*
> > openembedded-core/meta/recipes-gnome/gnome/gobject-introspection_git.bb
> > SRCREV = "efa7266bcf78478ce62e8dd778a4f0417bfd4d15"
> > PV = "0.10.8+git${SRCPV}"
> > 
> > OE om-gta02 at shr ~/shr-core $ find meta-openembedded/ -name gobject-introspection\*
> > meta-openembedded/meta-oe/recipes-gnome/gnome/gobject-introspection_0.9.10.bb
> > meta-openembedded/meta-oe/recipes-gnome/gnome/gobject-introspection_git.bb
> > SRCREV = "8d64bc23d2b837421ecf9c7b0e4b8d5d95ca0d21"
> > PV = "1.29.0+gitr${SRCPV}"
> > 
> > I had to add gobject-introspection_git.bb to meta-oe, because we're
> > using newer glib with gdbus-codegen included (instead separate
> > gdbus-binding-tool we were using before)
> > meta-openembedded/meta-oe/recipes-core/glib-2.0/glib-2.0_git.bb with
> > SRCREV = "d97cbc6731deab137770bc0fe9c69b06f689f5b4"
> > PV = "2.29.3+gitr${SRCPV}"
> > and default gobject-introspection version is not compatible with it.
> > 
> > Problem is that with 2 _git recipes LOCALCOUNT is incremented twice
> > because there are 2 different SRCREVs found during parsing.
> > 
> > I wanted to use gobject-introspection_git.bbappend, but it looks like
> > changing PV/SRCREV from .bbappend is not supported (bitbake-layers also
> > reported that it cannot find right gobject-introspection version to my
> > bbappend. And I also cannot blacklist gobject-introspection_git.bb from
> > oe-core, because Angstrom blacklister uses only PN. So in the end I've
> > removed that recipe from my oe-core-contrib/shr branch which is used for
> > SHR builds..
> > 
> > Is there better way to resolve this? With more layers enabled this could
> > happen more often imho.. Maybe we could add unexpanded -PV to LOCALCOUNT
> > persistent db key with sideeffect of reseting LOCALCOUNT on every PV
> > change (upgrade to newer version).
> 
> I like this idea at least in principle. If you're changing PV, you don't
> mind if the counter resets so I don't see that as a problem...

But it would need fallback to key without -PV in case PN-PV is not found
to prevent LOCALCOUNT breakage like branch addition to key did, also
it's a bit harder to test older bitbake after such change (as fallback
will work only one-way).

http://git.openembedded.org/cgit.cgi/bitbake/commit/?id=8c0afc13ad5eefea62b0b136f5b66792ba4e44cb

Regards,

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20110609/fe5ae562/attachment-0002.sig>