Subject: issue with linux Filesystem Hierarchy Standard

From: Mike Kaufman <[email-masked]>
Date: Tue, 12 Feb 2002 22:17:38 -0600

hi-

the FHS standard at http://www.pathname.com/fhs/
decrees that if the mail system is installed, user mailboxes should be
located in /var/mail.

so I'm using imap-2001a

compiling with "make slx" puts the SPOOLDIR at "/var/spool" instead of
"/var", so I got to go check out:

"Help! My INBOX is empty! What happened to my messages?" in the FAQ and
of course it was no help whatsoever.

I see that Redhat puts a symlimk to /var/spool/mail, It appears Mandrake
does the same thing. I don't know about other distros.

I'm sure this has been fixed for ages in the dev versions, and/or
discussed endlessly in the archives, but I didn't make it there before I
implemented my novel solution :)

still, there should probably be an alternative explanation in the FAQ anyway.  

-mike

PS: the issue of having to subscribe just to send this informational message
 is a load of crap. I know it stops spam, but I wonder how many questions, etc
 you miss from lack of effort to sub.
-- 
------------------------------------------------------------------
 For information about this mailing list, and its archives, see: 
 http://www.washington.edu/imap/c-client-list.html
------------------------------------------------------------------

---

From: Mark Crispin <[email-masked]>
Date: Tue, 12 Feb 2002 20:47:42 -0800 (PST)

> decrees that if the mail system is installed, user mailboxes should be

Who delegated the authority to decress this to them?

> "/var"

Well, golly gee, on the Linux systems that I use, the spool directory is on
/var/spool/mail.  Some but not all of them have symlinks from /var/mail to
/var/spool/mail.

So some propellerhead has decided to further exacerbate confusion by setting a
"standard" that is incompatible with existing Linux systems.  And it's my
fault that I support what's compatible with existing Linux systems?

> does the same thing. I don't know about other distros.

On the Redhat systems I use, it's on /var/spool/mail and there's no link from
/var/mail.

> implemented my novel solution :)

If by "fix" you mean "change from /var/spool/mail to /var/mail", it hasn't
been since that would break the Linux systems it works on now.

>  is a load of crap. I know it stops spam, but I wonder how many questions,
> etc  you miss from lack of effort to sub.

Probably much fewer than the number of offers for get-rich-quick schemes,
quack medicines, worthless stocks, pornography, etc.  If the c-client list
didn't limit posting to list members, I wouldn't see any of the messages
anyway, because I would unsubscribe from it.

---

From: Mark Crispin <[email-masked]>
Date: Tue, 12 Feb 2002 21:23:39 -0800 (Pacific Standard Time)

> On the Redhat systems I use, it's on /var/spool/mail and there's no link from

I just checked my Mandrake 8.1 system.  The mail spool is on
/var/spool/mail, but there is a /var/mail symlink.

So far, of all the Linux systems I've tried:
 . all had the mail spool on /var/spool/mail
 . none had the mail spool on /var/mail
 . one had a symlink from /var/mail to /var/spool/mail

It sure sounds like /var/spool/mail is the correct setting for Linux.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.

---

From: Mike Kaufman <[email-masked]>
Date: Tue, 12 Feb 2002 23:43:12 -0600

> fault that I support what's compatible with existing Linux systems?

uh, from their document:

BEGIN RATIONALE
The logical location for this directory was changed from /var/spool/mail
in order to bring FHS in-line
with nearly every UNIX implementation. This change is important for
inter-operability since a single
/var/mail is often shared between multiple hosts and multiple UNIX
implementations (despite NFS locking issues).
It is important to note that there is no requirement to physically move
the mail spool to this location.
However, programs and header files must be changed to use /var/mail.
END RATIONALE

I think it's fairly rational.

Please note however, that I don't necessarily think that somebody should
"mandate" something like this, so don't get pissy with me for bringing
the issue to your attention. I thought maybe you guys would like to know
that for the people (like me) who like to roll their own distributions 
(and follow some semi-conherent directory structure), when these people
compile your program, it breaks.

and about this "it's my fault?" comment. I didn't think when I
originally wrote this that I was laying blame on anybody. I did think
when I wrote this, that maybe somebody else would benefit from the extra
15 minutes it took me to get this program working. I guess I see what my
attempted altruism gets me... 

> been since that would break the Linux systems it works on now.

No. _my_ "fix" is what works for me. I personally don't really give a shit 
how you intend to fix it (my suggestion would be at minimum include this 
issue in the relevant FAQ question).

[snip]

Oh and another thing, on "Where can I go to ask questions?" in the FAQ,
it says:

