[Python-modules-team] Modules with changing APIs/ABIs

[Torsten Marek]

[To those who see this email twice, sorry for posting again, this should
have gone to pmt at lists.a.d.o in the first place]

Hi,

python-sip4 (the runtime support library beneath all bindings of Qt for
Python) changes its ABI with more or less every major release, and
sometimes between minor releases. While practically no code uses it
directly, all Python extension modules using Qt or KDE depend on it and
have to be recompiled for every new release.

So far, in python-qt{3,4} I have handled this by depending on the
current major version (i.e. python-sip4 (>= 4.x), python-sip4 (<< 4.(x
+1)), but several more project have started using it and this approach
clearly doesn't scale. 

So far, I could think of two solutions:

1. Changing binary package names

   This is more or less how libraries are handled: The runtime module is
shipped in python-sip4-x (with x being whatever the ABI version happens
to be) and changed appropriately.

2. Provides:

   In this scenario, the package name stays the same, but python-sip4
provides sth. like sip-runtime-x.y, which is updated accordingly.
Packages like python-qt4 then have to depend on the correct sip-runtime
version.

In any case, exact version should not be hardcoded, but provided by a
substvar. A package which builds Python extension modules has to
build-depend on sip4 (which is the code-generator package) and invoke
dh_sip4 in its rules file. Each binary package that ships a Python
extension that depends on the sip module must then depend on
${sip:Depends}, which contains either the binary package name or the
virtual package name. Thus, the packages are binNMU-safe and a new
version of sip can be handled by a simple rebuild (assuming that the
binding code does not have to be adapted, which happens frequently
enough).

I would somehow prefer solution no. 2 (less hassle, no new queue
involve), especially since the module name is always sip.so and thus
python-sip4-x+1 replaces python-sip4-x completely anyway.

If you have any comments/thoughts, I'd be pleased to hear your input.


best,


Torsten

-- 
.: Torsten Marek
.: http://shlomme.diotavelli.net
.: torsten at diotavelli.net -- GnuPG: 1024D/A244C858


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://lists.alioth.debian.org/pipermail/python-modules-team/attachments/20090805/a798ca7d/attachment.pgp>