Control: retitle 825385 "dpkg: Does not know the native arch for another db"
Control: forcemerge 825385 -1
Hi!
On Thu, 2022-09-22 at 22:13:34 +0200, Johannes Schauer Marin Rodrigues wrote:
> Package: dpkg
> Version: 1.21.8
> Severity: normal
> X-Debbugs-Cc: jo...@debian.org
> steps to reproduce on amd64:
>
> #!/bin/sh
> set -exu
> mkdir -p dpkgroot/var/lib/dpkg
> echo "arm64" > dpkgroot/var/lib/dpkg/arch
> cat << 'END' > dpkgroot/var/lib/dpkg/status
> Package: perl-base
> Status: install ok installed
> Architecture: arm64
> Version: 1
> END
> mkdir -p pkg/DEBIAN
> cat << 'END' > pkg/DEBIAN/control
> Package: perl-modules-5.34
> Version: 1
> Architecture: all
> Depends: perl-base
> END
> dpkg-deb --build pkg pkg.deb
> PATH=/usr/sbin:/usr/bin:/sbin:/bin dpkg \
> --log=/dev/null \
> --force-not-root \
> --force-script-chrootless \
> --root=dpkgroot \
> --install pkg.deb
>
> result:
>
> Preparing to unpack pkg.deb ...
> Unpacking perl-modules-5.34 (1) ...
> dpkg: dependency problems prevent configuration of perl-modules-5.34:
> perl-modules-5.34 depends on perl-base.
> dpkg: error processing package perl-modules-5.34 (--install):
> dependency problems - leaving unconfigured
> Errors were encountered while processing:
> perl-modules-5.34
>
> If one changes "Architecture: arm64" to "Architecture: amd64" (the
> architecture of my native dpkg) it works.
>
> Maybe the prolbem is, that dpkg treats perl-modules-5.34 (it being
> arch:all) implicitly as the native arch which is (wrongly) chosen to be
> amd64 instead of arm64. And in that case, perl-base:arm64 cannot satisfy
> its dependency.
As mentioned on IRC, the problem here (and on #825385) is indeed that
dpkg considers its own arch the native one, and when operating on a
cross-arch chroot, that goes wrong, both in dependency resolution
and when outputting arch-qualified package names for example.
Fixing this properly is tricky though, because there are multiple
requirements in tension here:
* The external dpkg should be able to tell what's the arch for the
internal one w/o having to execute anything (that it might not be
able to run anyway).
* Setting a file on the database means either requiring a dpkg
maintscript (for the bootstrap phase) which we are trying to get
rid of, or offloading this to the bootstrappers (even worse), it
also means it could be modified w/o dpkg noticing, which can break
dependency resolution from an existing system.
* Shipping a file with the arch would seem like the best option (as
that is checksummed) and not in the db, but that means then, that
pathname under /usr needs to be selectable too at run-time, as
that encodes configure-time vendor-specific fsys layout.
* Setting that directory from the config file is currently
problematic as dpkg does not have a way to specify a different
config directory.
* Perhaps just adding a new --foodir option to dpkg could be enough
for now, if the inner dpkg uses a different pathname, in the
same way if it uses a different database pathname.
* But then only specifying the db pathname would no longer be
enough, and dependency resolution and arch-qualifying would still
be wrong. :/
* But then if the file does not exist (or cannot be found in the
«right» place) it could still fallback to the currently running
native arch, but that looks flaky (not worse than now, though,
but not ideal). :/
I guess I can prototype something with the --foodir idea though, but
that's still rather meh.
Thanks,
Guillem
