I thought of 1.9 as the preparatory stage for complete removal of bluez4, so that in 2.0 it would be very easy to remove the support for bluez4. Continuing to have bluez5 added to DISTRO_FEATURES create the impression that BlueZ5 is still a second class citizen compared to BlueZ4, and it is not my intention to sustain this opinion via code. I hereby standup for my solution. At the moment, we are 1to1. “We think” – Who are the others persons, Ross? /Cristian
From: Burton, Ross [mailto:[email protected]] Sent: Monday, April 6, 2015 12:41 AM To: Iorga, Cristian Cc: OE-core Subject: Re: [OE-core] [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack On 3 April 2015 at 15:13, Cristian Iorga <[email protected]<mailto:[email protected]>> wrote: -# Define a variable that expands to the recipe (package) providing core -# bluetooth support on the platform: +# Define a variable that expands to the recipe (package) providing +# core bluetooth support on the platform: # "" if bluetooth is not in DISTRO_FEATURES -# else "bluez5" if bluez5 is in DISTRO_FEATURES -# else "bluez4" +# else "bluez4" if bluez4 is in DISTRO_FEATURES +# else "bluez5" That wasn't the behaviour that 1.8 sets. We think we should continue to respect the bluez5 DISTRO_FEATURE and add it to DISTRO_FEATURES_BACKFILL. Ross
-- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
