On Tue, 2004-10-19 at 01:36, Dale Newfield wrote: > On Tue, 19 Oct 2004, Bob [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> _______________________________________________ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
