Package: ucf
Version: 3.0036
Severity: wishlist
Hi,
the examples postinst and postrm files in /usr/share/doc/ucf are based
on quite old skeletons. Even dh_make creates templates that use
debhelper nowadays. Please consider adapting your examples to modern
packaging practices. Where are those skeletons from in the first place?
I haven't seen post(inst|rm) templates this verbose and well-documented
anywhere else in Debian, and examples this verbose and this
well-documented should not be hidden away in a tooling package's
examples directory.
Additionally, the example code does only cover the most simple cases. I
am currently missing the more complex cases, for example when a
ucf-conffile goes away during a package upgrade (but should be preserved
if there were local changes) or when an ucf-conffile needs renaming.
>From my modest experience with using ucf, I guess that the following
approaches will get the job done appropriately:
(1) removing an ucf-conffile during package upgrade
- ucf /dev/null
- this will replace with an empty file if there were no
local changes, or ask the local user whether to keep the local file or
to replace it with empty.
- If is an empty file, do ucf --purge, ucfr --purge
(2) renaming an ucf-conffile during package upgrade
- ship the file with the default new name in
- if old does not exist, touch old
- if new does not exist:
- mv old new
- ucfr --purge old
- ucf purge old
- if old still is non-empty, there were local changes to old, but new is
already present. I have no idea how to handle this case.
- if old is empty, rm old
- ucf new
- ucfr package new
If you indicate that this might be the correct approach, I might be
willing to submit patches to the example scripts and/or the docs. I am
not yet sure about the best way to document this.
Greetings
Marc
