Openembedded Core Discussions
 help / color / mirror / Atom feed
From: "Peter A. Bigot" <pab@pabigot.com>
To: openembedded-core@lists.openembedded.org
Subject: [RFC v2 0/9] Proposed solution to bluez4/bluez5 selection
Date: Wed, 26 Nov 2014 13:46:35 -0600	[thread overview]
Message-ID: <cover.1417030958.git.pab@pabigot.com> (raw)

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

-- 
1.8.5.5



             reply	other threads:[~2014-11-26 19:46 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-26 19:46 Peter A. Bigot [this message]
2014-11-26 19:46 ` [RFC v2 1/9] bluetooth.bbclass: simplify recipe inference of bluetooth provider Peter A. Bigot
2014-11-26 19:46 ` [RFC v2 2/9] packagegroup-base: select distro preference for bluez provider Peter A. Bigot
2014-11-26 19:46 ` [RFC v2 3/9] pulseaudio: " Peter A. Bigot
2014-11-26 19:46 ` [RFC v2 4/9] qt-mobility: " Peter A. Bigot
2014-11-26 19:46 ` [RFC v2 5/9] gstreamer1.0-plugins-bad: " Peter A. Bigot
2014-11-26 19:46 ` [RFC v2 6/9] ofono: " Peter A. Bigot
2014-11-26 19:46 ` [RFC v2 7/9] neard: " Peter A. Bigot
2014-11-26 19:46 ` [RFC v2 8/9] libpcap: " Peter A. Bigot
2014-11-26 19:46 ` [RFC v2 9/9] connman: depend on distro provider of bluez Peter A. Bigot
2014-12-05  0:31 ` [RFC v2 0/9] Proposed solution to bluez4/bluez5 selection Peter A. Bigot
2015-01-24  9:17   ` Bian, Naimeng

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cover.1417030958.git.pab@pabigot.com \
    --to=pab@pabigot.com \
    --cc=openembedded-core@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox