[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



X-Debbugs-Cc: debian-devel@lists.debian.org

On Fri, Jan 03, 2020 at 08:23:58PM +0000, Sudip Mukherjee wrote:
> On Fri, Jan 3, 2020 at 7:49 PM Bastian Blank <bblank@thinkmo.de> wrote:
> >
> > Hi Marco
> >
> > On Fri, Jan 03, 2020 at 06:59:36PM +0100, Marco d'Itri wrote:
> > > On Jan 03, Sudip Mukherjee <sudipm.mukherjee@gmail.com> wrote:
> > > > Do we package libbpf from their github repo independent of the kernel
> > > > update? Then we will need to remove the libbpf building bits from the
> > > > Debian kernel source and create a separate package for libbpf.
> > > This is what some of the upstream libbpf developers requested us to do.
> >
> > What I don't understand is, if the kernel git tree is the primary
> > location for this library, why should we use an external copy?
> >
> > What are the benefits of doing so?
> 
> The only benefit will be that we will be able to update the libraries
> irrespective of kernel update. libbpf v0.0.6 has been released in
> December but we will not be able to move to that version. The
> userspace application using this library is deprived of the benefit of
> the fixes that v0.0.6 brings.

Any thoughts on this please...

I have now done an initial packaging and can open an ITP if everyone
thinks we should move this out of debian kernel packaging.

And, I think I should also point out here that libtraceevent developers
are also moving to a separate repo which will have their final releases
rather then using the kernel repo. I will open a separate bug report for
them after they have decided where they want their new repo. And, libperf
might also follow suit after libtraceevent.

It might be better if we decide now what we want to do and tell them
accordingly.


--
Regards
Sudip


Reply to: