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