Filesystem Hierarchy Standard (FHS) compliancy?

Dan Merillat harik at chaos.ao.net
Sat Aug 12 06:56:26 UTC 2000


> > And I find it ironic that /etc/<a>, /usr/lib/<a>, /usr/share/<a>,
> > etc is somehow considered "easier" than /usr/local/<a>/*.
> 
> I find nothing ironic about consistency.  That is the raison d'etre of
> the FHS.  I find nothing "easy" about dealing with [n] different
> software packages, and having [n] different directory hierarchies to
> remember.

Exactly how is /etc/<a> and /bin/<a> better then <a>/etc and <a>/bin?

For micro-installations, perhaps.  I find it convienient for crap I never
bother with to be FHS'ed. (/etc/ftp, /etc/samba, /etc/smail).  Then
I don't have to know anything about the package to find the configs.

Also, all those are PACKAGED things.  debian's inn package is FHS compliant,
as is redhat's.   They're also for drop-in-place low traffic newsservers.

If you're serious about usenet, you're going to be compiling the thing by
hand and not packaging it.  There's lots of source tweaking being done
by lots of admins of large sites to keep up with the 150gig/day flows.

> However, given that there seems to be very little (if any opposition)
> to the slight restructuring of /usr/local/news that is necessary in
> order to provide an easy way for an installer to choose to install
> with FHS conformity, it seems to be a mostly moot point anyway...

Check out the debian .diffs.  They scatter inn pretty liberally 
in the FHS conformant matter... /etc/news, /usr/include/inn, 
/usr/lib/news/bin, /usr/share/doc/inn, /usr/share/manx, /var/run/news
and /var/spool/news/{archive,articles,incoming,innfeed,outgoing,overview,uniover}
Whew.

Were I to try to upgrade that all by hand... Well, I wouldn't.  I'd purge
the package, and ./configure --prefix /news

FHS is nice if you're using a package.  Trying to update by hand?  Hah.
Trying to backup JUST my important news bits?  Fun.

--Dan



More information about the inn-workers mailing list