Re: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0

[Florian La Roche <florian@suse.de>]

On Wed, Jan 20, 1999 at 11:53:32PM -0800, H. Peter Anvin wrote:
> > > Please think about it and stay with /var/spool/mail.
> 
> Right now, /var/mail and /var/spool/mail both suffer the same problem:
> whichever is used, some people need to use the other, hence it is a
> *requirement* that both can be used by programs.

If think that /var/spool should indicate that the data can grow very large.
That is the case for mail and so /var/spool to not too wrong.

It is fact that Linux distributions currently only use /var/spool/mail.

> 
> Given that, it is better to use /var/mail, because the mail inbox
> directory is *not* a spool (a daemon transshipment point -- the mail
> *spool* is /var/spool/mqueue.)  Putting it under /var/spool causes

But the real spool dir shouldn't matter for this standard. The MTA
should be free to use another dir than /var/spool/mqueue/. That's just
what sendmail uses.

> disk space management problems.

It is normal admin work to symlink a dir to another partition if you
have the need for it. Update progs should be smart enough to handel
this.
I fail to see why /var/mail should be superior from a technical standpoint.
Can you explain why /var/spool/mail is worse than /var/mail for any
disk space management problems?

If you'd said that Solaris uses /var/mail and maybe other documents
use this as the standard mail spool, then I'd says yes: If we currently
had all distributions use /var/mail, I'd see no reason to move to
/var/spool/mail.
I can also see some points why /var/mail would be a better standard point
if we would make a "new" decision about this. But Linux has a large user
base now and after the move from /var/spool/mail to /var/mail, we would
not have gained a lot. So why do it?

There are reasons why all distributions stayed with /var/spool/mail.
Even Debian who also thinks a lot about making things sane/clean has
stayed with /var/spool/mail.

This standardization project should be documenting the current state
and the current movement. This will bring the Linux distributions
together and manifest the (global) movement to a standard Linux system.
I don't see any reason this project should dictate completely new
things to the different Linux distributions. They already do their best
to improve it.

Florian La Roche