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

[Lennart Regebro]

From: "Oleg Broytmann" <phd@phd.pp.ru>
>    That because you manage only one computer.

1. No I don't. Don't make assumptions about people you know nothing about.
2. The more computers you manage the less hassle it is. If you install Zope
once and only once, you may start with looking for an RPM. In that case it's
a drawback that there isn't one, since you are looking for it. But once you
have installed Zope one time, you will then know how easy it is, and the
next
installation takes no time at all.

> Think about poor sysadmins who
> maintain dozens servers on a site - they just don't have enough time to
> untar and compile all that crap...

Firstly, most of the time you manage not only several computers, but several
websites on each computer. Most of the times you are then not using a
standard install anyway, and thereby you would not be able to use an RPM
even if you wanted to. An RPM assumes a certain type of install, and in the
Zope case that would mean doing exactly the same thing as wo_pcgi.py does.
Secondly, "untar and compile all that crap" does not take any longer than it
takes you going to an RPM archive to see if there is a Zope RPM, downloading
it and installing it.


From: "Derek Simkowiak" <dereks@realloc.net>
> RPM is system-wide version control.  'Pristine' sources.

How can it be more pristine that getting the source from the manufacturer
and compiling it?

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

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

Making binary distributions of any kind is a huge pain in the ass. What
operating systems and version do you think Zope should have packages for?
How many would that amount to?

Zope installes with such an amazing ease that you get very few benefits from
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. There are loads of better things to use that time to.

If you so badly want an RPM for just the incarnation of the operating system
that you are using: Go ahead, create one. If it's easy to do, then it's not
a problem, right? If it is a complicated task, then you realize why it isn't
done.
But don't tell others that they should put down loads of time into something
that very few people will find particularily useful. There are reasons most
people that create binary installs for a software aren't connected to the
people making the software. They simply have better things to do.

From: "Adam Manock" <abmanock@earthlink.net>
> The bad news:
> The install sticks much closer to the default install than previously,
> effectively undoing a lot of the good restructuring work done in earlier
> RPM releases.

There went the so called "safe upgrade path". :-)

> The "throw everything in either /usr/share/zope or /var/zope"
> install is definitely not pretty (or FHS compliant). There is no "make
> install" equivalent functionality that puts stuff where it should be, IMHO
> this should be done by wo_pcgi, or distutils anyway, not by a monster
1000+
> line spec.

Thats because things are *exactly* where they should be after you have
unpacked the tarball, unless you want to run multiple servers from the same
zope-code, in which case there really doesn't seem to be any One Right Way
to do it.
Zope does not install like most unix software. It does not consist of a
couple of exe files and a few configuration files in an obscure format. For
that reason, there is no place where each file *should* be. There is no
obvious way to split a Zope installation and spread the files in fifty
different places as most installations of many other unix softwares
unfortunately do.

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.