On 27 April 2000, Harry Henry Gebel said:
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):
Yuck. I like the idea that all meta-data is supplied in the setup script, but some of this stuff is obviously RPM-specific so really shouldn't clutter up the main DistributionMetadata class/object. I think the answer is to put it in the mythical setup.cfg -- one more thing prodding me to go off and finish thinking through Distutils config files, argg! I'll let the 'package_data' file slide for now since I haven't supplied a viable alternative, but its days are numbered...
*name - name of package *version - package version *summary - short summary of package *description - long summary of package
Another yuck: description in setup.py -> summary in the .spec file, and long_description in setup.py -> description in the .spec file. Oh well: name conflicts happen, that's just life. I think the confusion can be localized to bdist_rpm.py, so it's not too bad.
doc - a list of string containing names of files and directories to put in the system's documentation directory.
This should be initialized to ["README"] or ["README.txt"] (whichever one happens to be supplied). The "sdist" command ought to make that information available, but there isn't really a clean way to get it now. Hmmm again.
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?
I would say definitely do type-checking, and do it in the logical way: require that everything be a string except: * 'summaries' and 'descriptions' must be {string:string} dictionaries * 'release' can be a number or a string
'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 .
I think the right way to do this is to put these "not-quite-fundamental" meta-data bits in the config file, in a "bdist" section (rather than a "bdist_rpm" section). But that points back to me getting back to the config file stuff....
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.
Why does the .spec file need a directory of its own? The .spec is tiny and essential; I think it belongs right in the distribution root, like a setup script or a makefile. Any temporary by-products of "bdist_rpm" belong somewhere in the build tree: build/rpm, perhaps? I haven't looked at the code yet, but I certainly hope that "bdist_rpm" uses "sdist" to create the source tarball -- if not, that should be fixed.
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.
If you're talking about the standard source distribution tarball, I don't think it *has* to include the .spec file: after all, the point of the "bdist_rpm" command is to 1) generate a spec file, and 2) optionally run some "rpm -b" commands on it. Anyone who downloads the source distribution should be able to reconstruct the .spec file themselves using the "bdist_rpm" command. Of course, then the module developer has to be sure to include "package_data" in MANIFEST.in, but that file should go away to be replaced by setup.cfg, which *will* be one of the default files like README.txt and setup.py.
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.
How about another option to generate a source RPM? Not essential, but it just seems complete. Plus it's generally considered nice to provide source RPMs when you provide binary RPMs. I think it should be accessible like this: setup.py bdist --format=srpm or setup.py bdist_rpm --srpm Maybe --source-rpm or --source-only on that last one; not sure. Also, should the normal output of "bdist_rpm" be just a binary RPM, or both binary and source RPMs? If both by default, "--source-only" makes sense.
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'
The default files that are included in MANIFEST are entirely up to the "sdist" command, which knows nothing about RPMs or other platform-specific distribution mechanisms. I maintain, though, that it's not necessary to include the .spec file in source distributions, so the issue is moot. I could be wrong... Off to actually read the code... Greg -- Greg Ward - Unix bigot gward@python.net http://starship.python.net/~gward/ One man's theology is another man's belly laugh.