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/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Re: pylibs and pydeps: shlibs-like support for Python extensions
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 <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: pylibs and pydeps: shlibs-like support for Python extensions
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? Sorry, besides my other response, I need to answer: No, the soname stays the same. When things are upwards-compatible, we bump shlibs. We don't change the package name. -- Joe Wreschnig <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: pylibs and pydeps: shlibs-like support for Python extensions
Le mercredi 01 février 2006 à 11:02 -0600, Joe Wreschnig a écrit : > 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. > > > > Sorry, besides my other response, I need to answer: No, the soname stays > the same. When things are upwards-compatible, we bump shlibs. We don't > change the package name. I should be the one to be sorry. I misunderstood you and thought extensions built against 2.6 wouldn't work with 2.8 either. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
python-kid
Hi people I debian/testing there's a deb package called just 'kid'. It's a very nice templating system for python. Debian's package 'kid' is for python2.3... so I'd maybe prefer calling it python2.3-kid. And there's no python2.4 version of this package... Although it's easy to install it using python2.4 setup.py install... it doesn't install 2.4's scripts properly. Pavel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: python-kid
Pavel ?imerda wrote: > Hi people > I debian/testing there's a deb package called just 'kid'. It's a very nice > templating system for python. > > Debian's package 'kid' is for python2.3... so I'd maybe prefer calling it > python2.3-kid. > > And there's no python2.4 version of this package... > Although it's easy to install it using python2.4 setup.py install... it > doesn't install 2.4's scripts properly. > > Pavel Officially, wait for DD to push it http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=338276 Unofficially deb ftp://ftp.real-time.com/linux/real-time-debpool sid custom main deb-src ftp://ftp.real-time.com/linux/real-time-debpool sid custom main -- Bob Tanner <[EMAIL PROTECTED]> | Phone : (952)943-8700 http://www.real-time.com, Minnesota, Linux | Fax : (952)943-8500 Key fingerprint = AB15 0BDF BCDE 4369 5B42 1973 7CF1 A709 2CC1 B288 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
