Hiya. So far we reached 5 arches having multilib flags: x86, mips, ppc, riscv, s390 (note: ppc just retracted their multilib support but I've left it commented out for further consideration).
Of those, only x86, mips and riscv actually ever had multilib profiles. In other words, the ABI flags for ppc and s390 were practically unused. While the large number of flags is practically invisible to user with all the USE_EXPAND hiding, it negatively impacts pkgcheck. When the number reached 10, CI became unusable. We're currently back down to 8, thanks to powerpc team, but the problem is going to happen again sooner or later. Ideally we'd improve pkgcheck but I'm not aware of anyone having a good idea how to do it. On the other hand, if I am consider the benefit of having large number of flags that will never benefit the majority of users (if anyone) vs. having much faster CI (= being able to run it more frequently, and therefore report problems faster), you can guess which way I prefer. The amd64 multilib was added for quite obvious reason -- we need it to run prebuilt 32-bit software. The whole multilib thing was designed against this particular concept -- and so multilib affects mostly libraries which are used as dependencies of prebuilt software. We barely have any multilib *programs*. Now, the question is: why do we have multilib on other arches? I'm not really aware of major prebuilt software for mips, ppc, riscv (this arch has barely started!) or s390. It really feels like cargo cult -- x86 has it, we should have it too. I would really prefer if we didn't create unnecessary complexity for theoretical benefit of having multilib, using a model that's unfit for any real use. And I would really prefer if new arches with no existing prebuilt software didn't start right away as multilib, especially when the only difference between the two parallel ABIs is whether doubles are passed in registers or not. Do you really think users having hardware capable of passing doubles in registers would benefit from building software in two versions, one passing them in registers and the other not, when the only consumers are native programs that will use the default ABI? I understand that mips has been multilib for years now, so removing those flags could cause real harm. However, ppc and s390 do not use multilib at all, so I'd like to kill their flags (ppc already agreed to that). And riscv is a completely new thing which doesn't seem to have any reason to actually have multilib, so I'd rather not see it introduced for silly PR reasons before someone actually *wants* to use it. What do you think? -- Best regards, Michał Górny
