On Thu, Apr 27, 2017 at 3:18 AM, Wouter Verhelst <wou...@debian.org> wrote: > On Wed, Apr 26, 2017 at 07:53:57AM -0400, Tom H wrote: >> On Sun, Apr 23, 2017 at 3:00 PM, Wouter Verhelst <wou...@debian.org> wrote: >>> >>> The "packages drop files in /usr/*, sysadmins override in /etc" way of >>> doing things is prevalent in the RPM world; in Debian, however, we >>> traditionally have packages drop files in /etc, and let the maintainer >>> change them in place. This is possible, because our package management >>> system deals better with changed files than does RPM (which must work >>> silently, rather than confirming things with the user). >> >> s/package management system deals better/package management system >> deals differently/ >> >> rpm doesn't have a problem with config file handling and deals with >> config files in a similar way that dpkg uses the "conffile" attribute >> to deal with them. rpm spec files use two (one-and-a-half?) macros: >> >> - "%config": "foo.conf" is replaced in an upgrade and saved as >> "foo.conf.rpmsave"; >> >> - "%config(noreplace)": "foo.conf" isn't replaced in an upgrade and >> the new "foo.conf" is installed as "foo.conf.rpmnew". > > Yes, I am aware of that (many of my customers use RedHat systems). > However, you will notice the complete absense of a "merge" option in the > above. This means that new configuration files are dropped on the > system, *without* any active notification to the user, so it's up to you > to figure out that this has happened and that you may have work to do. > > I didn't say RPM *doesn't* deal with changed files; I said ours deals > with it better. I stand by that.
Sure; and an rpm or emerge user'll tell you that dpkg is inferior because an interactive upgrade's a crazy thing to do.
