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

[H. Peter Anvin]

> 
> I'd live with that, but I'd prefer just /var/mail be used and if vendors
> want to create a symlink for backward compatibility or even from
> /var/mail to /var/spool for easy upgrades, let them..  (creating a
> symlink from /var/mail to /var/spool/mail if /var/mail does not exist is
> likely how Debian would handle such a change without surprises for the
> user..)
> 

I would prefer it as well, but I agree with Alan Cox that it is
probably not appropriate for standardization.  Make the standard say
/var/mail and /var/spool/mail both have to work.

-hpa

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

[Joseph Carter]

On Sat, Jan 30, 1999 at 07:14:04PM +, Alan Cox wrote:
> I'd like to propose that for now the FHS is changed to read
> 
> "The mail spool area location is undefined. It is guaranteed that both
>  /var/mail and /var/spool/mail point to this mail spool area if the system
>  has a mail spool. The preferred reference name is /var/mail.
> 
>  [Rationale: /var/mail is the only name available on some other modern Unix
>   platforms. /var/spool/mail is the older Linux tradition and needed for
>   compatibility]
> 
>  [Rationale2: The physical location of the mail spool is not relevant to
>   an application and is administrator policy. It is thus left open.]
> 
> 
> Can everyone live with that and bury the thread

I'd live with that, but I'd prefer just /var/mail be used and if vendors
want to create a symlink for backward compatibility or even from
/var/mail to /var/spool for easy upgrades, let them..  (creating a
symlink from /var/mail to /var/spool/mail if /var/mail does not exist is
likely how Debian would handle such a change without surprises for the
user..)

-- 
"I'm working in the dark here."  "Yeah well rumor has it you do your best
work in the dark."
   -- Earth: Final Conflict

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

[Jakob 'sparky' Kaivo]

On Sat, 30 Jan 1999, Alan Cox wrote:

> I'd like to propose that for now the FHS is changed to read
> 
> "The mail spool area location is undefined. It is guaranteed that both
>  /var/mail and /var/spool/mail point to this mail spool area if the system
>  has a mail spool. The preferred reference name is /var/mail.
> 
>  [Rationale: /var/mail is the only name available on some other modern Unix
>   platforms. /var/spool/mail is the older Linux tradition and needed for
>   compatibility]
> 
>  [Rationale2: The physical location of the mail spool is not relevant to
>   an application and is administrator policy. It is thus left open.]

Sounds a lot like what I said last week. :) And HPA before that. ;)

Seriously, I think that this solution is the one that the most people can
agree on, as it seems to make everyone happy (except for maybe the
~/Mailbox people, but they should be drawn and quartered ;). 

+-++
| Jakob 'sparky' Kaivo|  [EMAIL PROTECTED] |
| NoDomainName Networks   |http://www.nodomainname.net |
| AtDot E-mail Services   |   http://www.atdot.org |
+-++

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

[Eric S. Raymond]

Alan Cox <[EMAIL PROTECTED]>:
> I'd like to propose that for now the FHS is changed to read
> 
> "The mail spool area location is undefined. It is guaranteed that both
>  /var/mail and /var/spool/mail point to this mail spool area if the system
>  has a mail spool. The preferred reference name is /var/mail.
> 
>  [Rationale: /var/mail is the only name available on some other modern Unix
>   platforms. /var/spool/mail is the older Linux tradition and needed for
>   compatibility]
> 
>  [Rationale2: The physical location of the mail spool is not relevant to
>   an application and is administrator policy. It is thus left open.]
> 
> 
> Can everyone live with that and bury the thread

Works for me, too.
-- 
http://www.tuxedo.org/~esr";>Eric S. Raymond

If a thousand men were not to pay their tax-bills this year, that would
... [be] the definition of a peaceable revolution, if any such is possible.
-- Henry David Thoreau

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

[Dale Scheetz]

On Sat, 30 Jan 1999, Alan Cox wrote:

> 
> I'd like to propose that for now the FHS is changed to read
> 
> "The mail spool area location is undefined. It is guaranteed that both
>  /var/mail and /var/spool/mail point to this mail spool area if the system
>  has a mail spool. The preferred reference name is /var/mail.
> 
>  [Rationale: /var/mail is the only name available on some other modern Unix
>   platforms. /var/spool/mail is the older Linux tradition and needed for
>   compatibility]
> 
>  [Rationale2: The physical location of the mail spool is not relevant to
>   an application and is administrator policy. It is thus left open.]
> 
> 
> Can everyone live with that and bury the thread

Works for me.

Dwarf
--
_-_-_-_-_-   Author of "The Debian Linux User's Guide"  _-_-_-_-_-_-

aka   Dale Scheetz   Phone:   1 (850) 656-9769
  Flexible Software  11000 McCrackin Road
  e-mail:  [EMAIL PROTECTED] Tallahassee, FL  32308

_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-

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

[Alan Cox]

> Technical reasons for making the change;
> 
> a.  Compatibility with the majority of existing unix systems.

Incompatibility with the majority of Linux systems. Incompatibility
with the majority of Linux packages. 

> b.  See a.  It can not be stressed enough.  If FHS is ever to get OUT
> of the Linux camp it's going to have to cause Linux to look more
> like other unix systems and less like Linux.

Thats an argument for saying "there are these symlinks. We specify no
more". Not for changing

> c.  Removal of the special case for Linux in many public domain/freeware
> software, though this should already be handled via paths.h if the
> application is written with portability considerations.

Those applications are already present

> d.  BSD based systems basically made this same change over 15 years
> ago.  It was no real big deal.  /usr/spool -> /var/spool, then

/var/spool was done by Sun and for very big technical reasons - sharable
/usr


You still don't have a leg to stand on.

---
Now something more productive.

These are the points being recycled

We've proved:

a)  People want to put their mail where they like it.
b)  Where you put mail is application dependant

FHS 2.0 has mandated /var/mail, the entire vendor population regards it
as unacceptable hassle to change, as does the user base in general.

In some environments /var/mail helps compatibility with nonLinux

---

I'd like to propose that for now the FHS is changed to read

"The mail spool area location is undefined. It is guaranteed that both
 /var/mail and /var/spool/mail point to this mail spool area if the system
 has a mail spool. The preferred reference name is /var/mail.

 [Rationale: /var/mail is the only name available on some other modern Unix
  platforms. /var/spool/mail is the older Linux tradition and needed for
  compatibility]

 [Rationale2: The physical location of the mail spool is not relevant to
  an application and is administrator policy. It is thus left open.]


Can everyone live with that and bury the thread

Alan

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

[Rodney W. Grimes]

> > but I haven't heard any technical reasons besides, "Moving spool
> > directories is hard".  When I and others have pointed out that moving
> > the spool directory isn't required; just a symlink, I have heard dead
> > silence.  So the lack of technical discussion, but just a stony-silence
> > "No!" is rather disappointing as far as I'm concerned.
> 
> One simple one - I want my mail on the spool disk. Its in the grows
> randomly, mostly crap, doesnt cause hassle if it fills for a while
> category
> 
> I have no problem with a "both paths must one work one or more may be a
> symlink". At that point however the FHS should mandate one which may be a
> symlink only. Right now everyone uses /var/spool/mail whats the technical
> reason for using /var/mail that is good enough to justify the change ?

Okay... to summary what I have seen (this being the third time that this
list has gone over the /var/mail vs /var/spool/mail issue.)

Technical reasons for making the change;

a.  Compatibility with the majority of existing unix systems.

b.  See a.  It can not be stressed enough.  If FHS is ever to get OUT
of the Linux camp it's going to have to cause Linux to look more
like other unix systems and less like Linux.

c.  Removal of the special case for Linux in many public domain/freeware
software, though this should already be handled via paths.h if the
application is written with portability considerations.

