On Mon, 2006-06-05 at 14:23 +0200, Marc Dequènes wrote: > Steve Langasek <vorlon@debian.org> writes: > > > No. An extension has to be separately *compiled* for each python version > > it's to support. A python-foo package containing > > /usr/lib/python2.3/site-packages/foo/foo.so and > > /usr/lib/python2.4/site-packages/foo/foo.so must not claim to be compatible > > with python (>= 2.5). > > I'm not that silly... > > > However, it *should* be possible to provide a toolchain such that this > > python-foo can be binNMUed when python-2.5 becomes available and > > automatically pick up support for it. > > That's what i suggested in other words. If we can rely on python-all (or > any other mean to get the list of supported versions), and as we already > have the list of package-specific supported versions (via .version in > python-support for example), so that every version is compiled without > having to care to provide the list of versions manually, so > transitioning becomes seamless. CDBS could be enhanced to generate all > the necessary rules, so managing python packages would be painless. CDBS is not necessary; look at python-gst0.10's packaging. The versions it's built for is controlled entirely via a single Make variable, and it uses regular debhelper. This could be further refined to find all installed versions of Python at build time, and simplified because everything would be in the same binary package (so it wouldn't be limited by debian/control). New tools aren't needed to make binNMUs easier, though they can do that too. A few policy changes (mostly what I outlined in my last mail) would be enough to do that with existing tools and minimal trouble. New tools are mostly needed to prevent rebuilding at all (by fixing byte-compilation issues). -- Joe Wreschnig <piman@sacredchao.net>
Attachment:
signature.asc
Description: This is a digitally signed message part