Packaging with the new Python policy

A package developers view

Manoj Srivastava

Developer
The Debian Project
Revision History
Revision 1.0.412 Aug 2006
Revision 1.0.310 Aug 2006
Revision 1.0.28 Aug 2006
Revision 1.0.107 Aug 2006
Revision 1.0.031 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. Introduction
1.1. Acknowledgements
2. Goals of the new Python policy
3. Nomenclature and definitions
3.1. Python versions
3.1.1. The Default Python version
3.2. Categorization of Python software
4. General Notes
4.1. Naming python module packages
4.2. Python versions supported by the source
4.3. Byte compilation
4.4. Linking extention modules
4.5. Depends:
4.6. Provides
4.7. Build-Depends:
4.8. Deprecating "current" in versions supported
5. Recipe for developers
5.1. Script
5.1.1. Supported versions
5.2. Private Pure Python Modules
5.2.1. Byte compilation
5.2.2. Supported versions
5.3. Private Extension
5.3.1. Supported versions
5.4. Public pure Python Module
5.4.1. Byte compiling
5.4.2. Supported versions
5.4.3. Depends:
5.5. Public Extension
5.5.1. Supported versions
5.5.2. Provides
6. Changing the default Python version
6.1. Python rtupdate scripts
6.1.1. 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 Debian Python Policy , and the new policy Wiki, the 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 pain.

1.1. Acknowledgements

While this document draws upon the expertise of multiple people and various documents, it has benefited especially from the patience and gentle corrections of people on the Debian-devel mailing list, and specifically from Josselin Mouette, Loíc Minier, Pierre Habouzit, and Matthias Klose.