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

[Siggy Brentrup]

--VMt1DrMGOVs3KQwf
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Apr 18, 2004 at 08:55:41PM +0200, Laszlo 'GCS' Boszormenyi wrote:
> On Sun, Apr 18, 2004 at 11:10:53AM -0600, Bernd S. Brentrup <bsb@haydn.de=
bian.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.

Argl, these purists! As it stands, there will be just one plain file in
/etc/mailman, so this is hardly an overcrowded directory.  But if you
insist ... :-)

> > +- 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?

Defaults are already in Mailman/Defaults.py and Mailman/mm_cfg.py.dist.
I'm still hoping using code along the lines

--- snip---
#! /usr/bin/env python

import sys
sys.path[0] =3D '/var/lib/mailman/Mailman'

def_gbls =3D globals().copy()
usr_mod  =3D {}
usr_def  =3D {}
execfile('/var/lib/mailman/Mailman/Defaults.py', def_gbls)
usr_gbls =3D def_gbls.copy()
execfile('/etc/mailman/mm_cfg.py', usr_gbls)


def same_func(f, g):
    f_code, g_code =3D f.func_code, g.func_code
    return (f_code.co_filename =3D=3D g_code.co_filename
            and
            g_code.co_firstlineno =3D=3D g_code.co_firstlineno)


for var, usr_value in usr_gbls.items():
    try:
        def_value =3D def_gbls[var]
        if usr_value !=3D def_value:
            usr_mod[var] =3D 1
    except KeyError:
        # Handle user defined variable here
        usr_def[var] =3D 1
# Generate commented /etc/mailman/mm_cfg.py.dpkg-dist

for var in usr_mod.keys():
    val =3D usr_gbls[var]
    if var.startswith('__') or callable(val) and same_func(val, def_gbls[va=
r]):
        del usr_mod[var]

print "User modified variables:"
for var in usr_mod.keys():
    print '  %s:\t%r was %r' % (var, usr_gbls[var], def_gbls[var])

print "User defined variables:"
for var in usr_def.keys():
    print '  %s: \t%r' % (var, usr_gbls[var])
--- snip ---

yielding on xlab.net e.g.:

--- snip ---
User modified variables:
  DEFAULT_URL:	'http://lists.xlab.net/cgi-bin/mailman/' was None
  DEFAULT_EMAIL_HOST:	'lists.xlab.net' was 'localhost'
  DEFAULT_URL_HOST:	'lists.xlab.net' was 'localhost'
  IMAGE_LOGOS:	'/images/mailman/' was '/doc/mailman/images/'
  MTA:	None was 'Manual'
  DEFAULT_SEND_REMINDERS:	0 was True
User defined variables:
  DEB_LISTMASTER: 	'postmaster@xlab.net'
  PRIVATE_ARCHIVE_URL: 	'/mailman/private'
--- snip ---

will suffice, but if this doesn't work out, there are still Python's
code inspection modules.

> > +- 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.
>=20
> > 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.

Fine, this will require a different repository layout like this:

pkg-split
  core         generate mailman, mailman-{common,doc,i18n}
  spamassasin  generate mailman-spamassassin
  spamprobe    generate mailman-spamprobe (native debian)
  savannah     generate mailman-savannah
  clamav       generate mailman-clamav

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

Most probably you're correct, as for lintian cleaness I mostly use
an interactive step by step approach :)

> Just a question: is there any reason why python2.2-korean-codecs
> suggested over the 2.3 version?

Dunno, never used these. With 2.3 being the default Python, I tend to drop
2.2 support completely.

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

Sorry to hear that, especially with only 2 out of 5 really contributing.

My best wishes
 . Siggy

--VMt1DrMGOVs3KQwf
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAg96m94B/SGO8KQcRAsexAJ487ho6savOlyKCaUfomgx1MT6E4ACgtF4U
Sx6KXh/rpp1ZVXn+lxWv9Pw=
=+HEQ
-----END PGP SIGNATURE-----

--VMt1DrMGOVs3KQwf--