Subject: fhs

From: [email-masked]
Date: 15 Aug 1996 00:04:01 -0000

I don't understand why, for example, /var/spool/mail needs to be
changed to /var/mail -- this seems like a candidate for a symlink.

I'm somewhat ambivalent about /usr/libexec/ -- in general code and
data are interchangable entities.  The issue that typically requires
these be stored in separate locations is architectural incompatabilities.
>From what I've read (which isn't anywhere the near complete story),
libexec isn't slanted towards storing different architectures' binaries
side-by-side...

Here's my question: given that I have not much time to spend on many 
issues, should I even get involved in FHS?  If so, where should I best
spend my time?

-- 
Raul

---

From: Daniel Quinlan <[email-masked]>
Date: Wed, 14 Aug 1996 17:33:05 -0700

> changed to /var/mail -- this seems like a candidate for a symlink.

This is under discussion right now.  There are several reasons to use
/var/mail and several reasons to stick with /var/spool/mail.

Reasons to do this include:

* SVR4 uses /var/mail
* BSD (Net/2 and later) uses /var/mail
* `mail' doesn't clearly fit the definition of spool data, unless you
  consider users to be a resource.  :-)
* Only other major OS that uses /var/spool/mail is SunOS 4.1.
* `mail' is a shared resource (between applications) and would seem to
  fit better under /var in a similar fashion to /var/lock, /var/log,
  /var/run, and /var/tmp.

Reasons to not change are:

* Transition difficulties.  People disagree about how hard it will be.
* No real functionality gain, haven't had any problems not using
  /var/mail thus far.

There are other reasons, of course, but these are the best IMHO.

And regarding the /var/mail symbolic link, I recently said (taken
slightly out of context):

# If any change means a permanent symbolic link, I have reservations
# about it.  Today, we could drop /usr/lib/sendmail with no problem.
# /etc/rmt is a different problem -- remote programs don't refer to
# /var/spool/mail, they use POP (or NFS if you accept or ignore the
# risks).
#
# In several years, we may be able to drop a /var/spool/mail ->
# /var/mail symbolic link, but if we really think we need a /var/mail
# symbolic link, common sense would tell us that it is better to move
# the directory now.
#
# All that being said, I *don't* think we need a /var/mail symbolic link
# and I am very doubtful that we will ever have a problem because of
# using /var/spool/mail.  I'm content to stick with /var/spool/mail, but
# I'm also happy to move to /var/mail if Linux distribution-makers think
# it's a better long-term move.

> [...]

If you are interested, I would suggest you read the current FHS draft to
know where we are.  Sit and watch the mailing list until you're
comfortable with the discussion and jump in when you have something to
add to the discussion.  A lot of people lurk and only say something when
they get worried about the direction of the discussion.

Dan