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

[Richard Purdie]

On Wed, 2013-03-13 at 10:14 +0100, Koen Kooi wrote:
> 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.

For reference we still have "bluez4" in OE-Core as nobody wanted the
pain from a rename...

Cheers,

Richard