Manoj Srivastava <sriva...@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 (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
