RHEL8 rpmbuild and /usr/lib/.build-id

Latest response

As a general rule, I only install from official RH supplied repos, but sometimes I have to build my own RPM file, for example I'm not aware of any anti-virus software in the official repos.

In RHEL7, I was able to separate my custom installations into /usr/local, keeping them well away from the official RH software.

In RHEL8, there seems to be a problem, due to a change in Fedora, nearly all RPM installs will want to create files in location /usr/lib/.build-id (to improve debugging).

BUT, this means I can no longer keep my RPM completely separate from the official RH supplied software. I don't think you can specify '/usr/local/lib/.build-id' instead?


There seem to be some useful options regarding build_id links.

Thanks Akemi,

I did see this option, but all it does is turn off the feature. It's a possible workaround, but it's not really a solution.

I can confirm that adding

%define _build_id_links none

to the start of the spec file does prevent creation of the build ids in /usr/lib, so it's a kind of work around, but then I end up with a package that is very inconsistent with the official RedHat packages and similar EPEL packages, and also the debuginfo part probably won't work.

Is it better to just ditch /usr/local, and allow all the files to be jumbled up in /usr/bin, /usr/lib64 and rely on RPM to keep track of them?

You could disable the macro in your spec, as you have shown, but yeah please just stop using /user/local/ because it's against our (Fedora Community) packaging guidelines, which are pretty much inherited by any downstream distro (e.g. RHEL, Cent, etc.). So my recommendation is to either disable build-id in your spec, or switch to a supported %prefix.

Thinking about this, it might be possible to expose these build-id's to alternate install prefix (/opt or /usr/local), but the debug tools would need to learn how to find out (run the database queries), if it's even possible. I would imagine the RPM database knows some things about the prefix, and it would be reasonable to just assume $prefix/.build-id's might exist.

Regarding /opt, this raises an interesting question, because the original idea with Software Collections, was to be able to keep all files separate to the default RH repos, which is the same thing I'm trying to do with my own RPM packages. So I'm guessing SCL would run into the same issue (if it were to exist in RHEL8).