Re: RH tools and conf changes (was: Re: Vi backspace key problem)

[Dag Wieers <dag wieers com>]

On Thu, 21 Jul 2005, Chester R. Hosey wrote:

> On Thu, 2005-07-21 at 19:42 +0200, Dag Wieers wrote:
> > On Thu, 21 Jul 2005, Chester R. Hosey wrote:
> > 
> > > On Thu, 2005-07-21 at 18:30 +0200, Dag Wieers wrote:
> > > As I see it, overwriting custom configuration is something that a tool
> > > should warn you about, even after the fact. RPM isn't meant to be
> > > informative or interactive? Fine! Roll it into a RHN somehow. It's a
> > > reasonable feature to ask for. If it weren't reasonable that you might
> > > expect automated notification of potential breakages, why did you ever
> > > envision a tool that would look for evidence of exactly this situation?
> > 
> > When the system overwrites a configuration file it often is ok :) It's the 
> > times it doesn't that are most likely the scary ones. But not all of them.
> > 
> > And that's the real problem, how to filter the signal from the noise. 
> > Packages need extra metadata for that and it's an afwul lot of manual work 
> > if you want to do it correctly.
> > 
> > If you'd require that extra work from me, I'd drop packaging instantly. 
> > And so will many others, I'm sure.
> 
> So if I'm reading into this correctly, RPM doesn't care at all whether
> the configuration file was changed from the previous original -- it just
> overwrites it regardless.

No depending on how the packager flags the configuration file and whether 
the configuration file has changed, it may or may not replace the file.

If you end up with an .rpmnew file it has NOT replaced the file, if you 
end up with a .rpmsave file it has replaced it. The correct logic is 
described in the Maximum RPM documentation if you care.


> Then my expectations of implementation ease are assuming functionality
> that RPM doesn't have, and that's why you're telling me that it would be
> difficult to determine when to send notification?
> 
> Is that correct?

The problem is that what you expect is not why something happens. Sure you 
can have RPM mail something whenever it replaces (or does not replace) a 
configuration file. But does it matter in that cases to notify the 
sysadmin ? In most cases it might not, but only the sysadmin knows.

In the end, if I have to implement something like this for you in a 
guaranteed environment, I would let RPM send out a mail everytime an 
upgrade happens as this will cover all cases where it might be important 
:) And you will agree that this was not your intention.


> Ouch. I'm further disappointed by RPM -- I'd assumed it tracked by
> modification date, MD5 sum, or SOMEHOW. My assumptions have led me to
> improper assumptions.

It does track by modification date and md5sum, but that does not have the 
knowledge about what the sysadmin wants or when it matters. Again, you 
could have a mail send out whenever a file is and is not replaced, but 
you'll have so many false negatives and false positives that it equals to 
'check your upgraded services after every upgrade'.

It could be improved with a _lot_ of manual work, tracking changes, adding 
some sort of changelog as Ed indicated, but in the end the work it 
requires will not live up to the expectations and will be massive.

If you're disappointed in all this, go design and implement something that 
works like you think it should and prove me wrong :)

Kind regards,
--   dag wieers,  dag wieers com,  http://dag.wieers.com/   --
[all I want is a warm bed and a kind word and unlimited power]