Well, my first real experience with bdist_rpm was last Thursday, putting together the Distutils 0.9 RPM. I also built RPMs for NumPy and mxDateTime just to see if it would work (it did, mostly).
* is it really necessary to run "build" twice? This takes quite a while with NumPy (with two source files > 600k) on a 100 MHz Pentium, and I don't think it's necessary -- you *should* just be able to ask the "build" command what its outputs would have been with 'get_outputs()'
* the .spec file is always generated with "python setup.py ..." commands, even if I ran "/usr/local/bin/python1.6 setup.py ..." to generate the RPM. Thus, if I use a non-standard Python to create the .spec file, it still uses the standard /usr/bin/python, and I end up with an RPM that goes in /usr/lib/python1.5/site-pacakges. I'm not saying that an RPM that installs to /usr/local/lib/python1.6/site-packages is necessarily a good thing to be distributing, but if I use that python to make the RPM...
* should we put the output RPMs (source and "binary" -- not really a binary for pure-Python distributions, but you-know-what-I-mean) in a more convenient place? If I didn't know the system intimately, it would not have occurred to me to look for the built RPM in build/bdist.linux2/rpm/RPMS/noarch. ;-)
I'm thinking that a common directory for distribution bureaucracy is a good idea, and we already have a start: putting .spec files in "dist" if bdist_rpm is *only* generating the .spec file. So here's a short list of what could go in "dist" right now: - .spec file - RPMs - Win32 exes - source distributions (tarball, zip file) - dumb built distributions (tarball, zip file)
Currently, all of these things wind up wherever they feel (mostly in the distribution root, but also a few other places). This just seems like a really good idea to me, so unless anyone howls I'm going to go ahead and implement it.
In future, there could be a "debian" subdirectory of "dist", and maybe a directory of FreeBSD "port" info (if that's how it works -- not really clear on that). A Wise script could also go there, if you need to generate a full-blow Windows installer instead of Thomas' minimalist self-extracting ZIP file.