Problems with new policy
Ricardo Javier Cardenes
I'm re-packaging 'sip' and 'python-pyqt' to make them comply the new
Policy, but I've just found a problem. Let me explain it a bit:
- sip is a tool that helps creating Python wrappers over C++ classes.
It parses a .sip (kind of .i - swig) file, and generates .cpp and .py
You end with a .py module which makes use of a .so extension module.
- The .so extension module relies on what I package under the name of
'libsip'. It's a helper library used by sip wrappers for some common
tasks (allocation, deallocation objects, etc).
The problem will be more apparent if I say that libsip includes "Python.h"
when compiling. This means I need a 'libsip-python1.5',
'libsip-python2.1',... which is fairly easy to achieve. Both versions are
interchangeable, because the ABI doesn't changes, but they won't
(presumably) work for a different version of Python than they were
compiled for (internal structure differences, I suppose).
This is no problem _BY NOW_, because the only libsip-dependant software in
Debian is PyQt (well I don't know of any other), and is reasonable to
think that no one wants to install both python1.5-pytq and python2.1-pyqt.
But... What will happen in the future? I've at least one other package I
want to upload that uses sip for interfacing a C++ lib (package libxdb).
What if one person wants to install PyQt for Python 2.1 and PyXBase
(libxdb wrapper) for Python 1.5. They both rely on libsip, but...
Anybody knows an elegant solution for this? :-) Maybe I'm talking about
a FAQ question, but It's the first time I have such a problem. Any ideas?
Regards.
--
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Ricardo Javier Cardenes
> On Mon, Nov 26, 2001 at 02:52:51PM +0000, Ricardo Javier Cardenes wrote:
> Maybe I'm an idiot and I don't fully understand the problem... but what's
> the problem?
Probably I explained bad the problem, or even there's no problem, and I'm
being worried before even trying it.
> Provided libsip-python1.5 and libsip-python2.1 can both co-exist, what's the
> problem with python1.5-pyqt and python2.1-pyqt co-existing? Where and how is
> the "libsip" being installed; is it in the /usr/lib/pythonX.Y/site-packages,
> or somewhere else?
libsip is not a Python extension module. It's a library needed by the
shared object part of extension modules created with sip.
> In any case, it is the same basic problem for any multi-version packages;
> you need to either make them co-exist properly so they can both be installed
> at the same time, or make them conflict and force any packages that use it
> to deal with the problems (ie, make two conflicting versions too, or just
> force everyone to use one version or not use it at all).
That's the point. There's no problem with PyQt. It's a Python module and
both it and its extension shared object reside at
/usr/lib/pythonX.Y/site-packages. My problem is about libsip. If libsip
has to be at /usr/lib (as it's right now), then I have a real problem with
versioned packages (if I want them to coexist, of course).
Colin Watson
> going slightly off-topic, this problem is a good example of i dubt i
> always had with debian sonames. shouldn't a package name libfoo4 provide
> a library named libfoo.so.4.x.x?
That depends on whether the library is actually called foo4 (i.e. if the
link line is -lfoo4) or whether it's just version 4 of libfoo. Even in
the latter case there's no reason why the soname should have to match
the version number of the package, because you only need to change the
soname when you make changes that affect binary compatibility.
> so, the right name is
>
> libsip-python2.1.so.2.0.0
If the soname wanted to be 2.0.0, then yes, but this means that people
who link against the library will have to use -lsip-python2.1,
potentially breaking source compatibility with other distributions.
> or
> libsip2-python2.1.so
This (no soname) is only allowed if you regard the library as private
and keep it somewhere other than /usr/lib.
> or
>
> libsip.so.2.python2.1.x.y... ugly! it is even possible?
That sounds best to me in the absence of any better coordination from
upstream, or being able to use a single libsip. I agree that it's ugly,
though.
Do libsip upstream set any sonames? Is it important that binaries linked
against it on Debian can be run on other distributions?
--
Colin Watson [cjwa...@flatline.org.uk]
Ricardo Javier Cardenes
> > or
> >
> > libsip.so.2.python2.1.x.y... ugly! it is even possible?
>
> That sounds best to me in the absence of any better coordination from
> upstream, or being able to use a single libsip. I agree that it's ugly,
> though.
>
> Do libsip upstream set any sonames? Is it important that binaries linked
> against it on Debian can be run on other distributions?
The actual library is:
libsip.so.6.0.0
(Taken directly from the upstream compile). By now, it's installed at
/usr/lib. When 2.* were not GPL compatible, I only packaged sip/libsip
for Python 1.5. Now we have multiple version of Python, and I want to
package it for all that versions. I'd better ask to the sip development
list if someone has done something for having two python versions working
at a time with it. In the meantime, I'll package the various versions with
a Provides: libsip and Conflicts: libsip (all other options seem too
ugly).
Thanks for all the help :-)