[Mailman-Developers] importing mailman lists...

Barry A. Warsaw barry@zope.com
Fri, 12 Oct 2001 17:44:46 -0400

>>>>> "RJ" == Ron Jarrell <jarrell@vt.edu> writes:

    >> I've been asked to serve a couple of lists on my production mm
    >> server (2.0.5) that are coming from a 1.0 server.  If I just
    >> accept a tar of the list directories, will a make update do the
    >> right thing, or am I screwed by the fact that the other lists
    >> have already been upgraded from 1.0 to 2.0.5 over the years?

    RJ> I decided that I could hack update with some work to just
    RJ> forcibly do a 1.0 to 2.0.5 upgrade on just those lists... Or,
    RJ> plan B, which is what I actually ended up doing because I
    RJ> figured it'd be faster, was set up another directory, grap the
    RJ> Release_1_0 cvs image, build and install that, drop the lists
    RJ> into it, then install the Release_2_5 image on top of it, and
    RJ> let update do what it normally does...  Since I could do it
    RJ> all in the background it took less of my real time than
    RJ> hacking the python would...

That was probably the best approach, because bin/update (what "make
update" runs), won't do anything if data/last_mailman_version
indicates you're already running the current version.  MM2.1's
bin/update has a -f/--force flag to force the update even if
last_mailman_version doesn't indicate that its necessary.

Then again, you probably don't need bin/update anyway.  This script's
most important task is to update things that aren't related to a
list's config.db schema, such as new directories that have cropped up,
moved files, template duplication removal, changes to qfile schemas,

The config.db/config.pck list schema load and store routines are
designed to automatically update them if necessary.  It does this by
comparing an integer in the database file against DATA_FILE_VERSION
and then migrating the schema as necessary.  So it should be the case
that if you have an older list directory, and you unpack it in a newer
Mailman installation directory, it'll get upgraded the first time the
list is referenced in an email or web hit.

You can force this by using bin/withlist:

% python -i bin/withlist -l myoldlist
Loading list myoldlist (locked)
>>> m.Save()
>>> m.Unlock()
>>> ^D

One caution is that MM1.0 is really old, and a direct update from it
to MM2.0.6 has never been tested, although upgrades along the way
dating back to 1.0b8 (I believe) have been tested.  It's always a good
idea to install a copy of the list and make sure it works before
turning off the old list.