On Sun, 19 Jan 2020 22:32:22 -0800 Andrii Nakryiko
wrote:
> Libbpf releases are only loosely synchronized with kernel releases,
> and it's only due to current convention we established within
> community. There is nothing preventing multiple releases of libbpf
> between two releases of kernel. So having Linux distributions use
> Github's release tags ensures that all of them are building from
> exactly the same source code version.
>
> > "No ties to any specific kernel, transparent handling of older kernels."
> >
> > What? Either they are upstream for it or patch the source. But this
> > point means it can't be a direct mirror. So what is it?
>
> It is mostly a direct mirror, with some extra Github-specific stuff
> beside (like Travis CI testing, etc). All the libbpf source code fixes
> do go through bpf-next tree, though.
>
> But the point here was that libbpf itself is not built with any
> particular kernel version in mind. It is by design possible to use the
> very latest libbpf against a pretty old kernel version and this will
> work: libbpf will degrade some of the features (e.g, BTF type info
> associations), but everything will keep working otherwise (unless user
> requests feature that requires latest kernel version, of course: in
> that case BPF program will fail to load and libbpf will return
> corresponding error code).
+1
Having libbpf packaged from GH would spare Linux user space developers from
headache of supporting different versioning across distributions, e.g. in
Fedora and Debian.
Libbpf releases are independent from kernel releases and mapping from
kernel to libbpf versions will confuse and complicate developers.
Libbpf from GH should be a common denominator across distributions, so
Debian doesn't create a corner case.
