On Mon, 2001-09-10 at 03:12, Borsenkow Andrej wrote:
>
> > As reported here a while ago, rpm is creating *.rpmnew files for any
> > config file that exists, whether it was modified since package
> > installation or not.
> >
Hmm ... not for me. I update fairly often and config never had a
problem. Just updated abd e.g. /etc/modules.devfsd was correctly
changed.
>
> About the fact that the rpmnew file is created even if it is the same
of
> the existing file, I don't see that as a big problem.
It is a *BIG* problem (if it really exists). It means that if you rely
on config file to provide some features you never get them. And if
config file had incompatible changes it won't be replaced and your
application may stop to work.
-andrej
But, if you changed settings in the configuration file to make that
application work in your environment, even if the new features/format
was installed and the application starts up, it STILL wouldn't work,
because it would no longer have your mods. So either way has its
drawbacks.
RedHat ALWAYS replaces the files, sometimes without warning. Then you
have to check every config file to make sure you didn't lose something.
With Mandrake, I just watch for messages about a .rpmnew being created.
If so, I go diff it with what I have to see what, if anything, needs to
be pulled in. It's called administering your system.
The only ways to solve this is (both probably require mods to rpm
itself):
1) (as suggested by the person who started this thread) if the file is
unchanged from its original default contents (using cmp or sums or
whatever way to verify), then overwrite it, else install the new one as
.rpmnew and warn (like now). Maybe a new tag like "(replaceunch)".
2) Create some logic that can find mods, if any, and merge them into the
new configuration file. (this would be REALLY hard, since there are SO
MANY ways a configuration file could be modified -- lines deleted,
commented out, etc. etc.)
1 seems like it would be doable, 2 doesn't.
In any case, I like Mandrake's way of doing it MUCH better than
RedHat's.
--
TTFN,
Lonnie Borntreger
------ ------ ------
Our mission is to authoritatively promote timely methods of
empowerment so that we may endeavor to collaboratively supply
inexpensive opportunities to exceed customer expectations