I wrote:
> I believe the conclusion you'll come to is that libc should parse the
> nsswitch.conf file at startup time and not make use of a db file.

Peter wrote:
> I reach the conclusion that many other databases used by libc needs
> updating. Perhaps a standard method for handling these would be
> beneficial?

That would certainly be better than gradually adding more and more
code for each configuration file.  But since people don't reach the
same conclusion as I do after looking at libc, I'd like to make the
following arguments (this is really a response to Luke's most recent
message, which I deleted too hastily):

	* If you're concerned about speed, turning a small
	  configuration file into a db file probably won't help you
	  any.  Caching the file contents in memory is a much better
	  answer.

	  Note that the existing configuration files which use
	  database files (/etc/aliases and /etc/master.passwd come to
	  mind) are actually system databases which are expected to
	  grow very large on some systems.

	* If you're concerned about having to restart a daemon in
	  order to make a configuration file change happen, consider
	  that libc can't prevent this from being necessary.  The
	  daemon may have cached any amount of information about the
	  system in application data (the hostname, the port for the
	  "telnet" service, the passwd entry for "root" and half a
	  dozen users, etc.), and libc can't do anything about that.

	  Thus it seems questionable to me that you want to add a lot
	  of complexity to libc without solving the problem.  In
	  general, when you want to change your system's parameters at
	  a low level (your hostname, the resolvers in
	  /etc/resolv.conf, group membership, etc.), you don't expect
	  all running processes to pick up those changes.

	* If you're concerned about getting partial data while editing
	  a configuration file, then libc isn't really equipped to
	  handle the situation alone.  Currently the local filesystem
	  passwd database is the only libc configuration file which
	  tries to handle changes in a robust manner (although its
	  locking discipline is broken), and it uses a separate
	  command to guarantee atomic update of the file (as well as
	  to regenerate its database files).

	  Clearly this kind of makeshift solution can't go on until we
	  have "newaliases" and "vipw" variants for everything from
	  /etc/group to /etc/motd.  It's not clear to me that we
	  really need to address this problem, but if we do, then we
	  should either:

		- Modify vi and ed to do atomic updates, emacs-style,
		  with the corresponding risk of leaving temporary
		  files in random directories.

		- Write a generic configuration file editor which is
		  also equipped to recognize the need for and generate
		  database files, following some convention (which the
		  passwd database would almost certainly not conform
		  to, sadly).