-> > RPM is system-wide version control. 'Pristine' sources. -> -> How can it be more pristine that getting the source from the manufacturer -> and compiling it? It can be more pristine by having checksum, filesize, and public key signature checks to verify that you're using the source EXACTLY as distributed by the 'manufacturer'. I.e., who knows whether or not that mirror you just downloaded from has a respectable admin... RPM does this automatically for me, instead of me having to do it myself manually. -> > A safe upgrade path. -> -> How does this become more safe with RPM's? If a new version is incompatible -> with your data somehow, it will be incompatible no matter how many RPMs you -> throw at it. I was not referring to data compatibility. What you say above is obvious. I was referring to (a) the updated list of dependencies, including what versions of which shared libraries you need installed, (b) pristine sources (see above), and (c) the RPM scripts that automatically shutdown/close/halt all necessary components, do the upgrade, then restart/open/run the program again. What happens if you do a "./configure ; make ; make install" on a server where you have a running Apache or Zope install? -> > A way to CLEANLY uninstall something. -> -> As said before: rm -r does that for Zope. And it only depends on you having -> the correct version of Python. Admittedly, with Zope the RPM thing is less of an issue because it's self-contained in its own directory. However, almost all of the GNU packages will put stuff in /usr/bin/, /usr/local/bin/, /usr/X11R6/, /lib, or some combintation thereof. So, I use RPMs. Since I use RPMs for everything else, I want to use it for Zope, too. -> Making binary distributions of any kind is a huge pain in the ass. Can you back this up? Many projects (MySQL? KDE?) just maintain the .spec file and auto-generate the RPMs for many different architectures. -> operating systems and version do you think Zope should have packages for? Just because we can't do ALL archictectures doesn't mean we shouldn't do at least a couple. -> How many would that amount to? How about the top 3? MS-Windows (already being done), i386 RPM (already being done but not auto-generated), and i386 DEB. Hell, if a SRPM were available, it would allow me to generate my own RPMs with a single --rebuild command. -> having a binary install. Instead somebody (and it seems to me that you guys -> think it is Zope corp ) has to maintain and test a ton of binary -> installations for several different version of several different operating -> systems. 1. I don't want Zope to test them. The community will do that. 2. An RPM .spec is very easy to maintain (or so I'm told) 3. I'm only asking for one, maybe two more than the Windows one they are already doing -> I suspect this is some of the reson for the great craving for RPM's. People -> simply do not realize that Zope installs much more easily and much more -> cleanly than most unix softwares. They don't realize that RPM's for Zope in -> most cases are more work than non-RPM installs. I want an RPM because, as someone who does use RPMs for system administration, I check to see if something is installed with a command like: [dereks@dereks src]$ rpm -qa | grep -i zope Zope-zserver-2.4.3-1 Zope-2.4.3-1 For me to (a) know, and (b) remember 6 months later, that Zope, unlike everything else on the system, was a tarball placed in /usr/share/zope or wherever, is an unsound administration practice. --Derek