rpm overwriting config files again
Jeffrey Johnson
n3npq at me.com
Fri May 29 16:43:03 CEST 2015
On May 29, 2015, at 4:28 AM, Elan Ruusamäe wrote:
> On 29.05.2015 00:13, Jeffrey Johnson wrote:
...
>> Was this behavior seen in a multiple package upgrade that you have snipped out?
> nop. this was 1 package upgrade:
>
OK thanks for -vv output.
> # rpm -q nagios-nrpe
> nagios-nrpe-2.15-1.i686
>
> # > /etc/nagios/nrpe.d/commands.cfg
>
> # rpm -qf /etc/nagios/nrpe.d/commands.cfg
> file /etc/nagios/nrpe.d/commands.cfg is not owned by any package
>
So an empty commands.cfg is generated.
> # rpm -Uvv nagios-nrpe-2.15-4.1.i686.rpm
>
(aside)
Nice! PLD appears to be trying to eliminate LOOPS.
> D: ignore package name relation(s) [0] QtGui -> Qt3Support
> D: ignore package name relation(s) [1] QtGui -> QtSvg
>
...
> D: ========== tsorting packages (order, #predecessors, #succesors, tree, Ldepth, Rbreadth)
> D: 0 0 1 1 0 0 +nagios-nrpe-2.15-4.1.i686
> D: ========== successors only (41485 bytes)
> D: 1 1 0 1 1 0 -nagios-nrpe-2.15-1.i686
...
>
> D: fini 100640 1 ( 0, 72) 6132 /etc/nagios/nrpe.cfg;55682259 altname
> warning: /etc/nagios/nrpe.cfg created as /etc/nagios/nrpe.cfg.rpmnew
> D: fini 040750 2 ( 0, 72) 0 /etc/nagios/nrpe.d
> D: fini 100640 1 ( 0, 72) 1828 /etc/nagios/nrpe.d/commands.cfg;55682259
...
>
> D: fini 100640 1 ( 0, 0) 7215 /etc/nagios/nrpe.cfg skip
>
> # ls -l /etc/nagios/nrpe.d/commands.cfg
> -rw-r----- 1 root nagios 1828 May 25 16:03 /etc/nagios/nrpe.d/commands.cfg
>
> # rpm -q rpm
> rpm-5.4.15-20.i686
>
> # rpm --version
> rpm (RPM) 5.4.15
So the problem comes down to user expectations of behavior when the new
package has a file marked %config(noreplace).
The observed behavior is exactly what I personally expect of RPM (and
is what has been implemented all this century AFAIK).
If you wish to change the behavior to, say, create foo.rpmnew instead of foo
when the new package file is marked %config(noreplace), then patch
lib/rpmfi.c to return FA_ALTNAME instead of FA_CREATE when marked
%config(noreplace) in lib/rpmfi.c rpmfiDecideFate()
The patch will likely be as simple as
- return FA_CREATE;
+ return save;
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.
73 de Jeff
More information about the pld-devel-en
mailing list