Re: FHS

[Russ Allbery]

Guido Draheim <address@hidden> writes:

> The other mode is of course a system-install, and in that mode you want
> to ensure that the /usr-filesys can be mounted readonly, that the basic
> configurations-files go under /etc and can be saved away in one go, and
> localstate and pooldir-paths go to the /var-filesys, so as an essence,
> in system-mode, a prefix like /my/prefix will make the config-files go
> to /etc/my/prefix instead of /my/prefix/etc which would be correct for a
> local-install.

The vast majority of software installations by system administrators from
source do not go into /usr, /etc, or anything else owned by the system.
They go into /usr/local, /opt, or some other local path.  /usr and the
like are reserved for the system and its own packaging system.

It's always worth remembering that while catering to GNU/Linux packagers
is important, they're a very small minority of the users of Autoconf-using
packages.

Personally, I'm somewhat annoyed to see yet more paths going into Autoconf
that I'll then have to override to get the installation paths that I want
(namely a flat tree of bin, sbin, lib, man, info, and etc); with over five
hundred packages installed that way and using automated tools to maintain
Stanford's shared software tree, I have no intention at the present time
of changing our package layout.  But I suppose I can always continue to
override all the individual paths like I already have to do for
sharedstatedir, libexecdir, and datadir.  (Of course, GNU gettext has a
habit of blissfully ignoring the datadir setting given at configure time
in favor of hard-coding share.  And I'm not sure anything actually uses
sharedstatedir and libexecdir except Emacs.)

Changes towards stricter FHS compliance do make things harder for those of
us who developed our file system layouts long before people started
fiddling with things like share and libexec and don't want to go through
the pain of trying to change them.

-- 
Russ Allbery (address@hidden)             <http://www.eyrie.org/~eagle/>