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