d.  BSD based systems basically made this same change over 15 years
ago.  It was no real big deal.  /usr/spool -> /var/spool, then
2 releases later /var/spool/mail -> /var/mail.  [If my grey matter
is recalling history correctly, it was 4.2BSD on the first move and
some place close to 4.3Tahoe on the second.

Thats it, not a lot of reasons, but IMHO it's A and B that are the real
justifiable reasons.


-- 
Rod Grimes - KD7CAX - (RWG25)   [EMAIL PROTECTED]
Accurate Automation, Inc.   Reliable computers for FreeBSD
http://www.aai.dnsmgr.com

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

[Husain Al-Mohssen]

I think that this is a good idea (IMHO as u would guess :) . I think that for 
far too long we have been chopping up our disks for this reason and losing alot 
of flexibility (and money if not sleep) because of this. I think that Linux 
needs new ideas in it or it would be just another very good unix but only that. 
OTOH I don't think I would be able to do it myself :-/

Husain

Rafal Pietrak wrote:

> Hi all,
>
> I know that it's a bit out-off-the-line (that is, the "solution" I'll 
> propose), I don't have anything to add the current "*/mail* discussion, but 
> please don't flame me, the "solution" is just an idea that may be somebody 
> from the current discussion audience could take if one likes it.
>
> The subject: It looks to me, that everybody cares about mail spool disk 
> usage, so a lot of people put mail spools on a separate partition. In doing 
> so, some people like to have partitions mounted as close to root as possible 
> (the /var/mail variant). IMHO the choice is really quite unimportant, we live 
> with symlinks for quite some time now, and they really serve the purpose of 
> allowing both distributors and admins not to care too much. There is also an 
> issue of  best backup schedules that are different for *spool/mail and for 
> *spool/lpd (for example) that make people have spool/mail on a separate 
> partition from spool/other; but this doesn't support my points in the 
> following paragraph, so I leave it alone for now.
>
> The actual problem is disk usage management limitation that we have on Unix 
> boxes. Independently of whatever conclusion this FHS discussion on */mail 
> comes to; Probably, it would be quite nice if some kernel guru took a deep 
> breath and think of a "subdirectory tree" based quotas as an addition to 
> current "UID based" filesystem quotas and "partition size" limitations, that 
> today's Unixes provide for disk space management.
>
> I think, that if such "quotas" existed - thus allowing to provide a quota of, 
> say 40MB, within /var/spool/mail for GID=mail and nobody else; and, say 10MB, 
> within /var/spool/lpd to UID=lpd and, say 15MB, within /var/spool/cron to 
> UID=root -- current /var/spool/mail discussion would be much less fierce or 
> even void. For a time, everybody would live with couple of compatibility 
> symlinks around, and since there would be no reason to move any */spool/* 
> around, even those symlinks would disappear soon... I think.
>
> -R
>
> --
> Od:  Alan Cox[SMTP:[EMAIL PROTECTED]
> Wys³any:  26 stycznia 1999 01:16
> Do:  Theodore Y. Ts'o
> DW:  [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL 
> PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL 
> PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; 
> debian-devel@lists.debian.org
> Temat:  Re: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0
>
> One simple one - I want my mail on the spool disk. Its in the grows
> randomly, mostly crap, doesnt cause hassle if it fills for a while
> category

 

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

[Joseph Carter]

On Wed, Jan 27, 1999 at 02:51:40PM +1100, Brian May wrote:
> Also, I suspect that some people might be confusing ~/Mailbox and
> ~/Maildir issues. These are two completely different issues. Maildir
> comes from Qmail, but my guess is that ~/Mailbox didn't. Qmail has a
> program that will automatically convert ~/Maildir to ~/Mailbox (this is
> what I use). The only problem I have experienced with Maildir is that it
> is not possible to convert Mailbox-->Maildir and programs like login and
> sshd which check for new mail on login do not work --- however this is
> deviating from the current topic.

~/Mailbox has been around awhile but qmail was the first MTA to use that
by default.  Debian's qmail uses procmail in order to use
/var/spool/mail/$LOGNAME instead of ~/Mailbox, though I have configured
procmail to use ~/Mailbox for all users and for myself I use
~/.mail/INBOX/ (maildir format)...  Of course, I do this with exim
nowadays as qmail drove me batty and isn't DFSG free anyway.

-- 
"I'm working in the dark here."  "Yeah well rumor has it you do your best
work in the dark."
   -- Earth: Final Conflict

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

[Rafal Pietrak]

Hi all,

I know that it's a bit out-off-the-line (that is, the "solution" I'll propose), 
I don't have anything to add the current "*/mail* discussion, but please don't 
flame me, the "solution" is just an idea that may be somebody from the current 
discussion audience could take if one likes it. 

The subject: It looks to me, that everybody cares about mail spool disk usage, 
so a lot of people put mail spools on a separate partition. In doing so, some 
people like to have partitions mounted as close to root as possible (the 
/var/mail variant). IMHO the choice is really quite unimportant, we live with 
symlinks for quite some time now, and they really serve the purpose of allowing 
both distributors and admins not to care too much. There is also an issue of  
best backup schedules that are different for *spool/mail and for *spool/lpd 
(for example) that make people have spool/mail on a separate partition from 
spool/other; but this doesn't support my points in the following paragraph, so 
I leave it alone for now.

The actual problem is disk usage management limitation that we have on Unix 
boxes. Independently of whatever conclusion this FHS discussion on */mail comes 
to; Probably, it would be quite nice if some kernel guru took a deep breath and 
think of a "subdirectory tree" based quotas as an addition to current "UID 
based" filesystem quotas and "partition size" limitations, that today's Unixes 
provide for disk space management. 

