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]
