[SRU][K][PATCH 0/1] linux-tools-common should provide bpftool
Andrea Righi
andrea.righi at canonical.com
Tue Nov 8 15:42:51 UTC 2022
On Tue, Nov 08, 2022 at 03:34:51PM +0100, Stefan Bader wrote:
> On 07.11.22 11:34, Andrea Righi wrote:
> > [Impact]
> >
> > In Debian, 'bpftool' is provided as a separate binary package.
> >
> > There are other packages in the archive (i.e., bpfcc,
> > lava-dispatcher-host) which reference this package.
> >
> > Rather than patching each package in Ubuntu to know the different Ubuntu
> > name for the package (linux-tools-common), we should make
> > linux-tools-common provide bpftool.
> >
>
> It is possible I am totally overthinking this ... I just have this fuzzy
> memory of linux-tools-common needing one linux-tools-<flavour> to be of use.
> And the other not so clear belief that having the provides in common will
> add that to the installation if something depends on bpftool. The command
> itself is in common, so that is ok.
> Just tried and running bpftool with just linux-tools-common installed gives
> you somewhat reasonable advice as to what you might be missing. If that is
> ok...
Hm.. I just checked and you are absolutely right.
It seems that linux-tools-common provides bpftool in /usr/sbin/bpftool,
but this is just a wrapper and the actual bpftool is provided by
linux-tools-<flavour>, that is stored in
/usr/lib/linux-tools/<flavour>/bpftool (called by the wrapper in
/usr/sbin).
I think we need to install also the real bpftool, the advice might be
not enough, since it could be hidden if it's not reported properly on
the console (and even in this case it sounds really bad to provide only
a "fake" bpftool).
So, I guess what needs to provide bpftool is actually
linux-tools-<flavour>.
Do you see any problem with this? If not I'll NAK this patch and send a
new one.
Thanks,
-Andrea
>
> -Stefan
>
> > [Fix]
> >
> > Add 'Provides: bpftool' to linux-tools-common.
> >
> > [Test case]
> >
> > Install any package from the archive that requires bpftool.
> >
> > [Regression potential]
> >
> > We could introduce potential package dependency regressions with this
> > change, however we are not introducing additional dependencies and
> > the fix allows to avoid patching a lot of other packages from the
> > archives (potentially introducing more regressions).
> >
> >
>
More information about the kernel-team
mailing list