[Pkg-mailman-hackers] Pkg-mailman commit - rev 67 - branches/pkg-split/debian

Laszlo 'GCS' Boszormenyi gcs-guest@users.alioth.debian.org
Sun, 18 Apr 2004 20:55:41 +0200


On Sun, Apr 18, 2004 at 11:10:53AM -0600, Bernd S. Brentrup <bsb@haydn.debian.org> wrote:
> +- Split into mailman, mailman-common, mailman-doc, mailman-i18n.
> +  installing $LANG/LC_MESSAGES/mailman.mo in /usr/share/locale.
 Move templates to /etc/mailman/templates/ ? See bug #199039.

> +- mailman-common.postinst should be better at building a new mm_cfg.py
> +  from an existing configuration, in particular at removing obsolete
> +  vars.  As it stands, a python postinst (using code inspection if
> +  needed) seems to be the way to go.
 Maybe store the key values with debconf, and rebuild it from ground up
for new package revisions? OK, this way me must be sure there's a part
where the user's changes are kept, a separated lines (like svn uses at
commit time) or can we include an other file as it's Python? Also,
/etc/default/mailman[.py] can be used?

> +- As far as I(bsb) am concerned, I'd even prefer separate source
> +  packages for mm-spamassassin, mm-spamprobe, mm-savannah and
> +  mm-clamav
 +1, for a new clamav, whatever handler change we should not release a
whole mailman package, meaning bigger downloads for the user.

> but with spamassassin and savannah already being in the
> +  archive, somebody will probably object :(
 Me not, and as far as we put a debconf warning for the user I think it
may be a good solution; but note we should do it with the normal package
split.

> +- Make lintian clean.
 Well, setgid-binary can be ignored I think as it's vital for the
package. About dir permissions: is 2775 really necessary? I think 0775
is about the same, as the cgi-bin programs and others are setgid/running
as the list user. Why we need an enforcement on gid list?
/usr/lib/mailman/Mailman/Post.py should get a +x in debian/rules, and
/var/lib/mailman/tests/fblast.py patched to start with #!/usr/bin/python
Just a question: is there any reason why python2.2-korean-codecs
suggested over the 2.3 version?

OK, it seems I'm really out. Can you take over two bugs I am currently
involved with?

Thanks,
Laszlo