On Fri, 2002-03-08 at 16:31, Derek Simkowiak wrote:
-> > 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...
Of course, this doesn't do a dmaned thing if rpm has a script in it that does an rm -rf /var/lib/rpm.
RPM does this automatically for me, instead of me having to do it myself manually.
Uhh hold on their partner, rpm only checks sigs if you tell it to, it is an additional step. besides, I can provide source to a package, a checksum, and there you go.
-> > 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.
Then, you meant convenient, not safe. ;^)
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?
The same thing as with an rpm. A Makefile can stop/start services and process just like an RPM does, and you *will* need a script to do so in either case.
-> > 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.
Well, you know what they say, if all you have is a hammer, everything looks like a nail. ;^)
Hell, if a SRPM were available, it would allow me to generate my own RPMs with a single --rebuild command.
You don't nee done of those, either. Just a spec file in a tarball. rpm -tb foo.src.rpm.
-> 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
Which would be followed later by this from someone else: "Hey, how come you provide an rpm for foo, but not bar. I want one for bar, and dammit, I like zope so you ZopeCo people need to get on the ball and make them. Don't worry, we the community can test them."
-> 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.
To me, using a hammer on everything, even if it isn't a nail, is folly. :^) -- Bill Anderson Linux in Boise Club http://www.libc.org Amateurs built the Ark, professionals built the Titanic. Amateurs build Linux, professionals build Windows(tm).