On Tue, Apr 14, 2015 at 6:28 AM, Burton, Ross <ross.bur...@intel.com> wrote:
> On 7 April 2015 at 00:41, Peter A. Bigot <p...@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
-- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
