[Zope] What do we want in the way of Zope binary distributions?

[Oliver Bleutgen]

Chris McDonough wrote:
> On Thu, 2003-04-17 at 06:46, Oliver Bleutgen wrote:
>>How are you going to cope with the fact that the stock python from the 
>>distribution maker might not be the "recommended/supported" version for 
>>the zope? I guess nobody can guarantee that even for the next two 
>>version of RH linux.
> 
> 
> We lucked out a bit here because Red Hat uses Python for a lot of their
> tools.  So we're almost guaranteed that Python 2.2.2 (the target version
> for Zope 2.7) will be installed on any recent Red Hat system.  I think
> it's pretty safe to assume that Python 2.3+ will also be available in
> RPM format, so if we come to depend on later Python versions, we can
> just depend on the RPM of that version.

I thought more of the situation where the stock python from the 
distribution is about 3 years younger the the version of python needed 
for the current zope. But that can never happen, right?  ;)

I can just relate to SuSE, and they had, AFAIR, never a specific python 
2.1.3 rpm, python 2.1.3 was just included in the zope rpm.
The result from something like that is that people get confused when 
they want to install python packages needed for a zope product they 
want. They often end up installing them for the wrong python.

> 
> No.  The RPM will just depend on (require) the proper version of the
> system Python.
> 
> I have a spec file stubbed out at
> http://cvs.zope.org/Zope/inst/Attic/Zope.spec.in?rev=1.1.2.8&only_with_tag=chrism-install-branch&content-type=text/vnd.viewcvs-markup

Which illustrates my point perfectly:

"""
# python2.2 packages from RedHat don't have 'compiler' package, but
#2.2.1 packages do, so we require 2.2.1, although 2.2.1 has bugs
#itself that cause Zope to crash.  We should require 2.2.2 here, but
#it hasnt yet been packaged.
"""


> 
>>While I'm no rpm expert, I know there are the options --relocate and 
>>--prefix, which allow to modify where the package is installed. The 
>>package must somehow support this.
> 
> 
> It would be nice to have, but IMHO most people who would install from an
> RPM wouldn't know how to relocate the package anyway, don't you think?  I
> I think the idea is to give folks who aren't comfortable with source
> releases an easy way to get going, but I'm not sure how many people
> would use RPM to do version control like this. Additionally, many
> instance homes can share a single software home and instance homes can
> be installed anywhere.  The installation of an instance home will
> however not be managed via RPM.

Fair point.

But the more I think about it the more I get the same opinion as Jim 
Penny. I would consider not offering any binaries on zope.org, at least 
not rpms which give a false impression of "robustness".
If people get the rpm to install, they expect the software to run 
flawlessly, and _will_ use it for production. Not a good idea in the 
constellation you are descibing in your spec comments.

ZC will never be able to offer the same testing as a distribution does 
(or at least) should, esp. concerning side possible side effects with 
other system components.

Apart from the general problem that Zope is very dependend (at the 
moment) on running on the right version of python, there's more to it.
When you go the rpm route, you are caught in the distribution business.
One example from SuSe 8.1, which has a seperate rpm package for the 
mysql DA:

 >rpm -qpR  zope-mysql-2.0.8-345.i586.rpm
zope
python-mysql
rpmlib(PayloadIsBzip2) <= 3.0.5-1

So, if a user installed your rpm, he will be able (AFAIK) to install the 
stock zope-mysql DA. But what happens if this doesn't work?
Are you sure you have the resources to untagle the mess distributions 
will be able to cause, when they begin to offer not one, but 20 extra 
rpms for certain zope products?

But if all you want to do is to give the beginner an easy starting point 
(which you seem to imply in your last paragraph), why not just stay with 
the bin.tgz?

But you really don't need to convince me, since I'm not a user of the 
binaries, I just want to give an other persective.

cheers,
oliver