No subject

directories are needed, to be able to handle these cases:

    1.  A directory path is computed by using some other configurable
        directory as a prefix, and the computed directory path does
        not conform to the FHS.

    2.  A single directory path contains multiple files/programs that
        should be in separate directories under the FHS.

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
only way to achieve that is to set PATHBIN to /usr/lib/inn, which is
definitely not the most appropriate location.

An example of situation #2 is LIBDIR, which winds up containing
static/shared libraries (libinn and libstorage), as well as
innreport_inn.pm, innshellvars*, and docheckgroups.  All non-libraries
should be in some other directory (or directories).

Provided that any new configurable directories inherit the same values
as they currently have if they aren't explicitly set (either by hand,
or with the option that enables FHS compliance), and that the creation
of new configurable directories is kept to the minimum required to
enable a --with-fhs-compliance option to work properly, do we care if
more configurable directories are created?

> > That way, someone building an RPM can just use the %configure
> > macro, which should do exactly the right thing,
>
> I think this will be hard to do, since the %configure macro isn't
> going to know about our other directories that don't fit neatly into
> the list of directories in a typical autoconf project.  The db files
> and the article spool in particular don't map to any of the standard
> autoconf options.

This is true, but the values %configure uses can be overriden by the
--with-fhs-compliance option.  Realistically speaking, at least for
RPM-based vendors, I suspect most of them will wind up doing this:

%configure --with-fhs-compliance \
  --with-blah-dir=foo \
  --with-blaz-dir=bar \
  ...

The --with-fhs-compliance will (whenever possible) inherit the FHS
values which %configure will supply, and then the vendor can override
certain expansions of --with-fhs-compliance in the cases where what
they ship disagrees with the FHS...

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