[lkml]   [2019]   [Dec]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCHv4 0/6] perf/bpftool: Allow to link libbpf dynamically
On Thu, Dec 05, 2019 at 09:35:48AM +0100, Jesper Dangaard Brouer wrote:
> I don't think that is a good idea. You are creating double work and
> wasting distro developers time. Let me explain:
> 1. First of all, GitHub libbpf does not have a stable branches (which
> makes sense, given this is a read-only clone of kernel tree). Thus,
> distro developers have to maintain that themselves, in their internal
> package tree (that is based on GitHub libbpf).
> 2. Kernel BPF changes usually require updates to libbpf, as selftests
> uses libbpf. Thus, the distro kernel backporter is already required to
> backport libbpf parts.
> This is double work, the code changes to libbpf are now maintained in
> two places for the distro.

I totally agree with Jesper here.

I don't know how the situatiom with packaging libbpf and bpftool looks
like in Fedora/Centos/RHEL now, but in openSUSE we would like to build
both of them from the kernel source - use kernel-source package as a
requirement and use the kernel tree from /usr/src/linux to build those.
We do that for bpftool and perf currently.

So far we are building bpftool and perf without libbpf being dynamically
linked, so there is no dependency between those packages, although we
would like to change it as soon as we find a consensus on this series of

> The disadvantage for distros to package libbpf (+ bpftool and perf) off
> their distro kernel tree is that a fix to libbpf, requires rolling a
> new kernel minor release. The solution to that is simply that distro
> package for libbpf have a separate (RPM) spec file, with own
> versioning, which sources points to distro kernel tree.

That's a great idea. So far, we are using the same version for kernel,
bfptool and perf, but all of these have separate RPM specs, so we can do


 \ /
  Last update: 2019-12-05 13:09    [W:0.120 / U:0.196 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site