[Mailman-Developers] FHS installation changes

[John Dennis]

On Tue, 2004-10-19 at 01:36, Dale Newfield wrote:
> On Tue, 19 Oct 2004, Bob Puff at NLE wrote:
> > John makes some really valid points here.  While it is a bit more of a
> > change, FHS compatibility does make sense.  Is this something that we
> > can consider for future 2.1.x releases?
> 
> Upgradability without problems is very important for patch-level releases.
> I like the ability to specify more "put this there" detail in the
> configuration options, but I'd be leery of doing this upgrade in 2.1
> without very careful documentation of ALL the suggested changes (forwards
> and backwards), and enough testing to confidently be able to say that an
> admin that *doesn't* want to change the location of anything can just run
> "mailmanctl stop;config.status;make install;mailmanctl start" and still
> have everything work.

In theory if the patch is applied to 2.1.5 nothing should change, it
should produce the exact same installation as previously.

O.K. thats theory, and then there is actual practice :-) Which is why
I'm 100% in Dale's camp of wanting testing. One of my concerns is being
blinded by my own computing environment or my own assumptions.

One potential for problems is that packaging introduces an entire extra
set of operations beyond mailman's "make install" step. Things which
occur during package creation and package installation augment what
occurs in "make install" and as consequence may mask problems or
introduce problems, none of which would exist when building from a
vanilla tarball. This is a significant consideration.

We've also made some enhancements to mailmanctl to better integrate with
init.d scripts and system service control. It's not clear to me if this
is generally applicable but I'm more than happy to share. One
enhancement I think is general case is the ability to invoke mailmanctl
and have it return process status (e.g. is the master qrunner running,
if so what is its pid, the pid file is not sufficient to answer this
question and there were permission issues to overcome), this allows a
non-root, non-mailman user to do "/sbin/service mailman status"
-- 
John Dennis <jdennis at redhat.com>