I'll be uploading dpkg 1.16.2 targeting unstable, by the end of
this weekend or beginning of next week the latest (after some final
polishing). Some pretty important points follow, the first section
On-disk db damage
The previous multiarch in-core db layout was bogus, resulting in a
possible inconsistent or broken on-disk db. If you are running any
dpkg derived from code that has never been in the main git repo (this
includes dpkg from the jenkins test builds [T], dpkg from experimental,
dpkg from Ubuntu, one of the personal pu/ branches, etc),
any of the
following might affect you.
With those dpkg versions, when installing a M-A:same instance of
package P arch A, when a previous non-M-A:same version of package P
arch B was present in a config-files state, the installation would
incorrectly remove the control files on the infodb for the arch B
instance. You should check for any packages in the status db w/o
matching files under /var/lib/dpkg/info/.
Another effect of the bogus in-core db layout affected the disappearing
logic, so if you have been running any such dpkg versions, you should
also check in the logs that no package has been improperly disappeared,
although the installed files should still be present.
And finally (well, these are just some of the effects I've explicitly
looked for after revealing them through code review, there could be more
related to this, but I've not bothered after having reworked the in-core
db layout), upgrading from those versions to the new dpkg 1.16.2 might
cause the status db to get messsed up in some conditions. Before
upgrading, you should either downgrade to a non-multiarch enabled dpkg, or
make sure there's no package present (i.e. with status >= config-files)
with a mix of M-A:same and non-M-A:same instances. If there's such package
with two instances, the new dpkg will consider that a “cross-grade” and
as such replace one of them with the other, depending on the order they
are parsed, but leaving any control files untouched; if there's more than
two instances the new dpkg will outright refuse to parse such bogus and
inconsistent status db.
Do not file any bug report if you upgraded from a system with a damaged
db, w/o first reproducing it on a clean system.