Important information regarding upcoming dpkg 1.16.2 upload
 

Hello,

For people who have been playing with multiarch and are scared by
Guillem's (uncoordinated) announce, I have written a small script
to detect whether you have been affected by one of the theoretical
problems that Guillem diagnosed (you only need libdpkg-perl and perl).

If it outputs nothing on your system, then you're fine. Otherwise
it should give you some instructions to follow to bring it back to a
coherent state.

On Sat, 10 Mar 2012, Guillem Jover wrote:
> 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/.

The script checks for this but dpkg would already output a warning
anyway ("files list file for package `%.250s' missing, assuming
package has no files currently installed.").

> 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.

I don't check this but dpkg prints an explicit message about disappearance
of packages and AFAIK a normal apt-get upgrade should never trigger the
case where a package can be improperly disappeared. It was only seen when
trying to replace a package by its foreign counterpart which was not
really allowed in the first place.

Checking your dpkg logs doesn't hurt though.

> 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.

The script verifies that any package with multiple instances are correctly
marked as Multi-Arch: same.

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/

Important information regarding upcoming dpkg 1.16.2 upload
 

Hello,

For people who have been playing with multiarch and are scared by
Guillem's (uncoordinated) announce, I have written a small script
to detect whether you have been affected by one of the theoretical
problems that Guillem diagnosed (you only need libdpkg-perl and perl).

If it outputs nothing on your system, then you're fine. Otherwise
it should give you some instructions to follow to bring it back to a
coherent state.

On Sat, 10 Mar 2012, Guillem Jover wrote:
> 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/.

The script checks for this but dpkg would already output a warning
anyway ("files list file for package `%.250s' missing, assuming
package has no files currently installed.").

> 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.

I don't check this but dpkg prints an explicit message about disappearance
of packages and AFAIK a normal apt-get upgrade should never trigger the
case where a package can be improperly disappeared. It was only seen when
trying to replace a package by its foreign counterpart which was not
really allowed in the first place.

Checking your dpkg logs doesn't hurt though.

> 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.

The script verifies that any package with multiple instances are correctly
marked as Multi-Arch: same.

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/