I think, that if such "quotas" existed - thus allowing to provide a quota of, 
say 40MB, within /var/spool/mail for GID=mail and nobody else; and, say 10MB, 
within /var/spool/lpd to UID=lpd and, say 15MB, within /var/spool/cron to 
UID=root -- current /var/spool/mail discussion would be much less fierce or 
even void. For a time, everybody would live with couple of compatibility 
symlinks around, and since there would be no reason to move any */spool/* 
around, even those symlinks would disappear soon... I think.

-R


--
Od:  Alan Cox[SMTP:[EMAIL PROTECTED]
Wys³any:  26 stycznia 1999 01:16
Do:  Theodore Y. Ts'o
DW:  [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL 
PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL 
PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; 
debian-devel@lists.debian.org
Temat:  Re: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0


One simple one - I want my mail on the spool disk. Its in the grows
randomly, mostly crap, doesnt cause hassle if it fills for a while
category

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

[Joseph Carter]

On Tue, Jan 26, 1999 at 05:37:53PM -0800, H. Peter Anvin wrote:
> > Most Mail User Agents for standard Unix systems look in /var/mail/
> > for the user's mailbox.  So if qmail is switching to ~/Mailbox, then
> > they have to solve the problem for all of the various MUA's out there,
> > and that is really qmail's and mutt's problem.  I assume someone in that
> > community must have thought about the problem, since people generally
> > don't react well when they're told that they can't use their favorite
> > mail reader because some new mail system has decided to use a different
> > mailbox convention.  
> > 
> >So maybe any standard should not say something about the mail spool dir?
> 
> Actually, it might be worthwhile to specify that if environment
> variable MAILBOX exists, then MUAs need to honour it?

MAIL

-- 
"I'm working in the dark here."  "Yeah well rumor has it you do your best
work in the dark."
   -- Earth: Final Conflict

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

[Brian May]

In article <[EMAIL PROTECTED]> you write:
>> Most Mail User Agents for standard Unix systems look in /var/mail/
>> for the user's mailbox.  So if qmail is switching to ~/Mailbox, then
>> they have to solve the problem for all of the various MUA's out there,
>> and that is really qmail's and mutt's problem.  I assume someone in that
>> community must have thought about the problem, since people generally
>> don't react well when they're told that they can't use their favorite
>> mail reader because some new mail system has decided to use a different
>> mailbox convention.  
>> 
>>So maybe any standard should not say something about the mail spool dir?
>
>Actually, it might be worthwhile to specify that if environment
>variable MAILBOX exists, then MUAs need to honour it?

What MUAs *can't* use ~/Mailbox? The only problem I have with my
computer is that each MUA (eg pine and nmh) requires seperate
configuration, and doesn't look at the $MAIL environment variable. elm
supports it though, mutt might, but I haven't tried it.

Where does the $MAILBOX environment variable come into it? elm uses
$MAIL. eg I have $MAIL=$HOME/Mailbox

I don't administer large Unix systems, but I like the idea of keeping
users private mail in their home directories - IMHO it makes is easier to
manage when a users files are all in one location and not segragated
around the entire disk structure.

Also, I suspect that some people might be confusing ~/Mailbox and
~/Maildir issues. These are two completely different issues. Maildir
comes from Qmail, but my guess is that ~/Mailbox didn't. Qmail has a
program that will automatically convert ~/Maildir to ~/Mailbox (this is
what I use). The only problem I have experienced with Maildir is that it
is not possible to convert Mailbox-->Maildir and programs like login and
sshd which check for new mail on login do not work --- however this is
deviating from the current topic.

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

[Kragen Sitaker]

On Tue, 26 Jan 1999, Theodore Y. Ts'o wrote:
> Most Mail User Agents for standard Unix systems look in /var/mail/
> for the user's mailbox.  So if qmail is switching to ~/Mailbox, then
> they have to solve the problem for all of the various MUA's out there,
> and that is really qmail's and mutt's problem.

Generally it's configurable; my .pinerc just says 'inbox-path=Mailbox'
and that takes care of it, and Mutt (along with many other mailers, I'm
told) just pays attention to $MAIL.

There's a file in the qmail distribution called INSTALL.mbox that
explains what to do to switch to the ~/Mailbox convention.

>So maybe any standard should not say something about the mail spool dir?
> 
> Well, the problem is what happens if a third-party wants to ship a mail
> user agent?  If how you get mail on a system is a distribution-local
> thing, that means that only the distribution-provided mail readers have
> a chance of working correctly.  The whole point of the LSB effort was to
> allow this kind of third-party application provider to be able to work
> across different Linux systems, and not have certain applications that
> only work on RedHat systems, but not Debian systems, or vice versa.

There are several ways to handle this.  You can use DLLs like
Microsoft, you can specify filesystem locations and file formats (which
is the current FHS situation), you can specify environment variables
and file formats (which is the current de facto standard, and the
reason why switching to ~/Mailbox was easy for me).

Setting environment variables like MAIL can be done in the global
profile and csh.cshrc files.

Currently, the FHS only specifies filesystem locations.  This is
considerably more restrictive than the other alternatives; switching to
maildir format is essentially infeasible.

The benefit of only specifying filesystem locations is that it keeps
both the interface and the implementation simple.  If every MTA came
with a DLL to provide access to mailboxes stored in that MTA's format,
I suspect that mailboxes and access thereto would be considerably more
complex and failure-prone.

-- 
<[EMAIL PROTECTED]>   Kragen Sitaker 
Computers are the tools of the devil. It is as simple as that. There is no
monotheism strong enough that it cannot be shaken by Unix or any Microsoft
product. The devil is real. He lives inside C programs. -- [EMAIL PROTECTED]

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

[H. Peter Anvin]

> Most Mail User Agents for standard Unix systems look in /var/mail/
> for the user's mailbox.  So if qmail is switching to ~/Mailbox, then
> they have to solve the problem for all of the various MUA's out there,
> and that is really qmail's and mutt's problem.  I assume someone in that
> community must have thought about the problem, since people generally
> don't react well when they're told that they can't use their favorite
> mail reader because some new mail system has decided to use a different
> mailbox convention.  
> 
>So maybe any standard should not say something about the mail spool dir?

Actually, it might be worthwhile to specify that if environment
variable MAILBOX exists, then MUAs need to honour it?

> Well, the problem is what happens if a third-party wants to ship a mail
> user agent?  If how you get mail on a system is a distribution-local
> thing, that means that only the distribution-provided mail readers have
> a chance of working correctly.  The whole point of the LSB effort was to
> allow this kind of third-party application provider to be able to work
> across different Linux systems, and not have certain applications that
> only work on RedHat systems, but not Debian systems, or vice versa.

-hpa

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

[Theodore Y. Ts'o]

   From: Florian La Roche <[EMAIL PROTECTED]>
   Date: Tue, 26 Jan 1999 10:44:20 +0100

   How can changing from /var/spool/mail to /var/mail be a "full
   solution" for the next years to come?  Many people think that the
   mail-dir solution that e.g. qmail and mutt support is the real
   solution for the future. Maybe future Linux distributions want to
   ship that as a default? They couldn't be compliant with this standard
   even though they use a more modern mail-storing setup.  The change
   from /var/spool/mail can be done on any system with an "ln -s
   spool/mail /var/mail". Why mix up all Linux users instead of keeping
   this a local solution anybody can do?

Most Mail User Agents for standard Unix systems look in /var/mail/
for the user's mailbox.  So if qmail is switching to ~/Mailbox, then
they have to solve the problem for all of the various MUA's out there,
and that is really qmail's and mutt's problem.  I assume someone in that
community must have thought about the problem, since people generally
don't react well when they're told that they can't use their favorite
mail reader because some new mail system has decided to use a different
mailbox convention.  

   So maybe any standard should not say something about the mail spool dir?

Well, the problem is what happens if a third-party wants to ship a mail
user agent?  If how you get mail on a system is a distribution-local
thing, that means that only the distribution-provided mail readers have
a chance of working correctly.  The whole point of the LSB effort was to
allow this kind of third-party application provider to be able to work
across different Linux systems, and not have certain applications that
only work on RedHat systems, but not Debian systems, or vice versa.

- Ted

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

[Jakob 'sparky' Kaivo]

On Wed, 27 Jan 1999, Alan Cox wrote:

> > The mail spool MUST be accessible through /var/mail AND /var/spool/mail,
> > and spool files MUST take the form /var/{spool/}mail/$LOGNAME. Either
> > /var/mail or /var/spool/mail, or both, MAY be symbolic links to another
> > directory. 
> 
> That sounds good to me

And several others, I beleive. Perhaps a vote is in order?

> > It is RECOMMENDED that /var/mail be the actual directory and
> > /var/spool/mail be the symbolic link. At some point use of /var/spool/mail
> > may become deprecated.
> 
> Thats policy where it isnt needed

Then it doesn't have to be included. I only put it in to placate all the
"other UNIXen use /var/mail, so /var/spool/mail shouldn't even exist" type
people.

+-++
| Jakob 'sparky' Kaivo|  [EMAIL PROTECTED] |
| NoDomainName Networks   |http://www.nodomainname.net |
| AtDot E-mail Services   |   http://www.atdot.org |
+-++

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

[Jakob 'sparky' Kaivo]

This is getting WAY out of hand here. How about this:

The mail spool MUST be accessible through /var/mail AND /var/spool/mail,
and spool files MUST take the form /var/{spool/}mail/$LOGNAME. Either
/var/mail or /var/spool/mail, or both, MAY be symbolic links to another
directory. It is RECOMMENDED that /var/mail be the actual directory and
/var/spool/mail be the symbolic link. At some point use of /var/spool/mail
may become deprecated.

+-++
| Jakob 'sparky' Kaivo|  [EMAIL PROTECTED] |
| NoDomainName Networks   |http://www.nodomainname.net |
| AtDot E-mail Services   |   http://www.atdot.org |
+-++

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

[Manoj Srivastava]

Hi,
>>"Ted" == Theodore Y Ts'o <[EMAIL PROTECTED]> writes:

 Ted> I keep hearing people claim that distribution folks are saying "ick",
 Ted> but I haven't heard any technical reasons besides, "Moving spool
 Ted> directories is hard".

Fine. Here are a few.

I, and a number of other sysadmins, have a partition for /var,
 and mount /var/spool on it. The understanding has always been that
 */spool/ directories contain data that may grow unpredictably.  If I
 use log rotation, and purge old logs regularly, /var remains a more
 or less static in size, apart from the spool directories.  One has
 little control over the size of the spool directories. So, one puts
 the spool directory on another partition. 

This has been standard practice in OS's derived from BSD, I
 think (I know we used to do it on Ultrix, in the good old days).

Another factor is wehen the spool directories are used for
 USENET or mail, there are a large number of small files with a high
 turnover; one some file systems one may tweak parameters to make the
 file system better suited for spools. (This is certainly less true
 for mail than for news, but still)

