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?
Ross
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
