Re: Bug#1198: dpkg silently fails to install a file
Bruce Perens writes ("Bug#1198: dpkg silently fails to install a file"):
> I am using dpkg version 65 which I built from source, but this problem existed
> in version 63 as well. To demonstrate, retrieve the files from
> ftp.pixar.com:/pub/bruce/dpkg-problem . These include a sysvinit package and
> a debugging log from my installation made with -D01777. The package contains
> /etc/init.d/halt. I have removed /etc/init.d/halt from the system before
> installing the package. Dpkg creates /etc/init.d/halt.dpkg-new and then
> removes it without prompting me, and at the end of the run there is no
> /etc/init.d/halt .
>
> It also fails to replace a zero-length /etc/init.d/halt , if I create one.
> It doesn't prompt me about replacing it as it should, it just fails.
/etc/init.d/halt is listed as a conffile. In the transcript we see:
D000200: conffderef in=`/etc/init.d/halt' current working=`/etc/init.d/halt'
D000200: conffderef nonexistent
D000020: deferred_configure `/etc/init.d/halt' (= `/etc/init.d/halt') useredited=1 distedited=0 what=2
So, dpkg thinks:
(a) That you, the user, have edited the file. This is correct.
(Removing the file counts as `editing' it, because for many
configuration files the absence of a file is meaningful.)
(b) That the package maintainer hasn't edited their version of the
file since the last time the package was installed. dpkg can tell
this because it records the MD5 checksum of the distributed version of
the file when it does conffiles processing, so that the next time it
can see if it's just the same file again. I presume that this is
correct too.
So, based on this, dpkg has correctly decided to preserve your
system's (modified) configuration information through package
reinstallation. This is the whole point of conffile processing !
(`what' is an enum saying what to do, and value 2 is `cfo_keep',
meaning to keep the user's file and discard the newly-unpacked one
without prompting or leaving behind a .dpkg-new file, or without
disturbing any backup file that was there before.)
If dpkg is wrong when it thinks that the version in the package has
not been changed then it is a bug. In this case please check the
values of the MD5 checksums in the /var/lib/dpkg/status file, so that
we can see whether dpkg is failing to put the right checksum in the
file or failing to act correctly given the correct checksum, or both.
I'm closing this bug report.
Ian.
Reply to: