私はいくつかのrpmパッケージを構築し、rpmlint
を使用して標準とスタイルの適合性をチェックしています。パッケージは私の職場のシステムに固有のものであり、アップストリームにプッシュされることはありません。当社のパッケージには、社内ソフトウェア、リポジトリからのパッチ適用バージョンのソフトウェア、公式リポジトリから入手できないソフトウェアなど、さまざまなソフトウェアが含まれています。ローカルパッケージを/usr/local
にインストールする理由はたくさんあります。
yum update
がローカルパッケージを破壊するのを防ぎますbin
、lib
、include
)に準拠していません。 、share
など)ただし、ファイルを/usr/local
にインストールするパッケージで実行すると、rpmlint
は非常に不満になります。たとえば、GNU Hello Worldのカスタムビルドでは、これはrpmlint -i
が言う必要があることです。
hello.x86_64: E: dir-or-file-in-usr-local /usr/local/hello-2.8/bin/hello
A file in the package is located in /usr/local. It's not permitted for
packages to install files in this directory.
ファイルシステム階層標準 を知っています。
'/ usr/local'の背後にある元々のアイデアは、 '/ usr'以外のすべてのマシンに個別の( 'local') '/ usr'ディレクトリを置くことでした。 '/ usr'の構造をコピーします。最近では、「/ usr/local」は、自己コンパイルまたはサードパーティのプログラムを保持するのに適した場所と広く見なされています。/usr/local階層は、システム管理者がソフトウェアをローカルにインストールするときに使用します。システムソフトウェアが更新されたときに上書きされないように安全である必要があります。これは、ホストのグループ間で共有可能であるが、/ usrにはないプログラムおよびデータに使用できます。ローカルにインストールされたソフトウェアは、/ usr内のソフトウェアを置き換えまたはアップグレードするためにインストールされている場合を除き、/ usrではなく/ usr/local内に配置する必要があります。
実際、私たちはこれらの標準に従い、これらの理由だけでローカルソフトウェアを/usr/local
にインストールしているので、パッケージマネージャーを使用して/usr/local
にパッケージをインストールすることに問題がある理由がわかりません。ただし、ローカルパッケージ間の一貫性以外の理由がない限り、パッケージも標準に準拠している必要があります。では、なぜrpmlint
は/usr/local
内のファイルに対してエラーをスローするのですか?これはパッケージャーの裁量によるものではありませんか?このエラーを無視するか、少なくともrpmlint
に警告を出力させることはできますか?
rpmlint
は、RPMをある種のパッケージングポリシーと照合するためのツールです。その構成は通常、配布に依存し、特定の配布ポリシーに対してパッケージをチェックします。これがあなたが望むものである限り、あなた自身のパッケージをチェックすることは問題ありません。
ポリシーが配布ポリシーと異なる場合は、それに応じてrpmlint
を構成するか、使用を控えるか、特定のエラーを無視する必要があります。
/etc/rpmlint/config
または~/.config/rpmlint
(テストされていません)に追加すると、次のようになります。
addFilter("E: dir-or-file-in-usr-local")
出典:
あなたは基準に従っていません。 /usr/local
は、ローカルでコンパイルされたファイル、つまりローカルマシンでビルドされたファイルを含むように設計されています。
パッケージを作成するときの目標は、それを他のマシンに配布することです。
パッケージをマシンにインストールしてから、まったく同じマシンのソースから同じソフトウェアをビルドする場合、両方のターゲットが/usr/local
の場合、パッケージファイルは上書きされます。これは、rpmlint
が回避しようとしている競合です。
あなたの場合、/opt/hello2.8
の下にファイルをインストールするパッケージを作成することをお勧めします。後者のディレクトリは、アップストリームパッケージまたはローカルでビルドされたファイルと競合しません。