NAK: [SRU][BIONIC][PATCH v2 0/2] add bpftool to linux-tools-common

[Seth Forshee]

On Wed, Oct 09, 2019 at 02:10:46AM +0100, Quentin Monnet wrote:
> 2019-09-27 07:38 UTC-0500 ~ Seth Forshee <seth.forshee at canonical.com>
> > On Mon, Sep 09, 2019 at 12:39:21PM +0100, Quentin Monnet wrote:
> >> BugLink: https://bugs.launchpad.net/bugs/1774815
> >>
> >> [Impact]
> >>
> >> bpftool is a debugging and introspection tool for BPF elements,
> >> developed by the BPF kernel community. It is essential to list and dump
> >> BPF programs and maps loaded on the system. Its sources are located in
> >> the kernel repository, and because it is not packaged, administrators
> >> willing to use bpftool must download the whole kernel sources, compile
> >> and install the utility.
> >>
> >> [Fix]
> >>
> >> Adding bpftool to linux-tools and linux-tools-common packages makes it
> >> easily accessible. These packages are already used to provide other
> >> tools located in the kernel repository, such as perf.
> >>
> >> Because the bpftool version provided with kernel 4.15 does not build
> >> properly (API changed at some point in bfd.h from binutils-dev),
> >> backport a patch from 4.16 to fix the calls to libbfd's disassembler.
> > 
> > What should be done instead is to remove binutils-dev from the package
> > build-depends, as binary packages should not have dependencies on
> > libbinutils. It causes linux-tools to be locked to a specific binutils
> > version, causing issues if binutils needs to be updated.
> > 
> > We've gone through this before with perf, where we disabled use of libfd
> > in perf but seemingly forgot to remove the binutils-dev build-depends
> > (I've looked through our history to confirm that the dependency was only
> > added for perf). I've already removed the dependency in eoan, and we
> > should do the same when bringing bpftool to older releases.
> > 
> > Thanks,
> > Seth
> 
> Hi Seth,
> 
> Thanks for the feedback. You removed binutils-dev from the dependencies
> in commit 721d5f0c5807, right? As you mentioned, we loose some
> functionalities by doing so. For bpftool, this means no disassembling of
> the JIT-compiled code. I'd like to keep that feature if possible, but I
> understand the dependency on a specific version of binutils-dev is
> painful to manage :s. Do you see any alternative solution that would
> allow keeping binutils-dev?

The binutils-dev package description forbids dependencies on libbfd:

 This package includes header files and static libraries necessary to build
 programs which use the GNU BFD library, which is part of binutils.  Note
 that building Debian packages which depend on the shared libbfd is Not
 Allowed.

My understanding is that this is because libbfd does not promise ABI
compatibility, and we would end up locked to a specific libbfd version
meaning binutils updates get blocked by the kernel also needing to be
updated. Then once both are updated the tools packages for any older
kernels will not have the libbfd version they need. As long as this is
the situation with libbfd I don't know any way around it.

> If not, and regarding bpftool compilation: binutils-dev was made
> optional in kernel patch 29a9c10e4110, in linux v5.0 (so not in bionic's
> kernel). Would you have me backport this patch instead, then (plus the
> patch to remove binutils-dev from build-depends)?

Yes, from what I know about the situation this is probably the only way
forward currently.

Thanks,
Seth