[OE-core] [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack

[Christopher Larson]

On Mon, Apr 6, 2015 at 2:21 PM, Peter A. Bigot <pab at pabigot.com> 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.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20150406/5ab050af/attachment-0002.html>