Summary

We do a lot of magic currently in postinst/preinst scripts for Python packaging. This has caused problems before. It is also hard to debug: unpack/configure ordering makes it hard to reproduce. Users have a hard time diagnosing, too.

Release Note

The python packaging system is now more robust, easier to inspect and more user-friendly.

Rationale

Design guidelines for the proposed changes:

User stories

Jane perform a upgrade from 8.10 to 9.04 and wants to play a game during the (boring) upgrade. This does not work because right now and she is disappointed. With the 9.04 to 9.10 upgrade it does work and she is much happier.

Design

There are currently two python packaging system implementations. For pycentral we need to tweak the way its used. For python-support we need to start a dialog with the maintainer and see if we can agree on a good way forward.

In detail:

Implementation

For python-central the default is switched to "include-links". No further code changes are required. We need to also add (regression)tests for "pycentral pkginstall foo" and "pycentral pkgremove foo".

For python-support we need to start a dialog with the upstream maintainer and suggest to have "include-links" like semantics by default. With the new karmic version of python-support packages will keep working between the --unpack and --configure phase.

Migration

The migration will happen automatically as python packages get rebuild. For each new python major version (e.g. 2.7) a no-changes rebuild is required with the include-links schema.

Test/Demo Plan

Testing this change should be part of the regular upgrade testing process. We need to check for upgrade failures (that may be caused by this) and do some functional testing after the upgrade.

BoF agenda and discussion

mvo

NOTES

history why we have the current policy

problem space

problems

possible solutions/improvements

action items

liw

We do a lot of magic currently in postinst/preinst scripts for Python packaging. This has caused problems before. It is also hard to debug: unpack/configure ordering makes it hard to reproduce. Users have a hard time diagnosing, too.

mvo would like to simplify Python packaging.

Recap of why the current code is in place (to avoid flip-flopping between problems):

- in intrepid: tried to make time when packages are non-working as short

- originally (before Ubuntu!) Debian had to rebuild python modules when

- python is ugly when it comes to (system) upgrades

- we packaged a module as python2.2-foo - sabdfl always listens! - 2006: the goal was to get remove all hardcoded python versions in the

- Debian now no longer has problem with packages moving into testing,

- there is no real formal Python policy that applies to this time/space

- building for old and new versions of python eases transitions to Debian

- creating symlinks in preinst is rejected by Debian and is pretty fragile - in debconf6 @ mexico some design was whiteboarded which used

- few actual improvements to the situation, we ran out of time - using the same package names for real and virtual packages causes problems

Python-team in Debian has (practically) decided to standardize on python-support, and to avoid python-central.

proposal for just one packaging tool; emerged from discussion at Debconf9: http://lists.debian.org/debian-python/2009/08/msg00003.html


CategorySpec

FoundationsTeam/Specs/KarmicPythonPackagingChanges (last edited 2009-11-30 02:21:50 by robbie.w)