[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: pylibs and pydeps: shlibs-like support for Python extensions



Le mardi 31 janvier 2006 à 16:08 -0600, Joe Wreschnig a écrit :
> The immediate problem: PyGTK encourages other Python modules to use its
> code generator and GObject wrappers. Between 2.6 and 2.8 the ABI changed
> so that extensions build against 2.8 do not work against 2.6. This is
> breaking gst-python and its reverse dependencies, soundconverter,
> quodlibet, and istanbul. It may break other packages as well.
> 
> The general problem: Python modules that provide build-time shared
> objects have no way of expressing dependencies like this. PyGTK is the
> first example to break, probably because it's very large and widely
> used. However, it's not unique in this respect: Pygame uses shared
> objects from Numeric, for example.
> 
> The solution: Debian solved this problem for regular shared objects with
> shlibs files. So the attached changes to dh_python and Python policy are
> an implementation of something like shlibs files, for Python.

I don't think the proposed solution addresses the specific issue you
describe (PyGTK ABI breakage).

First, when a library package breaks the way you describe, the SONAME is
changed, and the package name is changed accordingly. Same problem, same
solution: wouldn't it be better to simply change the python-gtk2 package
name?

Second, the shlibs mechanism was introduced because it is easy to obtain
(through objdump) a list of dependencies for a binary. Your patch only
seems to read the .pydeps file, which still has to be written by the
maintainer. It then relies on the .pylibs of the package you depend
upon, which has to guess when the ABI can break in the future.
-- 
 .''`.           Josselin Mouette        /\./\
: :' :           josselin.mouette@ens-lyon.org
`. `'                        joss@debian.org
   `-  Debian GNU/Linux -- The power of freedom



Reply to: