Re: Packaging bpftool and libbpf: GitHub or kernel?

["Toke Høiland-Jørgensen" <toke@redhat.com>]

Shung-Hsi Yu <shung-hsi.yu@suse.com> writes:

> A side note: if we want all userspace visible libbpf to have a coherent
> version, perf needs to use the shared libbpf library as well (either
> autodetected or forced with LIBBPF_DYNAMIC=1 like Fedora[4]). But having to
> backport patches to kernel source to keep up with userspace package (libbpf)
> changes could be a pain.

So basically, this here is the reason we're building libbpf from the
kernel tree for the RHEL package: If we use the github version we'd need
to juggle two different versions of libbpf, one for the in-kernel-tree
users (perf as you mention, but also the BPF selftests), and one for the
userspace packages. Also, having libbpf in the kernel tree means we can
just backport patches to it along with the BPF-related kernel patches
(we do quite extensive BPF backports for each RHEL version). Finally,
building from the kernel tree means we can use the existing
kernel-related procedures for any out of order hotfixes (since AFAIK
none of the github repositories have any concept of stable branches that
receive fixes).

YMMV of course, but figured I'd share our reasoning. To be clear,
building from the kernel tree is not without its own pain points (mostly
related to how the build scripts are structured for our kernel builds).
We've discussed moving to the github version of libbpf multiple times,
but every time we've concluded that it would be more, not less, painful
than having the kernel tree be the single source of truth.

-Toke