>
> 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 h
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 p
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 n
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 referenc
> 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
> > 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
> > "N
MTP:[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 PROT
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 automatica
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 PROTECTE
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
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
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 p
> 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
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
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 g
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
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
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
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 ou
> 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/spoo
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 al
> 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 wor
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 distributio
> 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/
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
> > reach
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 hear
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
> 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
> 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 pa
> 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 rat
> 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 dir
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.
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 p
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 o
> >> 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
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
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. Al
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
---
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 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 r
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, SuS
> 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
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?
>
> Ther
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
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 re
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 prob
> 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
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
> > 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 t
> > 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 don
> 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
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 /va
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
(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, a
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, sp
> > 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 /
[ 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/mai
58 matches
Mail list logo