Got a suggestion on behavior you'd be happier with?

Yum can track when a .rpmnew file gets created and you could write a plugin to do whatever you want, really.

So - what do you think the right behavior is?

I have a hard time buying this whole argument. What it comes down to is that there are very few exceptions to two main cases:

• You haven't changed the file. You accept the vendor's defaults, and you should continue to accept the vendor's defaults unless you have a compelling reason not to. You have no reason to diff the file, since the defaults are good enough for you. Overwrite the config with the .rpmnew file.
• You have changed the file. Since you've already edited this config, then clearly you know what it does. You should diff and remediate changes manually, since this is a production configuration and you had a compelling enough case to go out of your way to customize it in the first place.

Only the second case is interesting, and the logistics of it should be determined by the vendor's update strategy. In the case of RHEL/CentOS, updates to trivial version/release bumps typically don't do anything interesting, and you can almost universally ignore them until the next minor update of the OS if you like.

From my perspective, you're arguing two different things. You're arguing that system administrators don't always understand the files in /etc. That's true. But you're also arguing that a sysadmin has to manually look at every single file with an .rpmnew equivalent, or their system will fall apart and do horrible things. But the subtext of your argument is one of two things: that RHEL/CentOS are incredibly fragile systems that will make your system fall apart in subtle ways and that the problem is with the magic of the entire system playing with your config files without your knowledge or consent, or you're overtly saying that most sysadmins are full of shit and don't know enough to do their jobs (but this is somehow the package manager's fault). Either way, I'm not convinced, and if these configs are so important that it's too dangerous to replace one default with another, I don't think that automatically remediating changes via something with as little intelligence as diff/patch is the way to go either.

Remediating is as simple as following this process:

• find /etc -name \*.rpmnew
• If I haven't made changes to these config files, replace the old versions with the new ones. If OS magic made changes to them before, it will make changes to them again. If not, I'm confident that this is a bug I've already caught in QA, and I've reported it to the vendor.
• IFS=`echo -ne "\n\b"`; ( for f in `find /etc -name \*.rpmnew`; do diff -u ${f%%.rpmnew} $f; done ) | /usr/share/vim/vim##/macros/less.sh
• Remediate as necessary.

I've never had this process take me more than two minutes on any production system.

--Jeff

@Jeff: My overall argument is that if you have not yourself edited a config file, either you should be able to ignore the .rpmnew file or the package update has a bug. Your argument to my first entry is effectively that this is not so and that it is not a bug for a package update to force you to inspect and mangle .rpmnew files even if you have not yourself edited the config file.

If OS magic made changes to them before, it will make changes to them again. If not, I'm confident that this is a bug I've already caught in QA, and I've reported it to the vendor.

My past experience with Red Hat distributions is that this at least was not the case; there were RPMs that directly edited files supplied by other RPMs only when they were installed. Do something that recreated the original file from scratch (such as replace it with its .rpmnew version) and you lost all of those changes.

(The classical case is /usr/share/info/dir, the master index of all GNU Texinfo documentation files installed by packages. I'm confidant that there are others.)

Got a suggestion on behavior you'd be happier with?

Not for RPM behavior, really, apart from fixing the multi-arch bug. The problem isn't that RPM creates .rpmnew files; the problem is that you can't ignore them because packages do stupid things.

(That's why my original entry blamed the smartmontools package for the problem, not RPM.)

@Jeff:

You have changed the file. Since you've already edited this config, then clearly you know what it does.

Only if you remember both that you changed the file, what the purpose of that change was, and what the change actually was.

If there was an easy way to see how the file in production differed from the file that was originally placed there, you could get automatic notification that the .rpmnew file might indicate you have to repeat your change, and you could then get automatic notification as to what your change actually was. From there one would hope you would remember what the point of the change originally was.

-- David Mackintosh

@David:

That's a problem that was solved long ago by having proper change management procedures. If your organization can't track down the date/time and purpose of a particular change to a file, your processes are flat-out broken -- how can you tell the difference between an intentional change, an accidental change, or a malicious change? Some people do this the super-bureaucratic way with ticketing systems and signoff, which works for big enterprises with huge SLAs, but the simplest way to handle this is with a revision control system (given, of course, that you use real commit messages). On any given server, for any given file, you should be able to do a git-log php.ini or whatever and get a list of all the changes made and why they happened. (Redmine or some other repo browser is also a really nice tool for aggregating all these changes into a nice web UI.)

Everyone defending RPM's current practice: see how Debian does it, particularly ucf which supports a three-way merge.

James

One funny thing is, packages used to produce lots of fake .rpmnew's: even if configuration was byte-to-byte identical, the .rpmnew were created anyway. I used to run this after every update:

find /etc -name '*.rpmnew' | while read f; do d=$(dirname $f); b=$(basename $f .rpmnew); if cmp $d/$b $f; then mv $f $d/$b; fi; done

These days I run a batch-diff and then patch.

@James:

I absolutely agree, and I love the way that Debian handles things, especially the way that the criticality of the file update is tagged so you can review the really important files and ignore the ones that don't matter. The bigger issue ties into yesterday's post, and that is: "is the .rpmnew behavior of RPM sufficiently problematic where it should cause problems on production servers because the file differences are so numerous and difficult to remediate that it's too frustrating to even try?"

I contend that it absolutely isn't, though I would love to see RPM handle merging the way that dpkg does.