Copyright © 2006 Manoj Srivastava
Revision History | ||
---|---|---|
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 | |
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.
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.
Next | ||
Goals of the new Python policy |