Okay, here are the directions for bdist_rpm To run: ./setup.py bdist --format=rpm or ./setep.py bdist_rpm Will build an RPM using DistributionMetaData to get package information. Additional information can be put in the file 'package_data'. 'package_data' contains python code setting the following variables (variables marked with * are by default set from DistributionMetaData and do not be need assigned in package_data unless you need to override the values in .setup.py): *name - name of package *version - package version *summary - short summary of package *description - long summary of package summaries - a dictionary, keys are locales and values are summaries for that locale. descriptions - a dictionary, keys are locales and values are descriptions for that locale. *copyright - the license used by rpm release - the release of the rpm (for example '1mdk') group - the group the package belongs to vendor - the package's vendor packager - the package's packager *url - the package's URL doc - a list of string containing names of files and directories to put in the system's documentation directory. changelog - a string containing a properly formated changelog (I haven't tried it, but I'm pretty sure RPM will exit with an error if it is fed an improperly format changelog) Unless otherwise noted these must all be strings. There is no type checking yet, I would like people's opinion: should they be cast to strings or should an exception be raised if they are not strings? Or maybe some combination; for example releases are (especially on RedHat) often numerals, so it might be natural to allow a numeric value and cast it to a string, but a value like '8' would probably never make sense for something like 'copyright', so an exception would be raised. 'package_data's local namespace includes the variable 'package_type' which is set to 'rpm', this variable will hopefully allow 'package_data' to be used for all bdist_* commands . bdist_rpm works by making a spec file and saving it into the 'redhat/' directory (making the directory if necessary), it then produces a gzipped source tarball and runs `rpm -ta --clean` on the tarball. bdist_rpm leaves the spec file and tarball around since they would probably be wanted anyway. Here are the caveats I mentioned. If you have not configured rpm to allow you to build RPMs without being root you will have a directory and three files (the redhat/ directory and spec file, the MANIFEST file, and the tarball) saying around owned by root. The other caution is that the spec file must be included in MANIFEST.in, otherwise it will not be included in the tarball and therefore the tarball will not be buildable with rpm. The first will be solved with an option I am adding tonight which will just generate the spec file and tarball, the user can then su and run 'rpm -ta' on the tarball. The MANIFEST problem I don't know what is the best way to solve, should the spec file be automatically added like setup.py, should bdist_rpm add it to the MANIFEST itself, or should it remain the user's responsibility? If it is automatically included should package_data also be automatically included?, if a user alters the package in some way they will want to change the 'release' variable and regenerate the spec file, this will be easier if they have 'package_data' What is everybody's input on the above? -- Harry Henry Gebel, Senior Developer, Landon House SBS West Dover Hundred, Delaware PyNcurses ncurses binding for Python: http://pyncurses.sourceforge.ne