フォローアップとしてこれ質問、これらのデバッグ機能に興味がない場合はどうすればよいですか？単にこれらのビルドIDファイル（デバッグ情報パッケージ？）のインストールを防ぐには？最終的に私は（少なくとも近いうちに）クライアント側のデバッグサポートに興味がありません。一方、同じシステムに異なるクライアントRedhat製品（パッケージ）をインストールするときは、既知の「ビルドIDフォルダの競合」を克服する必要があります。これはどのように達成できますか？
私読むrpmを使用してインストールするときは、--excludepath = / usr / lib / .build-id /を使用するのがきちんとした解決策です。そうですね。 「デバッグ機能」を失うことに加えて、他の欠点はありますか？
--excludepath実際には役に立ちません。しかし、%define _build_id_links noneここで提案されているように使用しました。簡単に言えば、デバッグサポートに興味がなければ、どれほど大きな問題でしょうか？ ここにリンクの説明を入力してください
ベストアンサー1
--excludepath=/usr/lib/.build-idはい、クリーンなソリューションです。私が知る限り、「デバッグ能力」を失っているはいrpm --verify唯一の欠点は、このオプションでスキップされたファイルが失敗を引き起こさないことです。ただし、「デバッグ可能性」を失うと、有用な出力を得る能力が制限される以上ですgdb。たとえば、エラー報告ツールは、意味のあるスタックトレースを提供する場合は手動介入が必要です。%define _build_id_links noneパッケージを作成していて、パッケージと一緒にデバッグ情報を送信したくない場合でも問題ありません。
あなたの2つの質問は、パッケージのさまざまな側面をカバーしています。rpm --excludepathパッケージを梱包するときに発生する状況に影響します。インストール済み、これは%define _build_id_linksパッケージがいつに影響します。立てられる。パッケージの作成に興味がある場合は、これが役に立たないのがrpm --excludepath普通です。その時点では関係がないからです。
また提案したようにあなたがリンクしたバグレポート、ビルドIDの競合は、パッケージングの問題を示します。パッケージをビルドする場合は、パッケージの問題を修正するのではなく、問題を修正する必要があります。