Dear Maintainer,

While testing cross toolchains [1], dpkg bailed out when trying to
overwrite a shared file with different contents.

Particularly, /lib/ld.so.1 is different on powerpc, mips, and mipsel.
I only checked arches listed under 'Foreign Architectures' below;
upstream has list at https://sourceware.org/glibc/wiki/ABIList

Since ld.so is the single most important file on a system, it is hard-coded
in all existing binaries, but at least the conflict needs to be declared.

(Theoretically, Debian doesn't officially need to support binaries that
don't come from .deb packages or Debian-provided gcc, so it might be
possible to remove the conflict in the long term. Practically, it would
be dangerous to change it on native arches, but sufficient packaging magic
can ensure that users who don't opt in never see the difference.)

This is a known problem, but there is no way to define cross-architecture
conflicts with the current dependencies system, and the conflicts/provides
doesn't work either as long as we keep providing biarch or triarch
packages. This bug is therefore not going to be fixed until a technical
solution is found.

* split out ld.so into a separate debian package whose name depends on
the actual path
* mark that package Multi-Arch: none instead of Multi-Arch: same
* specify appropriate depends/conflicts/replaces/whatever
* Be VERY, VERY, careful that the symlink exists at all times during
the upgrade, no matter what the unpacked/installed status is of libc6
and the new package?

That way:
* libc6:amd64 will depend on
libc-ld-symlink-lib64-ld-linux-x86-64-so-2 (which must be from the
same arch. i.e. amd64)
* libc6:i386 will depend on libc-ld-symlink-lib-ld-linux-so-2 (which
must be from the same arch, i.e. i386)
* libc6:powerpc and libc6:mips will both depend on
libc-ld-symlink-lib-ld-so-1 (which must be from the proper arch, and
which automatically conflicts with the same package from another arch)
* People with special needs for cross-building can create an empty
Arch: all package and always pass --dynamic-linker=<multiarch path to
the linker> to ensure that we can run testsuites.

(I already tried using dpkg-divert to move the file out of the way,
but you can only do one diversion, so install at most two packages.)

That's not something possible, we don't want to break systems.