[Mailman-Users] Upgrade hell (Debian)

Karl Fogel kfogel at floss.red-bean.com
Wed Jan 5 06:58:17 CET 2005

In this message


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...


In MM 2.0.8 under Debian, virtually all of Mailman lived under

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
       mv ${name} old-${name}
       ln -s /usr/lib/mailman/${name} .

(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 :-).

-Karl Fogel and Brian Fitzpatrick

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

More information about the Mailman-Users mailing list