I have generally put large partitions for spool, and prefer
 not to have an overfull spool partition bring down the system.

 Ted> When I and others have pointed out that moving the spool
 Ted> directory isn't required; just a symlink, I have heard dead
 Ted> silence.  So the lack of technical discussion, but just a
 Ted> stony-silence "No!" is rather disappointing as far as I'm
 Ted> concerned.

I have no objections to a compatibility link in /var/mail, or
 to modifying code to look in both places.

 Ted> I think we should require that new applications use /var/mail,
 Ted> and that backwards compatibility symlinks should exist.


While the new FHS is trying for conformance with other unices,
 we should also consider rtadition (traditionally, /var/spool/mail has
 been the location for Linux boxes)

Why can't we get compatibility with the so called other unices
 just by putting in a sym link in /var/mail, and leaving the spool
 directory where it is?

 Ted> If we must back out /var/mail (for no good technical reason that I can
 Ted> determine), then at the very least I think we should state that there
 Ted> that for all compliant distributions, /var/mail *MUST* be a valid way of
 Ted> reaching the spool directory (i.e., there should be a symlink there, or
 Ted> where the spool directory actually lives) and that it be permissible for
 Ted> applications to use /var/mail to find the mail directory (but that
 Ted> applications that want to keep using /var/spool/mail would not be
 Ted> considered obsolete).

I think this is a reasonable compromise.

 Ted> At least that way applications that want to use the same dirctory as the
 Ted> vast majority of other Unix systems will work without needing a special
 Ted> case for Linux.  However, I would much rather see us adopt the full,
 Ted> correct solution, rather than this half-measure.

This is the first rationale I have seen for actually going to
 /var/mail, other than ``those other unices do it'', and I think a
 symlink shall address all those concerns quite well. I suppose there
 sould also be an argument that the mail spool is not really a spool,
 but a message queue still qualifies for being on the spool partition.
 (trying to move my mail spool directory to /var/mail may well fail on
 some of my machines due to file system getting overfull)

I have not being following the FHS list, so these opinions may
 well be un informed.

manoj
-- 
 +#if defined(__alpha__) && defined(CONFIG_PCI) /* The meaning of
 life, the universe, and everything. Plus this makes the year come out
 right. */ year -= 42; +#endif (From the patch for 1.3.2:
 (kernel/time.c), submitted by Marcus Meissner)
Manoj Srivastava <[EMAIL PROTECTED]>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E

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

[Ben Collins]

On Tue, Jan 26, 1999 at 01:27:13PM +, Alan Cox wrote:
> > I'll give you one solid reason, uniformity across unix platforms is a
> > must have if unix, especially free unices, are going to succesfully
> 
> If we are in marketing mode let me point out we are not Unix in the first
> place and that C:\> is the standard 

s/Unix/Unix-Like/ for clarification.

> > I don't see a connection between /var/spool/mail or /var/mail and
> > home directories or priviliedges. IOW, how does one lend itself better
> > to the task at hand?
> 
> Modern mail systems dont use a mail spool in general. Or when they do they
> use a format different to "tradition"

Obviously every admin and 'modern' mail system is going to want to do
things their way. Our goal is hopefully to put standard on where it
_should_ be and where the default system should have it. What the admin or
third party mail systems do after that is completely beyond the scope of
the distributions. If our contention is that we cannot forsee what will
become of future mailing systems then maybe we should be arguing whether
or not we should have a "standard" or should we have a scope of acceptible
implementations.

> > well as far as the system is concerned. What we need to decide is, do
> > we want to go with the standard, or make a new standard simply because
> > we don't want to change?
> 
> Is the purpose of the FHS to make Linux run after and blindly copy things
> from Unix platforms or to provide a best Linux platform ?

The same could be argued for both sides of this double-edged sword. Not
everyone is going to be pleased with the outcome, right now I'd say the
opinions are split even. We can either stick with what we have to suit our
definiton of a mail spool, or to please the cross-platform admins, go with
the old tradition to have a uniform setup. Where is the compromise here
that we need?

-- 
--- -  -   ---  -  - - ---   
Ben Collins <[EMAIL PROTECTED]>  Debian GNU/Linux
UnixGroup Admin - Jordan Systems Inc. [EMAIL PROTECTED]
-- -- - - - ---   --- -- The Choice of the GNU Generation

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

[Hamish Moffatt]

On Tue, Jan 26, 1999 at 07:19:20AM -0500, Ben Collins wrote:
> 
> I'll give you one solid reason, uniformity across unix platforms is a
> must have if unix, especially free unices, are going to succesfully
> dominate the market. Sun/AIX/HP-UX/OSF/SCO are not going to change,
> but we could prove our willingess and ability to ensure these uniformities.
> 

Mail spool location is really the least of the problems in inter-UNIX
compatibility. Why do you think autoconf-generated configure scripts
check so many things?

Application vendors probably shouldn't hardcode ANY location. On one
system I use at the university where I study, email is kept in
~/.inbox. Vendors need to make things configurable anyway to support
configurations like that.


Hamish
-- 
Hamish Moffatt VK3TYD  [EMAIL PROTECTED], [EMAIL PROTECTED]
Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5
CCs of replies from mailing lists are welcome.   http://hamish.home.ml.org

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

[Alan Cox]

> I'll give you one solid reason, uniformity across unix platforms is a
> must have if unix, especially free unices, are going to succesfully

If we are in marketing mode let me point out we are not Unix in the first
place and that C:\> is the standard 

> I don't see a connection between /var/spool/mail or /var/mail and
> home directories or priviliedges. IOW, how does one lend itself better
> to the task at hand?

Modern mail systems dont use a mail spool in general. Or when they do they
use a format different to "tradition"

> well as far as the system is concerned. What we need to decide is, do
> we want to go with the standard, or make a new standard simply because
> we don't want to change?

Is the purpose of the FHS to make Linux run after and blindly copy things
from Unix platforms or to provide a best Linux platform ?

Alan

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

[Ben Collins]

On Mon, Jan 25, 1999 at 10:33:27PM -0800, Joseph Carter wrote:
> On Mon, Jan 25, 1999 at 07:09:34PM -0500, Kragen Sitaker wrote:
> > > If we must back out /var/mail (for no good technical reason that I can
> > > determine), then at the very least I think we should state that there
> > > that for all compliant distributions, /var/mail *MUST* be a valid way of
> > > reaching the spool directory (i.e., there should be a symlink there, or
> > > where the spool directory actually lives)
> >
> > If you include this change, will using ~/Mailbox violate the FHS?  Does
> > it already?  Should it?  Should we require symlinks from
> > /var/mail/$USER to ~$USER/Mailbox?
>
> I still want to know what /var/mail gains us over /var/spool/mail.  I've
> asked many times of many people and all I have gotten back is that it's
> an issue of style or that mail isn't a spool (which I disagreed with)..
> I am curious for the answer to this, so far I have heard "/var/mail is
> good and we all know it's good but the dists don't agree."  So I ask in
> front of all of everybody in the hopes that maybe the answer will make
> sense, what technical reason is there for change now?


I'll give you one solid reason, uniformity across unix platforms is a
must have if unix, especially free unices, are going to succesfully
dominate the market. Sun/AIX/HP-UX/OSF/SCO are not going to change,
but we could prove our willingess and ability to ensure these uniformities.


> If you want my opinion as I am SURE everybody does, /var/anything/mail is
> probably a bad plan from a least privileges standpoint.  Qmail users are
> not the only people out there with ~/Mailbox setups and there are good
> reasons why, starting with security.  The only argument against this I
> have ever seen is that not all mail users have home directories.  While
> my machine is single-user and this isn't a problem for me, I have seen a
> few solutions to it.

I don't see a connection between /var/spool/mail or /var/mail and
home directories or priviliedges. IOW, how does one lend itself better
to the task at hand?

