[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

A bdist_deb command for distutils



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.






Reply to: