I've been working on adding a bdist_deb command to Python distutils. It makes binary .deb packages (and optionally source packages) from any distutils-type python package. (Distutils already has several other bdist_* commands, e.g. bdist_rpm.)
I've posted my code to the python patch tracker at SourceForge: http://sourceforge.net/tracker/index.php?func=detail&aid=1054967&group_id=5470&atid=305470 If you feel like checking it out, I'd appreciate your comments (and bug reports). Best Regards, Jeff Dairiki ==== Here is some of README.bdist_deb (which is included in my patches): Basic Usage =========== If you have a distutil-ized package and you want to create a binary .deb package so that you can install it cleanly on your Debian systems, try: python setup.py bdist_deb This will: 1. Run the 'sdist' command to build a clean source .tar.gz; 2. Unpack the clean source distribution into a temporary directory 3. Create and populate a debian subdirectory within that clean source dir 4. Run debuild to create the Debian binary package 5. Move the resulting package files into the dist subdirectory. By default, you will get one binary package for each python version for which the corresponding pythonX.X-dev package is installed on the build host. You will also get one dummy package which contains no actual files, but merely depends on the binary package for the 'current' python version. (See sections 2.2.3, case 1 of /usr/share/doc/python/python-policy.txt.gz, in Debian's python package for more on this.) Useful Options --python-versions Explicitly specify which python versions to build binary packages for. (Note that if you want to build packages for python1.5, you need to have boty the python1.5-distutils and python1.5-dev packages on the build host. For python2.x, you need only the appropriate python-dev package.) --keep-temp Don't delete temp files when done. Very useful when the build process is crapping out and you're trying to figure out why. --basename Set the suffix for the Debian package name. Normally this is taken from the python package name. Debian, however, is rather picky about the format of the package names however, so sometimes you might have to override the default. (According to Debian policy, the basename should be the name of the "primary module" in the package.) --source-package Build a source package, too. There are many more options useful for manipulating the meta-data placed in debian/control and debian/changelog. As always try 'python setup.py bdist_deb --help' for a list. Note also that it's much easier to set most of these options for a setup.cfg file rather than on the command line. Maintaining a Debian Package ============================ At present, the bdist_deb command is inadequate if you want to maintain the (Debian) package for inclusion in a Debian package repository. Mostly this is because no history is maintained in the debian/changelog (it will only contain a dummy entry for the most recent release). Also, a package maintainer often would want to hand-tune the various files in the debian subdirectory. For this, there is a second added command, dh_make, which will create and populate a debian subdirectory in the top-level source directory of your python distribution. It is intended that the 'dh_make' command is run only once. From then on Debian packages are built the standard debian way (e.g. by running debuild or debian/rules directly.) In short: python setup.py dh_make is essentially a version of /usr/bin/dh_make (from the Debian dh-make package) which is specialized to python packages. Bugs and Wierdness ================== I'm sure there are many. Let me know if you find any not listed here. (Or if you have good ideas on how to fix the ones listed here.) If your package has any scripts, bdist_deb will generate dummy manpages for them. If your package installs it's own manpages (do any python packages do that?) there probably will be trouble. If your package has any scripts, you will not be able to install binary packages for multiple python versions, as the scripts have the same names in each package and will generate conflicts. TODO: A solution for this would be to make bdist_deb rename scripts from, e.g., /usr/bin/scriptfoo to /usr/bin/scriptfoo-python2.3, and then put appropriate invocations of update-alternatives into postinst and prerm scripts for the package. (The man-pages need to be dealt with in a similar fashion, too.) If your package has any data files, you most likely will have similar problems. I'm not at all sure how to address that issue in any automated manner.