Since there is no real concrete reason to use /var/mail over
/var/spool/mail except for meeting a standard filesystem concept
(which is, uh, what we are trying to do) then maybe people need to look
at it from that stand point instead "what's better about it". We could
put mail in /usr/var/mymail/whereIwantit/ and it would work just as
well as far as the system is concerned. What we need to decide is, do
we want to go with the standard, or make a new standard simply because
we don't want to change?

--
--- -  -   ---  -  - - ---   
Ben Collins <[EMAIL PROTECTED]>  Debian GNU/Linux
UnixGroup Admin - Jordan Systems Inc. [EMAIL PROTECTED]
-- -- - - - ---   --- -- The Choice of the GNU Generation

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

[Alan Cox]

> But I don't think the FHS should be specifying the actual location of
> the files at all.  True, the FHS should not cause too much pain for the

Ok good we agree on this 

> The only thing that really matters is what pathnames applications can
> count upon to work.  Given that the rest of the world is moving to

Right now every package you build for linux assumes /var/spool/mail. I dont
actually care what the rest of the world is doing. From a rather brutal 
point of view _we_ are becoming the rest of the world.

> /var/mail, I think it would be good for us to start a gradual migration
> to /var/mail.  The extra symlink doesn't cost anything, and gradually
> moving applications over to use /var/mail really doesn't cost much
> either.

By the time we migrate to /var/mail and annoy alll the vendors - netscape,
applix, zmail and the like the old style unix mail format will be dying.

It seems to be pain for the sake of it. If all the Linux vendors already
used /var/mail and you said "lets use /var/spool/mail" I'd be equally
opposed.

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

[t . sippel-dau]

The keyboard of Kragen Sitaker emitted at some point in time:
> 
> On Mon, 25 Jan 1999, Theodore Y. Ts'o wrote:
> > If we must back out /var/mail (for no good technical reason that I can
> > determine), then at the very least I think we should state that there
> > that for all compliant distributions, /var/mail *MUST* be a valid way of
> > reaching the spool directory (i.e., there should be a symlink there, or
> > where the spool directory actually lives)
> 
> If you include this change, will using ~/Mailbox violate the FHS?  Does
> it already?  Should it?  Should we require symlinks from
> /var/mail/$USER to ~$USER/Mailbox?

Hmm, and a mandatory symlink form $LOGNAME/Mailbox to /var/mail/$LOGNAME,
and we will have established FHS compliant systems as those "where email
won't work any more".

N.B. your phrasing was not POSIX compliant, tut, tut, tut. A good example
how technically simple and conceptually irrelevant changes (from USER to
LOGNAME) are still extremely dificult to achieve in practice.

> Switching a single one-user system to ~/Mailbox is easy, btw.
> Switching a single multi-user system to ~/Mailbox is likely to cause a
> certain amount of pain.

Pain of no real benefit to the end user, as long as "it works".

>  Distributing applications to millions of
> people, some of whom use one convention, and some of whom use another,
> is surely asking for trouble.

Yes, it is. arguing about it will make mpore pain.

Thomas

*   Why not use metric units and get it right first time, every time ?
*
*   email: cmaae47 @ imperial.ac.uk

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

[Florian La Roche]

> At least that way applications that want to use the same dirctory as the
> vast majority of other Unix systems will work without needing a special
> case for Linux.  However, I would much rather see us adopt the full,
> correct solution, rather than this half-measure.

How can changing from /var/spool/mail to /var/mail be a "full solution"
for the next years to come?
Many people think that the mail-dir solution that e.g. qmail and mutt
support is the real solution for the future. Maybe future Linux distributions
want to ship that as a default? They couldn't be compliant with this
standard even though they use a more modern mail-storing setup.
The change from /var/spool/mail can be done on any system with an
"ln -s spool/mail /var/mail". Why mix up all Linux users instead of
keeping this a local solution anybody can do?

So maybe any standard should not say something about the mail spool dir?

Florian La Roche

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

[Joseph Carter]

On Mon, Jan 25, 1999 at 07:09:34PM -0500, Kragen Sitaker wrote:
> > If we must back out /var/mail (for no good technical reason that I can
> > determine), then at the very least I think we should state that there
> > that for all compliant distributions, /var/mail *MUST* be a valid way of
> > reaching the spool directory (i.e., there should be a symlink there, or
> > where the spool directory actually lives)
> 
> If you include this change, will using ~/Mailbox violate the FHS?  Does
> it already?  Should it?  Should we require symlinks from
> /var/mail/$USER to ~$USER/Mailbox?

I still want to know what /var/mail gains us over /var/spool/mail.  I've
asked many times of many people and all I have gotten back is that it's
an issue of style or that mail isn't a spool (which I disagreed with).. 
I am curious for the answer to this, so far I have heard "/var/mail is
good and we all know it's good but the dists don't agree."  So I ask in
front of all of everybody in the hopes that maybe the answer will make
sense, what technical reason is there for change now?

If you want my opinion as I am SURE everybody does, /var/anything/mail is
probably a bad plan from a least privileges standpoint.  Qmail users are
not the only people out there with ~/Mailbox setups and there are good
reasons why, starting with security.  The only argument against this I
have ever seen is that not all mail users have home directories.  While
my machine is single-user and this isn't a problem for me, I have seen a
few solutions to it.



> Switching a single one-user system to ~/Mailbox is easy, btw.
> Switching a single multi-user system to ~/Mailbox is likely to cause a
> certain amount of pain.  Distributing applications to millions of
> people, some of whom use one convention, and some of whom use another,
> is surely asking for trouble.

And then you have people who use MH or Maildir instead of traditional
mbox.  The only way to REALLY deal with it sanely is to read $MAIL and
see what it says, I suspect.

-- 
"I'm working in the dark here."  "Yeah well rumor has it you do your best
work in the dark."
   -- Earth: Final Conflict

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

[Theodore Y. Ts'o]

   From: Alan Cox <[EMAIL PROTECTED]>
   Date: Tue, 26 Jan 1999 00:15:37 + (GMT)

   > but I haven't heard any technical reasons besides, "Moving spool
   > directories is hard".  When I and others have pointed out that moving
   > the spool directory isn't required; just a symlink, I have heard dead
   > silence.  So the lack of technical discussion, but just a stony-silence
   > "No!" is rather disappointing as far as I'm concerned.

   One simple one - I want my mail on the spool disk. Its in the grows
   randomly, mostly crap, doesnt cause hassle if it fills for a while
   category

But I don't think the FHS should be specifying the actual location of
the files at all.  True, the FHS should not cause too much pain for the
certain obvious and common partition layouts, but once we enter the
realm of server systems, there's no guarantee where the mountpoints
might end up falling.  For example, I might want the mail files on /u1,
and the printer spool files in /u2 --- in which case there will probably
a number of symlinks in /var and /var/spool.  

The only thing that really matters is what pathnames applications can
count upon to work.  Given that the rest of the world is moving to
/var/mail, I think it would be good for us to start a gradual migration
to /var/mail.  The extra symlink doesn't cost anything, and gradually
moving applications over to use /var/mail really doesn't cost much
either.

- Ted

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

[Richard Gooch]

Alan Cox writes:
> > 2. Disk space management.
> 
> We've proved between us that both views are held here. This therefore is a
> rather spurious claim. A (maybe) symlink called /var/spool/mail that points 
> somewhere arbitary is all that is needed for this issue. The FHS need
> say nothing else

I have to agree with Alan on this. Disc space management is a sysadmin
issue. Anyone who cares about protecting the mail spool from overfill
*from other spools* (like the printer) is going to have to deal with
is issue properly. That means putting /var/mail on a separate FS from
/var/spool. As soon as you do that, I can't see any advantage to
mandating /var/mail instead of /var/spool/mail. If you have a separate
FS for mail, the choice boils down to a fer characters in /etc/fstab.

Given that the default RedHat install dumps everything in one FS
under / I don't see any practical benefit (from the disc space
management point of view) of /var/mail over /var/spool/mail. Anyone
who wishes to set up their system sanely is going to put /var and /tmp
elsewhere anyway, so at that point they can decide whether they want
another FS for mail.

On big networks like the one we have here, it matters not, because the
mail spool is on a central fileserver anyway. Again, the choice is a
few characters in /etc/fstab.
Although for Linux there a problem with NFS locking, but let's
pretend they have been fixed for the sake of this discussion :-/


