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

[Daniel Quinlan <quinlan@transmeta.com>]

Alan Cox <alan@cymru.net> writes:

> If all the vendors think /var/mail is stupid then its perhaps time
> for the FHS to ask "ok why.. is there a problem, did we make a bad
> choice, or did we simply fail to explain the reasons /var/mail is
> good"

Well, I've been told that Debian, Red Hat, SuSE, PHT, and Caldera are
all still using /var/spool/mail.  This may be because most
distributions haven't completely updated for FHS 2.0.  Of course, that
might be due to the /var/spool/mail change.

The only software (that I know of) that has switched over to /var/mail
is glibc.

I am leaning towards backing out the change in FHS 2.1.  I think it's
a small long-term loss, and definitely a cop-out, but my hope is that
now there will be a more serious review of FHS 2.1 by distributions
before it is released.

The one thing I think people have forgotten is that FHS is not just
trying to codify current practice.  If that was the case, we'd all
still be using /etc for system binaries, there wouldn't be a standard
directory for many things (like log files and documentation), we'd
still use /usr/man/cat? for performatted manual pages, etc.

Before reverting to /var/spool/mail, the practical question to ask
distributions is:

  If we explicitly allow /var/mail to be a symbolic link to
  /var/spool/mail (or whereever), will you *consider* changing
  programs to reference /var/mail instead of /var/spool/mail?
  Upgraded systems would not need to have their mount point changed,
  and old programs that reference /var/spool/mail would be okay for
  one year.

New systems would need to have a /var/spool/mail -> /var/mail symbolic
link for about two years.

- Dan