On Mon, 17 Feb 2025 at 20:59, Ritesh Raj Sarraf <r...@debian.org> wrote:
>
> Dear Andreas,
>
> On Thu, 2025-02-13 at 10:34 +0100, Andreas Tille wrote:
> > Hi maintainers of tcputils and libbpf-tools,
> >
> >
> > Here is the solution which I see:
> >
> >   Keep the name tcpconnect for libbpf-tools since this is the
> > actively
> >   maintained code base and might get a wider user base.  However, I
> > do not
> >   see any good reason to but that binary into /usr/sbin.  What is the
> >   rationale to have it only inside the path of root?  This true for
> > all
> >   tools of libbpf-tools.
> >
>
> I'll have to check with Vasudev on the details of libbpf-tools. It has
> been a while I have followed it closely.
>
> For the BPFCC variant, we need root privileges because a runtime BPF
> module is compiled and loaded.
>
> @Vasudev, can you please confirm if libbpf-tools can be run otherwise,
> as a normal user.

No it always needs root privileges without which it can't be run.

>
> > So in case you (the maintainers of libbpf-tools) agree with me to
> > move
> > the tools to /usr/bin we would have a real file conflict and this bug
> > would become RC (instead of just normal since only confusing not
> > conflicting).
> >
>
> There's also another surprise element with libbpf-tools that I only
> noticed now, now that you've reported with this bug report.
>
> All binaries in bpfcc-tools were carefully chosen to have a suffix,
> making its origin obvious. The reason for this change was another set
> of instrumentation tools, being provided by the same upstream family,
> but from a different codebase. perf-tools-unstable.

I think perf-tools-unstable is no longer actively developed; the last
commit seems 6 years back.
Does it even make sense to keep it around? It has been superseded by
bpftools. So I would suggest dropping
perf-tools-unstable and rename binary back to their original names and
then we can add conflicts to libbpf-tools
which provides the same binary (not all are present from bpfcc-tools).

I'm not really a fan of renaming binary from upstream original name.
But that is just my opinion I'm okay with
whatever is decided here.


Thanks and Regards,
-- 

Vasudev Kamath

Reply via email to