[Zope] What causes the community to stall so often?

[Derek Simkowiak]

-> > 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