Re: dnscache-conf, etc.

Balazs Nagy <[email protected]> wrote:
> On Wed, 2002-08-14 at 22:18, Paul Jarc wrote:
>> If [automatically generated configurations] use the non-versioned
>> path [to the package], you can't test the configuration without
>> changing the current-version symlink, which risks breaking the
>> production service.
>
> Why can't you test?

I can test the configuration, but only using the current version of
the package.  If I change the current-version symlink so I can test
the new version of the package, it will affect the production
configuration as well.

> Maybe your problem is to restore the old package if the new one
> breaks.

No, that's easy: just change the current-version symlink to point back
at the old version.  My problem is that I want to be able to test the
new version of a package without interfering with the production
configuration; then after testing, I want to update the
current-version symlink, and I want the production service to start
using the new version without needing any further modifications.

The production configuration must therefore refer to the package via
the current-version symlink, but the testing configuration must refer
to it via an explicitly versioned name, in order to test that version
while it is not the current version.

> Maybe you can be happy with a new (normally down) service with
> version-specific configuration.

Yes, but then how will we produce such a configuration?  If a tool
like dnscache-conf puts the literal package path in lots of places,
then it's easy to make a mistake when changing it to use a different
path.  If instead all references are made via a symlink, I can just
update the symlink.

> OTOH don't run not tested configurations on production host.

This is an unreasonable limitation.  There's no reason we shouldn't be
able to run multiple configurations simultaneously that don't interfere
with each other.

> I think the package should know where the configuration is, not vice
> versa.

For package-wide configuration, yes.  But service directories are not
package-wide; there can be multiple service directories for the same
package, and there's no reason to force them all to use the same
version of the package.  The service directory is the "caller"; the
package is the "callee".  The caller must know where the callee is;
the callee need not know where the caller is.

>> 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.
...
> Use $PATH:

That doesn't work for files other than programs.


paul