In comments on my entry on Ubuntu packages playing 'hide the configuration file', James asked how RPM handles user editable configuration files (and then guaq gave a good answer). This is an important enough thing to talk about that I'm going to write an entry about it, because RPM's approach is both technical and social.

On the technical side, the first thing is that if the file hasn't changed between the old package and the new package update, RPM knows this and doesn't need to do anything; it doesn't touch the installed file and doesn't bother putting the stock version anywhere. If the configuration file has changed between the old and the new package and you've also edited the configuration file, most of the time the package will write out the new configuration file as <file>.rpmnew (for exact details of what happens when, see Jon Warbrick's writeup; while it's from some time ago, I don't believe RPM's behavior has changed since).

If this isn't enough, RPM packages can also do arbitrary things on package upgrades in their postinstall scripts. I believe that this has occasionally been used to do things like edit installed configuration files to modify or comment out configuration directives that have unavoidably changed or disappeared between software versions. However, this is where we shade into the social side of things.

Because RPM packages can't really try to do sophisticated things with configuration files, they have a strong social pressure to not need them. As a packager, part of your job is to make sure that the package's configuration files work right even within these restrictions. Generally you must keep existing configuration files working correctly even over package updates; resorting to pushing installed configuration files aside as .rpmsave files is strongly discouraged (as far as I know; it's certainly uncommon). This requires more up front work, is harder, and inevitably requires some tradeoffs (where people with edited configuration files don't magically get the benefit of new configuration options), but in my opinion it produces better long term benefits for sysadmins.

(It also encourages schemes to split configuration files up in various ways, because then it's more likely that most of the split configuration files will be unedited. RPM based systems are not alone in this, of course, and sometimes they don't do it as well as other systems.)

As a result, while you can do crazy things in RPM postinstall scripts, it's effectively discouraged. I would be surprised if Fedora packaging review was very receptive to mangling configuration files in postinstall scripts, for example (although it's not covered explicitly in the Fedora packaging guidelines). And of course the technical restriction that you can't ask the user any questions in your postinstall script limits the amount of things it's sensible to even try to have an ultra-smart script do.

This also affects what sort of default configuration it's sensible to set up in your package's stock files. Generally it's going to be better to create something minimal but stable instead of a complicated setup with lots of options that has to be managed by hand. Sure, many sysadmins will have to change your minimal setup, but on the other hand your package itself hopefully won't have to change and revise the setup from version to version. This keeps all of the changes, customizations, and updates in the hands of sysadmins, instead of making some of them your responsibility.

RPM's technical approach could not work without the social approach (although of course its technical limitations combined with sane people create the social approach). As a result, any RPM based system is going to have a terrible time with a program that needs configuration file customization and also changes its configuration files around in incompatible ways (either as for what's allowed in them or as to how they're organized). Fortunately there are not many programs like this, because they're unpopular with sysadmins even without RPM packaging issues.