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 than
N: 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/other
This 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.
