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