Re: RH tools and conf changes

["Chester R. Hosey" <Chester Hosey gianteagle com>]

On Fri, 2005-07-22 at 11:00 +0200, Dag Wieers wrote:
> On Fri, 22 Jul 2005, John Summerfied wrote:
> 
> > Dag Wieers wrote:
> > 
> > Clearly, if a package has no configuration file, there's nothing to say.
> > 
> > If a package upgrade replaces unaltered configuration files, there's probably
> > nothing to say (but there might be some exceptions).
> > 
> > If an upgraded package has configuration files which a user has updated, but a
> > new configuration file is the same as the original unaltered file, there's
> > probably nothing to say about that configuration file (but again, there may be
> > exceptions).
> 
> In all these cases RPM will not create .rpmsave or .rpmnew files.
> 
> 
> > Now, if a new configuration is different from an earlier one because comments
> > have been changed or reformatted, that's a little tricker but it's still not
> > hard to spot material differences in may cases.
> 
> Sure, although that depends on the format of the file. So what's next, 
> cataloguing every format and make RPM know about this so diffs can be made 
> sensibly ? Have packagers add this information manually ? I don't see that 
> work.

I agree up until this paragraph in the grandparent post. It is precisely
this point at which I'd like to receive notification. I don't want
anything going on as far as the software trying to make decisions for
me; simply "this happened, look into it".


> > [snip]
> 
> The example doesn't fit what we previously discussed. I'm not saying this 
> wouldn't be useful, it's just hard to automate and too much to ask for if 
> you expect people to do things like this manual.

Agreed.

> But instead of discussing back and forth, prove me wrong with an 
> implementation :) I'm not against the idea per se, I just don't think it's 
> implementable and even if it were (like discussed) it wouldn't be very 
> useful (too much false reports).

Given the lack of support for and the strong recommendations against
doing upgrades of the type for which this would be an ideal solution, I
agree that this would not be as useful as I'd originally assumed.

Under Debian one does upgrades quite interactively, and it makes sense
to do something like what I've suggested. Under Red Hat perhaps it is
worth just doing the "manual upgrade" instead of trying to do things
that the system really just isn't designed to do.

One thing I have learned is that if someone with more experience tells
you "don't do that, it'll break!" it isn't always worth pushing the
envelope just to eventually learn that you should have listened, and
you've broken something when it would have been easier to do it right in
the first place.

Thank you, Dag, for your time and patience in responding.

Chet