Steve Langasek <[EMAIL PROTECTED]> 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. So, that's my idea, willing to automatize all complicated build rules, and remove the upper boundaries in dependencies, which would be rendered useless by intelligent binNMUs. So ok, this is quite some work, but this could be done on time. Transitioning scripts-only packages has already begun and can be accelerated while we work on the scripts for compiled modules, so only minor dependency updates would have to be done. -- Marc Dequènes (Duck)
pgpKtPuZ0Qt57.pgp
Description: PGP signature
