On Fri, Nov 24, 2006, Ralf S. Engelschall wrote:
>On Thu, Nov 23, 2006, Bill Campbell wrote:
>
>> I spent a fair amount of time getting zope and plone working
>> under OpenPKG this week. The current packaged zope-2.9.1 is
>> somewhat out of date
>
>Zope 2.9.1? Our current Zope package in CURRENT
>is for Zope 3.3.0, Bill!?
I have to say that our primary use of Zope is running Plone.
As I understand it, Plone doesn't work on Zope 3.x.
When I first started digging into this earlier this week as we
have to update our productions systems (which have been running
zope-2.7.4 and Plone-2.0.4) I looked at the CURRENT and STABLE
branches. I found zope-2.9.1-2.20060622 to be the most recent
OpenPKG version of zope-2.x so that was my starting point.
Our production systems are a mix of Release 2.5 with newer
packages from CURRENT or STABLE as necessary to stay with
releases of programs like spamassassin, clamav, and amavisd.
When I build zope-2.9.1-2.20060622.src.rpm, I found that it would
not start as the zopectl program pointed to an invalid location
for the installed Startup/zopectl.py script, and it wasn't
setting the environment correctly. I modified zopectl and
zoperun to get it to run, but Plone-2.5.1 then failed.
It seems that the installation procedure and install directories
of zope were in a state of flux around 2.9.1, which installed
zope under the %{l_prefix}/lib/python director intead of outside
the python directory structure. Since Plone's documentation says
it neads zope-2.9.4 or later, I went with the latest release in
the 2.9.x releases.
I built a OpenPKG package on zope-2.10.1 only to find that Plone
had problems with that as well.
My final cut on zope-2.9.6 required minimal modification of the
zope.spec file to take care of using ``make ... install'' in
place of the ``python install.py'' of the 2.9.1 spec file, and
fixing the zopectl and zoperun scripts to point to the correct
scripts under the %{l_prefix}/lib/zope/Zope2/Startup directory,
and setting the SOFTWARE_HOME enviornment variable correctly.
>> , and wouldn't start requiring changes to the
>> zopectl and zoperun scripts as the paths have changed.
>>
>> I found that the current Plone-2.5.1 won't run with zope.2.10.x,
>> and the most recent version it likes is zope-2.9.6.
>>
>> I modified the zopectl and zoperun scripts to use the correct
>> paths, and had to do some tweaking to the build process as the
>> zope build process has changed since zope-2.9.1. The main
>> changes I made were to add the --prefix to the build process,
>> change the %install to use make defining LN=true to avoid a
>> problem with the install process, making the symlink to python
>> in the zope.spec file.
>>
>> The Plone packaging is based loosely on Tres' packaging of
>> zope-cmf, installing under %{l_prefix}/lib/zope-plone with the
>> appropriate symlinks to %{l_prefix}/var/zope/Products. It also
>> installs zopeedit.py under %{l_prefix}/bin/ manually to avoid
>> problems using ``python setup.py install'' in the spec file.
>>
>> I have these packages available here:
>>
>> ftp://ftp.celestial.com/tmp/zope-2.9.6-20061121.src.rpm
>> ftp://ftp.celestial.com/tmp/zope-plone-2.5.1-20061123.src.rpm
>
>Ok, so do I understand correctly: Zope/Plone insists on running with
>Zope 2.9.6 only. That's the reason why you downgraded from Zope 3.3.0 to
>2.9.6, right? Hmm... but then I would expect that we (1) fix the "zope"
>package at the version 3.3.0 (in case it is also broken), (2) create a
>"zope2" package which still provides Zope 2.9.6 but has "Provides: zope
>= %{version}-%{release}" and then (3) create the "zope-plone" package
>which has "...PreReq: zope <= 2.9". I really would like to see that
>we both provide the "latest and greatest" Zope and a working couple
>Zope+Plone. Can you do this and commit those changes, Bill?
I'll take a look at that for CURRENT, probably this weekend.
I suggest that the zope-2.9.1 in the stable release be updated to
zope-2.9.6 since the current version isn't working.
My guess at this time is that we're probably the only ones using
Zope since nobody has brought up these problems.
We're going to be looking at several Plone Products as part of an
effort to get a standardized system for customer Intranets, and I
will be creating packages for those we decide to use. Would it
be logical to use names like zope-plone-atbibliolist to indicate
their dependency on Zope and Plone, or would some other naming
convention be better?
Bill
--
INTERNET: [EMAIL PROTECTED] Bill Campbell; Celestial Software LLC
URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way
FAX: (206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676
To say that UNIX is doomed is pretty rabid, OS/2 will certainly play a role,
but you don't build a hundred million instructions per second multiprocessor
micro and then try to run it on OS/2. I mean, get serious.
-- William Zachmann, International Data Corp
______________________________________________________________________
The OpenPKG Project www.openpkg.org
Developer Communication List openpkg-dev@openpkg.org
