On Sun, Sep 11, 2022 at 05:08:57PM +0200, Samuel Thibault wrote: >... > The issue we see is that some DDs end up setting a hardcoded list in > the "Architecture" field, rather than just letting builds keep failing > on these archs (and then possibly succeeding after some time whenever > somebody contributes a fix upstream that gets propagated to Debian). >...
I'd say it is the best solution when a package needs non-trivial architecture-specific porting for every architecture it supports. With "non-trivial" I mean not just adding a new architecture to a few #ifdefs, but serious upstream porting efforts. E.g. valgrind does not support riscv64, and if it would ever gain the support in a new upstream version I'd expect the maintainer to add that to the Architecture field when upstream announces support for a new architecture. But Architecture lists for expressing e.g. "64bit" or "little endian" are a real pain for everyone working on bringup of a new port. Which happens far more often than most people realize. There is not only riscv64 (64bit, little endian). Ports is about to start building for arc (32bit, little endian). There are people working on ports like arm64be (64bit, big endian), loongarch64 (64bit, little endian) and many other ports that might never end up being built in the Debian infrastructure (but some of them might get built by derivatives). Architecture lists containing all 64bit ports or all little endian ports create much extra work for anyone adding support for a new 64bit little endian architecture. > Samuel cu Adrian
