Alan Milligan wrote:
> 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.

I have not.  You are free to do so if it's worrisome to you.

- C

Repoze-dev mailing list

Reply via email to