Regards,

Richard

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

[Alan Cox]

> 1. Interoperability with other systems.

10+ million Linux boxes use /var/spool/mail. Its also a spurious claim. All
existing tools assume linux uses /var/spool/mail. Other systems even sharing
via NFS dont get problems with this /var/spool usage

> 2. Disk space management.

We've proved between us that both views are held here. This therefore is a
rather spurious claim. A (maybe) symlink called /var/spool/mail that points 
somewhere arbitary is all that is needed for this issue. The FHS need
say nothing else

Your arguments don't IMHO hold water, nor in fact anything else

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

[H. Peter Anvin]

> One simple one - I want my mail on the spool disk. Its in the grows
> randomly, mostly crap, doesnt cause hassle if it fills for a while
> category

That, I believe, is not the majority opinion.  At most industrial
sites, mail spool overflow is a major crisis.

> I have no problem with a "both paths must one work one or more may be a
> symlink". At that point however the FHS should mandate one which may be a
> symlink only. Right now everyone uses /var/spool/mail whats the technical
> reason for using /var/mail that is good enough to justify the change ?

1. Interoperability with other systems.
2. Disk space management.

-hpa

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

[Alan Cox]

> but I haven't heard any technical reasons besides, "Moving spool
> directories is hard".  When I and others have pointed out that moving
> the spool directory isn't required; just a symlink, I have heard dead
> silence.  So the lack of technical discussion, but just a stony-silence
> "No!" is rather disappointing as far as I'm concerned.

One simple one - I want my mail on the spool disk. Its in the grows
randomly, mostly crap, doesnt cause hassle if it fills for a while
category

I have no problem with a "both paths must one work one or more may be a
symlink". At that point however the FHS should mandate one which may be a
symlink only. Right now everyone uses /var/spool/mail whats the technical
reason for using /var/mail that is good enough to justify the change ?

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

[H. Peter Anvin]

> On Mon, 25 Jan 1999, Theodore Y. Ts'o wrote:
> > If we must back out /var/mail (for no good technical reason that I can
> > determine), then at the very least I think we should state that there
> > that for all compliant distributions, /var/mail *MUST* be a valid way of
> > reaching the spool directory (i.e., there should be a symlink there, or
> > where the spool directory actually lives)
> 
> If you include this change, will using ~/Mailbox violate the FHS?  Does
> it already?  Should it?  Should we require symlinks from
> /var/mail/$USER to ~$USER/Mailbox?
> 
> Switching a single one-user system to ~/Mailbox is easy, btw.
> Switching a single multi-user system to ~/Mailbox is likely to cause a
> certain amount of pain.  Distributing applications to millions of
> people, some of whom use one convention, and some of whom use another,
> is surely asking for trouble.
> 

~/Mailbox systems are inherently local-setup anyway; they're going to
need their own applications, unless they have the symlinks (I think
there are special daemons to create link farms like that using a
virtual NFS server.)

-hpa
 

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

[Kragen Sitaker]

On Mon, 25 Jan 1999, Theodore Y. Ts'o wrote:
> If we must back out /var/mail (for no good technical reason that I can
> determine), then at the very least I think we should state that there
> that for all compliant distributions, /var/mail *MUST* be a valid way of
> reaching the spool directory (i.e., there should be a symlink there, or
> where the spool directory actually lives)

If you include this change, will using ~/Mailbox violate the FHS?  Does
it already?  Should it?  Should we require symlinks from
/var/mail/$USER to ~$USER/Mailbox?

Switching a single one-user system to ~/Mailbox is easy, btw.
Switching a single multi-user system to ~/Mailbox is likely to cause a
certain amount of pain.  Distributing applications to millions of
people, some of whom use one convention, and some of whom use another,
is surely asking for trouble.


-- 
<[EMAIL PROTECTED]>   Kragen Sitaker 
Computers are the tools of the devil. It is as simple as that. There is no
monotheism strong enough that it cannot be shaken by Unix or any Microsoft
product. The devil is real. He lives inside C programs. -- [EMAIL PROTECTED]

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

[Kragen Sitaker]

On Mon, 25 Jan 1999, Erik Troan wrote:
> On Mon, 25 Jan 1999, Daniel Quinlan wrote:
> 
> > New systems would need to have a /var/spool/mail -> /var/mail symbolic
> > link for about two years.
> 
> No, forever. Red Hat is promising an upgrade path for a lot longer then two
> years -- we've already provided upgradeable distributions for 3.5.

. . . which is good, because there are probably many people out there
like me who have something approximating Red Hat 3.2 systems from
secondhand CDs.

Ten or fifteen years is probably reasonable.

Interfaces should stay fairly stable.

Has anyone compared Linux's signal.h (the one that actually lists the
signal numbers) to the signal.h from Version 6 Unix for the PDP-11?
There are 22 years of difference, but it looks like about a year.  :)

-- 
<[EMAIL PROTECTED]>   Kragen Sitaker 
Computers are the tools of the devil. It is as simple as that. There is no
monotheism strong enough that it cannot be shaken by Unix or any Microsoft
product. The devil is real. He lives inside C programs. -- [EMAIL PROTECTED]

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

