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