Re: [Mailman-Users] Upgrade hell (Debian)

5 Jan 2005


      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