Subject: Re: please review mailman package
To: Frederick Bruckman <>
From: Manuel Bouyer <>
List: tech-pkg
Date: 07/26/2002 20:17:17
On Thu, Jul 25, 2002 at 07:36:22PM -0500, Frederick Bruckman wrote:
> On Thu, 25 Jul 2002, Manuel Bouyer wrote:
> > I created a package for mailman, the GNU list manager. However, as it's
> > a somewhat complex package, I'd like to have someone review it before it
> > gets commited.
> >
> > Most of the package (exept doc and apache fragment config which goes in the
> > standart place) installs under $PREFIX/mailman. There's not easy way to
> > install it in the standart distribution. Especially there's no infrastructure
> > in the sources to separate executables (binaries or scripts) from
> > config file or data files.
> You could install it under "${PREFIX}/lib/mailman", then make links
> under ${PREFIX}/bin for the executables the user is likely to invoke
> (with unique names, perhaps starting with "mailman-"). Just a thought.
> At least that avoids polluting the top level.

Adding these links to ${PREFIX}/bin may not be a good idea: these programs
should only be run by the mailman user, and nobody else. So it's better
to add it to mailman's path, if the user is too lazy to tyoe the whole
path (but these commands are not used often in regular operation anyway :)

> > There are one issues left:
> > the software is written in python. I don't know python, but it seems that
> > when a file is used python will dump the bytecode for this file to disk:
> > is is used, a myfile.pyc will appear. This pollutes the
> > $PREFIX/mailman hierarchy, and the package won't deinstall cleanly.
> > Is there a way to deal with this in pkgsrc ?
> I don't know python either, but I didn't have that problem after
> installing your package and running "$PREFIX/mailbin/bin/version",
> also ".../arch" and ".../check_perms", before deinstalling. If there

It seems to appear when the cron entries are run, or the cgi-bin from
the www interface. But I didn't investigate yet.

> is something else that creates such files the first time it's
> installed, why not run that once in a "post-install" target so that it
> can be added to the PLIST?

This may be hard, as some files may only be included by other under some
conditions (e.g. pending subscribtion). If there is a flag to python to 
precompile a file without executing it it may be easier.

> Alternatively, if there are directories in $PREFIX which accumulate
> easily reproducible crud (not user maintained files), you could remove
> them with "@unexec rm -r %D/path", rather than "@dirrm path",
> notwithstanding complaints by pkglint.

Yes, it's a solution but I don't like it very much :)

> > The package is available here:
> >
> One other thing: "/usr/pkg/mailman/bin/check_perms" complains a lot,
> and suggests that it be re-run with "-f". Perhaps that should be done
> in your install script?

No, bad idea. The package is really linux-centric, and is not aware that
some systems don't require the directories to be sgid. The best would be
to fix check_perms, but not knowing python I'd prefer to not have to look
at it myself :)

Manuel Bouyer <>