Re: FWD: When conffiles get cut adrift
On Fri, Sep 06, 2002 at 01:36:03PM -0400, Joey Hess wrote:
> It it a package's job to deal with moving a conffile if the conffile is
> renamed.
I recently considered this problem in the context of bug 157871 (and
indirectly bug 154555), in which I complained that zsh, in
transitioning the location of its conffiles from /etc/ to /etc/zsh/,
abandons the versions in /etc/ (though it does mention the issue in
a debconf note). I had a discussion (in the bug log) with the
maintainer (Clint Adams) and came up with the sketch of a solution.
The main concerns are:
1. The upgrade should behave as much as possible like a normal
upgrade wrt locally-modified conffiles.
2. On typical systems, the old conffiles should be removed, but ...
3. Systems which for whatever reason depend on the old conffiles
shouldn't break. (Clint gave the plausible example of a locally
compiled zsh that uses the /etc/ files.)
My approach is:
1. Pop a debconf dialog explaining the move, and asking whether the
files in /etc/ should be preserved.
2. In the preinst, for each old conffile, check whether it has been
locally modified. If so, copy it from /etc/ into /etc/zsh/,
unless the target already exists (in which case do nothing).
3. Let dpkg do its conffile conflict resolution thing.
4. In the postinst, delete the old conffiles if the answer to the
question in (1) was no.
In the typical case, the user answers no to the debconf question,
and is not prompted about any conffile he did not edit. conffiles
he did edit are treated as usual, with one exception: If the old
default conffile in /etc/ was the same as the new default conffile
in /etc/zsh/, the user will get the conflict question (I believe
that dpkg normally would not prompt when the package's version of
the conffile hasn't changed).
This can probably be improved upon using ucf, but I don't know
whether it's ready to use and whether such a large change is
warranted.
Although this is somewhat complicated, it looks solid to me, and I
believe it would be better than making every user clean up the /etc/
files himself. Moreover, other packages will likely want to do the
same thing (and probably already have, though I don't know any
examples), so coming up with a standard mechanism will pay off.
Andrew
PS. Note this does not address the other issue in the original
message, that of a package orphaning a conffile (without providing a
replacement). This can be solved with only steps 1 and 4. Though a
more elegant solution might be to let dpkg own a conffile without
actually providing it.
Reply to: