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 <Destination> - this will replace <destination> 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 <Destination> 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 <New File> - 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 File> 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
