/usr/lib/.build-id/ dirの目的は何ですか？
F27（netinstall）を新しくインストールした後、多くのpkgが小さなファイルを/usr/lib/.build-id/ dir。最初は、どういうわけか、dnfのあいまいな「デバッグ」モードを有効にしたと思いましたが、
$ dnf download httpd
rpmを取得します/usr/lib/.build-id/*ファイル。
前のFedoraリリースではこれを思い出しません。
_/usr/lib/.build-id_には、インストールされたパッケージのメインのビルドIDファイルが含まれています。 Fedora 27より前は、これらは_/usr/lib/debug_のデバッグファイルと一緒に存在し、デバッグRPMでのみ出荷されていました。 Fedora 27では、 変更が導入されました により、複数のデバッグ情報パッケージの並行インストールが可能になります。その変更の一部には、インストールされたバイナリと確実に一致させるために、一致するパッケージ内のメインのbuild-idファイルを出荷することが含まれます。
デバッグ情報パッケージは多くのディストリビューションで使用されており、ユーザーがバイナリを肥大化させることなく、必要なときにデバッグ情報をインストールする方法を提供します。プログラムまたはライブラリをビルドしてリンクすると、デバッグ情報を使用してビルドできるようになり、デバッガーを使用して、バイナリー内の場所をソースコード内の場所にマッピングできます。しかし、この情報は多くのスペースを占めます。そのため、デバッグ情報は通常、パッケージ化される前にバイナリから削除されます。近年、 strip および objcopy が強化され、デバッグ情報を個別に抽出して保存できるようになりました。これがデバッグ情報パッケージです。構築されています。次に必要なのは、バイナリとそのデバッグ情報が対応していることを確認するための何らかの方法であり、そこにビルドIDが入ります。これらは ld によって計算される一意の識別子です（_--build-id_ there）バイナリの重要な部分。 「メインのビルドIDファイル」は、ビルドIDから対応するバイナリファイルまたはデバッグ情報ファイルへのシンボリックリンクです。双方向のマッピングを実装できるので、コアダンプを効果的にデバッグできます（_.gnu_debuglink_セクションに、バイナリからバイナリ自体のビルドIDへのリンクがあります）。これらすべての背後にある理由の詳細な説明は Fedora build-id feature description にあります。