Renaming a conffile in maintainer scripts
Hi,
I was reviewing how we deal with renames of conffiles as now implemented
by dpkg-maintscript-helper (itself inspired by
http://wiki.debian.org/DpkgConffileHandling) and I wonder if we're not
doing something wrong.
Currently it works like this:
- in the preinst, mark the old conffile for removal if it's unmodified
- dpkg installs the new configuration file
- in the postinst
- commit the removal of the old conffile
- if the old file is still here, it means we have user changes to
preserve and we move the new conffile to <new>.dpkg-new and we
rename <old> to <new>
- in the postrm, we abort the removal on abort-upgrade
While this avoids the conffile prompt in all cases, it also means that if
the new conffiguration file has changes compared to the old one, the user
doesn't get to see them... instead they are stored in .dpkg-new without
any prompt.
BTW, .dpkg-new is an extension used by dpkg to unpack new versions of
files during dpkg --unpack. So it will be automatically removed in the
next upgrade of that package... because the hash of the distributed file
has not changed and hence it believes that nothing needs to be done.
At the very least, I think we should move <new> in <new>.dpkg-dist to be
consistent with what dpkg would have done if the user had seen a prompt
and answered to keep his old file. Do you agree with this?
But can we do better and somehow find out the hash on the new conffile
during the preinst (inspecting /var/lib/dpkg/info/tmp.ci/ maybe?) so that
we can put the old conffile in place of the new when we know that it would
have resulted in a prompt anyway?
Cheers,
--
Raphaël Hertzog ◈ Debian Developer ◈ [Flattr=20693]
Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)
Reply to: