Bug#948041: impossible to update libbpf without updating the kernel
Hi Jonathan,
On Wed, Jan 15, 2020 at 06:12:05AM +0000, Jonathan Nieder wrote:
> 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.
That will be difficult as all of them are dependent on the ftrace hooks
that are in the kernel.
>
> > 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.
Yes, one of my intent. Faster and independent.
>
> 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.
Agreed. I recently had to add libtraceevent which is also another one
in kernel source.
>
> 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?
Absolutely no. Atleast not from my side. As said before I had the
opportunity to do the packaging for libtraceevent and I had all the
help and guidance from the kernel team.
>
> Is there some underlying need that we could address more directly?
> I think I'm missing some piece of the motivation here.
Going back to the history of why I started this bug report. I was added
in a discussion about libtraceevent and Steven (upstream developer of
libtraceevent) was asking how can he make changes to the library without
releasing a new version and that the distros should not pick up as that
will still be premature and not tested enough. I could not suggest
anything as libtraceevent will be picked up autumatically when the next
kernel is packaged and as a result libtraceevent also, even though it
might still be in the development state. And at that point, Jiri Olsa
said that libbpf moved to github for this same reason.
So, here are my motivations for this bug report:
1) It will allow independent packaging.
2) It will not package something which is still in the middle of
development and not released yet by the developers.
--
Regards
Sudip
Reply to: