I used /usr/lib/bpf/nsd/ for nsd 4.13.0-2 in experimental. Lintian gives an E: on this, so I suggest things needs to be improved further, but at least it will be possible to test XDP things now.E: nsd: binary-from-other-architecture [usr/lib/bpf/nsd/xdp-dns-redirect_kern.o]N:N: This ELF binary appears to have been built for an architecture other thanN: the one of the binary package being tested. This may occur when a N: pre-built binary is shipped in the package or when an attempt to N: cross-compile didn't work. N: N: Visibility: error N: Show-Always: no N: Check: binaries/architecture/otherThis one should be fixed on lintian side. Please fill a bug
Isn't Lintian correct that this is a Debian Policy violation, namely § 9.1.1(4) at https://www.debian.org/doc/debian-policy/ch-opersys.html#xpointer(html/body//*[@id="file-system-structure"]/ol/li[4]) ? This might be an oversight in the policy but it says
Packages must not install files to any triplet path other than the one matching the architecture of that package; for instance, an Architecture: amd64 package containing 32-bit x86 libraries must not install these libraries to /usr/lib/i386-linux-gnu.The informational footnote which spells out the reason as follows hints that the definition of "triplet" must be interpreted broadly as including triplets for architectures Debian hasn't been ported to:
This is necessary in order to reserve the directories for use in cross-installation of library packages from other architectures, as part of multiarch.
I was thinking about this policy requirement a few days ago, when working on packages for bare-metal microcontrollers (i.e. stuff that doesn't have a kernel). For example it appears that no package is ever allowed to install anything in /usr/lib/sh-elf/, this being the triplet for bare-metal SuperH MCUs, because no Debian binary package with this architecture type will ever exist. libnewlib-sh-elf-dev contains static libraries and headers for these MCUs to be used in cross-compiling, but in Debian's point of view, it's an Architecture: all package. Therefore it uses the directory /usr/sh-elf/ as a cross system root; this is a convention commonly used by the GNU tools. I believe the MinGW packages to cross-compile for Windows do the same thing. For that specific sh-elf example I'm not itching to use multiarch paths for gcc-sh-elf anyway because it's served well by multilib in my specific case. However, I think the prohibition on using /usr/lib/$ARCH for values of $ARCH that can never be true Debian architectures by their very nature, is probably an oversight in crafting Debian Policy.
In any case I think Lintian's interpretation accurately captures that provision as written, and considerations to amend or clarify policy should be made first.