We should reconsider the effect of updating on configuration.
We recently had a problem: VDT 1.6.1k updated the Graita probes but the
"pacman -update" operation didn't preserve the configuration of the
probes. We amended our documentation to tell people how to preserve the
configuration by hand (copy the configuration files before the update,
copy them back afterwards), and we told people how to fix their broken
configuration if they had already done the update.
This rightfully upset the Gratia developers when we stopped getting data
from more than 50 sites. They would like to make sure this problem never
happens again.
This ticket has two possible goals: we need to discuss and figure out
what our goal is. (And maybe create more tickets to address them.)
Possible Goal 1: Fix the Gratia Probes so that updates are safe.
Possible Solution for Goal 1, from Chris Green:
>I think the best long term way forward is to have the probes install
>with ProbeConfig.vdtnew and urCollector.conf.vdtnew; and have
>configure_gratia configure the .vdtnew version and *only* copy it to
>the default location if it doesn't already exist.
Possible Goal 2: Figure out a more general fix. As Chris pointed out to
me, "In RPM, it's simple: %config(noreplace)". No immediately obvious,
simple, general fix occurs to me.
Thought: could our package lists someone be capable of marking a file as
a configuration file that shouldn't be replaced? vdt-uninstall wouldn't
remove it, and pacman -remove would fail to remove it. I'm not sure what
would happen on the update though, since the probes currently include
the configuration file: would it just get overridden? Hmmm... my thought
is not fully thought out.
RT for crt.cs.wisc.edu
