[OE-core] [PATCH] bluez4/5: Add EXCLUDE_FROM_WORLD = 1

Richard Purdie richard.purdie at linuxfoundation.org
Thu Sep 12 12:59:14 UTC 2013


On Thu, 2013-09-12 at 10:29 +0100, Paul Eggleton wrote:
> On Wednesday 11 September 2013 14:38:01 Saul Wold wrote:
> > We can't build both recipes in the world build as there is a collision of
> > package name and PR values. Specificly the libasound-module-bluez which is
> > the same in both goes backwards from r5 (bluez4) -> r0 (bluez5) and the
> > subpackage_metadata check fails:
> > 
> > ERROR: Recipe lib32-bluez5 is trying to change PR from 'r0' to 'r5'. This
> > will cause do_package_write_* failures since the incorrect data will be
> > used and they will be unable to find the right workdir.
> > 
> > [YOCTO #5165]
> > 
> > Signed-off-by: Saul Wold <sgw at linux.intel.com>
> > ---
> >  meta/recipes-connectivity/bluez/bluez4.inc  | 1 +
> >  meta/recipes-connectivity/bluez5/bluez5.inc | 2 ++
> >  2 files changed, 3 insertions(+)
> > 
> > diff --git a/meta/recipes-connectivity/bluez/bluez4.inc
> > b/meta/recipes-connectivity/bluez/bluez4.inc index b540622..e4f6834 100644
> > --- a/meta/recipes-connectivity/bluez/bluez4.inc
> > +++ b/meta/recipes-connectivity/bluez/bluez4.inc
> > @@ -43,3 +43,4 @@ EXTRA_OECONF = "\
> >    --with-udevrulesdir=`pkg-config --variable=udevdir udev`/rules.d \
> >  "
> > 
> > +EXCLUDE_FROM_WORLD = "1"
> > diff --git a/meta/recipes-connectivity/bluez5/bluez5.inc
> > b/meta/recipes-connectivity/bluez5/bluez5.inc index e5cb9e8..2e25d86 100644
> > --- a/meta/recipes-connectivity/bluez5/bluez5.inc
> > +++ b/meta/recipes-connectivity/bluez5/bluez5.inc
> > @@ -82,3 +82,5 @@ FILES_${PN}-dbg += "\
> >  RDEPENDS_${PN}-testtools += "python python-dbus python-pygobject"
> > 
> >  SYSTEMD_SERVICE_${PN} = "bluetooth.service"
> > +
> > +EXCLUDE_FROM_WORLD = "1"
> 
> Surely we don't need to exclude both from world, just one of them?

This way the right one gets selected by the dependency trees. If you do
it the other way, we'd have to revisit the problem and anyone choosing
an alternative would possibly end up with build issues. 

Cheers,

Richard




More information about the Openembedded-core mailing list