Filesystem Hierarchy Standard (FHS) compliancy?

James Ralston qralston+ml.inn-workers at
Wed Mar 21 09:02:49 UTC 2001

On Wed, 21 Mar 2001, Marco d'Itri wrote:

> On Mar 20, James Ralston <qralston+ml.inn-workers at>
> wrote:
> > An example of situation #1 is PATHBIN and PATHAUTH.  Currently,
> > PATHAUTH is automatically defined as "$(PATHBIN)/auth".  Under the
> > FHS, PATHAUTH should most appropriately be /usr/lib/inn/auth, but
> > the
> I don't think there is any real difference between
> /usr/lib/news/auth and the current /usr/lib/news/bin/auth .

Probably not.  But if PATHBIN has /usr/lib as a prefix, then it cannot
contain binaries that are meant to be executed directly, and the main
point of PATHBIN seems to be to contain such binaries.

To me, it seems a lot more intuitive to map PATHBIN to a real "binary"
directory (such as /usr/sbin) and relocate PATHAUTH and other
subdirectories, than to place PATHBIN in the wrong place (according to
the FHS) just to avoid splitting off the subdirectories.

> > An example of situation #2 is LIBDIR, which winds up containing
> > static/shared libraries (libinn and libstorage), as well as
> >, innshellvars*, and docheckgroups.  All
> > non-libraries should be in some other directory (or directories).
> I don't agree. static libraries should be moved by the distribution
> package-building script to /usr/lib

I strongly disagree.  It shouldn't be the responsibility of the person
building the package to move things around after the "make install"
step.  If this is necessary, it means that the package lacks the
ability to be adequately and reasonably customized.

> and the other files should go to /usr/lib/news.  But keeping
> everything in the same directory is an acceptable solution too.

Not according to the FHS.  Shared and static libraries go into
/usr/lib; a file which is not a shared or static library should not go
into /usr/lib.  As it currently stands, it is impossible to define
LIBDIR so that both of these stipulations are met.

More generally speaking, keep in mind that these are only two
examples.  There will be more situations like this.  If your answer to
my question of "Do we care if more configurable directories are
created?" is "yes", then please just say so, rather than trying to
invalidate my assertion that more configurable directories are needed
by invalidating each example I provide.

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

More information about the inn-workers mailing list