[ On Saturday, August 26, 2000 at 03:42:58 (-0600), Richard Stallman wrote: ]
> Subject: Re: HTML format documentation
>
> Which reminds me: $(sysconfdir) should never include $(prefix). If
> there's a common need for a configuration directory under $(prefix) then
> it should be represented by $(localconfdir) or some similarly named
> variable.
>
> This is a question I would like people to discuss more
> so we can figure out what to do.
I should probably elaborate on the motivation I have for suggesting the
above. It relates to my desire to eliminate /usr/local on systems where
I have packaging tools to keep track of stuff I've added to a system.
I've already done this rather successfully on NetBSD with their "pkgsrc"
system. In doing so though I didn't want to confuse the users I was
creating these systems for, so I really did want all configuration files
to be in /etc (and those users are extremely happy with the resulting
fully integrated systems since they no longer have to remember where to
look for some given configuration file). For those packages configured
with GNU Autoconf I did this by simply saying "--prefix=/usr" when
configuring them (actually "pkgsrc" did this for me because it has a
similar configuration item that deals with all types of packages, and it
simply passes this value on to packages using Autoconf with --prefix).
However this meant I was either faced with creating a symlink to point
"/usr/etc -> ../etc", or patching all Autoconf'ed packages so that they
did as I suggested above and did not include $(prefix) in $(sysconfdir).
After considering just how many patches I would have to create, I
settled on the first option. I'm not really happy with the symlink
choice though because it is not only a bit ugly and potentially less
efficient, but it also means that the package binaries believe that by
default their configuration files are in /usr/etc and as a result if the
symlink is accidentally damaged these packages will fail to work.
If there had been a separate "--localconfdir" choice I would have been
able to decide, on a per-package basis without having to patch it,
whether or not I wanted it to live under /usr, or /etc, or wherever.
For example I would want configuration files for a web server to be in a
unique subdirectory, and whether or not they would best go in /etc/httpd
or /usr/local/httpd/conf or even /usr/local/etc/httpd would depend on
local system policies. I'd choose /etc/httpd for most systems,
especially those without /usr/local of course, but I might want to use
/usr/local/httpd/conf for those with /usr/local where the users were
accustomed to finding all files related to a package within a unique
"top-level" (i.e. immediately within $(prefix)) subdirectory.
Note that I would expect packages only to use $(localconfdir) if they
really did want to create a new unique sub-directory in which to store
their configuration files, such as when a package has multiple such
files; and by default packages would continue to use $(sysconfdir). I
would also suggest that $(localconfdir) default to having the value
"$(sysconfdir)/$(package)". I think it is good to encourage people to
keep all of their configuration files, including those for add-on
packages, in one common place on the system.
Obviously packages using $(localconfdir) should still try to use unique
names that would not likely collide with those from other packages, and
particularly not with system files in order not to cause problems for
users who still want to set "--localconfdir=/etc" for whatever reason.
For example a package should never use the name "hosts" for a
configuration file that is not the standard system /etc/hosts file.
Even if I were to actually build a system without a separate /usr
hierarchy, where I'd want "--prefix=/", it still doesn't really make
sense to me that one would include $(prefix) as a part of $(sysconfdir).
--
Greg A. Woods
+1 416 218-0098 VE3TCP <[EMAIL PROTECTED]> <robohack!woods>
Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]>
