On Wed, 2006-02-01 at 16:16 +0100, Josselin Mouette wrote: > 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? That causes unneeded transitions for programs/modules that depend only on the Python-exposed API (which is most of them). > 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. Well, not "guess". The maintainer should ask upstream when stuff will break. In the case of PyGTK, upstream was certainly aware of the issue. They just didn't care. You're right that it's suboptimal, but it's far more managable than the existing system where we cross our fingers and hope things don't break. -- Joe Wreschnig <piman@debian.org>
Attachment:
signature.asc
Description: This is a digitally signed message part