[Mailman-Users] Upgrade hell (Debian)

[Karl Fogel]

Two things I left out of this previous message:

   http://mail.python.org/pipermail/mailman-users/2005-January/041687.html

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

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