I often use the kernel config option CONFIG_IA32_EMULATION=n "Include code to run legacy 32-bit programs under a 64-bit kernel. You should likely turn this on, unless you're 100% sure that you don't have any 32-bit programs left." And as of kernel 6.7 this is going more mainstream, see https://www.phoronix.com/news/Linux-6.7-IA32-Emulation-Boot This 32-bit disablement is not tracked sufficiently. Some machinery is there to detect it in the glibc ebuild unpack phase, but thats it. If other ABI_X86_32 packages are pulled in, they will fail. Reproducible: Always Actual Results: Yes I know Obviously its wrong to use multilib with a mismatched kernel, but due to chroots and containers, it becomes increasingly likely to get hit by this. Expected Results: Ideally, Emerge should detect this upfront ahead of time and warn you, not just schedule known multilib builds (ABI_X86_32) under a known incompatible kernel only to inevitably have them fail. Also - Can (32) bit packages NOT be pulled in at all ? They can be delayed until such time as they CAN actually be built (I currently need to use --keep-going to workaround these build failures and it has to re-run all the prepares and stuff)
Created attachment 879745 [details] libatomic X86 build failure
Created attachment 879746 [details] the glibc unpack has an IA32 check - other packages do not
This really isn't a "profiles" issue. Profiles are simply configuration; they don't directly cause any messaging to be displayed to the user. It sounds like you are proposing an enhancement to the Portage package manager (emerge).
My opinion: this is too much hand holding. If you choose to disable CONFIG_IA32_EMULATION, you should be fully aware of what you are doing.
Agreed - this is PEBKAC, sorry. Don't set things you don't understand or don't understand the consequences of. Supposing there were an appropriate place to do this - like pkg_pretend in every multilib pkg, that'd slow things down so much, just to avoid a footgun in a niche situation. I'll call this WONTFIX given it seems I'm not alone on this. If another developer on the team wants to revisit it, we can.
*** Bug 941610 has been marked as a duplicate of this bug. ***
