Re: policy for shipping sysctl.d snippets in packages?
On Thu, Apr 27, 2017 at 3:18 AM, Wouter Verhelst <wouter@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 <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.
Sure; and an rpm or emerge user'll tell you that dpkg is inferior
because an interactive upgrade's a crazy thing to do.
Reply to: