|| ||Matthias Klose <doko-AT-cs.tu-berlin.de>|
|| ||Move to python 2.4 / Changing the packaging style for python packages|
|| ||Tue, 13 Jun 2006 01:49:26 +0200|
-----BEGIN PGP SIGNED MESSAGE-----
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_ho...)
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.
-----BEGIN PGP SIGNATURE-----
Comment: Processed by Mailcrypt 3.5.8, an Emacs/PGP interface
-----END PGP SIGNATURE-----
To UNSUBSCRIBE, email to debian-devel-announce-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org
to post comments)