[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1114917: Lintian give E:binary-from-other-architecture on eBPF *.o files

Note: I don't help with Lintian, eBPF, or have any authority on this issue. Nevertheless I want to make sure this doesn't get lost, if for no other reason than to be a "devil's advocate" to provoke thought.

For the benefit of the Lintian folks and others thinking about how to address this, please take a peek at my remarks on debian-devel which are attached or can also be seen at https://lists.debian.org/msgid-search/7fa5675f5f658471d4cbb51a0f583337%40posteo.net

Basically there are two conditions that are simultaneously necessary here for the Lintian error: an eBPF (or other esoteric non-Debian-arch machine code) file, and installing it into the /usr/lib/TRIPLET/ multiarch-style path. (The necessity of the latter condition is not obvious from the subject line, nor from Lintian's error name, so I want to affirm this.) Simon said in filing this report
> I'm not certain where these files should be placed, but it seems /usr/lib/bpf/nsd/ isn't necessarily an obvious incorrect place for objects for a different architecture, or is it?

Simon is right that there's no obvious, or even practical problem, if this were to be allowed. However, it has been affirmed that "bpf"—despite its brevity—is a multiarch tuple, one that corresponds to the enclosed binaries, and packages (even Arch: all) ones trampling on multiarch paths not of their native architecture is very broadly prohibited. Because the informative rationale in Debian Policy asserts this is for the sake of forwards compatibility to allow new ports to use their multiarch paths without those being preempted, this must be interpreted as including multiarch tuples that Debian doesn't support as a native architecture; there is no known reason to contest that understanding. This prohibition is almost surely not helping anyone in this case, and that informative Debian Policy rationale would never be relevant here, but going by what Debian Policy says, the use of /usr/lib/bpf/ is prohibited, and the informative rationale doesn't contradict this.

Except for my opinion that Debian Policy technically prohibits any package from installing anything to /usr/lib/bpf/ (or /usr/lib/x86_64-w64-mingw32/, /usr/lib/sh-elf/, /usr/lib/pdp-11/, etc.), this would be a great case for Lintian overrides. The purpose of Lintian overrides isn't to work around bugs, but I think it's a sort of molly guard that says "Yes, I've thought about this really hard and I know what I'm doing." Shipping foreign library binaries for use in cross compilation (like for Windows) is the typical example of where this is deserved. Especially a package including a Windows binary when it's not supposed to, or an eBPF object shipping in a non-Linux binary package, is almost surely an error, and a grave one if source is not provided. (This sort of thing isn't so far out; I filed #1112162 where an entire *GNU/Linux virtual machine* was in a binary package and slipped under the radar!)
--- Begin Message --- 
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.
--- End Message ---

Attachment: signature.asc
Description: This is a digitally signed message part

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply to: