Move to python 2.4 / Changing the packaging style for python packages

We will hopefully soon switch the default python version in sid from 2.3 to 2.4. With the upcoming releases of the last packages which didn't support 2.4 yet (Plone on the Zope application server) we may be able to drop support for 2.3 in sid and etch as well.

We think that the support of more than one python version in the distribution at the same time is still needed, as it takes time for some applications to adopt new python versions, and the migration of a python version change from sid to testing can be eased by supporting the python version you come from and the version you go to.

In the past months many changes to to the current python policy were proposed, which were summarized at the python BoF at Debconf6. In short:

- Applications using python and application specific python modules (called here "private modules") do not need an reupload on a python version change, but are just byte-compiled using the new current python version.

- The current pythonX.Y-foo packages having modules in the python library path are collapsed into one package python-foo. Binary independent modules are made available for the python versions currently supported in the distribution. Binary dependent extensions are put for all supported python versions into the same python-foo package. The overhead for a maybe unused extension module was accepted in favour of a reduction of packages, the removed need to rebuild a package for a change of the default python version and less NEW processing when adding support for a new pythonX.Y version.

- We keep information on which python versions are supported by a source package in the source package database, and information for which python versions a package is currently built in the binary package database. That information allows on overview for a python version transition, addition of a new python version, or removal of a python version without looking at the package contents itself.

- Some infrastructure was implemented to remove all hardcoded information about versions in the packaging scripts, so that sourceless package rebuilds (binary NMUs) are enough to update a package for new/removed/default python versions.

The current transition from 2.3 to 2.4 will almost not benefit at all from these proposed changes; further transitions will be smarter.

We will prepare the transition in experimental by an upload of the python, python-dev packages on 2006-06-12 and try to prepare many packages, so that most packages in unstable can be uploaded at the same time and reduce the amount of uninstallable packages. The upload of all these packages should happen this weekend (2006-06-17/18).

Package maintainers currently can not find details in just one place. Information currently can be found at

- An updated Python policy, the current draft at http://people.debian.org/~piman/python-policy/

- On the wiki pages at http://wiki.debian.org/DebianPython/NewPolicy

- #debian-python on OFTC

- Packaging examples - CDBS (not yet available) - python-support (http://wiki.debian.org/DebianPythonFAQ) - python-central (http://python-modules.alioth.debian.org/python-central_howto.txt)

Thanks to all the contributors on debian-python, the participants of the Python BoF at Debconf6. Thanks to Raphael, Joe, Joss, Marc for updating the packaging tools and the policy document.

Matthias