Re: policy for shipping sysctl.d snippets in packages?
On Wed, Apr 26, 2017 at 07:53:57AM -0400, Tom H wrote:
> On Sun, Apr 23, 2017 at 3:00 PM, Wouter Verhelst <wouter@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.
--
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
people in the world who think they really understand all of its rules,
and pretty much all of them are just lying to themselves too.
-- #debian-devel, OFTC, 2016-02-12
Reply to: