Bugzilla Bug 21037

I strongly disagree with the move of mailman from /var/mailman to
/home/mailman.
(bug 14974)

The move of mailman to /home is in violation of the Filesystem Hierarchy
Standard, and clutters up my /home structure.  The FHS specifically states that
/home is for user home directories, and while 'mailman' is technically a
'user',
there is no individual associated with that account.  I generally assume that
/home is a "users-only" place...I don't like to see system/application files
cluttering it up.

A better place to put it would be under either /usr, or /opt (for optional
3rd-party packages).  /opt is preferable, because the FHS stipulates that
systems be able to mount /usr read-only.

A better idea still would be to split up the data and code parts of the
program,
so archives and associated list data get stored in /var, while everything else
resides in /usr (or /opt).  I don't know how difficult this would be to
do...the
last time I installed mailman, it was rather difficult, if not impossible.  But
that might have changed, as it's been a while since I installed it by hand.

FHS issues notwithstanding, it also breaks the package for those of us who had
it working happily in /var.  I had to move Mailman back to its original
location, and symlink /home/mailman.

I think that a little bash to check to see if it's already installed to /var
and tweak the configuration/installation accordingly would be the best approach
to avoid breaking existing installs.

Theoretically, /opt and /usr should both be mountable read-only. That leaves us
with /home and /var. Most people I've talked to think that /var is too
confusing for most packages.

If this was tweakable in the ebuild via an environment variable, would you be
okay with that solution (when combined with a fix to keep it from breaking
existing installs)?

Hmmm.  You have a good point about /opt needing to be able to be mounted
read-only.  I can also understand why /var is too confusing for many people.

Perhaps something like /var/opt or /var/local?  Although I suppose that has the
potential to be even more confusing... If only Mailman actually followed the
standard. :)

The environment variable would be fine with me, assuming we can't come up with
a better place to put it on our own.  Thanks!

I have commited 2.1.2 moving Mailman to /usr/local/mailman as the default
install of mailman would do.

And here I come.  
 
<rant mode on> 
I dislike both /home and /usr/local. 
 
I've run mailman for long time (compiled from source when I was a deadrat user :-/) and I've 
always installed it in /var/mailman.  
 
If we will go switching every package's information repository, then, we have cyrus-imap 
which stores e-mails under /var/spool/imap/user/, bind: /var/bind/ and apache 
/home/httpd, just to name the ones I use. 
 
I really don't want to move my data from here to there, so please, say where we will store 
information, and stick to it. 
<rant mode off> 
 
Of course, the real fix would be to store binaries in /usr, and data in /var, as someone else 
told before. But I don't know how hard could be: I'll take a look tomorrow. 
 
BTW, please, excuse my English. It's late, and I speak spanish. 
 
 
Best regards, 
Norberto 
 

As far as I am concerned the 'real' fix is to follow what mailman (An official
GNU application) does. Mailman 2.1.2 installs itself into /usr/local/mailman by
default. To me, if the people creating the package put it in /usr/local/ it
doesnt  seem like it violates FHS, or anything else, because as far as I can
remember GNU is pretty picky about that sort of thing.

Now, here is MY issue: One person doesnt want it in /var/ and says the mailman
default is /home. Another person says /home is a violation of FHS and wants it
back in /var or anywhere else. I take my time to find out where mailman
installs itself by default, discover it is /usr/local/ and change it
accordingly. Now you want it back in /var, or split /usr and /var.

I cant speak for your other package's, but this one is stored in the default
location for this package, so we didnt 'change' anything. In fact, up until a
recent version, mailman was supposed to go in /home/mailman and we were
changing it to use /var/mailman. (Which you seem fine with)

Unless you can give me very good reason, mailman is going to stay where the
creators of the application have it located, /usr/local.

I understand your issues, and BTW, looking at the ebuild, I see:  
INSTALLDIR="/usr/local/mailman" so I guess I can customize it to suit my needs. 
 
Regards, 
Norberto 
 

I hate to have to disagree with you Todd, but I think you are a little confused
about this issue:

Nearly all "official GNU applications" default to being installed under
"/usr/local", because the FHS says they should. The FHS also says that all
files under /usr/local must be safe from being overwritten when the system is
upgraded, http://www.pathname.com/fhs/2.2/fhs-4.9.html

What this means is that any tarball you download should default to installing
into "/usr/local" because it assumes it is being installed "by hand" more or
less. Any time that same package is installed by a distribution's package
manager (portage in our case) it should not be installed in /usr/local

A similar issue was discussed on gentoo-dev last year, and /var was chosen as
the location to install packages of this nature so that /home could be reserved
for real users, and /usr could be mounted read-only. There are links to some of
those discussions at the bottom of Glep #11. I haven't been keeping up on this
stuff, but from Glep #20 it looks as if this might be changing in the future.

In any event, there's a reason that even the ebuild "econf" function does, as a
standard part of it's operation, change an applications default install dir to
/usr instead of /usr/local.

That all being said, the INSTALLDIR variable is not a good solution. To get it
to install where I want it, I have to edit an ebuild and rebuild its digest,
and I'll have to remove mailman from my world definitions to prevent the next
version from making a new copy in /usr/local, which means I'll have to repeat
these steps next time I upgrade.

Thanks for your help on this.

Wow. I can't believe this is not fixed 1 year later. The last comment is
correct: package management systems should not touch /usr/local. This is
reserved for _hand_ installations not involving package management software.
The GNU standard covers _hand_ installations, not distro packaged software.

So if /opt and /usr can be mounted read-only, how do they ever get software
installed in them? Obviously, if you think for a minute, /usr and /opt need not
_always_ be mounted read only. Admins _can_ make them writable for the purpose
of installing software. And read-only /opt and /usr is really for passive
clients, not servers where mailman would be installed.

Please do the sensible thing and put this back in /var or /opt or any
reasonable place other than /usr/local or /home.