rpm overwriting config files again
n3npq at me.com
Sat May 30 05:22:39 CEST 2015
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.
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 ...
73 de Jeff
> pld-devel-en mailing list
> pld-devel-en at lists.pld-linux.org
More information about the pld-devel-en