.rpmnew files during RPM upgrade

Phil Mayers p.mayers at imperial.ac.uk
Tue Sep 11 22:03:58 CEST 2012

On 09/11/2012 04:37 PM, Brian Julin wrote:
>> -----Original Message-----
>> On 11/09/12 12:16, Phil Mayers wrote:
>> This approach of a separate available/enabled modules dir is the default
>> approach in the MASTER branch (to be 3.x)
> Would redhat packaging policy allow the package scripts to instead
> create e.g. modules.rpmnew/ and stuff its files under there
> instead?  (My hopes aren't high.)

I guess I don't see how this is qualitatively different than having RPM 
put the modules into modules-available/ then include&symlink to 

Well, not true; I think the latter solution is *superior*.

But sure - you can use %postinstall tricks to make RPM do anything. 
Since the OP said he "rolled and deployed" the RPM himself, I don't see 
why the solution isn't:

find /etc/raddb -name \*.rpmnew -exec rm -f {} \;

We adopt another solution - our local RPM puts the included /etc/raddb 
into /usr/share/doc/<name>/raddb for reference, and doesn't touch 
/etc/raddb (which we manage from SVN).

> Sounds like the job of a main config file directive, e.g. ignore_suffixes=

Shrug. Sounds like a job for proper config directory management to me! 
We don't have this problem - never have. We use various solutions - 
config in SVN, local package builds without confg files, cfengine "tidy" 
actions to manage package post-installs, never let something upgrade 
critical packages unattended, etc.

> That way it could appear right before the INCLUDE line in the
> configuration file so it's right out there in the open.

Well, config is hierarchial, so "immediately preceding" has problems. This:

modules {
  $INCLUDE modules/
ignore_suffixes=*.rpmnew *~
$INCLUDE sites-enabled/

...is harder to implement. Best you can sensibly manage without undue 
confusion is probably a top-level global.

It's not a feature I'd ever use, so as long as there isn't some 
hard-coded source "skip" list I don't care!

More information about the Freeradius-Users mailing list