Conflict with interception-tools

romgrk-comparative commented 2 years ago

On Archlinux, installing bear when interception-tools is already installed is impossible due to a conflict for the intercept binary.

/cc @romgrk

rizsotto commented 2 years ago

Hey @romgrk-comparative , thanks for raise this issue. A couple of questions:

Have you open an issue on the interception-tools repo too?
And what would be your recommendation to rename the intercept binary to?

romgrk-comparative commented 2 years ago

I have not, my thinking was that intercept here seems to be a binary used only for the purpose of this project; I don't see it mentioned anywhere in the readme, so it's more an internal thing, is it? Anyway, if it is I'd propose something like bear-intercept?

TornaxO7 commented 2 years ago

I have the same issue as well. I'm trying to use bear for dwm but I'm getting the following error message:

/usr/bin/intercept: error while loading shared libraries: libgrpc++.so.1.39: cannot open shared object file: No such file or directory

rizsotto commented 2 years ago

@TornaxO7 the error message you've copied here might not be caused by having the interception-tools conflicting with bear, rather than a missing dependency. Or am I missing something?

TornaxO7 commented 2 years ago

Eeh well, I just recompiled it and it's working now. Sorry for the missunderstanding.

dvdesolve commented 2 years ago

if it's internal utility, may be better way is to place it somewhere inside /usr/lib/bear/intercept ?

rizsotto commented 2 years ago

Will try to merge the functionality of the different tools into one. So, there will be a single bear executable, which won't collide with other binaries. It's a bigger change. I'm just collecting energy to make it. :smile:

romgrk-comparative commented 2 years ago

I'm just collecting energy to make it. :smile:

Can definitely relate to that :laughing: No worries. Workaround is to compile & install a version on a different (local) folder.

osamuaoki commented 2 years ago

For Debian, another internal binary wrapper is installed to usr/lib/x86_64-linux-gnu/bear/wrapper following new style of FHS 3.0. Apparently, wrapper's upstream install path is not /usr/bin. If you ever bothered to update the upstream install script, please make them consistent with wrapper. This is relatively simple patch which distribution maintainer can do.

Reading this thread, I assume you will not oppose distribution to make intercept as an internal binary until you integrate all into one binary. I will file a bug to the Debian bear package.

osamuaoki commented 2 years ago

FYI: Just to indicate what I meant, I am thinking patch as attached. (It builds and tests OK with existing test codes. I have no idea how it behaves in real life.)

From b5411bf78a5c4a3cbfba0d5d25a0f57896c5b09d Mon Sep 17 00:00:00 2001
From: Osamu Aoki <osamu@debian.org>
Date: Wed, 1 Jun 2022 14:06:53 +0900
Subject: [PATCH 2/3] intercept to /usr/libexec/.../bear/

Signed-off-by: Osamu Aoki <osamu@debian.org>
---
 source/intercept/CMakeLists.txt | 2 +-
 test/CMakeLists.txt             | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/source/intercept/CMakeLists.txt b/source/intercept/CMakeLists.txt
index e9598c0..3830cbc 100644
--- a/source/intercept/CMakeLists.txt
+++ b/source/intercept/CMakeLists.txt
@@ -62,7 +62,7 @@ target_link_libraries(intercept
         intercept_a)

 install(TARGETS intercept
-        RUNTIME DESTINATION ${CMAKE_INSTALL_BINDIR})
+   RUNTIME DESTINATION ${CMAKE_INSTALL_LIBDIR}/bear)

 # Markdown file is the source to the man file. Please modify that and generate
diff --git a/test/CMakeLists.txt b/test/CMakeLists.txt
index 3426675..c855711 100644
--- a/test/CMakeLists.txt
+++ b/test/CMakeLists.txt
@@ -52,7 +52,7 @@ if (LIT_EXECUTABLE)
             -D_TEST_EXEC_ROOT=${CMAKE_CURRENT_BINARY_DIR}
             -D_BIN_BEAR=${STAGED_INSTALL_PREFIX}/${CMAKE_INSTALL_BINDIR}/bear
             -D_BIN_CITNAMES=${STAGED_INSTALL_PREFIX}/${CMAKE_INSTALL_BINDIR}/citnames
-            -D_BIN_INTERCEPT=${STAGED_INSTALL_PREFIX}/${CMAKE_INSTALL_BINDIR}/intercept
+       -D_BIN_INTERCEPT=${STAGED_INSTALL_PREFIX}/${CMAKE_INSTALL_LIBDIR}/bear/intercept
             -D_BIN_WRAPPER=${STAGED_INSTALL_PREFIX}/${CMAKE_INSTALL_LIBDIR}/bear/wrapper
             -D_BIN_WRAPPER_DIR=${STAGED_INSTALL_PREFIX}/${CMAKE_INSTALL_LIBDIR}/bear/wrapper.d
             -D_LIB_EXEC=${STAGED_INSTALL_PREFIX}/${CMAKE_INSTALL_LIBDIR}/bear/${CMAKE_SHARED_LIBRARY_PREFIX}exec${CMAKE_SHARED_LIBRARY_SUFFIX}
