[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

> > 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 rather disappointing as far as I'm concerned.
> 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
> I have no problem with a "both paths must one work one or more may be a
> symlink". At that point however the FHS should mandate one which may be a
> symlink only. Right now everyone uses /var/spool/mail whats the technical
> reason for using /var/mail that is good enough to justify the change ?

Okay... to summary what I have seen (this being the third time that this
list has gone over the /var/mail vs /var/spool/mail issue.)

Technical reasons for making the change;

a.  Compatibility with the majority of existing unix systems.

b.  See a.  It can not be stressed enough.  If FHS is ever to get OUT
    of the Linux camp it's going to have to cause Linux to look more
    like other unix systems and less like Linux.

c.  Removal of the special case for Linux in many public domain/freeware
    software, though this should already be handled via paths.h if the
    application is written with portability considerations.

d.  BSD based systems basically made this same change over 15 years
    ago.  It was no real big deal.  /usr/spool -> /var/spool, then
    2 releases later /var/spool/mail -> /var/mail.  [If my grey matter
    is recalling history correctly, it was 4.2BSD on the first move and
    some place close to 4.3Tahoe on the second.

Thats it, not a lot of reasons, but IMHO it's A and B that are the real
justifiable reasons.

Rod Grimes - KD7CAX - (RWG25)                   rgrimes@gndrsh.aac.dev.com
Accurate Automation, Inc.                   Reliable computers for FreeBSD

Reply to: