4

I'm currently testing installing a RPM with a config file using the config(noreplace) directive.

As per using config(noreplace) my spec file marks a single file as a config file:

%config(noreplace) /opt/lm/dest/conf/db.xml

I did an on disk modification to the file for version 1 and proceeded to upgrade to version 2. I was expecting the verbose output to (when using -Uvh) to indicate that it has create a db.xml.rpmnew which it didn't however the on disk modifications I made are intact.

Does anyone know why this might be the case?

Some background info: I am using the same tar file to create both version 1 & 2 which shouldn't make a difference but thought I'd mention it anyway.

EDIT 1:

Incase it wasn't clear the db.xml.rpmnew file was not created.

  • Are you observing that db.xml.rpmnew isn't created, or just that it's creation isn't mentioned in the verbose output of the rpm command? – HBruijn Mar 3 '15 at 6:37
  • db.xml.rpmnew is not created. – kaizenCoder Mar 3 '15 at 6:38
8

What you observe is expected behaviour. A .rpmnew package is only created when both of the following conditions are met:

  1. the default configuration file in the new RPM package is different from the configuration file that was originally included in the current/previous version of the RPM package. (Changes to the defaults have been made by package maintainer.)
  2. the actual configuration file on disk has been changed from the default that was included the current/previous version of the package. (Changes from the defaults have been made by administrator.)

According to the Changelog:

commit e64bf5b93ab689e6031fce4489e4ae38ebaebef1
Author: Panu Matilainen
Date: Tue Aug 28 09:04:09 2007 +0300

Avoid .rpmnew when the file hasn't changed in package (rhbz#194246)

The current behavior of %config(noreplace) creates a .rpmnewfile iff the type of the current file has been changed wrto what was originally installed.

The patch changes this behavior so when old and new (in db and in package) is identical -> not changed, the function returns FA_SKIP -> it won't clobber anything, it simply skips installation of the file from the package. This patch handles also the opposite case when old and new packages contain %config symlink and we have regular file on disk.

Patch from Tomas Mraz.
  • Thanks for that! just with the second comment:"AND the configuration file on disk has been changed from the default as well." - isn't this my scenario, where I changed the config file on disk? – kaizenCoder Mar 3 '15 at 8:03
  • 2
    Is there a difference in the included config file between version 1 and version 2 of your rpm package? No? Then no .rpmnew file. - The implied logic is that your custom modifications are still going to be valid for the upgraded version of the package. Now if the new version of the package has completely new defaults, then an administrator might/should compare how his modifications compare to the new default settings the package maintainer included and a .rpmnew file is useful and should be created. – HBruijn Mar 3 '15 at 8:16
  • Is there any documentation describing the new behavior introduced by commit referenced in this answer? – Piotr Dobrogost Nov 16 '17 at 13:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.