[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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: