[ On Monday, August 28, 2000 at 00:04:57 (-0600), Richard Stallman wrote: ]
> Subject: Re: HTML format documentation
>
> I think you are mixing two issues that ought to be separate.
>
> 1. Whether the program should make a special subdirectory to contain
> its config files.
>
> 2. Where the config files, or alternatively that subdirectory, should go.
Yes, you are right, I am lumping these things together, and perhaps they
should remain separate.
> I think it is fine if #1 is decided by the developer. I don't think
> it needs to be customizable.
Yes, I agree that a package-specific subdirectory for config files
should be specified by the developer -- however what I would like to
encourage developers to do in this case is to specify just the basename
for their configuration subdirectory and that the default parent path
for a relative directory be equal to what I've for the moment called
$(localconfdir).
> Meanwhile, --sysconfdir specifies #2.
Well, actually, this is partly where the confusion comes in (see below).
> So the only question is, should we change the default for --sysconfdir?
>
> I see the advantage of putting system configuration files in /etc.
> The question is, is there any screw in doing so?
People who have made assumptions about how packages install themselves
in order just so that they can do "unexpected" things might run into
trouble, but I'm not sure if people doing unexpected things should have
their needs catered to! :-)
The other major thing to take into consideration is of course whether or
not developers are going to be expected to install things directly into
$(sysconfdir) during "make install" or not and thus what to do to
satisfy the concerns of those who do not ever want to install anything
outside of $(prefix) [which includes myself!]. If packages are expected
to find their own configuration files in $(sysconfdir) then they have to
get there somehow and changing the default implies that developers would
have to be required to install only template configuration files
(presumably somewhere under within $(datadir)) and to optionally provide
a package enable script that could be used by an administrator without
the presence of the source distribution to install these template
configuration files.
There is one place where I forsee trouble, and I don't think it is
caused by anyone doing anything "unexpected" (I don't see the following
practice explicitly described in the Standards document, but it is
alluded to several times). If a developer uses $(sysconfdir) to both
refer to the location of configuration files owned by the system
(eg. /etc/inetd.conf) and the location of the package's own
configuration files, then it may not be so simple to just change the
setting of $(prefix) when installing in order to make a binary package.
This is in fact one of the other reasons why I think it is important to
separate the implied meaning of $(sysconfdir) [i.e. for "system" owned
native configuration files], and $(localconfdir), which would refer to
the configuration files accompanying the package. Consider the following
example where a package is configured to run in the standard place, but
then installed in a temporary directory where it can be used to create a
binary package:
./configure
make
mkdir $TMPDIR/foo-binary
make prefix=$TMPDIR/foo-binary install
cd $TMPDIR; tar -cvzf foo-binary.tar.gz foo-binary
If this package does as I've described above (i.e. refers to system
owned configuration files using $(sysconfdir)) then it may be critical
that $(sysconfdir) not include $(prefix), regardless of whether my newly
proposed $(localconfdir) does.
[[ Of course there are other factors which make this somewhat contrived
example a little unlikely, but I think it helps illustrate my point.... ]]
In fact I might even be happy to just rename $(sysconfdir) to
$(localconfdir). The only real use of a variable that would specify the
location of native configuration files would be to specify a location
other than "/etc" under the assumption that the native configuration
files being referred to had been supplanted by other add-on packages.
However this case is undoubtably better handled by explicit
--with-file=path settings since one cannot guarantee that all such files
have been relocated to the same place.
--
Greg A. Woods
+1 416 218-0098 VE3TCP <[EMAIL PROTECTED]> <robohack!woods>
Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]>