[Theodore Y. Ts'o]

I keep hearing people claim that distribution folks are saying "ick",
but I haven't heard any technical reasons besides, "Moving spool
directories is hard".  When I and others have pointed out that moving
the spool directory isn't required; just a symlink, I have heard dead
silence.  So the lack of technical discussion, but just a stony-silence
"No!" is rather disappointing as far as I'm concerned.

I think we should require that new applications use /var/mail, and that
backwards compatibility symlinks should exist.

If we must back out /var/mail (for no good technical reason that I can
determine), then at the very least I think we should state that there
that for all compliant distributions, /var/mail *MUST* be a valid way of
reaching the spool directory (i.e., there should be a symlink there, or
where the spool directory actually lives) and that it be permissible for
applications to use /var/mail to find the mail directory (but that
applications that want to keep using /var/spool/mail would not be
considered obsolete).

At least that way applications that want to use the same dirctory as the
vast majority of other Unix systems will work without needing a special
case for Linux.  However, I would much rather see us adopt the full,
correct solution, rather than this half-measure.

- Ted

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

[H. Peter Anvin]

> >> New systems would need to have a /var/spool/mail -> /var/mail symbolic
> >> link for about two years.
> 
> Erik Troan <[EMAIL PROTECTED]> writes:
> 
> > No, forever. Red Hat is promising an upgrade path for a lot longer then two
> > years -- we've already provided upgradeable distributions for 3.5.
> 
> I said "new systems", not systems that are being upgraded.
> 
> > You seem to be ignoring the upgrade issue. Allowing in-place upgrades
> > necessetates /var/spool/mail to exist in some form.
> 
> I'm not ignoring it, I just don't think it's a problem.
> 
> If today's in-place upgrades don't allow /var/spool/mail to be a
> symbolic link, then they are broken.  The same would be true for
> /var/mail on a system that still mounted the spool on /var/spool/mail.

I think interoperability requires that they be compatible as long as
possible, preferrably indefinitely.  I would suggest:

1. REQUIRE /var/mail and /var/spool/mail to both exist, and be
   aliases.
2. RECOMMEND future use of /var/mail throughout.
3. DEPRECATE the use of /var/spool/mail.

I don't see a need for abolishing the link /var/spool/mail any time
soon; it has to remain reserved namespace indefinitely anyway.

-hpa

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

[Daniel Quinlan]

Daniel Quinlan <[EMAIL PROTECTED]> writes:

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

Erik Troan <[EMAIL PROTECTED]> writes:

> No, forever. Red Hat is promising an upgrade path for a lot longer then two
> years -- we've already provided upgradeable distributions for 3.5.

I said "new systems", not systems that are being upgraded.

> You seem to be ignoring the upgrade issue. Allowing in-place upgrades
> necessetates /var/spool/mail to exist in some form.

I'm not ignoring it, I just don't think it's a problem.

If today's in-place upgrades don't allow /var/spool/mail to be a
symbolic link, then they are broken.  The same would be true for
/var/mail on a system that still mounted the spool on /var/spool/mail.

Dan

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

[Erik Troan]

On Mon, 25 Jan 1999, Daniel Quinlan wrote:

> > Ten years.
> 
> Are you serious?  The Linux community has already made larger changes
> in far far less time.  We're talking about modifying one or two lines
> in 10 or 20 source packages (like src RPMs).

You seem to be ignoring the upgrade issue. Allowing in-place upgrades
necessetates /var/spool/mail to exist in some form.

Erik

---
|   "For the next two hours, VH1 will be filled with foul-mouthed,|
|  crossdressing Australians. Viewer discretion is advised."  |
| |
|   Linux Application Development  --  http://www.redhat.com/~johnsonm/lad|

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

[Erik Troan]

On Mon, 25 Jan 1999, Daniel Quinlan wrote:

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

No, forever. Red Hat is promising an upgrade path for a lot longer then two
years -- we've already provided upgradeable distributions for 3.5.

Erik

---
|   "For the next two hours, VH1 will be filled with foul-mouthed,|
|  crossdressing Australians. Viewer discretion is advised."  |
| |
|   Linux Application Development  --  http://www.redhat.com/~johnsonm/lad|

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

[Daniel Quinlan]

t sippel-dau <[EMAIL PROTECTED]> writes:

> Ten years.

Are you serious?  The Linux community has already made larger changes
in far far less time.  We're talking about modifying one or two lines
in 10 or 20 source packages (like src RPMs).

It was several years ago already that we dropped some of the symbolic
links that shipped with Linux systems circa FSSTND 1.0 (such as /usr/spool).

- Dan

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

[t . sippel-dau]

The keyboard of Daniel Quinlan emitted at some point in time:

> 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.

Ten years.

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

Ditto.

Software development may change fast, and many software developers will
change quickly in this case.  Documentation is much mmore difficult, and
what is actually used by users takes much longer again.

Since /var/mail and /var/spool/mail are "out there", it will not be
possible to use the "loosing" path for anything else for many years.

Thomas

*   Why not use metric units and get it right first time, every time ?
*
*   email: cmaae47 @ imperial.ac.uk

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

[Daniel Quinlan]

Alan Cox <[EMAIL PROTECTED]> 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

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

[Alan Cox]

> I thought the purpose of this project (at least the FHS) is to create a 
> standard
> of what the filesystem should look like, not necessarily what it currently 
> looks
> like. Just because `Everyone is doing it' (tm) doesn't mean it's right.
> Personally, I want Linux to be clean and elegant in its implementation, so if
> that means breaking from convention and putting mail in /var/mail, so be it. I
> for one don't know the answer. Whatever the answer is should be the right one,
> not just the one people are doing.

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"

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

[Gordon Tetlow]

Florian La Roche wrote:
>
> 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.

I thought the purpose of this project (at least the FHS) is to create a standard
of what the filesystem should look like, not necessarily what it currently looks
like. Just because `Everyone is doing it' (tm) doesn't mean it's right.
Personally, I want Linux to be clean and elegant in its implementation, so if
that means breaking from convention and putting mail in /var/mail, so be it. I
for one don't know the answer. Whatever the answer is should be the right one,
not just the one people are doing.

Gordon Tetlow

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

[Erik Troan]

On Wed, 20 Jan 1999, H. Peter Anvin wrote:

> 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
> disk space management problems.

Moving it on running systems is an nightmare, and there is simply no compelling
reason to do so, imho.

Erik

---
|   "For the next two hours, VH1 will be filled with foul-mouthed,|
|  crossdressing Australians. Viewer discretion is advised."  |
| |
|   Linux Application Development  --  http://www.redhat.com/~johnsonm/lad|

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

[Scott K. Ellis]

On Thu, 21 Jan 1999, Florian La Roche wrote:

> 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.

Note that Debian has not yet moved from FSSTND to FHS for the most part,
and relocating /var/spool/mail hasn't been done in part due to discussion
on the technical issues involved.

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

[bandregg]

On Wed, 20 Jan 1999 23:53:32 -0800 (PST), "H. Peter Anvin" wrote: 
>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
>disk space management problems.

But mine is. My mail spools there until I collect it via fetchmail. This is 
exactly the process of outgoing mail spooling in /var/spool/mqueue in reverse.
-- 
Bryan C. Andregg * <[EMAIL PROTECTED]> * Red Hat Software

"Gee, I'm glad you're around to tell me the almighty-truth[tm]."
-- Patrick J. Volkerding

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

[Roeland Th. Jansen]

> Sorry for writing the same several times again. Since I have moved from
> /var/spool/mail to /var/mail and back again, I know what's it like and
> I know that having only one dir instead is more sane/clean than several
> ones.

well, I tend to agree here. I moved to /var/mail and added a symlink but
basically, it's ugly. it does work, but if I take a close look at my current
filesystem, it's symlink galore all over the place.


-- 
Grobbebol's Home |  Don't give in to spammers.   -o)
http://www.xs4all.nl/~bengel | Use your real e-mail address   /\
Linux 2.0.36  on  an i586/64 MB  |on Usenet. _\_v  

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

[Florian La Roche]

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

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

[H. Peter Anvin]

> > 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.

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
disk space management problems.

-hpa

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

[H. Peter Anvin]

> > I agree.  I also don't think it's a big deal.  What's important is that
> > all of the MUA's get compiled so that they look for the mail spool in
> > /var/mail.  If /var/mail is a symlink to /var/spool/mail, or /u3/mail,
> > or something else --- that's fine.
> 
> Adding that symlink can be done easily by the admin of a machine. Why
> do you already want to do it on the distribution level?
> 
> I'd either want the standard to move everything to /var/mail and
> abandom /var/spool/mail or to keep with /var/spool/mail.

For interoperability reasons.  It is not good if people can't use
binaries or scripts from another distribution.

> The move to /var/mail would take some time for the Linux community until
> it is finished. The end result would be that (just like now with /var/mail)
> some admins will add a link from /var/spool/mail to the new /var/mail to
> be compatible with old Linux systems or DEC machines.
> 
> So the move to /var/mail will get us some confusion in the Linux community
> and at the end we will have the same situation as now: some admins will
> have to add a compatibility symlink. We achieved nothing...
> 
> Please think about it and stay with /var/spool/mail.

-hpa

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

[Florian La Roche]

> I agree.  I also don't think it's a big deal.  What's important is that
> all of the MUA's get compiled so that they look for the mail spool in
> /var/mail.  If /var/mail is a symlink to /var/spool/mail, or /u3/mail,
> or something else --- that's fine.

Adding that symlink can be done easily by the admin of a machine. Why
do you already want to do it on the distribution level?

I'd either want the standard to move everything to /var/mail and
abandom /var/spool/mail or to keep with /var/spool/mail.

The move to /var/mail would take some time for the Linux community until
it is finished. The end result would be that (just like now with /var/mail)
some admins will add a link from /var/spool/mail to the new /var/mail to
be compatible with old Linux systems or DEC machines.

So the move to /var/mail will get us some confusion in the Linux community
and at the end we will have the same situation as now: some admins will
have to add a compatibility symlink. We achieved nothing...

Please think about it and stay with /var/spool/mail.

Florian La Roche

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

[Florian La Roche]

On Wed, Jan 20, 1999 at 10:18:07AM -0500, Erik Troan wrote:
> On 20 Jan 1999, Daniel Quinlan wrote:
> 
> >  1. totally revert, drop /var/mail, and specify /var/spool/mail
> >  2. partially revert, /var/spool/mail is a directory and /var/mail
> > must be a symbolic link to it
> >  3. allow a /var/spool/mail directory, provided that /var/mail is
> > a symbolic link to it
> >  4. allow either /var/spool/mail or /var/mail to be a directory,
> > provided that the other is a symbolic link to it.
> 
> Who will #1 affect? Does anyone use /var/mail?

If we allow both things to exist, then all distribution will have to
ship with a symlink from the other directory in the future.

