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

[Manoj Srivastava <srivasta@golden-gryphon.com>]

Hi,
>>"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
 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     <srivasta@acm.org>    <http://www.golden-gryphon.com/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E