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

[Chris McDonough]

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

Right.  Which is why I'd rather not package a separate Python for
Zope.  And also why I'd want to "guarantee" that ZC-produced RPMs
would run on some version of Red Hat and not guarantee anything
further.  That's not to say they won't run on other platforms, just
that we can't promise they will.

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

That particular bug has been fixed by Red Hat and Python 2.2.2 is now
the stock Python 2 on RH 7.3+ (with compiler package and LFS).  This
matches our current requirements perfectly.  Your point is taken,
however, that this will not always be the case.

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

Yup.

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

I'm not sure anybody can, at least without a top-down binary
distribution model like Debian's, but I agree.

<snip examples>

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

No, you're right, I hadn't thought about it past actually creating the
Zope RPM itself.

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

Because we make the implicit promise that it will work on every Linux
distro, regardless of libc version, availability of large file support
on the platform, etc.  We can't test on all of these platforms (the
same "robustness" problem you mention above).

The desire to package an RPM instead of a tarball is really a desire
to make an insane situation into a sane one by limiting the platforms
on which we guarantee the software to work (in this case, Red Hat
7.3+).  But I understand that this is a politics

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

Fair enough, and thanks.  Maybe we should forego ZC-produced RPM
distros.  I dont have the time to deal with the politics, let alone
the technology issues you raise.  Let the distribution makers deal
with it. ;-)  A middle-ground alternative would be to package SRPMS
but not binaries.  I'm not sure what real goal this would serve,
however.

- C