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

[Christopher Larson]

On Tue, Apr 14, 2015 at 6:28 AM, Burton, Ross <ross.burton at intel.com> wrote:

> 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?
>

For what it's worth, I'd agree with that. There's no need to change the
logic.
-- 
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/20150414/9e55d6f7/attachment-0002.html>