Shared publicly  - 
 
#rant #sigh "_warning: foo.conf created as foo.conf.rpmnew" Ten years ago I had expected to rarely see messages like this it any more in 2013. But they IMHO still show up way to often(¹), as too many software still doesn't use the tricks(²) to avoid the hassle. It's one imho, as once in a while those rpmnew files contain important configuration values that break things if you don't merge them back into your configuration :-/

(¹) In this case for example, as this screenshot is from a test vm where I never configured a printer or otherwise touched the cups configuration :-/
(²) among them afaics: (1) sane default configuration somewhere in /usr/ and a empty file in /etc/ that only contains what's actually needed (including overrides) (2) config snippets that can be placed in subdirectories (/etc/modprobe.d/, /etc/X11/xorg.conf.d/)
9
Heiko Adams's profile photoThorsten Leemhuis's profile photoStefan Nickl's profile photoBjörn Gerhart's profile photo
8 comments
 
They are everywhere.  Seriously, /etc/issue.rpmnew and /etc/issue.net.rpmnew?!?

# locate rpmnew
/etc/chrony.conf.rpmnew
/etc/issue.net.rpmnew
/etc/issue.rpmnew
/etc/nsswitch.conf.rpmnew
/etc/rsyslog.conf.rpmnew
/etc/shells.rpmnew
/etc/kde/kdm/kdmrc.rpmnew
/etc/mail/sendmail.cf.rpmnew
/etc/mail/submit.cf.rpmnew
/etc/pam.d/password-auth.rpmnew
/etc/pam.d/postlogin.rpmnew
/etc/pam.d/su.rpmnew
/etc/pam.d/system-auth.rpmnew
/etc/ssh/ssh_config.rpmnew
/etc/ssh/sshd_config.rpmnew
/etc/systemd/journald.conf.rpmnew
/etc/yum.repos.d/fedora-updates-testing.repo.rpmnew
/etc/yum.repos.d/fedora-updates.repo.rpmnew
/etc/yum.repos.d/fedora.repo.rpmnew
/usr/share/texlive/texmf/web2c/fmtutil.cnf.rpmnew
 
The 80s are calling. People really need to get their act together to move their tools to the present. It's just sad what a dirty and broken hack all linux distributions still are. The first thing a modern OS needs to provide is strict separation of all "data" from the static "system" files of the distributed OS, and not blindly mangle all stuff together. Almost all in /etc just needs to go away entirely. This also means that configuration has no place at all in package management. In the long run, distributions that do not sort that stuff out, will just not survive, I'm very sure.
 
Big +1 to what +Kay Sievers said. Albeit that's one of those situations where I wonder if distributions should work together more closely and send upstream (that's where most of the hard work needs to be done afaics) a strong message to finally get their act together. I guess makeing the problem uderstood everywhere might be one of the most important things, as it seems too many developers are not aware of the problems they cause with their 80s-like approach to configfiles, /etc/ and such :-/
 
IMHO config files should be generated at first start of a app/daemon etc and not be shipped by vendors.
 
RPM's package management allows you to mark certain files as a configuration file, and the packager decides if the old config file will be overwritten or not (if performing an update). I would expect the packager to make the right decision in this respect, because he knows the reason why the package gets updated. Also I would expect only new functionality is getting supported with an updated configuration file syntax, so you may inspect the rpmnew file for your information if there comes new functionality within the update.
 
+Björn Gerhart what RPM does and supports wrt to config files are workarounds to make dealing with current software bearable; the proper solution is to fix the software instead so RPM normally does not have to deal with this stuff (see the "The first thing a modern OS" part in Kays comment).
 
+Thorsten Leemhuis +Kay Sievers got the idea. However, sometimes I find it helpful to take a look at some default configuration files, which often include useful comments. But I agree that such files also could be stored in a location other than /etc
Add a comment...