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. > 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. Now with libbpf-tools, it'd be another set of binaries from the same upstream family. I would say that all binaries presented via libbpf-tools be renamed with a suffix, just like bpfcc-tools. To keep it consistent across the remaining set of tools. And that in turn will auto-solve the name conflict. > My suggestion for tcputils is: > > 1. Move all tools of the package physically to > /usr/lib/tcputils/bin > 2. Symlink all other tools but tcpconnect to /usr/bin > 3. ln -s /usr/lib/tcputils/bin/tcpconnect > /usr/bin/tcputils_tcpconnect > 4. Add debian/NEWS.Debian with the following text: > > Due to a name conflict with /usr/bin/tcpconnect in the package > libbpf-tools this binary had to be renamed. So tcputils now > provides this executable under the name > > /usr/bin/tcputils_tcpconnect > > To remain compatible with local user scripts using the name > tcpconnect the real executable is provided under the PATH > > /usr/lib/tcputils/bin/tcpconnect > I'd suggest you do the same for tcputils as well, irrespective of what course we take for libbpf-tools. The only point I'd emphasize is that use as suffix for the extra name you want to attach. For the majority of the users, the execution flow is tcpcon => TAB, which will nicely make any modern shell with autocompletion, suggest the user with the available options. Otherwise, it'll just auto-complete with the one single name it has. As for ensuring backwards compatibility, your suggestion for moving all binaries to /usr/lib/tcputils/bin/ sounds good. > So if you want to use tcpconnect with its original name just > do the following: Set the PATH variable like > > export PATH=/usr/lib/tcputils/bin:$PATH > > Please make sure you can't easily use tcpconnect from the > libbpf-tools without specfying its explicit path in case > you have a co-installation of libbpf-tools and tcputils > > > Do you have any other suggestion? Usually its a good idea to > approach > upstream about those name conflicts. However tcputils upstream is > inactive since 25 years. So this task would be up to you (the > libbpf-tools maintainers). > > Kind regards and thank you for your cooperation > Andreas. > > [1] > https://salsa.debian.org/tille/tiny_qa_tools/-/wikis/Tiny-QA-tasks#bug-of-the-day > [2] https://salsa.debian.org/salvage-team/tcputils > -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System
signature.asc
Description: This is a digitally signed message part
