If the conffile affected by `dpkg-maintscript-helper rm_conffile` has been
modified, d-m-h moves it out of the way by renaming it to
conffile.dpkg-backup and then to conffile.dpkg-bak. This seems like
an appropriate thing to do if you are removing a "monolithic" conffile
similar to /etc/wgetrc.

I think it would be useful to have a mode (perhaps rm_conffile_if_unmodified)
that will remove unmodified conffiles, but leave a modified file in place:

- preinst: if unmodified, rename conffile to conffile.dpkg-remove
- postinst: remove conffile.dpkg-remove if present
- postrm: on abort, rename conffile.dpkg-remove to conffile

This is exactly the half of rm_conffile that deals with unmodified
conffiles, but converting the half that deals with modified conffiles
into a no-op, and it seems like the right thing to do if you are removing
a snippet in a .d directory, similar to the ones in /etc/dpkg/dpkg.cfg.d/.

In particular, this seems like it would be the right thing to use
when moving an integration-point file (udev rules, dbus-daemon policy,
etc.) from /etc into /usr in order to reserve /usr for sysadmin overrides,
which is a common pattern. If the file in /etc has been modified, then
it should stay intact with its original name so that it continues to
override the package's version in /usr; but if the file in /etc has not
been modified, then it should be removed so that the package's updated
version can be used.

    smcv

tags 1006655 + patch
thanks

I've attached a patch implementing an rm_conffile_if_unmodifed command
for dpkg-maintscript-helper, as well as a declarative version for
debian/conffiles.

I've included documentation and tests for both.

Using this has the same effect as rm_conffile if the file is unmodified.
However, if the file is modified, this leaves the file in place under
the existing name (treating it as an obsolete conffile so that it still
gets removed if purging the package).

Thus, unlike rm_conffile, this version is useful for packages that still
support reading the configuration file if present, and thus don't want
to move existing modified configuration aside with a .dpkg-bak suffix,
because that'll prevent the modified configuration from being used.

- Josh Triplett

Hi,

As I mentioned in #822462, I think the default should be changed instead
to do this. I sat yesterday to see how much this would imply code wise
and ended up with a smallish patch, which then required adapting few test
cases. I also added a new --assert-unmodified-obsolete-conffile-removal
(although I'm not entirely happy with such a long name). I'd still need
to add a few more tests for downgrades, but otherwise it seems to work
fine.

Being this such a behavior change, although it seems pretty safe to
me, I think it would still deserve to be discussed in debian-dpkg and
debian-devel. The only problematic thing that comes to mind, is that
it will be harder to spot conffiles that need to be marked as
remove-on-upgrade, as test systems would automatically get rid of
unmodified conffiles.

Will try to add the missing tests and push this into a branch tomorrow,
and then try to start a thread on the mailing lists during the week or so.

Regards,
Guillem

Hi,

As I mentioned in #822462, I think the default should be changed instead
to do this. I sat yesterday to see how much this would imply code wise
and ended up with a smallish patch, which then required adapting few test
cases. I also added a new --assert-unmodified-obsolete-conffile-removal
(although I'm not entirely happy with such a long name). I'd still need
to add a few more tests for downgrades, but otherwise it seems to work
fine.

Being this such a behavior change, although it seems pretty safe to
me, I think it would still deserve to be discussed in debian-dpkg and
debian-devel. The only problematic thing that comes to mind, is that
it will be harder to spot conffiles that need to be marked as
remove-on-upgrade, as test systems would automatically get rid of
unmodified conffiles.

Will try to add the missing tests and push this into a branch tomorrow,
and then try to start a thread on the mailing lists during the week or so.

Regards,
Guillem

Es gibt eine Familienspende in Höhe von 1.850.000,00 USD von Cheng Charlie
Saephan. Bitte antworten Sie für weitere Informationen. Denken Sie daran,
Ihrer Familie und den Bedürftigen in Ihrer Umgebung Gutes zu tun.

Dies ist bereits der zweite Versuch, Sie zu erreichen. Bitte antworten Sie
für weitere Details.

Es gibt eine Familienspende in Höhe von 1.850.000,00 USD von Cheng Charlie
Saephan. Bitte antworten Sie für weitere Informationen. Denken Sie daran,
Ihrer Familie und den Bedürftigen in Ihrer Umgebung Gutes zu tun.

Dies ist bereits der zweite Versuch, Sie zu erreichen. Bitte antworten Sie
für weitere Details.

Es gibt eine Familienspende in Höhe von 1.850.000,00 USD von Cheng Charlie
Saephan. Bitte antworten Sie für weitere Informationen. Denken Sie daran,
Ihrer Familie und den Bedürftigen in Ihrer Umgebung Gutes zu tun.

Dies ist bereits der zweite Versuch, Sie zu erreichen. Bitte antworten Sie
für weitere Details.