[Mailman-Users] Upgrade hell (Debian)

[Karl Fogel]

In this message

  http://mail.python.org/pipermail/mailman-users/2003-June/029660.html

Deirdre Saoirse Moen described a problem upgrade she had while
upgrading Mailman on a Debian GNU/Linux system.  We just encountered
the same problem, when we tried to do

   # apt-get install mailman

to go from MM 2.0.8 to 2.1.5-4.  We eventually solved it, though it
required some local klugery.  We do not claim the solution below is
elegant :-), but anyway Mailman 2.1.5 is working now.  In case it
helps anyone, here is what we did...

Details:
========

In MM 2.0.8 under Debian, virtually all of Mailman lived under
/var/lib/mailman/.

In MM 2.1.5, it seems that static data (scripts, templates, etc) lives
under /usr/lib/mailman/, and dynamic data under /var/lib/mailman/.
(Benjamin "Mako" Hill, a Debian developer, confirmed in IRC that this
is the standard way things are done these days.)

However, due to some Pythonvironmental weirdness, the scripts under
/usr/lib/mailman/bin/ were still trying to import from the old
/var/lib/mailman/Mailman/ directory, instead of from the new
/usr/lib/mailman/Mailman/ directory.

We still don't know why the Python import paths were messed up.  Our
solution was simply to take every directory under /var/lib/mailman/
that has the same name as a directory under /usr/lib/mailman/, and
make the former a symlink to the latter.  Thus:

   # cd /var/lib/mailman
   # for name in Mailman bin cron mail scripts
     do
       mv ${name} old-${name}
       ln -s /usr/lib/mailman/${name} .
     done
   # 

(That's not an actual transcript, but you get the idea.)

The result looks like this:

   # cd /var/lib/mailman
   # ls -l
   total 664
   [...]  Mailman -> /usr/lib/mailman/Mailman
   [...]  archives
   [...]  bin -> /usr/lib/mailman/bin
   [...]  cgi-bin -> /usr/lib/cgi-bin/mailman
   [...]  cron -> /usr/lib/mailman/cron
   [...]  data
   [...]  filters
   [...]  icons
   [...]  lists
   [...]  locks
   [...]  logs -> ../../log/mailman
   [...]  mail -> /usr/lib/mailman/mail
   [...]  mailman
   [...]  messages
   [...]  old-Mailman
   [...]  old-bin
   [...]  old-cron
   [...]  old-mail
   [...]  old-scripts
   [...]  qfiles
   [...]  scripts -> /usr/lib/mailman/scripts
   [...]  spam
   [...]  templates
   [...]  tests
   # 

Currently, "apt-get install mailman" works fine (it's basically a
no-op, but the point is that all the post-install configuration stuff
runs smoothly).  Brian and I expect future 'apt-get install mailman'
invocations to work as well, based on what apt-get seems to be trying
to do.  But who knows, we could be wrong :-).

Best,
-Karl Fogel and Brian Fitzpatrick

 kfogel {+at-sign+} red-bean.com
   fitz {+at-sign+} red-bean.com