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

[Koen Kooi]

Op 12 mrt. 2013, om 16:13 heeft "Burton, Ross" <ross.burton at intel.com> het volgende geschreven:

> 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.

And I remember the pain and churn when bluez4 was renamed to bluez. I don't want to go through that again. 

At the risk of sounding snarky while making a real recommendation: Why not do it oe-core style and completely remove bluez 4.x at the start of the 1.5 cycle and work through the breakage?  I guess that means I volunteer to help with that :)