Re: [RFC v2 0/9] Proposed solution to bluez4/bluez5 selection

["Peter A. Bigot" <pab@pabigot.com>]

Any feedback on this approach?

Thanks.

Peter

On 11/26/2014 01:46 PM, Peter A. Bigot wrote:
> Here's a new approach to bluez5 integration for YOCTO #5031 based on
> RP's feedback from the last attempt.
>
> Though the lib interface is supposedly compatible between bluez4 and
> bluez5 the dbus interface is not.  The functionality differences are
> currently significant and likely to remain so. Therefore there will be
> no virtual/bluez as originally proposed in the defect report.
>
> Selection of the provider of bluetooth services is mediated by
> DISTRO_FEATURES.  As has been the case, "bluetooth" signifies support
> for bluetooth.  Two new identifiers "bluez4" and "bluez5" distinguish
> the provider of bluetooth services, just as "systemd" and "sysvinit"
> distinguish the provider of init services.
>
> Recipes that reference bluetooth now inherit from bluetooth.bbclass,
> which inspects the DISTRO_FEATURES and provides the variable BLUEZ as a
> default-defined variable with the value:
>   "" if "bluetooth" is not in DISTRO_FEATURES, else
>   "bluez5" if "bluez5" is in DISTRO_FEATURES, else
>   "bluez4"
>
> The presence of "bluez4" or "bluez5" in PACKAGECONFIG is normally used
> to control configuration.  (In some cases this is an "interface change"
> with respect to PACKAGECONFIG values for specific recipes but I don't
> see an alternative where existing keys are insufficiently precise.)
>
> The assumption is most packages will support either bluez4 or bluez5.
> Existing packages that used "bluetooth" or "bluez" as the key to select
> an explicit dependence on bluez4 have mostly been changed to use
> "bluez4" as the key.
>
> Where a package (e.g. pulseaudio) supports both variants with distinct
> configuration options PACKAGECONFIG settings for both "bluez4" and
> "bluez5" should be provided.
>
> Where a package (e.g. connman) supports both variants without distinct
> configuration options the PACKAGECONFIG setting should be "bluez" and
> the dependence will be on "${BLUEZ}".
>
> The following changes since commit ab63640fad50954b0440ab107c96dbd3f919ea4d:
>
>    gdk-pixbuf: use ptest-gnome (2014-11-25 13:03:30 +0000)
>
> are available in the git repository at:
>
>    git://git.yoctoproject.org/poky-contrib pabigot/rfc-v2/bluez5
>    http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=pabigot/rfc-v2/bluez5
>
> Peter A. Bigot (9):
>    bluetooth.bbclass: simplify recipe inference of bluetooth provider
>    packagegroup-base: select distro preference for bluez provider
>    pulseaudio: select distro preference for bluez provider
>    qt-mobility: select distro preference for bluez provider
>    gstreamer1.0-plugins-bad: select distro preference for bluez provider
>    ofono: select distro preference for bluez provider
>    neard: select distro preference for bluez provider
>    libpcap: select distro preference for bluez provider
>    connman: depend on distro provider of bluez
>
>   meta/classes/bluetooth.bbclass                             | 14 ++++++++++++++
>   meta/recipes-connectivity/connman/connman.inc              |  6 ++++--
>   meta/recipes-connectivity/libpcap/libpcap.inc              |  6 ++++--
>   meta/recipes-connectivity/neard/neard.inc                  |  4 ++--
>   meta/recipes-connectivity/ofono/ofono.inc                  |  4 ++--
>   meta/recipes-core/packagegroups/packagegroup-base.bb       |  3 ++-
>   .../gstreamer/gstreamer1.0-plugins-bad.inc                 |  6 +++---
>   .../gstreamer/gstreamer1.0-plugins-bad_git.bb              |  1 -
>   meta/recipes-multimedia/pulseaudio/pulseaudio.inc          |  4 ++--
>   meta/recipes-qt/qt4/qt-mobility_1.2.0.inc                  |  6 ++++--
>   10 files changed, 37 insertions(+), 17 deletions(-)
>   create mode 100644 meta/classes/bluetooth.bbclass
>