Op 12 mrt. 2013, om 16:13 heeft "Burton, Ross" <ross.bur...@intel.com> het volgende geschreven:
> On 12 March 2013 03:07, Martin Jansa <martin.ja...@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 :) _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
