Bug#470633: Explicitly say obsolete configuration files may be removed

[Russ Allbery <rra@debian.org>]

Manoj Srivastava <srivasta@debian.org> writes:

>         This bug has not been looked at for a while. The wiki article:
>  states:
> ,----[  http://wiki.debian.org/DpkgConffileHandling ]
> |   If you completely remove a configuration file, you should make sure
> |   it's also removed from the disk. However if the user has modified it,
> |   then you have to preserve the user's modifications somehow in case
> |   they wish to refer to them (see also Policy 10.7.3). 
> |
> |   This can be done your preinst script when given the install or upgrade
> |   argument with a package version known to have the conffile that has
> |   been removed. 
> `----

>         I do think this makes  sense, and is definitely a good practice
>  (and thus belongs in the developers reference, at least, if not in
>  policy proper.

>         The argument I see for having it in policy proper is that a
>  conffile left behind which is no longer used has potential for
>  confusion, not only for humans, but other packages that may parse the
>  configuration.

Also, if I remember this discussion correctly, Policy currently could be
read as saying that a package isn't permitted to remove its obsolete
configuration files, so we should at least fix the wording to make it
clear it's permitted for packages to do that.

>         I also think we should consider what happens if the package is
>  subsequently purged; in that case, all the conffiles it uses are
>  purged -- but the conffile it no longer uses is left behind as cruft in
>  the system, which seems like a flaw.

It can be hard to track all of the historical checksums of configuration
files (consider logcheck-database, for instance), but I think it's
reasonable for Policy to say that packages should make a best effort to
remove obsolete configuration files on purge.  I believe puiparts is
already complaining about packages that don't do this.  We could start
with something lighter than should, or start with putting it in the
devref, I suppose.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>