Filesystem Hierarchy Standard patch

James Ralston qralston+ml.inn-workers at andrew.cmu.edu
Sat Apr 7 09:31:31 UTC 2001


On Sat, 7 Apr 2001, Marco d'Itri wrote:

> FHS 2.2, paragraph 5.1:
>
> > Applications must generally not add directories to the top level
> > of /var.  Such directories should only be added if they have some
> > system-wide implication, and in consultation with the FHS mailing
> > list.

Whoops, you're right... for some reason, I thought the recent
discussion on the fhs list was leaning *away* from that restriction,
but I just checked the FHS 2.2 beta, and it's still there.  Thanks for
catching that; I've updated my patch accordingly:

    http://www.andrew.cmu.edu/user/qralston/inn/

> Since I remember using INN on linux, distributions installed inn
> files in /{etc,var,lib,spool}/news, which are perfectly good names.
> I wonder why you propose to break current systems and traditional
> paths.

Whether certain subdirectories are called "inn" or "news" is arbitrary
to a certain degree.  Also, the location of the subdirectory itself
matters.  In /usr/lib, subdirectory names are usually chosen based on
the name of the package, not on the type of service or service name.
But in, say, /var/log, or /var/run, subdirectories are usually named
after the type of service or service name.

I thought that /etc/inn was a more appropriate FHS default than
/etc/news; similarly for /usr/lib/inn versus /usr/lib/news.  However,
I'm flexible on that; if the consensus here is that it would be better
to use "news" for subdirectory names everywhere, we can change the
defaults accordingly.  We could also go ask the FHS list for
advice--it might distract them from their (seemingly endless)
discussion of where mount points for removable media should be placed.
;)

(Note that there might be a /usr/include/inn subdirectory someday, so
trying to stamp out "inn" just to make the subdirectory names
consistent might be doomed to eventual failure anyway.)

> Well, I suppose sane distributions are just going to ignore your
> patch.

Package builders can customize to their heart's content; any
--with-*-dir options specified after --with-fhs-dirs will override the
defaults that --with-fhs-dirs picks.  I wanted to provide maximum
flexibility to package builders, but at the same time provide a simple
mechanism to get reasonable FHS defaults.

> I think this patch should not be committed because it diverges from
> long estabilished traditions

I think a more appropriate course of action would be to commit the
patch, and then quibble over the exact directory locations afterwards.
As I already stated, I'm open to suggestions on that front.  (Besides,
I'd like to see the corrected DESTDIR handling make it into at least
CURRENT and perhaps even STABLE, because the current handling *is* a
bug, as far as I can tell.)

> and makes wrong (read as: directly in violation of FHS) choices
> about most files locations.

I corrected /var/inn (to /var/lib/inn).  I didn't spot any other
violations--what other violations are you referring to?

-- 
James Ralston, Information Technology
Software Engineering Institute
Carnegie Mellon University, Pittsburgh, PA, USA



More information about the inn-workers mailing list