Control: tag -1 + wontfix
Control: severity -1 minor
07.08.2022 22:51, VA wrote:
Architectures that are not i386 or amd64 ship files like
/usr/lib/binfmt.d/qemu-x86_64.conf and /usr/lib/binfmt.d/qemu-i386.conf
However, i386 and amd64 flavours of the package ship neither.
The i386 flavour should ship x86_64 related files, and conversely.
This is very questionable and can not be done without querying particular system
capabilities at runtime.
The problem is that with i386 userland, users often run amd64 kernel
(on 64-bit capable machines). dpkg-architecture et all will report 32 bits,
but x64 executables will still run natively. This way, adding i386 binfmt
with qemu will break this.
It is more: you reboot such machine into i386 kernel, and now x64 binaries
will not work anymore, and qemu's binfmt support will be needed for x64
executables. Or put it backwards, - you install qemu when running i386
kernel, reboot the machine into amd64 kernel, and now you need to _remove_
qemu x64 binfmt support.
When thought about all this, I decided to omit x64 support on i386 userland.
All x86 machines these days are 64bit capable, only old machines does not
support x64 mode. And for those who does not support 64bit mode, emulating
x64 is very slow anyway. And it makes very little sense to emulate x64 on
x86, you can almost always install i386 version of software instead of x64
So overall, the issue is very minor (as in, with very limited use case),
and I think implementing it properly (with runtime detection) isn't worth
Marking it as wontfix for now.
Not having them prevents from using mmdebstrap to install an amd64 system from
a i386 system:
I suggest you to use x64 kernel there. Again, it is a very specific,
very limited use case.