Re: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0
- To: Kragen Sitaker <email@example.com>, "Theodore Y. Ts'o" <firstname.lastname@example.org>, email@example.com, Alan Cox <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, fhs-discuss@UCSD.Edu, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com
- Subject: Re: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0
- From: Ben Collins <firstname.lastname@example.org>
- Date: Tue, 26 Jan 1999 07:19:20 -0500
- Message-id: <19990126071920.B12453@visi.net>
- Mail-followup-to: Kragen Sitaker <email@example.com>, "Theodore Y. Ts'o" <firstname.lastname@example.org>, email@example.com, Alan Cox <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, fhs-discuss@UCSD.Edu, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com
- In-reply-to: <19990125223327.C10093@debian.org>
- References: <199901252309.SAA02711@dcl> <Pine.SUN.3.96.990125190541.1767Kfirstname.lastname@example.org> <19990125223327.C10093@debian.org>
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?
<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 we could prove our willingess and ability to ensure these uniformities.
<marketing b/s boots off>
> 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@example.com> Debian GNU/Linux
UnixGroup Admin - Jordan Systems Inc. firstname.lastname@example.org
------ -- ----- - - ------- ------- -- The Choice of the GNU Generation