Comment 6 for bug 901741

It occurs to me on analysis of apt that the debsums part of this cannot possibly cause an upgrade failure. The reason for this is that DPkg::Post-Invoke hooks are run in precisely three cases:

  1) waitpid for dpkg failed (i.e. some kind of programming error); return code from Post-Invoke is ignored
  2) dpkg exited with a non-zero wait status; return code from Post-Invoke is ignored
  3) every dpkg invocation in a complete apt run exited successfully

The mistake in my earlier analysis was that I believed that debsums might be run in the middle of an otherwise successful apt run. This is not so, both from code inspection and empirically. The only case in which a non-zero exit code from debsums can make the slightest difference to an upgrade is in case 3, and in that case it's running at the end of a successful apt run so can reasonably assume that apt left the perl packages in a sane state. Even if it fails there, the worst that happens is that it causes apt to exit non-zero after doing all its work; it's not going to convert a complete successful run into a partial failed run, which would be the real problem.

So, I think this is essentially cosmetic. It showed up as a problem in your original report because libwmf0.2-7's prerm had already failed, upon which apt attempted to run debsums as part of general cleanup, but it didn't actually make the situation any worse. If the libwmf0.2-7 problem hadn't been present, you wouldn't have seen a problem with debsums either.

I'll downgrade this to low and keep it open, because it might be worth changing debsums to catch these errors and add a clarifying note that it's probably due to Perl being mid-upgrade. However, based on the analysis above, I don't think we should muck around with debsums' exit code.