From: Martin Jansa <martin.jansa@gmail.com>
To: "Iorga, Cristian" <cristian.iorga@intel.com>
Cc: Koen Kooi <koen@dominion.thruhere.net>,
"openembedded-core@lists.openembedded.org"
<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH V3 2/2] bluez4: conflicts with/replaces bluez5 - upgrade real-life tests
Date: Tue, 26 Mar 2013 18:50:36 +0100 [thread overview]
Message-ID: <20130326175036.GJ7539@jama> (raw)
In-Reply-To: <969F26A8BAB325438E7EB80D3C3134FB1621A8A5@IRSMSX102.ger.corp.intel.com>
[-- Attachment #1: Type: text/plain, Size: 7264 bytes --]
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@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@qemux86:~# opkg list-installed | grep bluez
> bluez4 - 4.101-r6.0
> libasound-module-bluez - 4.101-r6.0
> root@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@qemux86:~# opkg install bluez5
> Multiple replacers for bluez5, using first one (bluez4).
> Package bluez4 is already installed on root.
> root@qemux86:~# opkg list-installed | grep bluez
> bluez4 - 4.101-r6.0
> libasound-module-bluez - 4.101-r6.0
> root@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@qemux86:~# opkg list-installed | grep bluez
> bluez5 - 5.3-r0.0
> libasound-module-bluez - 5.3-r0.0
> root@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@qemux86:~# opkg list-upgradable
> libasound-module-bluez - 4.101-r6.0 - 5.3-r0.0
> root@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@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@qemux86:~# opkg list-installed | grep bluez
> bluez4 - 4.101-r6.0
> libasound-module-bluez - 4.101-r6.0
> root@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@qemux86:~# opkg remove --force-depends bluez4
> Removing package bluez4 from root...
> root@qemux86:~# opkg list-installed | grep bluez
> libasound-module-bluez - 4.101-r6.0
> root@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@qemux86:~# opkg list-installed | grep bluez
> bluez5 - 5.3-r0.0
> libasound-module-bluez - 4.101-r6.0
> root@qemux86:~#
>
>
>
> -----Original Message-----
> From: Iorga, Cristian
> Sent: Monday, March 25, 2013 3:07 PM
> To: openembedded-core@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@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@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]
next prev parent reply other threads:[~2013-03-26 18:07 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-25 13:07 [PATCH V3 0/2] BlueZ 5.3 new package Cristian Iorga
2013-03-25 13:07 ` [PATCH V3 1/2] bluez5: new package for v5.3 Cristian Iorga
2013-03-25 13:07 ` [PATCH V3 2/2] bluez4: conflicts with/replaces bluez5 Cristian Iorga
2013-03-26 16:42 ` [PATCH V3 2/2] bluez4: conflicts with/replaces bluez5 - upgrade real-life tests Iorga, Cristian
2013-03-26 17:50 ` Martin Jansa [this message]
2013-03-26 18:00 ` Iorga, Cristian
2013-03-25 16:09 ` [PATCH V3 0/2] BlueZ 5.3 new package Koen Kooi
2013-03-25 16:23 ` Burton, Ross
2013-03-25 17:03 ` Martin Jansa
2013-03-25 17:14 ` Burton, Ross
2013-03-26 10:20 ` Iorga, Cristian
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130326175036.GJ7539@jama \
--to=martin.jansa@gmail.com \
--cc=cristian.iorga@intel.com \
--cc=koen@dominion.thruhere.net \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.