ons about this software, you can send me email directly or use the
[email-masked] mailing list

however, who "me" is and what me's email address is is mentioned nowhere 
in the document (at least on the webpage).

-mike

---

From: Mike Trank <[email-masked]>
Date: Tue, 12 Feb 2002 23:52:32 -0600 (CST)

> implementations (despite NFS locking issues).

Hoooo baby! Now your really in trouble!

---

From: Jeff Breitner <[email-masked]>
Date: Wed, 13 Feb 2002 10:03:12 -0500

> However, programs and header files must be changed to use /var/mail.

Considering that RedHat, SuSE and Slackware all seem to continue to use 
/var/spool/mail, I'd say that acceptance of the standard/recommendation is a 
bit down the road.

> However, programs and header files must be changed to use /var/mail.

Or, you need to create a directory in /var, with some creative symlinking.

> I think it's fairly rational.

It's rational, but I don't know how well it'll be received since Linux has a 
well established history of /var/spool/mail.  Package maintainers may simply 
decide that if you're crafty enough to be using NFS to hold your mailspool, 
those doing so should also have mastered the use of "ln" and "mkdir".

Then there are people like myself, who let their Unix systems put mail in 
/var only long enough to modify procmail or Exim to put it elsewhere (like 
the user's home directories).  You'll notice an absense of that situation in 
"make" for c-client, gnu-mailutils and other packages.  You will however, 
find ample instructions for dealing with that in the doc directory.

> compile your program, it breaks.

With all due respect Mike, you know you roll your own distro and you know 
that what you're doing is outside the "norm", so why should the failure of 
seemingly common applications surprise you?  It shouldn't, and you should be 
prepared to deal with it appropriately.  By the same token however, you 
shouldn't expect everyone who develops software to have to accomodate you.  
Considering the sometimes strange nature of those kernel and distro hacks, 
spending time to accomodate every little nuance of a distro is an exercise in 
futility.  Especially since things can change over the course of lunch.

Your options are:

1.  Dig open the source and create the patches and make them available.  Copy 
Crispin and maybe he'll include it in imap-2002-blah-blah.  Maybe not.

2.  Hack around it some other way.

>
> > > I see that Redhat puts a symlimk to /var/spool/mail, It appears
> > > Mandrake does the same thing. I don't know about other distros.

They apparently have opted for #2.

> in the document (at least on the webpage).

Try cracking open the source code.  Crispin's email address is in there more 
times than Coca-Cola's logo is associated with the Olympics.  You'll also 
find references to his dog (I'm not kidding).

-- 

Jeff Breitner
Lead System Administrator
(come to think of it, I'm the only system administrator)

---

From: Mark Crispin <[email-masked]>
Date: Wed, 13 Feb 2002 08:20:41 -0800 (PST)

On Tue, 12 Feb 2002 23:43:12 -0600, Mike Kaufman wrote:
> in order to bring FHS in-line with nearly every UNIX implementation. This
> change is important for inter-operability since a single /var/mail is often
> shared between multiple hosts and multiple UNIX implementations (despite NFS
> locking issues).   It is important to note that there is no requirement to
> physically move the mail spool to this location.

That rationale is nonsense.

/var/mail is what System V uses, but System V is hardly "nearly every UNIX
implementation" even though Bell Labs said you should "consider it standard"
in the 1980s.

Sharing the mail spool via NFS is also not a good idea.  This was understood
17 years ago, and is the reason why we have IMAP today.

I had never heard of FHS until your message, but statements such as the
"rationale" above don't give it much credibility.

If you choose to make a non-standard version of Linux -- and "standard" on
Linux is defined by the authors of Linux -- then you should expect that you
will have compatibility problems and little sympathy from software developers.
You are, in effect, making an incompatible operating system; and as such, you
can not expect a port for another operating system to work well on your
incompatible operating system.  You have to build a port for your operating
system.

---

From: Raul Dias <[email-masked]>
Date: Wed, 13 Feb 2002 15:11:49 -0200

> . one had a symlink from /var/mail to /var/spool/mail

Conectiva Linux 6, 7 and 8 have symlinks from /var/mail to /var/spool/mail.
I think all others version had too, but I don't have it anymore.

>It sure sounds like /var/spool/mail is the correct setting for Linux.

I agree, and it makes more sense too.
I always thought that /var/mail link was there for some kind of old compatibility
issue.

Raul Dias

---

From: Mike Kaufman <[email-masked]>
Date: Wed, 13 Feb 2002 11:14:36 -0600

[snip]
> 2.  Hack around it some other way.

You both are entirely missing my point. I'm not interested in debating the
merits or lack thereof of this so-called standard. I've wasted far too much
time on this anyway. What I was interested in was the FAQ -- you know that
place where people who are having trouble with your software ought to go
first?

Your answer to "My inbox is empty!" has an incomplete answer. There is
_another_ answer to this and that is that imap might be looking in the
wrong place for my mailboxes. Check the Makefile to see if SPOOLDIR is
the correct location.

I've already chosen my option. Again, I don't care at all if you change 
the src to address this issue. Apparently you won't. whatever.

> find references to his dog (I'm not kidding).

yeah, ok. I see now how you guys expect a FAQ to work. Make all sorts of
obscure references that can only be found by digging through the source
code. Even for something as simple as contact information... I mean, why do
guys have a FAQ anyway? It can all be found in the source code, right?

-mike

---

From: Mark Crispin <[email-masked]>
Date: Wed, 13 Feb 2002 09:15:41 -0800 (PST)

> I think all others version had too, but I don't have it anymore.

Well, I looked on a Cobalt Linux system, a few Redhat systems, and a Debian
system, and none of them had /var/mail in any form

> I agree, and it makes more sense too.

I agree that /var/spool/mail makes more sense.  I don't think that there is a
snowball's chance in hell of "standardizing" upon /var/mail, at least not
without a lot more community input.  You can't just put up a web page and
claim to be a new standard.

---

From: chris drumgoole <[email-masked]>
Date: Wed, 13 Feb 2002 12:27:58 -0500 (EST)

I think that a resourceful person who has the knowledge to roll their own
distro would also check the CONFIG file, in the docs dir.  It has
information on how to do this.

The FAQ refers to this file several times.

While it doesn't specifically say "check CONFIG if your mailbox is in a
non-standard location", I don't see the point of adding this information
in the FAQ question you specified.

It should be known to check all the files in doc/ before asking questions
on this list.

 --
chris drumgoole
university of michigan
college of engineering

On Wed, 13 Feb 2002, Mike Kaufman wrote:

+Date: Wed, 13 Feb 2002 11:14:36 -0600
+From: Mike Kaufman <[email-masked]>
+To: [email-masked]
+Cc: [email-masked]
+Message-ID: <[email-masked]>
+Subject: Re: issue with linux Filesystem Hierarchy Standard
+
+On Wed, Feb 13, 2002 at 10:03:12AM -0500, Jeff Breitner wrote:
+> On Wednesday 13 February 2002 12:43 am, Mike Kaufman wrote:
+>
+
+[snip]
+>
+> > Please note however, that I don't necessarily think that somebody should
+> > "mandate" something like this, so don't get pissy with me for bringing
+> > the issue to your attention. I thought maybe you guys would like to know
+> > that for the people (like me) who like to roll their own distributions
+> > (and follow some semi-conherent directory structure), when these people
+> > compile your program, it breaks.
+> >
+>
+> With all due respect Mike, you know you roll your own distro and you know
+> that what you're doing is outside the "norm", so why should the failure of
+> seemingly common applications surprise you?  It shouldn't, and you should be
+> prepared to deal with it appropriately.  By the same token however, you
+> shouldn't expect everyone who develops software to have to accomodate you.
+> Considering the sometimes strange nature of those kernel and distro hacks,
+> spending time to accomodate every little nuance of a distro is an exercise in
+> futility.  Especially since things can change over the course of lunch.
+>
+> Your options are:
+>
+> 1.  Dig open the source and create the patches and make them available.  Copy
+> Crispin and maybe he'll include it in imap-2002-blah-blah.  Maybe not.
+>
+> 2.  Hack around it some other way.
+>
+
+You both are entirely missing my point. I'm not interested in debating the
+merits or lack thereof of this so-called standard. I've wasted far too much
+time on this anyway. What I was interested in was the FAQ -- you know that
+place where people who are having trouble with your software ought to go
+first?
+
+Your answer to "My inbox is empty!" has an incomplete answer. There is
+_another_ answer to this and that is that imap might be looking in the
+wrong place for my mailboxes. Check the Makefile to see if SPOOLDIR is
+the correct location.
+
+I've already chosen my option. Again, I don't care at all if you change
+the src to address this issue. Apparently you won't. whatever.
+
+>
+>
+> >
+> > > > I see that Redhat puts a symlimk to /var/spool/mail, It appears
+> > > > Mandrake does the same thing. I don't know about other distros.
+>
+>
+> They apparently have opted for #2.
+>
+>
+> > ons about this software, you can send me email directly or use the
+> > [email-masked] mailing list
+> >
+> > however, who "me" is and what me's email address is is mentioned nowhere
+> > in the document (at least on the webpage).
+> >
+> > -mike
+>
+>
+> Try cracking open the source code.  Crispin's email address is in there more
+> times than Coca-Cola's logo is associated with the Olympics.  You'll also
+> find references to his dog (I'm not kidding).
+
+yeah, ok. I see now how you guys expect a FAQ to work. Make all sorts of
+obscure references that can only be found by digging through the source
+code. Even for something as simple as contact information... I mean, why do
+guys have a FAQ anyway? It can all be found in the source code, right?
+
+-mike
+>
+> --
+>
+>
+> Jeff Breitner
+> Lead System Administrator
+> (come to think of it, I'm the only system administrator)
+

---

From: Mark Crispin <[email-masked]>
Date: Wed, 13 Feb 2002 09:19:55 -0800 (PST)

> place where people who are having trouble with your software ought to go

The FAQ in the IMAP toolkit, like the FAQ for just about any other software,
is aimed at end users and not at the vendors of incompatible operating system
variants.

You want an FAQ for you?  OK, here is.  It applies to all questions on all
software packages!

Q: I made a set of incompatible changes to my operating system and a program
    isn't working.  What do I do?
A: Review all your incompatible changes, and see which ones may have broken
    something that the program depended upon.  For each such change, either
    provide a compatibility measure so that the program is no longer broken,
    or edit that program so it knows about your change.

This FAQ is only 6 lines long, and covers all situation which you as the
vendor of an incompatible operating system will encounter.

Most people assume that the answer to this question is obvious and doesn't
need to be stated.

> wrong place for my mailboxes. Check the Makefile to see if SPOOLDIR is

That is irrelevant.  When you make incompatible changes to the operating
system, then the potential set of causes of a problem is infinite.  It is
absolutely impossible for me or any other human being to anticipate all the
ways in which an incompatible operating system change can cause a particular
symptom.

> guys have a FAQ anyway? It can all be found in the source code, right?

You are a vendor of an incompatible operating system, and you apparently wish
to bundle third-party software with your incompatible operating system.

As such, it is your responsibility to dig into the source code of all third
party software to make it run on your incompatible operating system.  It is
not the responsibility of the vendors of third party software to accomodate
you.

If you do not like it, then I respectfully suggest that you get out of the
business of incompatible operating systems.  Not many people want to get into
that business; of those who have, many have left.  You now know one of the
reasons why.

FAQs deal with user problems, not with the foibles of the vendors of
incompatible operating systems.  It is impossible for any FAQ to accomodate
the latter.

---

From: Raul Dias <[email-masked]>
Date: Wed, 13 Feb 2002 15:51:03 -0200

>claim to be a new standard.

The FHS is the "sub-division" of LSB to stadartize the filesystem in a
Linux OS.

It is sponsored by many linux distributions and related organizations and
its members are (or should be at least) Linux kernel hackers, developers
and packagers from the OS community and the distributions.  It is open
to anyone willing to contribute.

That said, it is too strange for me a change to something that no one uses.

Raul Dias

---

From: Anthony Guarnieri <[email-masked]>
Date: Wed, 13 Feb 2002 12:58:07 -0500 (EST)

I think we've hit the 'beating a dead horse' stage on both sides...

---

From: "Jaldhar H. Vyas" <[email-masked]>
Date: Fri, 15 Feb 2002 23:46:18 -0500 (EST)

> Who delegated the authority to decress this to them?

A commitment to follow FHS has been part of Debian policy for a long time
now and followed to a lesser or greater degree by the others.  The FHS is
part of the Linux Standard Base (http://www.freestandards.org/) effort
which all the major Linux distributions have agreed to.

> /var/spool/mail.  Some but not all of them have symlinks from /var/mail to

Most vendors are going with the symlink precisely to deal with legacy
situations but /var/mail is indeed correct.  I patched uw-imap in my
binary packages to use /var/mail as the mail spool about six months ago I
think.

> So some propellerhead has decided to further exacerbate confusion by
> setting a "standard" that is incompatible with existing Linux systems.
> And it's my fault that I support what's compatible with existing Linux
> systems?

The nice thing about standards as they say is that there are so many to
choose from. :)  This one looks like it might stick however.

> On the Redhat systems I use, it's on /var/spool/mail and there's no link from

How old is it?  Red Hat 7.2 has the symlink.  Debian hasn't released an
official stable distribution for a long time (don't get me started on
that!) so many Debian systems may not have it but newer ones do.

So bottom line is for Linux you ought to set the mail spool dir to
/var/mail by default and let people who want something else change it.

-- 
Jaldhar H. Vyas <[email-masked]>
It's a girl! See the pictures - http://www.braincells.com/shailaja/