dnscache-conf, etc.

In an old thread on this or the dns list that I can't find now, the
issue was raised of what path should be embedded into configurations
produced by tools like dnscache-conf.  If they use the versioned path,
the configuration will break after the package is upgraded and the old
version is removed, which is bad for production configurations.  If
they use the non-versioned path, you can't test the configuration
without changing the current-version symlink, which risks breaking the
production service.

I think the best thing to do is to have the -conf tool set up a
symlink in the configuration directory pointing to the package
directory.  Scripts, etc., in the configuration that refer to files in
the package can do so by way of the symlink.  A configuration created
to test a particular version of the package will have its symlink
pointing to the versioned path.  A production configuration will have
its symlink pointing to the non-versioned path.  Then the only
question left is which path the symlink should point to initially.
But since it will be easy to fix it afterwards, I don't think that's
very important.

This is a special case of the general rule I try to work by: a package
(in this case, a configuration) that refers to another package should
do so by way of a symlink in its own directory.  This allows for
maximum flexibility, since the notion of the "current version" of the
referred-to package need not be systemwide.  If A and B both use C,
but they require different versions of C, they can still both work
simultaneously.


paul