1 |
Hi, |
2 |
|
3 |
Please mark your package as ALLARCHES if at all possible. |
4 |
|
5 |
The <stabilize-allarches/> metadata.xml tag indicates to arch teams |
6 |
that the package is architecture independent and therefore testing on one |
7 |
architecture is sufficient. |
8 |
|
9 |
You can read more in the devmanual: |
10 |
https://devmanual.gentoo.org/keywording/#simultaneous-stabilization-on-all-architectures. |
11 |
|
12 |
We should do this even if your package is pure ~arch to simplify |
13 |
matters if it becomes a dependency or included in a stable request in future. |
14 |
|
15 |
It only takes a few minutes to check if your package is compiling anything |
16 |
or installing e.g. ELF files but can save arch teams a lot of time. |
17 |
|
18 |
Proactively doing this is a huge help and I’d be really grateful if maintainers |
19 |
could take the time to do this. |
20 |
|
21 |
Generally, unless the package seems somehow special, I wouldn’t |
22 |
restrict yourself to marking only your own packages ALLARCHES either. |
23 |
|
24 |
Tips: |
25 |
1) If you don’t know, ask somebody! Email me or ask in e.g. #gentoo-dev on IRC. |
26 |
|
27 |
2) Python packages are generally ALLARCHES, see the wiki: |
28 |
https://wiki.gentoo.org/wiki/Project:Python#ALLARCHES |
29 |
|
30 |
3) Perl packages don’t count. Technically, some COULD, but due to |
31 |
prominent usage of e.g. unpack() throughout the ecosystem, it’s best |
32 |
not to risk it for now. We may find a better way to check for problematic |
33 |
functions in future. |
34 |
|
35 |
4) graaff has advised that Ruby is in a similar situation. Far too often |
36 |
both Perl and Ruby end up exposing system internals. |
37 |
|
38 |
Thanks! |
39 |
Sam |