Chris McDonough wrote:
> Chris McDonough wrote:
>> Chris McDonough wrote:
>>> Alan Milligan wrote:
>>>> Hi,
>>>> I'm in the midst of rolling repoze out on our BastionLinux RPM's 
>>>> (at (repoze.* 
>>>> and zope.*) for *exactly* what files and versions are being shipped).
>>>> We're at zope-2.9.9, the latest release that runs up plone-2.5.x.  
>>>> I've thus packaged up the required components on 
>>>> However, the zope.interface-3.4.0 is from a later version of Z3 
>>>> than ships with Z2 (I think this is still at 3.3) and when 
>>>> from the Z2 tree is invoked through paster, it 
>>>> dies horribly when it can't find zope.interface.adapter.Surrogate - 
>>>> which appears to have vanished between releases.  Downgrading to 
>>>> zope.interface-3.3.0, as shipped with zope-2.9.9 fixes this 
>>>> (insofar as zope2.wsgi now runs up from the command line).
>>> Eek.  You're right.  I mispackaged.  The zope.interface version up 
>>> there now is the 3.2 version that ships with Zope 2.9.  We maintain 
>>> multiple indexes, and we haven't yet automated a buildbot to test 
>>> them so it's exceedingly difficult to make sure they all work at all 
>>> times.  Apologies.
>>>> Similarly, the ZODB3 version (3.7.2) is later than that shipped in 
>>>> zope-2.9.9.  I don't expect any issues with this (yet at least) as 
>>>> I'm running vanilla zeo from zope-2.9.9
>>> That doesn't cause any problem in our testing.
>>>> Is this anomaly simply due to hoping that nobody will notice if the 
>>>> Z2.10 tarballs are foisted on Z2.9 users - or indeed are these 
>>>> genuinely required, and I'm about to enter module import hell?
>>> No, I think you should be good now with the new distribution.  
>>> Thanks for the notification.
>>>> Note that the zope.proxy and zope.testing tarballs are similarly 
>>>> incorrect, but they too appear benign.
>>> I also believe these are benign.
>>> I'm currently running an easy_install to make sure.
>> Well it *would* have worked if easy_install didn't go off to 
>> to find the latest zope.interface package due to a 
>> promiscuous distribution_links in the ZODB package.  See also 
>> .. Ugh. I'll need to re-roll that ZODB egg without the 
>> dependency-links and put it up there.  I'll post when that's done.
> OK, the answer was:
> - Reroll the ZODB3 tarball.  A new tarball named 
> exists 
> in both of these indexes (and is preferred over the "old" ZODB3 egg by 
> easy_install as a result of the .1agendaless):
Hmmm.  The ZODB version in 2.9.9 is 3.6.2 - you're inflicting an 
upgrade.  I'm not au fait with the changelog between these two 
versions.  As long as you've assured that if someone were to have run up 
repoze over a ZODB, and then at some later point, restarted Z2 over it, 
that Z2 can still read it, then that's fine.  We've all had experiences 
in the past with nasty __setstate__ side effects ensuring downgrades are 
no longer possible.

Repoze-dev mailing list

Reply via email to