On 04/06/2015 02:31 AM, Iorga, Cristian wrote:
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
While I fully support moving to bluez5 and use it in all my images, I do
think it's a bit abrupt to make it the default in the first stable
release that provides a usable bluez5. On the other hand, Yocto's late
to the bluez5 party and it's going to be harder to support bluez4 now.
Six of one; sign me up as weak support for delaying the move to default
bluez5 until 1.10.
Just an opinion.
Peter
*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
