[OE-core] [PATCH 2/2] bluez5: new package for v5.3

[Burton, Ross]

On 12 March 2013 03:07, Martin Jansa <martin.jansa at gmail.com> wrote:
>> You can't just upgrade from bluez4 to bluez5 like you'd upgrade from
>> glib 2.10 to glib 2.12 - the API was totally rewritten and the reason
>> that we're maintaining both is because removing bluez4 would mean
>> removing bluetooth support is most of the integration points (connman
>> being the notable exception).
>>
>> A distro upgrades from 4 to 5 when they've made the explicit decision
>> to do so, and changes all of their dependencies to reflect this.
>
> That would work with bluez_5.3 with negative D_P too, wouldn't it?
>
> Now they need to refine RREPLACES/RCONFLICTS/RPROVIDES combo in distro
> config too when they do explicit decision to change bluez version.

Yes, so bluez4 and bluez5 should explicitly conflict each other.  This
should be be done.

Obviously both approaches are valid.  the approach of major-in-name
was taken so that packages could depend on the version that they need
for clarity.  As the linkage is over DBus there won't be any shlib
dependencies, so it would be simple to build an image which contained
bluezN but was using the bluezM APIs.

Ross