Dropping multilib [Re: Bug#1100544: glibc adds some conflicts letting gcc-14-cross ftbfs]

[Helmut Grohne <helmut@subdivi.de>]

Hi Matthias,

On Sat, Mar 15, 2025 at 12:03:37PM +0100, Matthias Klose wrote:
> How many users are affected by this? If users are confused by multilib
> packages, then let's remove them in trixie. No need to have them anymore in
> forky, I assume.  People can use the cross compilers instead.

I am wondering whether this is polemic or serious.

I have been arguing in favour of removing multilib for quite some years
and perceived resistance from you. As far as I understand it, Aurelien
would also be happy to drop those packages. (Can you confirm?) We
already dropped many of the multilib libraries. What is left are these:

 * aflplusplus (?)
 * elfutils (uses multilib compilers in tests)
 * fasm (installs /usr/bin/fasm as an i386 executable on amd64)
 * fis-gtm (?)
 * gcc-* (recursive)
 * gnu-efi (I suppose this is easily moved to cross toolchains)
 * grub2 (?)
 * ispc (?)
 * libnss-extrausers (?)
 * linux (?)
 * llvm-toolchain-* (?)
 * memtest86+ (should likely use cross toolchains)
 * multiboot (really should be using gcc-x86-64-linux-gnu)
 * ncurses (needs to drop multilib libraries, used by readline only)
 * oaklisp (32bit-only)
 * readline (needs to drop multilib libraries, no rdeps)
 * rr (?)
 * sbsigntool (?)
 * smlnj (?)
 * snapd (?)
 * strace (needs to drop the strace64 package, no rdeps)
 * syslinux (should likely use cross toolchains)
 * user-mode-linux (?)
 * valgrind (?)
 * wraplinux (?)
 * x86info (?)
 * xbyak (test dependency)
 * xen (?)
 * zlib (needs to drop multilib libraries, required by gcc)

Do we now have agreement that we want to get rid of multilib? I'd be
happy to work on that if there is consensus on that goal.

Helmut