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
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
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
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
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
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
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
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
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
Most Mail User Agents for standard Unix systems look in /var/mail/user
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
On Tue, 26 Jan 1999, Theodore Y. Ts'o wrote:
Most Mail User Agents for standard Unix systems look in /var/mail/user
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
In article [EMAIL PROTECTED] you write:
Most Mail User Agents for standard Unix systems look in /var/mail/user
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
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/user
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
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
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
]; [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
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.,
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
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
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
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
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
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
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
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
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,
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
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
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
On Tue, Jan 26, 1999 at 07:19:20AM -0500, Ben Collins wrote:
marketing b/s boots on
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
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:\
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,
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
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
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,
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
[ 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
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
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,
(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
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
58 matches
Mail list logo
