Re: [PATCHv3 00/10] bluez4/bluez5 selection fixing Yocto 5031

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

[-- Attachment #1: Type: text/plain, Size: 1619 bytes --]

On 02/10/2015 09:43 AM, Burton, Ross wrote:
>
> On 8 February 2015 at 21:16, Christopher Larson <clarson@kergoth.com 
> <mailto:clarson@kergoth.com>> wrote:
>
>         DISTRO_FEATURES_append = " bluez5"
>             PREFERRED_PROVIDER_bluez-hcidump = "bluez5"
>             PNBLACKLIST[bluez-hcidump] = "superseded by bluez5"
>             PNBLACKLIST[gst-plugin-bluetooth] = "dropped from bluez5"
>             PNBLACKLIST[bluez4] = "superseded by bluez5"
>
>
>     For what it's worth, I like the look of this series (and have
>     since they were first posted). Hopefully it gets merged.
>
>
> My concern with this series is using DISTRO_FEATURES to control what 
> version of BlueZ is used in the image.  What makes BlueZ so special 
> that it deserves a DISTRO_FEATURE as opposed to a 
> PREFERRED_PROVIDER_virtual/bluez or a variable such as BLUEZ_VERSION 
> defined in bluetooth.bbclass?

Tried that first pass; I'll defer to RP and the list archives for the 
rationale.

>
> Oh, and gst-plugins-bad has support for BlueZ5 but this series doesn't 
> enable it.

I saw no sign of such support when I started back in November, and 
though the gst-plugins-bad master branch does have it now it looks like 
the package would have to be updated from 0.10.23 to enable it.  IMO 
that's out of scope.  My intent with this series is to make it possible 
to use bluez5 at all, not to make sure that every package that might 
work with bluez5 has support enabled.  That's best left to people who 
have the hardware/use-cases that allow such a configuration to be validated.

Peter

[-- Attachment #2: Type: text/html, Size: 3307 bytes --]