rpm overwriting config files again

[Jeffrey Johnson]

On May 29, 2015, at 3:25 PM, Elan Ruusamäe wrote:

> On 29.05.2015 17:43, Jeffrey Johnson wrote:
>> I won't make the change in RPM upstream because I believe it's
>> more important to have consistent %config handling than it is to
>> preserve unpackaged configuration files on upgrade when the
>> new (but not the old) package has file content (which almost never happens).
>> 
>> I can be convinced otherwise if there is a demonstrable consensus that a different
>> behavior is needed and necessary.
> the scenario is quite simple:
> 
> some software loads config from conf.d dir (using *.conf glob), at some point sysadmins put their configs there.
> now rpm starts to put their files there too, it happens to be the same filename,
> now if the file already exists, it will ovewrite sysadmin changes.
> 
> if it created .rpmnew, then the previous file (created by sysadmin) would be used, and new config (from rpm), would be stored as .rpmnew
> 
> overall config stays running, nothing is overwritten.
> 

The alternative scenario is equally plausible:

Sysadmin is trying to install software manually, lacks expertise in configuring. Eventually\
the sysadmin attempts install from rpm packages, mis-configuration is overwritten,
and everything Just Work. Which isn't true if the newly installed configuration is
renamed with a .rpmnew suffix.

Enough already: you know well how RPM behaves with %confoig, and you are
able to patch in whatever behevaior you choose: I told you how to patch
in the behavior you desire.

(aside)
You do realize that RPM5 embeds libgit2 sufficiently well to perform
a commit that git(1) understands? Discusssing Newer! Better! Bestest!
%config handling, with (.rpmnew/.rpmorig/.rpmsave) handling is
so so so last century ...

*shrug*

73 de Jeff

> -- 
> glen
> 
> _______________________________________________
> pld-devel-en mailing list
> pld-devel-en at lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-devel-en