/usr/lib/.build-id contains the main build-id files for installed packages. Before Fedora 27, these lived alongside the debug files in
/usr/lib/debug, and were only shipped in debug RPMs. In Fedora 27, a change was introduced to allow parallel installation of multiple debug info packages. Part of that change involves shipping the main build-id files in the package they match, to ensure that they match the installed binaries.
Debug info packages are used in many distributions to provide a way for users to install debugging information when necessary, without bloating binaries for everyone. When a program or library is built and linked, it can be built with debugging information, which debuggers can then use to map locations in the binary with locations in its source code; but this information takes up a lot of room. So debugging information is typically stripped from binaries before they’re packaged. In recent years,
objcopy have been enhanced so that debugging information can be extracted and stored separately — that’s how debug info packages are built. All that’s needed then is some way of ensuring that a binary and its debug information correspond, and that’s where build ids come in — they are unique identifiers calculated by
ld (look for
--build-id there) over the significant portions of a binary. “Main build-id files” are symlinks from a build id to the corresponding binary or debug info file; they allow two-way mappings to be implemented, so that core dumps can be usefully debugged (there’s a link from binaries to their build ids in the binaries themselves, in the
.gnu_debuglink section). You’ll find a detailed explanation of the reasoning behind all this in the Fedora build-id feature description.