Hi,
This is version 1.05 of the draft, now with typo fixes, and
some initial policy support for partial upgrades for pure python
public modules that are trying to drop support for older versions of
python. The idea is that error cases are minimized if we do not drop
a version of python in a new stable that was the default version in
oldstable; at the same time insisting that every pre python public
module that says "all" in the versions supported field must support
all shipping versions of python in stable (even if this takes extra
effort in the form of splitting off private modules and including them
conditionally based on python version from a wrapper module that does
little but conditional imports.
The current version, and future updates, are to be
found at http://www.golden-gryphon.com/software/manoj-policy/
manoj
Packaging with the new Python policy
A package developers view
Manoj Srivastava
Developer
The Debian Project
Copyright (c) 2006 Manoj Srivastava
Revision History
Revision 1.0.5 4^th November 2006
Revision 1.0.4 12 Aug 2006
Revision 1.0.3 10 Aug 2006
Revision 1.0.2 8 Aug 2006
Revision 1.0.1 07 Aug 2006
Revision 1.0.0 31 Jul 2006
Specification of the new Python policy. This article grew as an attempt to
correct a gap in the concrete specification of the new Python policy, and
has grown to be close to a formal specification of the proposed new
policy.
--
Table of Contents
1. [1]Introduction
1.1. [2]Acknowledgements
2. [3]Goals of the new Python policy
3. [4]Nomenclature and definitions
3.1. [5]Python versions
3.1.1. [6]The Default Python version
3.2. [7]Categorization of Python software
4. [8]General Notes
4.1. [9]Naming python module packages
4.2. [10]Python versions supported by the source
4.3. [11]Byte compilation
4.4. [12]Linking extention modules
4.5. [13]Depends:
4.6. [14]Provides
4.7. [15]Build-Depends:
4.8. [16]Deprecating "current" in versions supported
5. [17]Recipe for developers
5.1. [18]Script
5.1.1. [19]Supported versions
5.2. [20]Private Pure Python Modules
5.2.1. [21]Byte compilation
5.2.2. [22]Supported versions
5.3. [23]Private Extension
5.3.1. [24]Supported versions
5.4. [25]Public pure Python Module
5.4.1. [26]Byte compiling
5.4.2. [27]Supported versions
5.4.3. [28]Depends:
5.5. [29]Public Extension
5.5.1. [30]Supported versions
5.5.2. [31]Provides
6. [32]Changing the default Python version
6.1. [33]Python rtupdate scripts
6.1.1. [34]rtupdate script invocation
1. Introduction
While trying to update SELinux packages, I ran across problems in trying
to determine if my packages were complying with the new python policy: any
practical tips for packaging generally devolved to the statement "Oh, just
run dh_python". This is my attempt to offer more concrete tips for
packaging. While this document started by reverse engineering dh_python,
it has, thanks to help from various people more knowledgeable about Python
than I, moved beyond that, and is closer to being a specification
unfettered by the idiosyncrasies of current tools and implementations.
So now this document is a draft formal specification of the proposed new
Python packaging policy. While it draws upon earlier documents, notable
[35]Debian Python Policy , and the [36]new policy Wiki, the [37]Debian
Python FAQ, and the source code for dh_python, and debhelper scripts, it
has essentially been written from scratch, with material reworded,
reorganized, and rearranged, to the extent that it bears little
resemblance to the original sources.
Compiled Python modules are very dependent on the specific Python
version they were compiled against, and may otherwise have restrictions on
the versions of Python they are compatible with. Unless care is taken,
introducing, or dropping, new versions of Python, or changing the default
version, trigger long and often painful transitions where the archive is
inconsistent, and the systems is ill-integrated for the duration. This new
Python policy seeks to address these potential messy transitions, and
minimize the pai
