On Wed, 28 Oct 2020 19:50:51 -0700 Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> wrote: > On Wed, Oct 28, 2020 at 7:34 PM Stephen Hemminger > <stephen@xxxxxxxxxxxxxxxxxx> wrote: > > > > On Wed, 28 Oct 2020 19:27:20 -0700 > > Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> wrote: > > > > > On Wed, Oct 28, 2020 at 7:06 PM Hangbin Liu <haliu@xxxxxxxxxx> wrote: > > > > > > > > On Wed, Oct 28, 2020 at 05:02:34PM -0600, David Ahern wrote: > > > > > fails to compile on Ubuntu 20.10: > > > > > [...] > > > > You need to update libbpf to latest version. > > > > > > Why not using libbpf from submodule? > > > > Because it makes it harder for people downloading tarballs and distributions. > > Genuinely curious, making harder how exactly? When packaging sources > as a tarball you'd check out submodules before packaging, right? > > > Iproute2 has worked well by being standalone. > > Again, maybe I'm missing something, but what makes it not a > standalone, if it is using a submodule? Pahole, for instance, is using > libbpf through submodule and just bypasses all the problems with > detection of features and library availability. I haven't heard anyone > complaining about it made working with pahole harder in any way. I do believe you are missing something. I guess I can be the relay for complains, so you will officially hear about this. Red Hat and Fedora security is complaining that we are packaging a library (libbpf) directly into the individual packages. They complain because in case of a security issue, they have to figure out to rebuild all the software packages that are statically compiled with this library. Maybe you say I don't care that Distro security teams have to do more work and update more packages. Then security team says, we expect customers will use this library right, and if we ship it as a dynamic loadable (.so) file, then we can update and fix security issues in library without asking customers to recompile. (Notice the same story goes if we can update the base-image used by a container). -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer