On Tue, 2015-02-10 at 15:43 +0000, Burton, Ross wrote: > > On 8 February 2015 at 21:16, Christopher Larson <clar...@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 -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core