3

As a follow up on this question, what if I am not interested in having these debug features - how do I simply prevent these build-id files (debug info packages?) from being installed ? Ultimately I do not care (at least for the near future) about supporting debugging at clients. On the other hand, I need to overcome the known "build-id folder conflicts" when installing our different client redhat products (packages) in the same machine. How can that be accomplished ?

  1. I read that using --excludepath=/usr/lib/.build-id/ when installing with rpm is a clean workaround. Sounds so. Do you see any drawbacks except losing "debug capabilities" ?

  2. --excludepath actually did not help. But using %define _build_id_links none as suggested here did. In a short, how problematic is that, if I am not interested in debug support ? enter link description here

Veverke
  • 338
  • 3
  • 16

1 Answers1

4

  1. --excludepath=/usr/lib/.build-id is a clean workaround, yes. As far as I’m aware, losing “debug capabilities” is the only drawback; files skipped by this option won’t even cause rpm --verify to fail. However, losing “debug capabilities” has consequences beyond limiting the ability to get useful output of gdb; for example, manual intervention will be required if bug reporting tools want to provide meaningful stacktraces.

  2. %define _build_id_links none is OK too, if you’re building packages and you don’t want to ship debugging information with them.

Your two questions target different aspects of packages. rpm --excludepath affects what happens when a package is installed, whereas %define _build_id_links affects what happens when a package is built. If you’re interested in building packages, it’s normal that rpm --excludepath didn’t help, because it’s not relevant then.

Note too that, as suggested by the bug report you linked to, build-id conflicts indicate packaging problems. If you’re building packages, you should fix the issues in your packages, instead of working around them.

Stephen Kitt
  • 411,918
  • 54
  • 1,065
  • 1,164
  • Thanks for the last note. Not much clear to me where the problem is - I have the same machine generating 2 red hat packages, the 2 that when installed on the same machine fails with the conflict mentioned [here](https://unix.stackexchange.com/a/411736/433212). Will look at it in more detail. Both packages have the same parent target directory -> /usr/local/bin - but they ultimately reside in a subfolder there with the package name. What I do not understand is how the same build IDs are generated when packaging different stuff. – Veverke Feb 01 '22 at 14:28
  • Only now noticed the answer's clarification on the different aspects of my 2 proposed solutions. Thanks a lot for that, very helpful! – Veverke Feb 01 '22 at 20:46