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

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Tue, 2015-02-10 at 15:43 +0000, Burton, Ross wrote:
> 
> On 8 February 2015 at 21:16, Christopher Larson <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?

I think that concern has been holding this up for a while but I don't
see a good way to avoid it. I'd observe that:

* DISTRO_FEATURES was created to have a common place to enable/disable 
  things rather than individual variables
* There is precedent for package specific issues in DISTRO_FEATURES 
  (e.g. libc)
* PREFERRED_PROVIDER is not a good match for this problem as the 
  providers are not identical, or a drop in replacement, far from it.

So whilst I understand the concern I think we have to move past that
based on the above.

Cheers,

Richard