More Robust Python Packaging
Discuss a more robust python packaging that is less sensitive to unpack/configure ordering. The current python magic had some issues in the past with upgrades. We should improve this and make the system more robust. Possible design guidelines:
• do building/compiling on the buildds
• catch errors on the buildds (and not on the user machines)
• let dpkg do the shuffling of files
• let dpkg do (file) conflicts checking
• as little complexity in the maintainer scripts as possible
• don't force people learn new tools if something is wrong (dpkg -L python-foo should be enough)
• as little work for the archive-admins as possible
Its also a plus if python application can still be run between "unpack" and "configure".
Blueprint information
- Status:
- Complete
- Approver:
- Colin Watson
- Priority:
- Low
- Drafter:
- Michael Vogt
- Direction:
- Approved
- Assignee:
- Barry Warsaw
- Definition:
- Superseded
- Series goal:
- Accepted for lucid
- Implementation:
-
Deferred
- Milestone target:
- None
- Started by
- Completed by
- Barry Warsaw
Whiteboard
Work items:
make python-central use "include-links" as default (e.g. in dh_pycentral): TODO
rebuild all python-central packages in a PPA for testing: TODO
use that PPA and do a test-upgrade (with python-regression test from the lts-upgrades spec): TODO
[lool] propose to debian a similar solution as "include-links" for pysupport (if possible): DONE
ensure python applications keep working between --unpack and --configure: TODO
regression testing for the python2.5 -> python2.6 upgrade (hardy->lucid): TODO
clarify what supported, old-versions and unsupported means in /usr/share/
propose to Debian a way forward to resolve the python-
lool, 2009-12-03: had discussed include-links in pysupport with the Debian maintainer, but the core design of pysupport is in contradiction with a feature such as include-links since the whole symlink tree can be rebuilt from scratch
