[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

 - 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

 - 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.


Version: 2.6.3i
Charset: noconv
Comment: Processed by Mailcrypt 3.5.8, an Emacs/PGP interface


Reply to: