On Tue, 03 Mar 2026 at 13:06:13 +0200, Peter Pentchev wrote:
BTW is the unsupported-architecture example given on that page wrong?
I mean, it says to B-D on unsupported-architecture [!the-not-supported-arch],
and I think that's... kind of backwards?
I think so. src:lsp-plugins seems like a correct use:
Build-Depends: unsupported-architecture [armel hurd-i386 hurd-amd64],
(Even better if it was [armel hurd-any].)
I think the advice to use unsupported-architecture in devref is perhaps
more broad than it needs to be. If a piece of software explicitly
depends on Linux and is not intended to be portable to other kernels
(like systemd and Flatpak), or if it explicitly depends on one of a
finite number of CPU architectures for which it needed specific porting
and isn't intended to be portable to others (like Wine), I think it
still makes sense to use things like
Architecture: linux-any
Architecture: amd64 i386 arm64
The recommendation to use unsupported-architecture makes more sense for
cases where a piece of software is intended to be portable to "most"
architectures, but does make some assumptions that are not true
everywhere, for example this (which is no longer relevant in
testing/unstable because armel was dropped anyway):
# Needs native atomic operations, which most architectures do have
Build-Depends: unsupported-architecture [armel]
Because Architecture doesn't allow negatives:
# Not allowed
Architecture: !armel
before the introduction of the unsupported-architecture convention, a
package that doesn't work on armel would have needed a long list of all
the architectures that are *not* armel:
# Avoid this, use unsupported-architecture instead
Architecture: amd64 arm64 armhf i386 loong64 ...
which requires trivial packaging changes every time a new architecture
is added (but without needing specific porting in upstream code, like
e.g. valgrind does).
smcv
