Re: [Mailman-Developers] version mismatch?
--On 21 July 2005 05:32:43 +0900 Tokio Kikuchi <tkikuchi@is.kochi-u.ac.jp> wrote:
Barry Warsaw wrote:
On Wed, 2005-07-20 at 12:16, Ian Eiloart wrote:
Am I right in thinking this means that I need to downgrade my python version to make this work?
No, but apparently does mean that you'll have to rebuild the codec extensions that come with Mailman. I /think/ if you run Mailman's config.status and then run make install again (against Python 2.4.1 of course) you should be golden.
Or, you may have to clear the previously installed codec modules by % rm -rf <prefix>/pythonlib/{japanese,korean} then run make install again.
Hmm, is that because the build process looks for existing codecs in <prefix>?
I can't take down Mailman while I build the new version - it takes too long, and Mailman is too important for our business. And, I don't work nights!
Similarly, I can't mess with the current installation in order to make the new one build. I have to make a new build, test it, then deploy it. If deployment takes a couple of minutes to take down the service, move some links, then bring it back up, that's OK.
Actually, that raises an issue. When I install Python, it kindly installs in eg /local/lib/python2.4 - then it moves a link to enable the new installation.
It would be very nice if Mailman would do the same. Taking down my list server while building the new one isn't practical. Especially when I can't be sure the new one will work. I found I have to: build (configure, make, make install) with <prefix> = /local/mailman-2.1.6. test the web pages (fixing apache config to find the cgi) configure with <prefix> = /local/mailman hack the Makefile to install in /local/mailman-2.1.6 make, make install link archive, log, queue directories take down mailman link /local/mailman put mailman back up
Now, this process is kind of workable, but has these drawbacks: 1. it's more complex than it should be 2. I never get to test what I finally install - it has to be rebuilt 3. It takes much longer than it should.
Let us know if that works and I'll update the release notes.
Ah, well that'll have to wait, I'm afraid. I've downgraded Python to 2.2.3, and reinstalled Mailman. Seems to work just fine. We don't use Python for much else, so I'm not desperate to update it.
-Barry
-- Ian Eiloart Servers Team Sussex University ITS
On Thu, Jul 21, 2005 at 02:05:07PM +0100, Ian Eiloart wrote:
Similarly, I can't mess with the current installation in order to make the new one build. I have to make a new build, test it, then deploy it. If deployment takes a couple of minutes to take down the service, move some links, then bring it back up, that's OK.
That's what I've been doing, see below.
It would be very nice if Mailman would do the same. Taking down my list server while building the new one isn't practical. Especially when I can't be sure the new one will work. I found I have to: build (configure, make, make install) with <prefix> = /local/mailman-2.1.6. test the web pages (fixing apache config to find the cgi) configure with <prefix> = /local/mailman hack the Makefile to install in /local/mailman-2.1.6 make, make install link archive, log, queue directories take down mailman link /local/mailman put mailman back up
Now, this process is kind of workable, but has these drawbacks: 1. it's more complex than it should be 2. I never get to test what I finally install - it has to be rebuilt 3. It takes much longer than it should.
The approach I've taken is: Install mailman in /mail/mailman-2.1.6 Symlink /mail/mailman-2.1.6 to /mail/mailman when my testing is complete. As far as Mailman is concerned it has been installed to /mail/mailman-2.1.6, whereas as far as everything else (Apache, Postfix [1], various shell and Python scripts, crontabs, etc) is concerned Mailman has been installed in /mail/mailman. Switching is as simple as: Kill Mailman, Postfix and Apache. rsync lists, logs, etc. Run genaliases. Remove old symlink, create new symlink. Start Mailman, Postfix and Apache.
It's possible, albeit unlikely, that some mail in Postfix's queue has had an alias expanded to the old Mailman path, but because I have two completely separate installations, I could run two parallel installations until such mail has drained from the queue (though archives would be messed up).
It's probably possible, with clever symlinking and aliases, enough knowledge of the code to know what's safe, and compatibles versions, to run two parallel installations using the same lists, qfiles, archives, locks etc, and different Mailman, bin, cgi-bin, messages, etc. That's taking it a bit far I think :)
[1]: Postfix is configured to consult /mail/mailman/data/aliases, but that file contains /mail/mailman-2.1.6/...
Hope this is some help in future,
-- John Tobin "It rose into space, its wings spread wide, then fell, its wings now a fluttering cape wrapped tight about the body of a man. It fell past me, its shadow sliding across walls, growing to swallow whole buildings, lit by the clouds below. The shadow faded into the clouds. It was gone." -- Batman: Year One, by Frank Miller.
On Thu, 2005-07-21 at 09:05, Ian Eiloart wrote:
No, but apparently does mean that you'll have to rebuild the codec extensions that come with Mailman. I /think/ if you run Mailman's config.status and then run make install again (against Python 2.4.1 of course) you should be golden.
Or, you may have to clear the previously installed codec modules by % rm -rf <prefix>/pythonlib/{japanese,korean} then run make install again.
Hmm, is that because the build process looks for existing codecs in <prefix>?
I think it's primarily because Python has a C API version number which gets encoded into C extensions, and this version number changed between Python 2.3 and 2.4. So fixing this basically entails getting the C extensions rebuilt against Python 2.4's API.
Actually, that raises an issue. When I install Python, it kindly installs in eg /local/lib/python2.4 - then it moves a link to enable the new installation.
It would be very nice if Mailman would do the same.
I agree, but it's much more difficult for Mailman. Python has the luxury of being almost entirely static, except for .pyc files, which are just cached byte code streams, and so can be automatically blown away and rebuilt if necessary. OTOH Mailman has lots of dynamic information, from the queue files, to the config.pck databases, to the archives, and those files can (and have) changed. Besides that, Mailman has lots of entry points, from mailmanctl, to the cron scripts, to the linkages with your mail and web servers, to all the command line scripts. It's much harder to just flip a symlink to ensure you're getting the latest Mailman, and the /same/ Mailman across all those touch points.
-Barry
participants (3)
-
Barry Warsaw -
Ian Eiloart -
John Tobin