Comment 14 for bug 1560797

As pitti can't reproduce it with a clean system there is a good chance an "unrelated" package from a PPA or cruft from an earlier upgrade confuses apt (as far as I remember PPAs are disabled on upgrade in Ubuntu, so it can't be new "unrelated" packages at least). These bugs are everyone’s favorite and log-staring usually doesn't work that well, so being able to reproduce this would be very nice…

What we can try is testing with the /var/lib/dpkg/status file from BEFORE the upgrade. Backups of this file can be found in /var/backups: The file "dpkg.status.X.gz" (where X is a number and .gz optional if X is 0) modified last before the upgrade would be good to have. Note before uploading: This file includes information about ALL packages you have (or in that case had) installed and in which version (which you might or might not consider private/personal information, but that applies already to most log files, too).

Assuming we would have such a file we could try on a THROWAWAY system: -o dir::state::status=/path/to/file -o Debug::pkgAcqArchive::NoQueue=1 -o Debug::pkgDpkgPM=1
(theoretically its possible to run this on a system you wanna keep, but theoretically there is also no problem with juggling a bunch of running chainsaws… until something goes wrong in practice)
The output will likely be a mile long including the exact commands apt would have used to call dpkg. If that exposes the wrong order we are "good".