[ On , August 27, 2000 at 01:26:36 (-0300), Alexandre Oliva wrote: ]
> Subject: Re: HTML format documentation
>
> On Aug 26, 2000, [EMAIL PROTECTED] (Greg A. Woods) wrote:
>
> > In any case if "sysconfdir" means what it says, i.e. "system
> > configuration directory",
>
> Only if you think of a system as a host. I think of a system as a
> set of hosts on which the same set of policies apply.
That's totally irrelevant. (Though I will point out tha the current
standards.texi document I have says in fact the opposite of what you
say: "The directory for installing read-only data files that pertain to
a single machine-that is to say, files for configuring a host.")
Whether the system is one, or many related, hosts the use of the word
"system" in the variable name clearly implies that ownership -- i.e. it
is normally read as "the system's configuration directory". Since by
implication anything configured with Autoconf is an add-on package, this
implies that $(sysconfdir) is where the native system's configuration
files are normally found.
All I'm "arguing" about is that $(sysconfdir) should explicitly refer to
the location of the systems' native configuration files, and not the
location of any similar files that are installed by the package
(i.e. the use of the phrase "for installing" and the default inclusion
of the unexpanded value "$(prefix)" in its makeup). I am saying that
those files installed by the package should be in a directory referred
to with the make variable $(localconfdir), if that is appropriate for
the given package and the number and types of configuratio files it may
have -- i.e. they are in a directory which is "local" to the application
(the overloaded use of the word "local" is unfortunate -- in this case I
do not mean "/usr/local"). It might be within $(prefix), but I'm still
not convinced that would be the best place.
> In this case, a
> shared configuration directory is precisely The Right Thing (TM).
Again mostly irrelevant (though of course whether or not it's a shared
diretory is a separate, site-local or system-local, policy decision).
(i.e. as above a "system" is indeed just a "host" and what you do with
multiple hosts is your private business as their administrator and not
something dictated by the GNU Coding Standards.)
I will however continue to point out that there is a very large segment
of the population of system administrators who strongly feel that all
configuration files, add-on or native, should all be in one place, and
they usually point to the system directory "/etc" as that one place.
For the purposes of reliability and security I firmly assert that the
only proper way to share commonalities amongst any configuration files
on multiple systems is to use some sort of periodic update mechanism
that is not in the critical path to correct system operation. (I.e. NFS
and similar schemes are definitely not appropriate, probably not even
when the systems in question are diskless and are already using NFS to
access all of their files!) There is also the very important
considation of making the administrator's job easier and thus less error
prone and frustrating. To this end it's definitely preferred to have
similar and related configuration items kept together and to have all
configuration files (native and add-on) in one common and none-too-deep
hierarchy under /etc.
In any case this is still mostly irrelevant to the topic at hand. The
only part that I feel is relevant is that which affects how "we" choose
the default setting for $(localconfdir). Here are the choices I
propose, in my preferred order, best first, with package specific
optional parts in square brackets:
/etc[/$(package)]
$(prefix)/etc[/$(package)] or $(prefix)/$(package)[/conf]
I put them in this order because IMNSHO it's a good thing for a document
like the GNU Coding Standards to take a stand on suggesting good and
safe system management techniques and to make it "easy" for people to
employ such techniques. I.e. I think it would be bad for Standards to
even mention the possibility of using NFS for sharing configuration
files.
> > then it must default to /etc (i.e. without $(prefix) prepended) on
> > any unix or unix-like system that I know of.
>
> Installing anything outside $(prefix) is wrong, unless explicitly
> requested by the user.
Ah, but I don't think I said "install" anywhere, and I definitely didn't
preclude the use of something like $(localconfdir) which *could*, if
everyone else insists, contain as part of its default makeup the
unexpanded value "$(prefix)" (so that packages which insist on directly
installing their sample configuration files in their "live" location can
do so with this variable).
There is no one correct way to deal with change management of live
configuration files -- the "right" way very much depends on site or
system policy. However I believe any policy it is best facilitated by
using a per-application management program (script, whatever) that will
help install and enable sample configuration files and related items for
any given instance (i.e. installed release) of a package, and which will
be available for execution well after the package itself has been
installed (along with perhaps a deactivation script, both of which can
be run many times over).
> I'd say it's ok to install something in
> $(sysconfdir) = $(prefix)/etc and look for it at run-time in
> $(localsysconfdir) = /etc, as long as some option is given to the user
> to override $(localsysconfdir), at configure time and/or at run time.
now that interpretation is certain to *totally* confuse almost everyone!!!!
(Besides most packages, as well as perhaps even some parts of the Coding
Standards, still need more roto-tilling until they can safely totally
separate the concepts of "installed in" and "searched in at run-time".
Even the rule that says one should be permitted to change $(prefix) on
the "make" command-line without reconfiguring is not always 100%
properly implemented.)
--
Greg A. Woods
+1 416 218-0098 VE3TCP <[EMAIL PROTECTED]> <robohack!woods>
Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]>
