Re: [Mailman-Developers] Mailman 3 production setup testbed

On 2015-11-24 7:32 AM, Andrew Hodgson wrote:
I hit this same issue, as it were. In my case, I knew exactly what was going on and why but, the problem arose when I needed other people to be able to do mailman-related stuff on the machine and it feels *really* weird to people to go into my home directory to restart mailman.
I think we should probably update the docs to suggest that you start by making a directory where you'd like mailman installed, rather than the way the guide is currently written where it sometimes surprises people that they have a live mailman install in their home directory (as opposed to the workflow people may be expecting which more like "I get a staged copy of my source in my home directory and then I type make install and it puts the executables and config files in expected places")
What would be a good default directory to have in the docs if I want to update them to suggest you start somewhere other than your home directory?
/opt/mailman
is probably the most appropriate one according to the LSB.
Does anyone want to make another suggestion before I update the docs to suggest that as a logical place to put your mailman stuff? (I'll leave a note saying that if you're just trying stuff out then your home directory is fine, too.)
Terri

Terri Oda writes:
+1 It's the only system hierarchy that the FHS lets us decide on the layout.
To fully conform with the FHS, use /opt/mailman requires us to register "mailman" with LANANA (http://www.lanana.org/). N.B. Neither the FSF nor GNU is currently registered, so no, we don't belong in something like /opt/gnu/mailman. (The rationale for that lack is pretty clear -- RMS would blow a cranial artery at the suggestion that GNU is an optional component of a Linux system. :-)
Personally, I'd like to get out of the main hierarchies; splitting things across /etc, /usr and /var is annoying. So /opt/mailman looks really good to me.
Steve

On Dec 05, 2015, at 11:38 PM, Stephen J. Turnbull wrote:
+1
Distro packagers will probably make different decisions, but that's okay too. If there's anything in our configs that don't allow installation to /opt/mailman and traditional locations, then that's a bug!
Cheers, -Barry

Note: subject adjusted to reality.
Barry Warsaw writes:
Of course! After all we don't have to deal with actually doing it. ;-) (Presented company *not* excepted IIRC? I hope?! Wouldn't want to impose extra work on Our FLUFLous Leader!!!)
If there's anything in our configs that don't allow installation to /opt/mailman and traditional locations, then that's a bug!
Indeed. But surely it's not terribly hard to allow both kinds of installation if we just avoid hard-coded references (including relative references) to config and data files.

On Dec 12, 2015, at 05:13 PM, Stephen J. Turnbull wrote:
I'm certainly hoping other folks will run with the packaging issues, both inside and outside distros. I'm really trying to free some brain cells to dive into mailmania (and yes, we still need a better name for that :).
Right. There should be no hard-coded references; everything should be configurable via the mailman.cfg file.
Cheers, -Barry

On 2015-12-12 3:32 PM, Barry Warsaw wrote:
Right. There should be no hard-coded references; everything should be configurable via the mailman.cfg file.
Yeah, no problems here. In fact, the *production* setup includes things to divide out the directories appropriately, the problem was mostly that our instructions start with "unpack this somewhere" for the test setup, which mostly leaves people with a running mailman install in their home directories, sometimes to their surprise. ;)
Docs have been updated and I tested that it didn't cause weird behaviour to install, and the only problem was when I forgot to give myself write access to /opt/mailman before I began, which I think is more a me problem than a mailman-bundler documentation one.
Terri

Terri Oda writes:
+1 It's the only system hierarchy that the FHS lets us decide on the layout.
To fully conform with the FHS, use /opt/mailman requires us to register "mailman" with LANANA (http://www.lanana.org/). N.B. Neither the FSF nor GNU is currently registered, so no, we don't belong in something like /opt/gnu/mailman. (The rationale for that lack is pretty clear -- RMS would blow a cranial artery at the suggestion that GNU is an optional component of a Linux system. :-)
Personally, I'd like to get out of the main hierarchies; splitting things across /etc, /usr and /var is annoying. So /opt/mailman looks really good to me.
Steve

On Dec 05, 2015, at 11:38 PM, Stephen J. Turnbull wrote:
+1
Distro packagers will probably make different decisions, but that's okay too. If there's anything in our configs that don't allow installation to /opt/mailman and traditional locations, then that's a bug!
Cheers, -Barry

Note: subject adjusted to reality.
Barry Warsaw writes:
Of course! After all we don't have to deal with actually doing it. ;-) (Presented company *not* excepted IIRC? I hope?! Wouldn't want to impose extra work on Our FLUFLous Leader!!!)
If there's anything in our configs that don't allow installation to /opt/mailman and traditional locations, then that's a bug!
Indeed. But surely it's not terribly hard to allow both kinds of installation if we just avoid hard-coded references (including relative references) to config and data files.

On Dec 12, 2015, at 05:13 PM, Stephen J. Turnbull wrote:
I'm certainly hoping other folks will run with the packaging issues, both inside and outside distros. I'm really trying to free some brain cells to dive into mailmania (and yes, we still need a better name for that :).
Right. There should be no hard-coded references; everything should be configurable via the mailman.cfg file.
Cheers, -Barry

On 2015-12-12 3:32 PM, Barry Warsaw wrote:
Right. There should be no hard-coded references; everything should be configurable via the mailman.cfg file.
Yeah, no problems here. In fact, the *production* setup includes things to divide out the directories appropriately, the problem was mostly that our instructions start with "unpack this somewhere" for the test setup, which mostly leaves people with a running mailman install in their home directories, sometimes to their surprise. ;)
Docs have been updated and I tested that it didn't cause weird behaviour to install, and the only problem was when I forgot to give myself write access to /opt/mailman before I began, which I think is more a me problem than a mailman-bundler documentation one.
Terri
participants (3)
-
Barry Warsaw
-
Stephen J. Turnbull
-
Terri Oda