Re: policy for shipping sysctl.d snippets in packages?
On Wed, Apr 26, 2017 at 2:55 PM, Ben Hutchings <ben@decadent.org.uk> wrote:
> On Wed, 2017-04-26 at 07:53 -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".
>
> I didn't know about this, and I'm pleased to see that this is (now)
> possible. Is this documented somewhere? (I've never been able to find
> documentation of RPM macros that isn't very old and incomplete.)
I first used it with RHEL 3 for some company-developed apps but it
might predate that.
But Google says that it was available since at least RHL 9:
http://people.ds.cam.ac.uk/jw35/docs/rpm_config.html
Fedora has an rpm draft doc:
https://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/RPM_Guide/index.html
>> So rpm isn't a factor;
>
> It is, because rpm is non-interactive and the above choice has to be
> made by the packager and not the adminsitrator.
It must've slipped my mind because I disable the interactivity.
Indeed, dpkg has the advantage that an administrator can change the
behavior at run-time, for the current transaction or for all, but that
flexibility doesn't give dpkg an advantage over rpm for dropping
config files in "/etc" rather than in "/usr/lib".
>> upstreams drop files into "/usr/lib" because
>> Red Hat is pushing the concept of all/almost-all distro-provided files
>> in "/usr".
Reply to: