Bug#688295: Bug#801958: dpkg: ${binary:Package} inconsistently reported in foreign arch chroots

[Guillem Jover]

[ CCing 688295 for the explanations below. ]

Hi!

On Fri, 2015-10-16 at 12:23:43 +0200, Andreas Beckmann wrote:
> Package: dpkg
> Version: 1.18.3
> Severity: important
> Control: block 688295 with -1

> Host: stretch, amd64 (foreign: i386)
> chroot: sid, i386 (foreign: amd64)
> the chroot has the native libgtk-3-bin and the foreign hello:amd64 packages installed

[… arch-qualification examples …]

> I would expect the output to be consistent inside and outside the chroot
> but now with 1.18.3 the output is relative to the host architecture,
> not the admindir architecture which is a regression from jessie and breaks
> debsums. (jessie was not correct w.r.t. to the foreign arch package hello
> either but at least the native libgtk-3-bin was OK).

This was an intentional change in dpkg 1.18.0, commit
d658a8ec1110c9b3b20987cd903a54f59801117f:

,---
    libdpkg: Consider foreign packages ambiguous in need of arch-qualifier

    With cross-arch dependencies, foreign arch-qualified dependencies and
    foreign packages become really ambiguous in error messages, but also
    on the usual progress reporting.

    Arch-qualifying foreign packages should be backwards compatible, because
    if a user had foreign packages installed on a pre-multiarch dpkg, then
    that was already out of spec. And if they do now, it means they have
    enabled multiarch. Keeping Multi-Arch:same packages always arch-qualified
    still makes sense because those will not appear on a non-Multi-Arch
    enabled distribution, and are required to distinguish which instance we
    are referring to.
`---

The actual problem here is that debsums is both accessing the internal
dpkg database, and implementing wrong heuristics.

In md5sums_path() it is inferring the database structure solely based
on the package name gotten from the dpkg-query call. But it is
ignoring the db info/format file, which specifies what the on-disk layout
of the db is. And it is not taking the Multi-Arch field into account when
deciding when to arch-qualify the pathname in the db. For format 1, only
Multi-Arch:same packages are arch-qualified, for format 0 no package is
ever arch-qualified (dpkg/src/infodb-format.c:pkg_infodb_get_file).

Ideally debsums should not access the internal dpkg db, and it would
switch to just use «dpkg --verify», which would remove the problem
entirely. Or we'd make it so that anything that it might need is
implemented properly in dpkg so that it can be either a very simple
frontend to dpkg or not be needed at all.

I think this is a problem in debsums of its own making. :) But I've just
realized that the documentation in dpkg-query for the binary:Package
field was not updated with that commit, so I think I'll close this bug
with that change.

Thanks,
Guillem