Re: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0
- To: email@example.com, "Theodore Y Ts'o" <tytso@MIT.EDU>
- Cc: Alan Cox <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org
- Subject: Re: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0
- From: Manoj Srivastava <email@example.com>
- Date: 26 Jan 1999 10:22:07 -0600
- Message-id: <firstname.lastname@example.org>
- References: <199901252309.SAA02711@dcl>
>>"Ted" == Theodore Y Ts'o <tytso@MIT.EDU> 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
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.
+#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@example.com> <http://www.golden-gryphon.com/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E