-- 
2.35.1

rizsotto commented 2 years ago

Thanks @osamuaoki , I think this change would work. I just have concern, that I wanted not to hide the functionality. (I myself calling intercept more often than bear. If the program would be installed into the LIBDIR, it would not be in the PATH.)

To move the wrapper into BINDIR I am hesitant too. This is the program I actually want to hide (and avoid to be in the PATH).

osamuaoki commented 2 years ago

If that is the case, you certainly want to keep it in PATH.

Debian needs to make these 2 packages conflict to each other until one of the package upstream decides to change command name. I mean to rename along

intercept-cmd or intercept-bear or bear-intercept for intercept in bear
intercept-evdev or intercept-kbd for keyboard (/dev/evdev) intercepting tool.

At least, with tab expansion these changes may not be too hard for users. The question is which command has more entrenched binary programs out there? In general, it is not prudent for the executable in PATH to have a common short English word.

Anyway, this is not anything urgent or strong request. Just a thought.

Osamu

oblitum commented 2 years ago

Hi @rizsotto, interception-tools author here. Could you clarify how Bear's intercept is used standing alone, as people here have already mentioned to have looked for that and only concluding it to be a internal tool at the time? I personally have gone through the same search too previously.

oblitum commented 2 years ago

I have mentioned that's a problem here in my issue tracker, your last comment is implying the reverse, so, sorry for that if that's not the case. In interception-tools, intercept is exposed/documented tool. In any case, I agree with @osamuaoki, it's best to have a set of tools under a prefix to avoid such issues.

rizsotto commented 2 years ago

Hey @oblitum , it's a good question when the intercept can be used directly.

I use it when I first build a project. It intercepts all command executions and stores it in an events file. Then I run the citnames (the tool which generates the compilation database). The benefit to doing this way is, that I can tune the config file for citnames without running the build over and over again.
I also use the intercept command for non C/C++ projects, but for Maven, Gradle or Cargo builds. It helps me to understand what commands it executes. (The debug output of these tools is too verbose, I found the intercept is more useful for such situation.)
The intercept output contains all command start and termination timestamp. Which I often use to have an insight what part of the build is the bottleneck.

To note here: the intercept in Bear project is also an exposed/documented tool.

To solve this issue, I would like to make it as a sub-command of bear. So, can reduce the number of executables this project is delivers. This is a bit bigger work than my free time is these days. :)

oblitum commented 2 years ago

Thanks for the explanation, now that I know, I may eventually have that in my workflow too when using Bear tooling.

To solve this issue, I would like to make it as a sub-command of bear. So, can reduce the number of executables this project is delivers. This is a bit bigger work than my free time is these days. :)

It's a good route. Sadly, I'm kinda in the same boat at the moment.

osamuaoki commented 2 years ago

Creating parent command is simple with a shell code. Install all your binaries to "/usr/lib/whatever/${MAIN_COMMAND_NAME}".

Then something like the following should work.

#!/bin/sh -e
# Public Domain
# adjust for each program
MAIN_COMMAND_NAME="my-main-command"
CALLING_COMMAND_NAME="${0##*/}"
PRIVATE_COMMAND_PATH="/usr/lib/whatever/${MAIN_COMMAND_NAME}"
if [ "$CALLING_COMMAND_NAME" = "${MAIN_COMMAND_NAME}" ]; then
  if [ -n "${1}" ]; then
    SUB_COMMAND="${1}"
    shift
  else
    SUB_COMMAND="help"
  fi
else
  SUB_COMMAND="${CALLING_COMMAND_NAME}"
fi
"${PRIVATE_COMMAND_PATH}/${SUB_COMMAND}" "$@"

samu698 commented 1 year ago

Hey @rizsotto

I would like to make it as a sub-command of bear

I started doing work on unifying all the tools in one binary, but I need help with CMake (of witch I have almost no knowledge of how to use it) and on how to layout the files.

This is the list of steps that I think are needed to make this change:

Move the code for bear out of the main.cc file to an Application.cc file
Move all the command line arguments parsing into bear's Application.cc file
When a subcommand gets issued use the code of the corresponding program to handle it
Redo CMakeLists.txt (need help on this one)
Refactor the tests

Also can you suggest a new folder structure, my idea was to move the intercept and the citnames folders into the bear folder, as they will be part of it. But I know it's better that I ask you about this.

rizsotto commented 1 year ago

Hey @samu698 , thanks for jumping in.

The change plan looks good to me.

Move the code for bear out of the main.cc file to an Application.cc file

I started to work on this a year before. The branch 3.1 has a commit to do this.

Redo CMakeLists.txt (need help on this one)

Can definitely help with this!

Also can you suggest a new folder structure, my idea was to move the intercept and the citnames folders into the bear folder, as they will be part of it. But I know it's better that I ask you about this.

As a start I would keep the files in place, just to keep things simple. And if this is getting painful then move them into bear as you suggested.

rizsotto commented 1 year ago

Fix is merged to master, will released as 3.1.0.

rizsotto / Bear

Conflict with interception-tools #412