Guido Draheim <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
