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