Filesystem Hierarchy Standard (FHS) compliancy?

[James Ralston]

On 16 Jan 2001, Russ Allbery wrote:

> Picking up an old thread....
>
> James Ralston <qralston+ml.inn-workers at andrew.cmu.edu> writes:
>
> > That is the main reason I brought this topic up--as INN currently
> > stands, you don't really have a choice to install following the
> > FHS to the letter.  Thankfully, there seems to be no opposition to
> > the minor modifications that will make it possible to install
> > following the FHS to the letter.
>
> Any progress on this?  Is there anything in particular that I should
> do to help the folks who want to work on this?  I really would like
> to see the modifications needed to install INN strictly conforming
> to the FHS be included so that each Linux distribution stops trying
> to do it themselves.

Doh, sorry; I've been sidetracked by other things and I've gotten
behind on my inn-workers mail.  I didn't see this message until
yesterday.

I am indeed working on this, as I need to upgrade from INN 2.2.2 to
INN 2.3.1, and I'm going to set up things for (optional) FHS
compliance.  When I'm done with that, I'll tweak the patches for the
CURRENT tree (it shouldn't take much effort) and send 'em in.

On 16 Jan 2001, Russ Allbery wrote:

> The ideal would be to make it a single configure option, something
> like --enable-fhs-compliance, so that one doesn't have to pass tons
> of separate options and so that everyone who uses FHS puts
> everything in the same place.

Well, for the distros that use RPM, recent verions of RPM encapsulate
the FHS-specific stuff in macros.  For example, if I have this in my a
spec file:

    %build
    %configure
    make

The %configure macro is expanded to:

    CFLAGS="${CFLAGS:-%optflags}" ; export CFLAGS ; \
    CXXFLAGS="${CXXFLAGS:-%optflags}" ; export CXXFLAGS ; \
    FFLAGS="${FFLAGS:-%optflags}" ; export FFLAGS ; \
    %{?__libtoolize:[ -f configure.in ] && %{__libtoolize} --copy --force} ; \
    ./configure %{_target_platform} \\\
            --prefix=%{_prefix} \\\
            --exec-prefix=%{_exec_prefix} \\\
            --bindir=%{_bindir} \\\
            --sbindir=%{_sbindir} \\\
            --sysconfdir=%{_sysconfdir} \\\
            --datadir=%{_datadir} \\\
            --includedir=%{_includedir} \\\
            --libdir=%{_libdir} \\\
            --libexecdir=%{_libexecdir} \\\
            --localstatedir=%{_localstatedir} \\\
            --sharedstatedir=%{_sharedstatedir} \\\
            --mandir=%{_mandir} \\\
            --infodir=%{_infodir}

The values of the various directories are taken from per-platform
macro files.  Under Red Hat 7.0, they are:

    %_prefix                /usr
    %_exec_prefix           %{_prefix}
    %_bindir                %{_exec_prefix}/bin
    %_sbindir               %{_exec_prefix}/sbin
    %_libexecdir            %{_exec_prefix}/libexec
    %_datadir               %{_prefix}/share
    %_sysconfdir            /etc
    %_sharedstatedir        %{_prefix}/com
    %_localstatedir         /var
    %_lib                   lib
    %_libdir                %{_exec_prefix}/%{_lib}
    %_includedir            %{_prefix}/include
    %_oldincludedir         /usr/include
    %_infodir               %{_prefix}/share/info
    %_mandir                %{_prefix}/share/man
    %_defaultdocdir         %{_usr}/share/doc

I'm not that familiar with Debian, but from what I've been able to
garner, they also seem to be moving towards using macros to
encapsulate configuration issues.

The tactic I plan to take is to put all of the directory information
above in configure, and have --enable-fhs-compliance cause configure
to build the default paths for things based on the FHS directories and
defaults instead of the existing defaults.  That way, someone building
an RPM can just use the %configure macro, which should do exactly the
right thing, and even without %configure, it should only be necessary
to tweak a single setting or two, as --enable-fhs-compliance should
get most of the values right to begin with...

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