Two things I left out of this previous message:
http://mail.python.org/pipermail/mailman-users/2005-January/041687.html
We fixed an apparent coding error in /usr/lib/mailman/bin/update. On line 556, we changed "addr = data[0].address" to "addr = data[0]", since data[0] was already an address string, not a list.
Further conversation with a Mailman expert (in irc.freenode.net channel #mailman) revealed that our allegedly non-elegant solution was actually what apt-get should have done anyway -- the symlinks we made are standard on a healthy Debian system. IRC transcript follows, just for reference.
--------------------8-<-------cut-here---------8-<-----------------------
<kfogel> http://mail.python.org/pipermail/mailman-users/2005-January/041687.html <kfogel> horrific details of our upgrade are at that url <kfogel> we did eventually get it working, and the new version (2.1.5) looks spiffy. <kfogel> I like the new moderation stuff. <Jim7J1AJH> Sounds like your upgrade didn't make all the symbolic links. <kfogel> Jim7J1AJH: I'm not sure what 'apt-get install mailman' was supposed to do in detail, but yeah, that seems like a fair assertion. <Jim7J1AJH> On the one Debian machine that I use Mailman on, /var/lib/mailman has several symlinks into the /usr/lib/mailman tree... where all the code lives. <kfogel> oh <kfogel> So we're not the only ones to have gone this route... <Jim7J1AJH> It is the "Debian" standard. <kfogel> IOW, we just manually reproduced what apt-get is supposed to do anyway? <kfogel> Great. <kfogel> At least that means future upgrades are likely to work. <Jim7J1AJH> Sounds like it. <Jim7J1AJH> Yup. <kfogel> If you want to post to that effect in response to my post, somebody somewhere a year from now would probably save 40 minutes of time. <kfogel> Your call :-). <Jim7J1AJH> /var/lib/mailman's Mailman, bin, cgi-bin, mail, and scripts all symlink into /usr/lib/mailman. <kfogel> heh! <kfogel> So, we linked cron, and we didn't link cgi-bin. <kfogel> Two points of difference.
- kfogel goes to link cgi-bin <Jim7J1AJH> Oops... yes, cron too. <Jim7J1AJH> You're right. <Jim7J1AJH> lrwxrwxrwx 1 root root 24 Nov 22 02:44 cgi-bin -> /usr/lib/cgi-bin/mailman <kfogel> Ah. <Jim7J1AJH> l <Jim7J1AJH> and one bit of Debian policy I find really goofy, they do: <Jim7J1AJH> lrwxrwxrwx 1 root root 12 Nov 22 02:44 templates -> /etc/mailman <kfogel> There is no /usr/lib/mailman/cgi-bin, but there is a /usr/lib/cgi-bin/mailman <kfogel> just as you said <kfogel> oy oy
- kfogel 's head spins with symlinks <Jim7J1AJH> Yes. One has to wonder what the packager was thinking. <Jim7J1AJH> That and leaving the 'cgi-bin' in the default URLs seems bogus to me. <Jim7J1AJH> They also do: <Jim7J1AJH> lrwxrwxrwx 1 root root 25 Nov 22 02:44 icons -> /usr/share/images/mailman <kfogel> AAAAAH <kfogel> good <kfogel> /var/lib/mailman/cgi-bin was already a link to the right place, we didn't have to do it. <Jim7J1AJH> lrwxrwxrwx 1 root root 18 Nov 22 02:44 locks -> ../../lock/mailman <Jim7J1AJH> lrwxrwxrwx 1 root root 17 Nov 22 02:44 logs -> ../../log/mailman <kfogel> huh <kfogel> locks is not a symlink for us <kfogel> but logs is, and in the way you describe <kfogel> I'm going to fix locks <kfogel> Leaving templates alone though. <Jim7J1AJH> They also put a symlink so that mm_cfg.py really lives in /etc/mailman <Jim7J1AJH> instead of in /usr/lib/mailman/Mailman <kfogel> goodness <kfogel> I'm sure there were Good Reasons for all of these decisions. <kfogel> But it sure makes debugging tough. <Jim7J1AJH> One would hope so. <Jim7J1AJH> Or answering people's questions when they show up using the Debian package. <kfogel> :-)