Bug#726163: multiarch upgrade issue

2014-05-05 Thread Michael Vogt 
On Wed, Apr 30, 2014 at 04:14:37PM +0200, Jelmer Vernooij wrote:
 Hi Michael,
Hi Jelmer,

[..]
  3. move libpytalloc-util.so.2 into its own libtalloc2-python (or
 similar) package
 I think this is the most reasonable option, though it's a pity we'd have to
 package something so small separately.
[..]
  I'm happy to work on a patch to get rid of the python-talloc
  dependency and unblock the multiarch upgrade, but I would like to hear
  from you what option you prefer.
 
 Hope this helps,

It did, thanks a bunch! Attached is a small patch for option 3 that
seperates the libpytalloc-util.so.2 into a new libtalloc2-pylibs
package.

Feedback, especially on the package name would be great as I would
like to apply this on Ubuntu as well and don't want to diverge on the
packagename of course :)

Cheers,
 Michael
diff -Nru talloc-2.1.0/debian/changelog talloc-2.1.0/debian/changelog
--- talloc-2.1.0/debian/changelog   2014-04-21 14:47:47.0 +0200
+++ talloc-2.1.0/debian/changelog   2014-05-05 08:10:02.0 +0200
@@ -1,3 +1,12 @@
+talloc (2.1.0-3) unstable; urgency=low
+
+  * debian/control:
+- move libpytalloc-util.so.2 into its own library package
+  to support multiarch upgrades of e.g. libsmbclient
+  (LP: #1308657)
+
+ -- Michael Vogt michael.v...@ubuntu.com  Mon, 05 May 2014 08:07:41 +0200
+
 talloc (2.1.0-2) unstable; urgency=medium
 
   * Change maintainer to Samba Debian maintainers.
diff -Nru talloc-2.1.0/debian/control talloc-2.1.0/debian/control
--- talloc-2.1.0/debian/control 2014-04-21 14:47:47.0 +0200
+++ talloc-2.1.0/debian/control 2014-05-05 08:23:54.0 +0200
@@ -42,6 +42,20 @@
  .
  This package contains the development files.
 
+Package: libtalloc2-pylibs
+Multi-Arch: same
+Pre-Depends: ${misc:Pre-Depends}
+Architecture: any
+Depends: ${shlibs:Depends}, ${misc:Depends}
+Section: libs
+Breaks: python-talloc ( 2.1.0-3)
+Replaces: python-talloc ( 2.1.0-3)
+Description: hierarchical pool based memory allocator - Python helper library
+ A hierarchical pool based memory allocator with destructors. It uses
+ reference counting to determine when memory should be freed.
+ .
+ This package contains the shared libraries for Python support.
+
 Package: python-talloc
 Pre-Depends: ${misc:Pre-Depends}
 Architecture: any
diff -Nru talloc-2.1.0/debian/libtalloc2-pylibs.install 
talloc-2.1.0/debian/libtalloc2-pylibs.install
--- talloc-2.1.0/debian/libtalloc2-pylibs.install   1970-01-01 
01:00:00.0 +0100
+++ talloc-2.1.0/debian/libtalloc2-pylibs.install   2014-05-05 
08:14:53.0 +0200
@@ -0,0 +1 @@
+usr/lib/*/libpytalloc-util.so.*
diff -Nru talloc-2.1.0/debian/libtalloc2-pylibs.symbols 
talloc-2.1.0/debian/libtalloc2-pylibs.symbols
--- talloc-2.1.0/debian/libtalloc2-pylibs.symbols   1970-01-01 
01:00:00.0 +0100
+++ talloc-2.1.0/debian/libtalloc2-pylibs.symbols   2014-05-05 
08:14:44.0 +0200
@@ -0,0 +1,11 @@
+libpytalloc-util.so.2 #PACKAGE# #MINVER#
+ PYTALLOC_UTIL_2.0.6@PYTALLOC_UTIL_2.0.6 2.0.6
+ PYTALLOC_UTIL_2.0.7@PYTALLOC_UTIL_2.0.7 2.0.7
+ PYTALLOC_UTIL_2.0.8@PYTALLOC_UTIL_2.0.8 2.0.8
+ PYTALLOC_UTIL_2.1.0@PYTALLOC_UTIL_2.1.0 2.1.0
+ pytalloc_CObject_FromTallocPtr@PYTALLOC_UTIL_2.0.6 2.0.6
+ pytalloc_Check@PYTALLOC_UTIL_2.0.6 2.0.6
+ pytalloc_GetObjectType@PYTALLOC_UTIL_2.0.6 2.0.6
+ pytalloc_reference_ex@PYTALLOC_UTIL_2.0.6 2.0.6
+ pytalloc_steal@PYTALLOC_UTIL_2.0.6 2.0.6
+ pytalloc_steal_ex@PYTALLOC_UTIL_2.0.6 2.0.6
diff -Nru talloc-2.1.0/debian/python-talloc.install 
talloc-2.1.0/debian/python-talloc.install
--- talloc-2.1.0/debian/python-talloc.install   2014-04-21 14:47:47.0 
+0200
+++ talloc-2.1.0/debian/python-talloc.install   2014-05-05 08:14:12.0 
+0200
@@ -1,2 +1 @@
 usr/lib/python*/*-packages/talloc.so
-usr/lib/*/libpytalloc-util.so.*
diff -Nru talloc-2.1.0/debian/python-talloc.symbols 
talloc-2.1.0/debian/python-talloc.symbols
--- talloc-2.1.0/debian/python-talloc.symbols   2014-04-21 14:47:47.0 
+0200
+++ talloc-2.1.0/debian/python-talloc.symbols   2014-05-05 08:14:36.0 
+0200
@@ -1,13 +1,2 @@
-libpytalloc-util.so.2 #PACKAGE# #MINVER#
- PYTALLOC_UTIL_2.0.6@PYTALLOC_UTIL_2.0.6 2.0.6
- PYTALLOC_UTIL_2.0.7@PYTALLOC_UTIL_2.0.7 2.0.7
- PYTALLOC_UTIL_2.0.8@PYTALLOC_UTIL_2.0.8 2.0.8
- PYTALLOC_UTIL_2.1.0@PYTALLOC_UTIL_2.1.0 2.1.0
- pytalloc_CObject_FromTallocPtr@PYTALLOC_UTIL_2.0.6 2.0.6
- pytalloc_Check@PYTALLOC_UTIL_2.0.6 2.0.6
- pytalloc_GetObjectType@PYTALLOC_UTIL_2.0.6 2.0.6
- pytalloc_reference_ex@PYTALLOC_UTIL_2.0.6 2.0.6
- pytalloc_steal@PYTALLOC_UTIL_2.0.6 2.0.6
- pytalloc_steal_ex@PYTALLOC_UTIL_2.0.6 2.0.6
 talloc.so #PACKAGE# #MINVER#
  inittalloc@Base 2.0.6

Bug#726163: multiarch upgrade issue

2014-04-30 Thread Michael Vogt 
Hi,

just wanted to mention that the current dependency of libsmbclient to
python-talloc cause a regression when upgrading from a samba3 based
libsmbclient to a samba4 based libsmbclient in certain multiarch
environments.

The problem is that libsmbclient:i386 and libsmbclient:amd64 can be
co-installed with samba3 but no longer with samba4 because of the
python-talloc dependency. Right now samba-libs contains a dependency
on libpytalloc-util.so.2 library which is part of python-talloc.
See https://bugs.launchpad.net/ubuntu/+source/samba4/+bug/1308657 for
the details.

The options are:
1. move libpytalloc-util.so.2 to libtalloc2
2. move /usr/lib/x86_64-linux-gnu/samba/libsamba_python.so.0 to
   samba-python
3. move libpytalloc-util.so.2 into its own libtalloc2-python (or
   similar) package

I don't know enough about the samba4 packaging to have a strong
opinion, but it seems like (1) is a reasonable solution as it does not
require changing existing dependencies. It would mean a tiny
additional lib (libpytalloc-util.so.2 - 11k on my system) in
libtalloc2 that not everyone needs.

I'm happy to work on a patch to get rid of the python-talloc
dependency and unblock the multiarch upgrade, but I would like to hear
from you what option you prefer.


Cheers,
 Michael


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#726163: multiarch upgrade issue

2014-04-30 Thread Jelmer Vernooij 
Hi Michael,

On Wed, Apr 30, 2014 at 04:02:01PM +0200, Michael Vogt wrote:
 just wanted to mention that the current dependency of libsmbclient to
 python-talloc cause a regression when upgrading from a samba3 based
 libsmbclient to a samba4 based libsmbclient in certain multiarch
 environments.
 
 The problem is that libsmbclient:i386 and libsmbclient:amd64 can be
 co-installed with samba3 but no longer with samba4 because of the
 python-talloc dependency. Right now samba-libs contains a dependency
 on libpytalloc-util.so.2 library which is part of python-talloc.
 See https://bugs.launchpad.net/ubuntu/+source/samba4/+bug/1308657 for
 the details.

(note that the samba4 source package has been removed in Debian, there
 is only the samba source package which now ships the binary packages
 previously provided by the samba source package).

 The options are:
 1. move libpytalloc-util.so.2 to libtalloc2
This means libtalloc2 will have to depend on Python; libtalloc2 has quite a few
reverse dependencies that don't require Python at the moment.

 2. move /usr/lib/x86_64-linux-gnu/samba/libsamba_python.so.0 to
samba-python
Several other things in samba-libs depend on libsamba_python.so.0 IIRC.

 3. move libpytalloc-util.so.2 into its own libtalloc2-python (or
similar) package
I think this is the most reasonable option, though it's a pity we'd have to
package something so small separately.

 I don't know enough about the samba4 packaging to have a strong
 opinion, but it seems like (1) is a reasonable solution as it does not
 require changing existing dependencies. It would mean a tiny
 additional lib (libpytalloc-util.so.2 - 11k on my system) in
 libtalloc2 that not everyone needs.
 
 I'm happy to work on a patch to get rid of the python-talloc
 dependency and unblock the multiarch upgrade, but I would like to hear
 from you what option you prefer.

Hope this helps,

Jelmer


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org