3

I'm creating my own RPM using rpmbuild.
My RPM contains config files which should never get overridden, even if the RPM contains a new version of these config files.

To archive this, I tagged these with

%config(noreplace) /opt/mypackage/etc/*

in the spec file.

According to the documentation and this site, a locally modified file will never get overridden in this case which is exactly what I want.

However, when doing the following operations:

  1. Install version 1 of the RPM
  2. Change configuration file etc/myconfig
  3. Update package with version 2 of the RPM

I'm getting a conflict:

$ rpm --prefix ~/rpmroot/ -ih dist/mypackage-1.0.1-1.x86_64.rpm
########################################### [100%]
file /home/user/rpmroot/mypackage/etc/myconfig from install of mypackage-1.0.2-1.x86_64 conflicts with file from package mypackage-1.0.1-1.x86_64

Questions:

  • How can this conflict be explained? (I'd expect that the new version of the config file would be stored as myconfig.rpmnew and the existing remains untouched)
  • What I am doing wrong?


UPDATE (additional information)

The output of rpm -qcp dist/mypackage-1.0.1-1.x86_64.rpm is:

/opt/mypackage/etc/config1.xml
/opt/mypackage/etc/config2.xml
/opt/mypackage/etc/run.sh
/opt/mypackage/etc/config3.xml

The complete %files section:

%files
%defattr(0444,root,root)
/opt/mypackage/java/*

#dba
%defattr(0444,root,root)
/opt/mypackage/dba/sql/*
%defattr(0555,root,root)
/opt/mypackage/dba/script/*

#srv
%defattr(0555,root,root)
/opt/mypackage/srv/bin/*
/opt/mypackage/srv/lib/*

#etc
%defattr(0664,root,root)
%config(noreplace) /opt/mypackage/etc/*
MRalwasser
  • 15,605
  • 15
  • 101
  • 147
  • 1
    So odd that the "(noreplace)" feature is not documented ... almost the expected behavior in my book when you go through the trouble to say "%config" ... – nhed Sep 12 '13 at 01:27
  • 2
    It's documented, but not well: http://www.rpm.org/wiki/PackagerDocs/Spec (and also have a look at the unofficial, but helpful site: http://www-uxsup.csx.cam.ac.uk/~jw35/docs/rpm_config.html ) – MRalwasser Sep 12 '13 at 08:28
  • Yes, I saw the unofficial, thats the only one that came up in my search (and your question). Last night was the first time we tried `noreplace` – nhed Sep 12 '13 at 13:27

1 Answers1

7

If this is actually your issue, you may kick yourself ...

I think this may be just because you are "installing" and not "upgrading" replace -ih with -Uh

I created a test RPM with similar setup, here are the results:

With -ih as you did

$ sudo rpm --prefix ~/rpmroot/ -ih /home/nhed/rpmbuild/RPMS/x86_64/ptst-1.1.0-1.x86_64.rpm

##################################### [100%] file /home/nhed/rpmroot/etc/a from install of ptst-1.1.0-1.x86_64 conflicts

with file from package ptst-1.0.0-1.x86_64 file /home/nhed/rpmroot/etc/b from install of ptst-1.1.0-1.x86_64 conflicts with file from package ptst-1.0.0-1.x86_64 file /home/nhed/rpmroot/etc/c from install of ptst-1.1.0-1.x86_64 conflicts with file from package ptst-1.0.0-1.x86_64

With -Uh

$ sudo rpm --prefix ~/rpmroot/ -Uh /home/nhed/rpmbuild/RPMS/x86_64/ptst-1.1.0-1.x86_64.rpm

##################################### [100%]

warning: /home/nhed/rpmroot/etc/a created as /home/nhed/rpmroot/etc/a.rpmnew

##################################### [100%]
nhed
  • 5,774
  • 3
  • 30
  • 44
  • 1
    if you have tons of files under `/opt/mypackage/etc/` it sounds like you can make a "manifest" file in the %install rule (or earlier) that will find all those files and prefix them with the `%config(norplace)` directive, then pass the manifest with '-f' to `%files` – nhed Sep 12 '13 at 01:38
  • 1
    You're right, %config can only be followed by one filename, but I think a filename with wildcards is allowed. Otherwise, they would most probably not being packaged - or I would expect an error message. Nevertheless, I tried this out - it does not make any difference, the conflict remains. (BTW, the book http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/RPM_Guide/ch09s05s03.html also shows %config with wildcards) – MRalwasser Sep 12 '13 at 07:17
  • @MRalwasser Can we see the rest of your %files section? Also can you paste the output of `rpm -qcp dist/mypackage-1.0.1-1.x86_64.rpm` – nhed Sep 12 '13 at 13:21
  • 1
    @MRalwasser fascinated enough I ran a test and updated my answer – nhed Sep 12 '13 at 15:04
  • 1
    Wow, thanks! That was indeed the problem. I thought that -i is a synonym for -U in case the package is already installed in an older version. Never expected that this could cause such an error. How did you find this error without knowing what I exactly typed? – MRalwasser Sep 12 '13 at 15:42
  • @MRalwasser your paste with the error shows your rpm command line with "-ih", and I tried to reproduce exactly what you did so I also made my package relocatable (though I usually don't bother). – nhed Sep 12 '13 at 17:21
  • Ah, you're right, it's part of my question - very attentive! Yes, I am also using relocation within my package. – MRalwasser Sep 12 '13 at 17:31