Problems with new policy

[Ricardo Javier Cardenes <ricardo@id-agora.com>]

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.