[PATCH V3 0/2] BlueZ 5.3 new package

[PATCH V3 0/2] BlueZ 5.3 new package

[Cristian Iorga]

- BlueZ 5 v5.3 experimental new package;
- bluez5 package does not replace bluez4 package,
  as a lot of components that interact with bluez
  are not prepared to work correctly with bluez5;
- bluez5 is not an upgrade path from bluez4.
- bluez5 conflicts with/replaces bluez4.

Cristian Iorga (2):
  bluez5: new package for v5.3
  bluez4: conflicts with/replaces bluez5

 meta/recipes-connectivity/bluez/bluez4_4.101.bb    |    5 ++-
 .../bluez5/bluez5-5.3/bluetooth.conf               |   16 +++++++
 .../bluez5/bluez5-5.3/fix-udev-paths.patch         |   35 +++++++++++++++
 meta/recipes-connectivity/bluez5/bluez5.inc        |   45 ++++++++++++++++++++
 meta/recipes-connectivity/bluez5/bluez5_5.3.bb     |   38 +++++++++++++++++
 5 files changed, 138 insertions(+), 1 deletion(-)
 create mode 100644 meta/recipes-connectivity/bluez5/bluez5-5.3/bluetooth.conf
 create mode 100644 meta/recipes-connectivity/bluez5/bluez5-5.3/fix-udev-paths.patch
 create mode 100644 meta/recipes-connectivity/bluez5/bluez5.inc
 create mode 100644 meta/recipes-connectivity/bluez5/bluez5_5.3.bb

-- 
1.7.10.4

[PATCH V3 1/2] bluez5: new package for v5.3

[Cristian Iorga]

- bluez5 does not replace bluez4
- bluez5 is integrated with systemd
- RCONFLICTS/RREPLACES bluez4

Signed-off-by: Cristian Iorga <cristian.iorga@intel.com>
---
 .../bluez5/bluez5-5.3/bluetooth.conf               |   16 +++++++
 .../bluez5/bluez5-5.3/fix-udev-paths.patch         |   35 +++++++++++++++
 meta/recipes-connectivity/bluez5/bluez5.inc        |   45 ++++++++++++++++++++
 meta/recipes-connectivity/bluez5/bluez5_5.3.bb     |   38 +++++++++++++++++
 4 files changed, 134 insertions(+)
 create mode 100644 meta/recipes-connectivity/bluez5/bluez5-5.3/bluetooth.conf
 create mode 100644 meta/recipes-connectivity/bluez5/bluez5-5.3/fix-udev-paths.patch
 create mode 100644 meta/recipes-connectivity/bluez5/bluez5.inc
 create mode 100644 meta/recipes-connectivity/bluez5/bluez5_5.3.bb

diff --git a/meta/recipes-connectivity/bluez5/bluez5-5.3/bluetooth.conf b/meta/recipes-connectivity/bluez5/bluez5-5.3/bluetooth.conf
new file mode 100644
index 0000000..ca5e9e4
--- /dev/null
+++ b/meta/recipes-connectivity/bluez5/bluez5-5.3/bluetooth.conf
@@ -0,0 +1,16 @@
+<!-- This configuration file specifies the required security policies
+     for Bluetooth core daemon to work. -->
+
+<!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"
+ "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
+<busconfig>
+
+  <!-- ../system.conf have denied everything, so we just punch some holes -->
+
+  <policy context="default">
+    <allow own="org.bluez"/>
+    <allow send_destination="org.bluez"/>
+    <allow send_interface="org.bluez.Agent"/>
+  </policy>
+
+</busconfig>
diff --git a/meta/recipes-connectivity/bluez5/bluez5-5.3/fix-udev-paths.patch b/meta/recipes-connectivity/bluez5/bluez5-5.3/fix-udev-paths.patch
new file mode 100644
index 0000000..37362f5
--- /dev/null
+++ b/meta/recipes-connectivity/bluez5/bluez5-5.3/fix-udev-paths.patch
@@ -0,0 +1,35 @@
+Add udevdir/udevrulesdir options
+
+Upstream-Status: Inappropriate [configuration]
+Signed-off-by: Constantin Musca <constantinx.musca@intel.com>
+Signed-off-by: Cristian Iorga <cristian.iorga@intel.com>
+
+Index: bluez-5.0/Makefile.am
+===================================================================
+--- bluez-5.0.orig/Makefile.am	2012-12-24 19:46:54.000000000 +0200
++++ bluez-5.0/Makefile.am	2013-01-30 14:33:15.760615474 +0200
+@@ -175,7 +175,7 @@
+ include Makefile.obexd
+ 
+ if HID2HCI
+-rulesdir = @UDEV_DIR@/rules.d
++rulesdir = @UDEV_RULES_DIR@
+ 
+ rules_DATA = tools/97-hid2hci.rules
+ 
+Index: bluez-5.0/configure.ac
+===================================================================
+--- bluez-5.0.orig/configure.ac	2012-12-24 19:46:54.000000000 +0200
++++ bluez-5.0/configure.ac	2013-01-30 14:34:59.068613895 +0200
+@@ -160,6 +160,11 @@
+ 	AC_SUBST(UDEV_DIR, [${path_udevdir}])
+ fi
+ 
++AC_ARG_WITH([udevrulesdir],
++    AS_HELP_STRING([--with-udevrulesdir=DIR], [udev rules directory]),
++    [], [with_udevrulesdir=/lib/udev/rules.d])
++AC_SUBST([UDEV_RULES_DIR], [$with_udevrulesdir])
++
+ AM_CONDITIONAL(HID2HCI, test "${enable_tools}" != "no" &&
+ 		test "${enable_udev}" != "no" && test "${enable_usb}" != "no")
+ 
diff --git a/meta/recipes-connectivity/bluez5/bluez5.inc b/meta/recipes-connectivity/bluez5/bluez5.inc
new file mode 100644
index 0000000..db9c766
--- /dev/null
+++ b/meta/recipes-connectivity/bluez5/bluez5.inc
@@ -0,0 +1,45 @@
+SUMMARY = "Linux Bluetooth Stack Userland V5"
+DESCRIPTION = "Linux Bluetooth stack V5 userland components.  These include a system configurations, daemons, tools and system libraries."
+HOMEPAGE = "http://www.bluez.org"
+SECTION = "libs"
+LICENSE = "GPLv2+ & LGPLv2.1+"
+LIC_FILES_CHKSUM = "file://COPYING;md5=12f884d2ae1ff87c09e5b7ccc2c4ca7e \
+                    file://COPYING.LIB;md5=fb504b67c50331fc78734fed90fb0e09 \
+                    file://src/main.c;beginline=1;endline=24;md5=9bc54b93cd7e17bf03f52513f39f926e"
+DEPENDS = "udev libusb dbus-glib glib-2.0 libcheck libical"
+
+PACKAGECONFIG ??= "\
+    ${@base_contains('DISTRO_FEATURES', 'alsa', 'alsa', '', d)}\
+    ${@base_contains('DISTRO_FEATURES', 'pie', 'pie', '', d)}\
+"
+PACKAGECONFIG[alsa] = "--enable-alsa,--disable-alsa,alsa-lib"
+PACKAGECONFIG[pie] = "--enable-pie,--disable-pie,"
+
+ASNEEDED = ""
+
+SRC_URI = "\
+  ${KERNELORG_MIRROR}/linux/bluetooth/bluez-${PV}.tar.gz \
+"
+S = "${WORKDIR}/bluez-${PV}"
+
+inherit autotools pkgconfig systemd
+
+EXTRA_OECONF = "\
+  --disable-gstreamer \
+  --enable-usb \
+  --enable-tools \
+  --enable-bccmd \
+  --enable-hid2hci \
+  --enable-dfutool \
+  --disable-hidd \
+  --disable-pand \
+  --disable-dund \
+  --disable-cups \
+  --enable-test \
+  --enable-datafiles \
+  --with-udevdir=${base_libdir}/udev \
+  --with-udevrulesdir=${nonarch_base_libdir}/udev/rules.d \
+  ${@base_contains('DISTRO_FEATURES', 'systemd', '--with-systemdunitdir=${systemd_unitdir}/system/', '--disable-systemd', d)} \
+"
+
+SYSTEMD_SERVICE_${PN} = "bluetooth.service"
diff --git a/meta/recipes-connectivity/bluez5/bluez5_5.3.bb b/meta/recipes-connectivity/bluez5/bluez5_5.3.bb
new file mode 100644
index 0000000..36fa154
--- /dev/null
+++ b/meta/recipes-connectivity/bluez5/bluez5_5.3.bb
@@ -0,0 +1,38 @@
+require bluez5.inc
+
+SRC_URI += "file://bluetooth.conf \
+            file://fix-udev-paths.patch"
+
+SRC_URI[md5sum] = "44de20f6422bf90a01b8df48e7dfe4ed"
+SRC_URI[sha256sum] = "828e2cd1109835c2fc1d731fb7fd7b46951044e451cc8556a37e1312d8c8c9a6"
+
+RCONFLICTS_${PN} = "bluez4"
+RREPLACES_${PN} = "bluez4"
+
+do_install_append() {
+	install -d ${D}${sysconfdir}/bluetooth/
+	install -m 0644 ${S}/profiles/audio/audio.conf ${D}/${sysconfdir}/bluetooth/
+	install -m 0644 ${S}/profiles/network/network.conf ${D}/${sysconfdir}/bluetooth/
+	install -m 0644 ${S}/profiles/input/input.conf ${D}/${sysconfdir}/bluetooth/
+	# at_console doesn't really work with the current state of OE, so punch some more holes so people can actually use BT
+	install -m 0644 ${WORKDIR}/bluetooth.conf ${D}/${sysconfdir}/dbus-1/system.d/
+}
+
+ALLOW_EMPTY_libasound-module-bluez = "1"
+PACKAGES =+ "libasound-module-bluez ${PN}-test"
+
+FILES_libasound-module-bluez = "${libdir}/alsa-lib/lib*.so ${datadir}/alsa"
+FILES_${PN} += "${libdir}/bluetooth/plugins ${libdir}/bluetooth/plugins/*.so ${base_libdir}/udev/ ${nonarch_base_libdir}/udev/ ${systemd_unitdir}/ ${datadir}/dbus-1"
+FILES_${PN}-dev += "\
+  ${libdir}/bluetooth/plugins/*.la \
+  ${libdir}/alsa-lib/*.la \
+"
+
+FILES_${PN}-test = "${libdir}/bluez/test/*"
+
+FILES_${PN}-dbg += "\
+  ${libdir}/${PN}/bluetooth/.debug \
+  ${libdir}/bluetooth/plugins/.debug \
+  ${libdir}/*/.debug \
+  ${base_libdir}/udev/.debug \
+  "
-- 
1.7.10.4

