Standards and /var/mail vs /var/spool/mail
I have been listening to this "discussion" with very mixed feelings. The
main problem I have with the conversation is that it is so long winded and
complex for something that is, in fact, a minor nit on the road to an LSB
standard. If we continue to focus for long periods of time on such minor
issues as these, we will never get to the end of this task.
So, let me see if I can put this into some perspective.
First, several people have asked: "Why are we trying to standardize such
things as the mail spool anyway?"
Well, if it is important to inter-operability, it is our self assigned
task to determine the particulars of what is needed. In particular, the
"standard" location of all such objects as mail spools comes under this
heading.
Second: Some folks have argued that FHS is a "future" standard, while
others have argued that it doesn't have a clue about the true future of
Linux.
While none of the Linux distributions are currently implimenting FHS, and
many people complain about one aspect or another of this standard, it is
my understanding that Debian intends to move toward FHS in the near
future. Dispite the fact that qmail and others have "non-standard" ideas
about the location of these objects, they are not "driving forces" in the
Linux community, and should not be. Such standards decissions should not
be made based on one piece of software or another, but on what the whole
system can manage most effectivly.
Third: Much technical argument has been made about the various methods of
managing file system exaustion, and how one or the other path suites this
or that method of disk management.
My take on all of those arguents is "Hogwash!". Whether /var/mail is used,
or /var/spool/mail is used instead, what physical device hangs on that
node is entirely up to the sysadmin/distribution.
I can see conceptual arguments that /var/mail is easier to manage in this
reguard, but I see no technical impediment to /var/spool/mail being
managed in the same way (even if /var/spool is a different device from
/var, there is no reason that /var/spool/mail can not be another device as
well)
This whole argument boils down to "what's in a name?". The task is to come
up with a "standard" name for this object, and I don't see any major
impacts which ever one we choose.
One of the "facts" about any LSB standard is that it is going to cause
everyone to make adjustments. If this were not the case, then there would
be no need for us to do the job we have undertaken. We can not base
inclusion of one or another feature into the standard on how much pain it
is likely to cause for the current distributions, as almost any
standardization will impact one distro or another. /var/mail seems to
impact every distro. So what!?
What we need to decide is not whether /var/mail or /var/spool/mail is the
right choice, but whether or not we wish to include FHS in the LSB
standard. I understand that there is a lot in this standard that many of
the distros object to. This is, in fact, why the announcement of the
LSB_FHS test suite met with such a vocal response.
If we decide to adopt FHS as a part of LSB standards, we are just going to
have to admit that the distros will kick and scream about it, but if we do
our job correctly, they will have no choice but to comply or remain
non-standard. If the standard actually accomplishes its goals, it would be
foolish for any distro to get left behind just because they are too stodgy
to accept the new standard.
I am inclined to accept the FHS with all of its imperfections as a
starting point for the LSB file system standards. We should only modify
the particulars when they get in the way of inter-operability, or cause
other "large" technical problems. Since the solution for systems that wish
to continue to support /var/spool/mail is a simple one of creating the
appropriate symlink, I see no large problems with this item.
Require that /var/mail exist on a "standard" system, but that it may be a
link to some other part of the file system, such as /var/spool/mail, and
everyone should be happy. Distros that wish to provide packages that
require the presence of /var/spool/mail can do so while meeting the
standards requirement for the existance of /var/mail. It would seem that
eventually all packages will move "toward" the standard and the distro can
remove the /var/spool/mail path whenever that move is complete.
Waiting is,
Dwarf
--
_-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_-
aka Dale Scheetz Phone: 1 (850) 656-9769
Flexible Software 11000 McCrackin Road
e-mail: dwarf@polaris.net Tallahassee, FL 32308
_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-
Reply to: