Thomas Hood <jdthood@yahoo.co.uk> writes:
> Roger Leigh wrote:
>> Until last month, dpkg "forgot" about conffiles which were removed or
>> moved on package upgrade. As a consequence, maintainers had to
>> remember to purge these conffiles "by hand" in the package postrm
>> script.
>
> I just want to highlight the word "these" above in order to reduce the
> possibility of confusion.
>
> Postrms should not delete files that are currently conffiles of the package.
> dpkg takes care of deleting such files at the right time.
>
> If a file /etc/foo was formerly a conffile of the package but no
> longer is so then /etc/foo should be dealt with in the preinst or
> postinst. ("Dealing with it" has to take into account both the old
> and the new behavior of dpkg with respect to disappearing conffiles.
> I speak vaguely here because I haven't looked into the new
> behavior.) If it isn't dealt with there then it might be
> appropriate to delete it in the postrm, but not if there is reason
> to suspect that some other package is now using /etc/foo.
How about this as a start?
This should be "safe" in that it won't remove a conffile if another
package (or itself) takes ownership of it. It also handles removal of
the dpkg cruft, but I'm not sure that's always appropriate, since dpkg
should handle it, at least for the new dpkg behaviour; this only
caters for the old.
Call in a postrm like this:
rm_conffile("/etc/my/conffile")
# Remove a conffile which has been forgotten by dpkg
# If the file does not exist, or is owned by any package, do not remove it.
rm_conffile() {
CONFFILE="$1"
if [ -f "$CONFFILE" ]; then
if dpkg -S "$CONFFILE" >/dev/null 2>&1; then
:
else
rm -f "$CONFFILE"
rm -f "${CONFFILE}.dpkg-old"
rm -f "${CONFFILE}.dpkg-new"
rm -f "${CONFFILE}.dpkg-dist"
fi
fi
}
Regards,
Roger
--
Roger Leigh
Printing on GNU/Linux? http://gutenprint.sourceforge.net/
Debian GNU/Linux http://www.debian.org/
GPG Public Key: 0x25BFB848. Please sign and encrypt your mail.
Attachment:
pgpMWqT3nG5DU.pgp
Description: PGP signature