May packages rm -rf subdirectories of /etc/ ?
Recently I purged a package foo which had a configuration directory
/etc/foo/. The package contained a number of conffiles in /etc/foo/ .
I backed up some of these before the purge by copying them to other
names, but leaving them in /etc/foo/ . To my surprise, the package
postrm did a "rm -rf" on the whole /etc/foo/ directory, thus
deleting my backups.
Looking at the postrms of other packages I have installed, I see that
a handful of them do likewise.
Now, on one hand I can see that given the current state of Debian's
packaging tools, removing an entire directory can be the convenient
thing to do. If a package maintains a bunch of configuration files
(not conffiles -- dpkg knows how to delete those) in the directory
then "rm -rf" is sure to remove them all.
However, "rm -rf" is always a dangerous command to use. Configuration
directories are often shared; add-on packages may store things in the
configuration directories of the packages to which they add things on,
especially if the latter uses run-parts to run hook scripts. Sometimes
one package Replaces another and hijacks the latter's configuration
files; but these will be improperly deleted if the admin later purges
the original package. And admins may store things in /etc/
subdirectories. I think it would be better if packages removed only
files that they have created.
One may want to treat /etc/foo/ differently from, e.g., /var/lib/foo/ .
I would never store anything additional in /var/lib/foo/ because it
wouldn't surprise me if a package did "rm -rf /var/lib/foo/" on purge.
I know of no policy section that pronounces on this. Am I overlooking
one?
If not, what do think of this? When is it OK for a package to
"rm -rf /etc/foo/" on purge?
--
Thomas Hood
Reply to: