Re: /var/mail back to /var/spool/mail
Manoj Srivastava writes:
>
> I have a technical reason for wanting mail in /var/spool as
> well. I have things in /var/spool that tend to grow to huge sizes (as
> does /var/log, but I live with that).
>
> I genrally have /var/spool on a separate partition, and
> generally have different policies for /var/spool that I do for /var
> in general (I have news, mirrors, and mail -- the major uncontrolled
> external data feeds feed into /var/spool/ partition).
>
> Personally, I am inclined to have /var/spool/log and have all
> my unknown data size stuff be in the /var/spool partition, but I know
> that is unlikely to fly.
Please correct me if I'm wrong, but as I understood it, the FHS was
directed at distribution maintainers/integrators, so as to help them
turn out a coherent distribution, compatible with industry practice,
and also at application maintainers, so as to help them turn out an
application that drops cleanly in to any distribution (or more
ambitiously, any variant of Unix-like OS). I was also under the
impression that it was not meant as gospel for individual site or
system administrators.
Just as users tweak their user environment so as to better meet their
needs, we expect syadmins to tweak the setup of the boxes they
administrate so as to better meet their needs. And I (at least, I
hope many on the list feel the same) expect that frequently this will
bend or even break FHS recommendations. That's fine -- it's on a per
site basis. It's the local syadmin's prerogative to change whatever
they want and their job to make sure nothing breaks because of it.
If it makes sense for your site to store logs in /var/spool/log and
you want to make a symlink /var/log -> spool/log , then that's great.
It's your box, do whatever is most practical for you.
As I see it, what we're trying to do here is influence, over time, the
direction distributions and applications are going in terms of file
location, and most definitely not mandate an overnight change for all
installed sites.
I just hate getting mired down in these "it doesn't work for my site"
arguments. No one layout is going to be best for every site. We want
a happy medium, a least-squares minimization of all the problems that
could crop up in all the myriad individual installation situations, if
you will. This makes for the aggregate least effort to customize out
the local problems or desires of each individual site.
This doesn't mean "it doesn't work for my site" is an entirely invalid
post. Obviously, if everyone with a FHS-compliant system were to say
that on one particular topic, then we've chosen the wrong solution.
But a handful of "it doesn't work for my site"s does not an argument
make in and of itself.
Don't stress so much over changing your system setup right now. Relax.
Have a virtual beer. When you upgrade to a newer distribution, or a
newer version of the relevant software package, and the newer version
happens to follow a more recent FHS recommendation that's different
than the previous version, just change then, while you're monkeying
with the system anyway. Or not. Or just customize around it to make
your old setup work with the new software. It's your site; do what you
want to do.
If I'm way out in left field here, folks, please end the inning and
bring me back to the dugout.
---------------------------------------------------------------------------
Carl Miller (chaz@devastator.extern.ucsd.edu)
Software/Firmware Engineer
System Design Group
9530 Padgett Street, Suite 109
San Diego, CA 92126
--
To UNSUBSCRIBE, email to debian-policy-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: