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

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



On Wed, 2020-01-15 at 12:50 +0000, Sudip Mukherjee wrote:
> 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.

This is a potential benefit, but probably only in the run-up to a
release when we might fix the kernel version early.

[...]
> > 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.
[...]

However, this ability to release libbpf *less* often also seems
important, and I think this point has been missed.

I have some concern about whether this might prevent us building
bpftool in future (if it depends on recent changes in libbpf) but
that's hypothetical at this point.

So on balance I support moving libbpf out to a separate source package.

Ben.

-- 
Ben Hutchings
73.46% of all statistics are made up.


Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: