On Fri, Jan 31, 2020 at 4:11 PM Ben Hutchings <b...@decadent.org.uk> wrote: > > 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 <wa...@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.
Since, bpftool will also be in userspace, so I am guessing that it will also have the same problem as libbpf and the upstream developers might again think of moving to github. But whatever is the case I am sure we can think of something to fix that problem if it arises. > > So on balance I support moving libbpf out to a separate source package. Thanks Ben. As discussed, I will raise a merge request on the kernel repo to remove libbpf building bits. And then use this bug to deliver the new source package. -- Regards Sudip
