Re: dnscache-conf, etc.

On Wed, 2002-08-14 at 22:18, Paul Jarc wrote:
> 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

Yes, it is bad.

> they use the non-versioned path, you can't test the configuration
> without changing the current-version symlink, which risks breaking the
> production service.

Why can't you test?  Maybe your problem is to restore the old package if
the new one breaks.  Maybe you can be happy with a new (normally down)
service with version-specific configuration.  OTOH don't run not tested
configurations on production host.

Maybe just I can't see the point.  Please write some scenarios.

> 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.

I think the package should know where the configuration is, not vice
versa.  My -conf utils know this.

> 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.

Use $PATH:

PATH=/package/xy/software-1.0/command:$PATH
export PATH

/package/xy/software-1.0/command/program should know where it's
configuration is located. My packages know this.
-- 
jul

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD4DBQA9Zmdh5jpN5TwhhtoRAgVhAJ4/MN7Bxf0nWwPyuQPgQKig+Os9HACYiIpf
9BynoY4h5FxPJePokHKLMg==
=Byi1
-----END PGP SIGNATURE-----