[OE-core] [PATCH 00/11] Change all bluez4 references to virtual/bluez

[Chris Larson]

On Wed, Mar 26, 2014 at 7:51 AM, Martin Jansa <martin.jansa at gmail.com>wrote:

> On Wed, Mar 26, 2014 at 09:27:54AM -0500, Lauren Post wrote:
> > This group of patches support the change of hardcoded bluez4 to
> > virtual/bluez so that the upgrade to bluez5 is easier.
> >
> > This group of patches must be applied together.  Bluez4 is still
> > default provider but it will be easier to override and provide bluez5
> > support in future.
> >
> > Note there is one related patch for openobex in meta-oe.
>
> virtual/* still doesn't work correctly in runtime variables, use
> VIRTUAL-RUNTIME_bluez variable.
>
> Last time I've asked for bluez4->bluez5 upgrade path fix on target I was
> told that it's not supported and bluez5 isn't drop-in replacement for
> bluez4 (yet), did that change already?


Afaik libbluetooth is API compatible, but the dbus api isn't. I haven't
done much runtime testing, though. So I don't think virtual/bluez is an
appropriate name given they aren't 100% compatible bluetooth implmentations
across the board. In meta-mentor, we moved to a combination of two
virtual-runtimes (for flexibility, to facilitate replacement not just with
bluez5, but also potentially with a third party implementation, two
virtual-runtimes, one for hardware support, one for the userland bluetooth
stack, (and potentially others in the future)) with a virtual/libbluetooth
build virtual, and then you need to ensure obexd/hcidump are left out of
the build, since they were merged into bluez5.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20140326/394c4e7a/attachment-0002.html>