[OE-core] [PATCH V3 2/2] bluez4: conflicts with/replaces bluez5 - upgrade real-life tests

Iorga, Cristian cristian.iorga at intel.com
Tue Mar 26 18:00:52 UTC 2013


Hi Martin,

For Case 1, I have not tested how happy were connman, ofono, and others after the upgrade. :-) I guess they were not happy at all, at least at runtime.
Also, given your thoughts/observation, please advise on how we should proceed on this one.
An option to postpone this upgrade until 1.5 is also possible.

Regards,
Cristian

-----Original Message-----
From: Martin Jansa [mailto:martin.jansa at gmail.com] 
Sent: Tuesday, March 26, 2013 7:51 PM
To: Iorga, Cristian
Cc: Burton, Ross; Koen Kooi; openembedded-core at lists.openembedded.org
Subject: Re: [PATCH V3 2/2] bluez4: conflicts with/replaces bluez5 - upgrade real-life tests

On Tue, Mar 26, 2013 at 04:42:07PM +0000, Iorga, Cristian wrote:
> Hello all,
> 
> Initial status:
> 
> QEmu machine core-image-sato.
> 
> Follow the /update/upgrade/install path as below:
> 
> Fact: bluez5, at this point, is not an upgrade path for bluez4.
> Logical conclusion would be that bluez 5 and bluez4 should be provided only with RCONFLICTS (case 2), so that doing an:
> opkg upgrade
> would not work, otherwise, user will conclude that, at this stage, bluez5 is a replacement for bluez4, which, simply, is not true (Case 1).
> 
> Forcing user to remove bluez4 and install manually bluez5 will suggest that bluez5 is not compatible with bluez4, so not a replacement.
> 
> In conclusion, in my opinion, we should go with RCONFLICTS only for bluez5.3 PU.
> 
> See cases below.
> 
> Please advise.
> 
> Case 1:
> bluez4 and bluez5: reciprocal RREPLACES and RCONFLICTS

I'm bit surprised that it replaced bluez4 in this case, because last time I tested this I also needed RPROVIDES (at least to keep ofono, packagegroup-base-bluetooth, connman happy).

> root at qemux86:~# opkg update
> Downloading http://192.168.7.1/upg-ipk/all/Packages.gz.
> Inflating http://192.168.7.1/upg-ipk/all/Packages.gz.
> Updated list of available packages in /var/lib/opkg/local_repo_all.
> Downloading http://192.168.7.1/upg-ipk/i586/Packages.gz.
> Inflating http://192.168.7.1/upg-ipk/i586/Packages.gz.
> Updated list of available packages in /var/lib/opkg/local_repo_i586.
> Downloading http://192.168.7.1/upg-ipk/qemux86/Packages.gz.
> Inflating http://192.168.7.1/upg-ipk/qemux86/Packages.gz.
> Updated list of available packages in /var/lib/opkg/local_repo_qemux86.
> root at qemux86:~# opkg list-installed | grep bluez
> bluez4 - 4.101-r6.0
> libasound-module-bluez - 4.101-r6.0
> root at qemux86:~# opkg list-upgradable | grep bluez 
> libasound-module-bluez - 4.101-r6.0 - 5.3-r0.0
> bluez4 - 4.101-r6.0 - 5.3-r0.0
> root at qemux86:~# opkg install bluez5
> Multiple replacers for bluez5, using first one (bluez4).
> Package bluez4 is already installed on root.
> root at qemux86:~# opkg list-installed | grep bluez
> bluez4 - 4.101-r6.0
> libasound-module-bluez - 4.101-r6.0
> root at qemux86:~# opkg upgrade
> Upgrading libasound-module-bluez on root from 4.101-r6.0 to 5.3-r0.0...
> Downloading http://192.168.7.1/upg-ipk/i586/libasound-module-bluez_5.3-r0.0_i586.ipk.
> Removing obsolete file /usr/share/alsa/bluetooth.conf.
> Removing obsolete file /usr/lib/alsa-lib/libasound_module_ctl_bluetooth.so.
> Removing obsolete file /usr/lib/alsa-lib/libasound_module_pcm_bluetooth.so.
> Upgrading bluez5 (5.3-r0.0) to root...
> Downloading http://192.168.7.1/upg-ipk/i586/bluez5_5.3-r0.0_i586.ipk.
> Installing libical (0.48-r0.0) to root...
> Downloading http://192.168.7.1/upg-ipk/i586/libical_0.48-r0.0_i586.ipk.
> Removing package bluez4 from root...
> Configuring libical.
> Configuring libasound-module-bluez.
> Configuring bluez5.
> root at qemux86:~# opkg list-installed | grep bluez
> bluez5 - 5.3-r0.0
> libasound-module-bluez - 5.3-r0.0
> root at qemux86:~#
> 
> Case 2:

