On 21 Jan 2015, at 11:13, Madko wrote:


Had the same problem about conf files renamed to .rpmsave, and therefor
opennebula was enable to start. Hopefully I saw this thread ;)

Is it possible to change this behavior and have .rpmnew instead, to prevent breaking everything after an upgrade? %config(noreplace) in the spec file
should do the trick, and it's a good practice.

It seems to me that this has to be looked at on a case-by-case basis. In THIS case, the installation of new default config files is inconsistent with the release notes that say there are no changes, so replacing derivatives of the 4.10.[01] files with defaul 4.10.2 files is wrong. However, most past updates have been documented as having incompatible changes in the config files, and in such cases it can be better to put the new default files in place and move the existing files to .rpmsave files, especially if the old config files are likely to break the new software at runtime. Ideally, a package's config files are structured and maintained to minimize the need for manual merging of local settings after updates, but OpenNebula is not near that ideal.

Of course, any competent upgrade process for RPM platforms *ALWAYS* includes checking for .rpm{save,new,orig} files afterwards and cleaning them up with the application of human intelligence not available to the RPM tools.
Users mailing list

Reply via email to