[PATCH V3 2/2] bluez4: conflicts with/replaces bluez5

[Cristian Iorga]

- 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

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

[Iorga, Cristian]

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

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

[Martin Jansa]

[-- 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 --]

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

[Iorga, Cristian]

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@gmail.com] 
Sent: Tuesday, March 26, 2013 7:51 PM
To: Iorga, Cristian
Cc: Burton, Ross; Koen Kooi; openembedded-core@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@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

Re: [PATCH V3 0/2] BlueZ 5.3 new package

[Koen Kooi]

Op 25 mrt. 2013, om 14:07 heeft Cristian Iorga <cristian.iorga@intel.com> het volgende geschreven:

> - BlueZ 5 v5.3 experimental new package;
> - bluez5 package does not replace bluez4 package,
>  as a lot of components that interact with bluez
>  are not prepared to work correctly with bluez5;
> - bluez5 is not an upgrade path from bluez4.

So you say it's not an upgrade path, but...

> - bluez5 conflicts with/replaces bluez4.

...  here you add RREPLACES. Why is that? 

Re: [PATCH V3 0/2] BlueZ 5.3 new package

[Burton, Ross]

On 25 March 2013 16:09, Koen Kooi <koen@dominion.thruhere.net> wrote:
> So you say it's not an upgrade path, but...
>
>> - bluez5 conflicts with/replaces bluez4.
>
> ...  here you add RREPLACES. Why is that?

The logic was that if a *distro* does the upgrade from bluez4 to
bluez5, the package manager needs to be able to remove bluez4 when
installing bluez5, as otherwise they'd just conflict and the package
manager would error out.

Ross

Re: [PATCH V3 0/2] BlueZ 5.3 new package

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 661 bytes --]

On Mon, Mar 25, 2013 at 04:23:26PM +0000, Burton, Ross wrote:
> On 25 March 2013 16:09, Koen Kooi <koen@dominion.thruhere.net> wrote:
> > So you say it's not an upgrade path, but...
> >
> >> - bluez5 conflicts with/replaces bluez4.
> >
> > ...  here you add RREPLACES. Why is that?
> 
> The logic was that if a *distro* does the upgrade from bluez4 to
> bluez5, the package manager needs to be able to remove bluez4 when
> installing bluez5, as otherwise they'd just conflict and the package
> manager would error out.

But opkg will still error out because of missing RPROVIDES, no?

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: [PATCH V3 0/2] BlueZ 5.3 new package

[Burton, Ross]

On 25 March 2013 17:03, Martin Jansa <martin.jansa@gmail.com> wrote:
> But opkg will still error out because of missing RPROVIDES, no?

I'll admit that I didn't test an upgrade path, but the scenario I can
see actually happening is that the distro flips its applications from
bluez4 to bluez5 so they rdepend on bluez5 now.  bluez5 will get
pulled in through that dependency, nothing depends on bluez4 anymore,
so opkg should remove bluez4.  bluez4 and bluez5 don't expose the same
ABI so they are not suitable RPROVIDES for eachother.

Ross

Re: [PATCH V3 0/2] BlueZ 5.3 new package

[Iorga, Cristian]

Hello all,

I will test today an install path for bluez5 using the opkg manager in a existent image.

I will keep you updated.

Regards,
Cristian

-----Original Message-----
From: openembedded-core-bounces@lists.openembedded.org [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of Burton, Ross
Sent: Monday, March 25, 2013 7:15 PM
To: Martin Jansa
Cc: Koen Kooi; openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH V3 0/2] BlueZ 5.3 new package

On 25 March 2013 17:03, Martin Jansa <martin.jansa@gmail.com> wrote:
> But opkg will still error out because of missing RPROVIDES, no?

I'll admit that I didn't test an upgrade path, but the scenario I can see actually happening is that the distro flips its applications from
bluez4 to bluez5 so they rdepend on bluez5 now.  bluez5 will get pulled in through that dependency, nothing depends on bluez4 anymore, so opkg should remove bluez4.  bluez4 and bluez5 don't expose the same ABI so they are not suitable RPROVIDES for eachother.

Ross

_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core