<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 14, 2015 at 6:28 AM, Burton, Ross <span dir="ltr"><<a href="mailto:ross.burton@intel.com" target="_blank">ross.burton@intel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"><span class=""><div class="gmail_quote">On 7 April 2015 at 00:41, Peter A. Bigot <span dir="ltr"><<a href="mailto:pab@pabigot.com" target="_blank">pab@pabigot.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">Thank you. So, if I understand correctly, the effect of adding
bluez5 to DISTRO_FEATURES_BACKFILL while keeping the current logic:<span><br>
<br>
# bluetooth support on the platform:<br>
# "" if bluetooth is not in DISTRO_FEATURES<br></span><span>
# else "bluez5" if bluez5 is in DISTRO_FEATURES<br></span>
# else "bluez4"<br>
<br>
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.<br>
<br>
If that understanding is correct, and reviewing
<a href="http://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#ref-features-backfill" target="_blank">http://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#ref-features-backfill</a>,
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).</div></blockquote></div><br></span>My reasoning for backfilling bluez5 is that bluetooth.<span class="il">bbclass</span> has a defined behaviour in 1.8:</div><div class="gmail_extra"><br></div><div class="gmail_extra">if bluetooth in DF:</div><div class="gmail_extra"> if bluez5 in DF:</div><div class="gmail_extra"> return "bluez5"</div><div class="gmail_extra"> else:</div><div class="gmail_extra"> return "bluez4"</div><div class="gmail_extra">else:</div><div class="gmail_extra"> return ""</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Or am I alone in thinking this is the best approach going forward?</div></blockquote></div><br>For what it's worth, I'd agree with that. There's no need to change the logic.<br>-- <br><div class="gmail_signature">Christopher Larson<br>clarson at kergoth dot com<br>Founder - BitBake, OpenEmbedded, OpenZaurus<br>Maintainer - Tslib<br>Senior Software Engineer, Mentor Graphics</div>
</div></div>