I tried to run dpkg-fsys-usrunmess from systemd’s emergency mode,
thinking that this would be safer, since nothing else would be
running.  This tickled a bug in systemd (see #991185) and got
dpkg-fsys-usrunmess killed in the middle of its run—specifically,
during the ‘dpkg --pending --configure’ operation.  As you can
probably imagine, this is a really bad time for the process to be
interrupted.  I have a *lot* of experience cleaning up after breakage
in unstable and it still took me five hours this time.

In another bug, I suggested a stopgap measure for the specific thing
that went wrong with dpkg-fsys-usrunmess this time, but a more
thorough fix would be to make dpkg-fsys-usrunmess restartable.  Each
phase of the operation could be made idempotent on a file-by-file
basis simply by ignoring failures due to the rename or whatever
already having happened, and in between phases it could checkpoint
itself in a file in the shadow directory.

If I get time this weekend I’ll try to come up with a patch.

The relevant program got removed from dpkg in the 1.22.12 release,
with:

https://git.dpkg.org/cgit/dpkg/dpkg.git/commit/?id=12e3bc2991ac27f73545a246bb95b84fb8d262c9

Closing, these reports.

Thanks,
Guillem