Re: Problems with new policy
On Mon, Nov 26, 2001 at 02:52:51PM +0000, Ricardo Javier Cardenes wrote:
>
> 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?
Maybe I'm an idiot and I don't fully understand the problem... but what's
the problem?
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?
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).
The best solution IMHO is to make the two versions co-exist...
--
----------------------------------------------------------------------
ABO: finger abo@minkirri.apana.org.au for more info, including pgp key
----------------------------------------------------------------------
Reply to: