On 04/06/2015 04:39 PM, Christopher Larson wrote:
On Mon, Apr 6, 2015 at 2:21 PM, Peter A. Bigot <[email protected]
<mailto:[email protected]>> wrote:
On 04/06/2015 09:32 AM, Iorga, Cristian wrote:
Well,
1. Peter, Otavio: There is not a single doubt about moving to
BlueZ 5 as default in 1.9;
2. The requested feedback was about the actual implementation;
3. Peter: " I do think it's a bit abrupt to make it the
default in the first stable release that provides a usable
bluez5."; The change is intended for 1.9,the release that will
come in October 2015. Do you think that it is still abrupt?
BlueZ5 is present in YP as an alternative BT stack from 1.7,
it will still be a fully supported alternative in the
(unreleased) 1.8 (as far as upstream goes as "fully
supported", of course), it will the default BT stack in 1.9
(coming October 2015), while BlueZ 4 will still be supported
as an obsolete, but still functional alternative; for 2.0 (why
1.10??), if that will be the name, all mechanisms for having
BlueZ alternatives will be removed, and BlueZ 5 will be the
only official supported BT stack. That's more than two years
for a transition, is that too soon??
Sorry; I got confused about which numbers were which and where
things are in the release cycle. I didn't consider bluez5 to be
generally usable until the patches that were merged in February
for what will be 1.8. Since both bluez4 and bluez5 will be
available in 1.8, making the default bluez5 in 1.9 is fine, and
removing bluez4 in what follows is fine. (I have no idea what
version is intended to follow 1.9, but if it isn't some huge
backwards-incompatible change I would expect it to be 1.10 rather
than 2.0. That's just from the way I normally manage versioning
myself.)
I have no objections to the technical approach in the patch (it's
consistent with what I had in mind when I created that bbclass)
but I'm not familiar with how DISTRO_FEATURES_BACKFILL is supposed
to work so abstain from further comment.
Backfill lets you add features which become default in DISTRO_FEATURES
even when a distro overrides DISTRO_FEATURES, unless they explicitly
add them to DISTRO_FEATURES_BACKFILL_CONSIDERED.
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).
In the absence of more detail on why using DISTRO_FEATURES_BACKFILL is a
better solution I prefer Cristian's original approach.
Peter
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
