Bug#948041: impossible to update libbpf without updating the kernel

[Jonathan Nieder <jrnieder@gmail.com>]

retitle 948041 libbpf-dev: please build from https://github.com/libbpf/libbpf
reassign 948041 libbpf-dev
merge 942903 948041
quit

Hi,

Julia Kartseva wrote:
> On Sun, 12 Jan 2020 09:51:55 +0100 Bastian Blank <waldi@debian.org> wrote:

>> Why should we?  If the upstream developers decide to maintain it
>> independently, aka don't use the kernel repo as true source, or better,
>> remove the source from it, then we have something to do.

I agree --- if upstream development were happening in
https://github.com/libbpf/libbpf then this would be a no-brainer.  It
appears to instead be a mirror of the source that's in the kernel
repo, though.

> Why should we switch from kernel sources to GH is a frequently asked
> question so the reason was explained in libbpf README [1].

If I'm reading that correctly, the intent appears to be that it would
allow faster libbpf upgrades.

In the context of the Debian project, that could go both ways.  The
Linux kernel packages are very well maintained.  New versions appear
in stable-backports pretty quickly, and that's *less* likely to happen
with a separate libbpf source package.  Binary package dependencies do
not force an end user to use the same version of the kernel as
userspace tools like this one.  Debian even permits binary packages to
have different version numbers from the source package they were built
from.

Depending packages would likely use Debian's shlibs or symbols
mechanism (if upstream provides symbol versioning, that is very
helpful) to automatically produce appropriate dependencies.  More
details about this are at
https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#dependencies-between-the-library-and-other-packages

So this appears to impose exactly the same costs and benefits as any
other instance where someone splits a binary package that comes from
the same upstream source package into a separate Debian source
package.  Sometimes that is the right thing to do, especially when the
Debian maintainers for the two packages do not work very closely
together.  Is that the case here?

Is there some underlying need that we could address more directly?
I think I'm missing some piece of the motivation here.

Thanks,
Jonathan

> [1] https://github.com/libbpf/libbpf#distributions