>>>>> Steve Langasek <[EMAIL PROTECTED]> writes: >> Hmm, seems a bit backward to me. What if I don't have python2.3 installed at >> all. What's the point in keeping /usr/lib/python2.3/site-packages/foo.so >> around?
> Nothing in policy will require that you do this. We discussed specifically > in the BoF whether it was appropriate to allow building binary modules only > for the current version of python, and the agreement was that yes, this was > appropriate and support will be implemented. Assuming that the package maintainer chose to support multiple versions, this still doesn't explain why we should keep binary modules for python versions that are not even installed by the user. Moreover, building binary modules only for the current version of python is not always practical. Consider the case of ctypes (a package that I maintain). ctypes is included in upstream python2.5. So, ctypes python packages will never include support for python >= 2.5. It doesn't make sense to call this package python-ctypes when Debian moves to python2.5 as default. I understand the upgrade issues that pythonX.Y packages cause with multiple versions of python in Debian. However, for binary modules I don't really see an alternative in some cases. How about this alternate proposal for binary modules * python-foo must support the current python version. * python-foo can optionally include support for older python versions (I am still not convinced on this one). * Alternatively, pythonX.Y-foo is allowed to support older versions of python in the archive. Ganesan -- Ganesan Rajagopal -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
