[OE-core] [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack

[Burton, Ross]

On 7 April 2015 at 00:41, Peter A. Bigot <pab at pabigot.com> wrote:

> Thank you.  So, if I understand correctly, the effect of adding bluez5 to
> DISTRO_FEATURES_BACKFILL while keeping the current logic:
>
> # bluetooth support on the platform:
> # "" if bluetooth is not in DISTRO_FEATURES
> # else "bluez5" if bluez5 is in DISTRO_FEATURES
> # else "bluez4"
>
> is that bluez5 becomes the default and is in DISTRO_FEATURES
> automatically, and it stays the default even if bluez4 is also in
> DISTRO_FEATURES unless somebody adds bluez5 to
> DISTRO_FEATURES_BACKFILL_CONSIDERED at which point bluez4 takes precedence.
>
> If that understanding is correct, and reviewing
> http://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#ref-features-backfill,
> it's not clear to me that it's the right approach.  We're not backfilling
> "bluetooth", which remains optional and continues to control whether either
> "bluez4" or "bluez5" is relevant.  We're changing the default provider of
> bluetooth services, something that I think can reasonably be changed
> between releases, and something that 1.8 already controls (via explicit
> specification of bluez4 or bluez5 in DISTRO_FEATURES).
>

My reasoning for backfilling bluez5 is that bluetooth.bbclass has a defined
behaviour in 1.8:

if bluetooth in DF:
  if bluez5 in DF:
   return "bluez5"
  else:
    return "bluez4"
else:
  return ""

There's no mention of a bluez4 DISTRO_FEATURE, just a "bluetooth" value to
enable/disable Bluetooth in general, and the toggle between BlueZ 4 and 5
is the presence of a "bluez5" DISTRO_FEATURE.

We don't need to change the algorithm or create new DISTRO_FEATURE entries,
as we have all the logic and items needed: by backfilling bluez5 into
DISTRO_FEATURES we get the default switched, and distributions can flip
back to bluez4 when upgrading to 1.9 by adding in meta-connectivity and
wiping out bluez5 from DISTRO_FEATURES.

Or am I alone in thinking this is the best approach going forward?

Ross
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20150414/a54aa7b9/attachment-0002.html>