Case 2 shows that if some distribution makes decision to replace bluez4 with bluez5 (e.g. doesn't have ofono, connman, packagegroup-base-bluetooth in their images, only their own app adapted to use bluez5), then they need to add RREPLACES to bluez4 by .bbappend.

That's why I was complaining about "upgrade path" when someone makes decision to change bluez version.

On the other hand, having whole R* combo in bluez5 can cause issues to people who don't want to upgrade yet (like in Case 1) - one answer to that is that they just shouldn't build it (no bluez5 in binary feed should prevent accidental opkg upgrade), but this works only until someone does e.g. "bitbake world" :/.

> bluez4 and bluez5: reciprocal RCONFLICTS (only) root at qemux86:~# opkg 
> list-upgradable libasound-module-bluez - 4.101-r6.0 - 5.3-r0.0 
> root at qemux86:~# opkg install bluez5 Installing bluez5 (5.3-r0.0) to 
> root...
> Collected errors:
>  * check_conflicts_for: The following packages conflict with bluez5:
>  * check_conflicts_for: 	bluez4 * 
>  * opkg_install_cmd: Cannot install package bluez5.
> root at qemux86:~# opkg upgrade bluez5
> Installing bluez5 (5.3-r0.0) to root...
> Collected errors:
>  * check_conflicts_for: The following packages conflict with bluez5:
>  * check_conflicts_for: 	bluez4 * 
> root at qemux86:~# opkg list-installed | grep bluez
> bluez4 - 4.101-r6.0
> libasound-module-bluez - 4.101-r6.0
> root at qemux86:~# opkg remove bluez4
> No packages removed.
> Collected errors:
>  * print_dependents_warning: Package bluez4 is depended upon by packages:
>  * print_dependents_warning: 	ofono
>  * print_dependents_warning: 	packagegroup-base-bluetooth
>  * print_dependents_warning: 	connman
>  * print_dependents_warning: These might cease to work if package bluez4 is removed.
> 
>  * print_dependents_warning: Force removal of this package with --force-depends.
>  * print_dependents_warning: Force removal of this package and its 
> dependents
>  * print_dependents_warning: with --force-removal-of-dependent-packages.
> root at qemux86:~# opkg remove --force-depends bluez4 Removing package 
> bluez4 from root...
> root at qemux86:~# opkg list-installed | grep bluez 
> libasound-module-bluez - 4.101-r6.0 root at qemux86:~# opkg install 
> bluez5 Installing bluez5 (5.3-r0.0) to root...
> Downloading http://192.168.7.1/upg-ipk/i586/bluez5_5.3-r0.0_i586.ipk.
> Installing libical (0.48-r0.0) to root...
> Downloading http://192.168.7.1/upg-ipk/i586/libical_0.48-r0.0_i586.ipk.
> Configuring libical.
> Configuring bluez5.
> root at qemux86:~# opkg list-installed | grep bluez
> bluez5 - 5.3-r0.0
> libasound-module-bluez - 4.101-r6.0
> root at qemux86:~#
> 
> 
> 
> -----Original Message-----
> From: Iorga, Cristian
> Sent: Monday, March 25, 2013 3:07 PM
> To: openembedded-core at lists.openembedded.org
> Cc: Iorga, Cristian
> Subject: [PATCH V3 2/2] bluez4: conflicts with/replaces bluez5
> 
> - RCONFLICTS/RREPLACES bluez5
> 
> Signed-off-by: Cristian Iorga <cristian.iorga at intel.com>
> ---
>  meta/recipes-connectivity/bluez/bluez4_4.101.bb |    5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-connectivity/bluez/bluez4_4.101.bb 
> b/meta/recipes-connectivity/bluez/bluez4_4.101.bb
> index 3ea2f25..2e98043 100644
> --- a/meta/recipes-connectivity/bluez/bluez4_4.101.bb
> +++ b/meta/recipes-connectivity/bluez/bluez4_4.101.bb
> @@ -1,6 +1,6 @@
>  require bluez4.inc
>  
> -PR = "r5"
> +PR = "r6"
>  
>  SRC_URI += "file://bluetooth.conf \
>              file://sbc_mmx.patch \
> @@ -11,6 +11,9 @@ SRC_URI += "file://bluetooth.conf \  SRC_URI[md5sum] = "fb42cb7038c380eb0e2fa208987c96ad"
>  SRC_URI[sha256sum] = "59738410ade9f0e61a13c0f77d9aaffaafe49ba9418107e4ad75fe52846f7487"
>  
> +RCONFLICTS_${PN} = "bluez5"
> +RREPLACES_${PN} = "bluez5"
> +
>  do_install_append() {
>  	install -m 0644 ${S}/audio/audio.conf ${D}/${sysconfdir}/bluetooth/
>  	install -m 0644 ${S}/network/network.conf 
> ${D}/${sysconfdir}/bluetooth/
> --
> 1.7.10.4
> 

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com




More information about the Openembedded-core mailing list