Managing configuration via RPMs?

Can I suggest an alternative solution? You might find that a configuration management tool like Puppet or Cfengine2 does what you want. You write manifest files that describe how you want a system to look and it goes away and changes the system so it looks like that. Notice the important distinction that you are describing how the system should look, not how you change the system. An example for ntp might be:

class ntp {
   package {"ntpd":
       ensure => latest,
   }
   file { "/etc/ntp/ntp.conf":
       source => "puppet:///ntp/ntp.conf",
       owner => "root",
       group => "root",
       mode => 644,
       require => Package["ntpd"],
   }
   service { "ntpd":
       ensure => running,
       enable => true,
       subscribe => File["/etc/ntp/ntp.conf"],
   }
}

When you include this class in a particular node, you will install the ntpd package, copy your file across to the server and make sure the daemon is running. If puppet makes any changes to ntp.conf, it will restart the ntp daemon (thanks to the subscribe line).

How does this solve your problems? Well, when a new version of ntp is installed, if the package overwrites the config file, puppet will copy the old one back. If there are any differences, it will display a diff as it changes it, so you can see what changes have been made, so you can notice any differences and update your central version if you want those changes.

Go with David's solution of using puppet instead. Really.

However, if you're determined, what you can do is create a package rassie-ntp-conf that contains "/etc/ntp.conf.rassie". In the spec file, you'll need a %post that copies your config over the default config and also a "%triggerin -- ntp-server" that does the same. That way if a later upgrade overwrites the config, the trigger will copy back over it. Maybe drop something into /etc/cron.daily to do the same to be really sure... Probably need to have all those scripts do a service ntpd condrestart after the cp, too.

That's the basics. If you want to do it for more packages, you might instead build a standard script that runs through /etc/rassie/ to find configs to copy over into /etc and have the %post and %triggerin stuff run that instead.

But, really, ignore that and use puppet or Chef or cfengine... This kind of "pushing configuration out via RPM" scheme is fraught with subtle problems stemming from the fundamental problem that RPM isn't designed to have two different packages fight over a single file. Hard to test, hard to debug, exactly the sort of clever solution that will make you later wish you'd gone with puppet in the first place.

Regardless of how you decide to push out the changes, if you need to modify ntp.conf (or any config file, really) and do not want to wholesale replace the file, take a look at Augeas (http://augeas.net). There is a little bit of a learning curve, but it removes a lot of the complexity of parsing/editing files.

I think Puppet or CFEngine is the way to go in the long run. But as a first step that easier to implement a version control system such as subversion or git should work. You'll want to keep your change history of configuration files even under Puppet and CFEngine.

I've tried to handle using only rpms to. Only when your config files are very simple it's possible.

The best approach, but it's not to simple to implement is using tools like puppet and cfengine as everyone suggested.