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 _______________________________________________ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