If we just stay with /var/spool/mail, anyone can just add a symlink
from /var/mail, if there is a _local_ need to have this compatibility
with e.g. Solaris boxes.

I don't see any reason for a standardization project to move people
from having one standard dir to allow for two possible paths.
/var/spool/mail is the default path and any admin can symlink other
dirs to it or move it somewhere else.

If you want to move this dir and don't want to make a symlink from
/var/spool/mail to a new dir, you must do 2 things:
- the configuration from the prog who receives email and stores it on
  the local disk (e.g. /etc/sendmail.cf and the way it calls procmail)
- all MUAs should use the environment variable MAIL. So setting this in
  the login scripts (like e.g. /etc/profile) should be enough.
  (If not, the user prog is buggy and should be fixed. That shouldn't
  add much code anyway.)
So the mechanisms already allow for an easy change of the default
mail spool. Why should Linux then come with a default of already
2 different dirs?

Another point against having two dirs: Configure scripts often have
a list of directories they search for and use the first dir they find.
If you compile new progs and have /var/mail as a symlink to /var/spool/mail,
/var/mail gets hardcoded and you are never able to remove that symlink
again. That's the wrong direction to go.

Sorry for writing the same several times again. Since I have moved from
/var/spool/mail to /var/mail and back again, I know what's it like and
I know that having only one dir instead is more sane/clean than several
ones.

Florian La Roche

P.S.: I'd like Linux to move on with making things even more sane in the
  future. E.g. I liked Red Hats move to only have /usr/sbin/sendmail
  and no /usr/lib/sendmail. They need to go through all progs and see
  if they do search for /usr/sbin/sendmail correctly.
  I think this was done too early and I personally still like to have
  a symlink from /usr/lib/sendmail on my machines.
  I just want to use this example to show that Linux distributions can
  move people to even more clean and sane setups. Adding backwards
  compatible symlinks is easy. Going through all progs and fix them
  is work and I hope that standardization projects don't hinder such
  things. The FHS was very good for Linux, but we cannot stop and
  freeze everything now.

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

[Erik Troan]

On 20 Jan 1999, Daniel Quinlan wrote:

>  1. totally revert, drop /var/mail, and specify /var/spool/mail
>  2. partially revert, /var/spool/mail is a directory and /var/mail
> must be a symbolic link to it
>  3. allow a /var/spool/mail directory, provided that /var/mail is
> a symbolic link to it
>  4. allow either /var/spool/mail or /var/mail to be a directory,
> provided that the other is a symbolic link to it.

Who will #1 affect? Does anyone use /var/mail?

Erik

---
|   "For the next two hours, VH1 will be filled with foul-mouthed,|
|  crossdressing Australians. Viewer discretion is advised."  |
| |
|   Linux Application Development  --  http://www.redhat.com/~johnsonm/lad|

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

[Anthony Towns]

(on /var/mail vs /var/spool/mail)

On Wed, Jan 20, 1999 at 12:19:26AM -0800, H. Peter Anvin wrote:
> > Since this is "the objection that won't die", I'm currently
> > considering four "ways out" of the mess created by this change that
> > went into FHS 2.0.
> >  1. totally revert, drop /var/mail, and specify /var/spool/mail
> >  2. partially revert, /var/spool/mail is a directory and /var/mail
> > must be a symbolic link to it
> >  3. allow a /var/spool/mail directory, provided that /var/mail is
> > a symbolic link to it
> >  4. allow either /var/spool/mail or /var/mail to be a directory,
> > provided that the other is a symbolic link to it.
> I believe the FHS 2.0 change was right on target.  Just about every
> UNIX implementation today has moved away from /var/spool/mail to
> /var/mail, and it has technical advantages.

May I ask what these other technical advantages are? (it might be worth
adding them to the rationale section of the FHS HTML on Dan's site, too)

The debian-policy thread [0] in May/June last year basically said ``it's
a pain to convert, /var/spool isn't particularly inappropriate, especially
for POP and IMAP users'' and ``everyone else does it, therefore we must''.

Why not require /var/mail exist, but possibly be a symlink to a different
place if necessary? This will probably end up happening on a number of
user systems anyway and has the advantage that it's trivial to become FHS
compliant, code can still get #ifdef's removed, and everyone can be happy.

Cheers,
aj

[0] http://www.debian.org/Lists-Archives/debian-policy-9805/msg00174.html

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. PGP encrypted mail preferred.

``Like the ski resort of girls looking for husbands and husbands looking
  for girls, the situation is not as symmetrical as it might seem.''


pgpAko0DUzbZu.pgp
Description: PGP signature

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

[Theodore Y. Ts'o]

   From: "H. Peter Anvin" <[EMAIL PROTECTED]>
   Date: Wed, 20 Jan 1999 00:19:26 -0800 (PST)

   I believe the FHS 2.0 change was right on target.  Just about every
   UNIX implementation today has moved away from /var/spool/mail to
   /var/mail, and it has technical advantages.

   If anything, specify /var/spool/mail being a symlink to /var/mail.

I agree.  I also don't think it's a big deal.  What's important is that
all of the MUA's get compiled so that they look for the mail spool in
/var/mail.  If /var/mail is a symlink to /var/spool/mail, or /u3/mail,
or something else --- that's fine.

I don't think distributions are required to move the spool directory
around as part of an upgrade; just install a symlink!  And if the user
has established a symlink so that the mail spool is on some entirely
different partition (for example, /u3/mail), then it's just a matter of
establishing a new symlink in /var/mail to point to /u3/mail.

- Ted

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

[H. Peter Anvin]

> > I would *much* prefer this, I just didn't think I'd be able to win
> > the argument.
> 
> Since this is "the objection that won't die", I'm currently
> considering four "ways out" of the mess created by this change that
> went into FHS 2.0.
> 
>  1. totally revert, drop /var/mail, and specify /var/spool/mail
>  2. partially revert, /var/spool/mail is a directory and /var/mail
> must be a symbolic link to it
>  3. allow a /var/spool/mail directory, provided that /var/mail is
> a symbolic link to it
>  4. allow either /var/spool/mail or /var/mail to be a directory,
> provided that the other is a symbolic link to it.
> 
> I'm personally most in favor of #2 or #3.  I think #1 is almost as bad
> as the original change in FHS 2.0 and #4 is potentially confusing.  No
> matter what, FHS 2.1 will specify at least #3, if not one of the other
> possibilities.
> 
> And for each possibility _PATH_MAILDIR is changed to reflect the
> actual directory, not the symbolic link.
> 
> - Dan

I believe the FHS 2.0 change was right on target.  Just about every
UNIX implementation today has moved away from /var/spool/mail to
/var/mail, and it has technical advantages.

If anything, specify /var/spool/mail being a symlink to /var/mail.

-hpa

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

[Daniel Quinlan]

[ I added the FHS and debian-devel mailing lists to the Cc list, so
  a huge number of people are now being Cc'ed -- sorry. ]

Florian La Roche <[EMAIL PROTECTED]> writes:

>> So if there are no other bigger standards that would make it very
>> convenient to move all Linux-distributions to /var/mail and
>> abandon /var/spool/mail, I'd hope that /var/spool/mail will be
>> listed as de-facto-standard of Linux systems.

Erik Troan <[EMAIL PROTECTED]> writes:

> I would *much* prefer this, I just didn't think I'd be able to win
> the argument.

Since this is "the objection that won't die", I'm currently
considering four "ways out" of the mess created by this change that
went into FHS 2.0.

 1. totally revert, drop /var/mail, and specify /var/spool/mail
 2. partially revert, /var/spool/mail is a directory and /var/mail
must be a symbolic link to it
 3. allow a /var/spool/mail directory, provided that /var/mail is
a symbolic link to it
 4. allow either /var/spool/mail or /var/mail to be a directory,
provided that the other is a symbolic link to it.

I'm personally most in favor of #2 or #3.  I think #1 is almost as bad
as the original change in FHS 2.0 and #4 is potentially confusing.  No
matter what, FHS 2.1 will specify at least #3, if not one of the other
possibilities.

And for each possibility _PATH_MAILDIR is changed to reflect the
actual directory, not the symbolic link.

- Dan