This turns out to be somewhat harder than it looks. dpkg does conffile processing during configuration. If anything goes wrong during conffile processing, it stops there; it does not (currently) keep a record in the status file of which conffiles have been processed and which are as yet undone. Instead, the processing of each individual conffile is made idempotent. That way a second dpkg run can tell if this file has already been processed.
The way this is done is that the new package's version of the file is left in .dpkg-new from the unpack phase. The processing renames it away to a different name. So an unprocessed conffile has a .dpkg-new and a processed one does not. However in the case of a disappearing conffile there is no .dpkg-new, so it is not easy to tell what's going on. Also, since the file has been removed from the new package, currently, once the new package has been unpacked, there is no record of it in dpkg's databases. I propose the following new arrangements: * Until the conffile is processed (during configuration), it remains owned by the package and listed in its .list file and Conffiles field even though the new version of the package doesn't contain the file. * However, we introduce a new syntax in the Conffiles status file field: optionally, after the md5sum, we add the annotation `disappearing'. This annotation is there exactly in the case where the conffile is only listed as part of the package because it was in a _previous_ version of the package and we haven't completed the conffile processing yet. * During the end of unpack processing, while the old files (ones on the old but not the new package) are being removed from the file list, if the old file was a conffile, we retain its entry in the status file's Conffiles field, with the old original hash, and we retain its entry in the file list. We add the `disappearing' annotation to the Conffiles entry. * During conffile processing, we check for the disappearing flag. If so we don't treat the nonexistence of the .dpkg-new file as telling us that the file has already been processed. Strictly, in this order, for each conffile: 1. check for .dpkg-new and `disappearing': .dpkg-new nonexistent not disappearing already done, do nothing .dpkg-new nonexistent disappearing goto 2, new arrangements .dpkg-new exists not disappearing process as we used to .dpkg-new exists disappearing error 2. check if locally modified; if not (or if file does not exist): delete it (if necessary) and goto 5. 3. ask user what to do 4. rename file to .dpkg-old if user says so, or just leave it (these two steps are where we do the algorithm Thomas Hood suggests, as modified by my followup). 5. post update to <package>.list and status file (in that order) with all trace of this file removed. * When we take over a Conffile entry from one package to another, during unpack, we clear the disappearing flag. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]