RPM パッケージングガイド
RPM パッケージマネージャーを使用した基本および高度なソフトウェアパッケージングシナリオ
概要
第1章 RPM のパッケージ化の使用 リンクのコピーリンクがクリップボードにコピーされました!
次のセクションでは、RPM パッケージ化の概念とその主な利点を説明します。
1.1. RPM のパッケージ化の概要 リンクのコピーリンクがクリップボードにコピーされました!
RPM Package Manager (RPM) は、RHEL、CentOS、および Fedora で実行できるパッケージ管理システムです。RPM を使用することで、上記のオペレーティングシステム用に作成したソフトウェアを配布、管理、および更新できます。
1.2. RPM の利点 リンクのコピーリンクがクリップボードにコピーされました!
RPM パッケージ管理システムは、従来のアーカイブファイルでのソフトウェア配布に比べて、いくつかの利点があります。
RPM を使用すると、以下が可能になります。
- Yum、PackageKit などの標準パッケージ管理ツールを使用した、パッケージのインストール、再インストール、削除、アップグレード、および検証。
- インストール済みのパッケージのデータベースを使用した、パッケージのクエリーおよび検証。
- メタデータを使用した、パッケージ、インストール手順、その他のパッケージパラメーターの記述。
- ソフトウェアソース、パッチ、完全なビルド命令の、ソースパッケージおよびバイナリーパッケージへのパッケージ化。
-
Yumリポジトリーへのパッケージの追加。 - GNU Privacy Guard (GPG) 署名鍵を使用した、パッケージへのデジタル署名。
1.3. 最初の RPM パッケージ作成 リンクのコピーリンクがクリップボードにコピーされました!
RPM パッケージの作成は複雑になる可能性があります。以下では、複数のことをスキップし、簡素化した完全で利用できる RPM Spec ファイルです。
このファイルを hello-world.spec として保存します。
ここで、以下のコマンドを使用します。
rpmdev-setuptree rpmbuild -ba hello-world.spec
$ rpmdev-setuptree
$ rpmbuild -ba hello-world.spec
コマンド rpmdev-setuptree は、複数の作業ディレクトリーを作成します。これらのディレクトリーは $HOME に永続的に格納されているため、このコマンドを再び使用する必要はありません。
コマンド rpmbuild は、実際の rpm パッケージを作成します。このコマンドの出力は、以下のようになります。
/home/<username>/rpmbuild/RPMS/x86_64/hello-world-1-1.x86_64.rpm ファイルが、最初の RPM パッケージです。これはシステムにインストールしてテストできます。
第2章 RPM パッケージ化を行うためのソフトウェアの準備 リンクのコピーリンクがクリップボードにコピーされました!
本セクションでは、RPM パッケージ化のソフトウェアを準備する方法を説明します。この準備には、プログラミングの知識は必要ありません。ただし、ソースコードとは、プログラムが作られる仕組み など、基本的な概念を理解しておく必要があります。
2.1. ソースコードとは リンクのコピーリンクがクリップボードにコピーされました!
ここでは、ソースコードの概要を説明し、3 種類のプログラミング言語で書かれたプログラムのソースコード例を紹介します。
ソースコードとは、人間が読むことのできるコンピューターへの命令で、計算の実行方法を記述しています。ソースコードは、プログラミング言語で書かれています。
2.1.1. ソースコードの例 リンクのコピーリンクがクリップボードにコピーされました!
本書では、3 つのプログラミング言語で書かれた Hello World プログラムが紹介されています。
各言語で、パッケージ化が異なります。
各言語の Hello World プログラムは、RPM パッケージャーの主要な 3 つのユースケースをカバーしています。
2.1.1.1. bash で書かれた Hello World リンクのコピーリンクがクリップボードにコピーされました!
bello プロジェクトは、bash で Hello World を実装しています。この実装には bello シェルスクリプトのみが含まれます。このプログラムの目的は、コマンドラインで Hello World を出力することです。
bello ファイルの構文は以下のようになります。
#!/bin/bash printf "Hello World\n"
#!/bin/bash
printf "Hello World\n"
2.1.1.2. Python で書かれた Hello World リンクのコピーリンクがクリップボードにコピーされました!
pello プロジェクトは、Python に Hello World を実装します。この実装には、pello.py プログラムのみが含まれます。このプログラムの目的は、コマンドラインで Hello World を出力することです。
pello.py ファイルの構文は以下のようになります。
#!/usr/bin/python3
print("Hello World")
#!/usr/bin/python3
print("Hello World")
2.1.1.3. C で書かれた Hello World リンクのコピーリンクがクリップボードにコピーされました!
cello プロジェクトは、C の Hello World を実装します。この実装には、cello.c および Makefile ファイルだけが含まれます。そのため、生成される tar.gz アーカイブには、LICENSE ファイル以外にファイルが 2 つ含まれます。
このプログラムの目的は、コマンドラインで Hello World を出力することです。
cello.c ファイルの構文は以下のようになります。
2.2. プログラムが作られる仕組み リンクのコピーリンクがクリップボードにコピーされました!
人間が判読できるソースコードからマシンコード (コンピューターがプログラムを実行するために従う命令) に変換する方法は、以下のとおりです。
- プログラムがネイティブにコンパイルされる。
- プログラムがマシンコードの解釈により、解釈される。
- プログラムがバイトコンパイルによって解釈される。
2.2.1. ネイティブにコンパイルされたコード リンクのコピーリンクがクリップボードにコピーされました!
ネイティブにコンパイルされたソフトウェアは、生成されたバイナリーの実行ファイルでマシンコードにコンパイルされるプログラミング言語で書かれたソフトウェアです。このようなソフトウェアは、スタンドアロンで実行できます。
この方法でビルドした RPM パッケージは、アーキテクチャー固有のパッケージです。
64 ビット (x86_64) AMD または Intel のプロセッサーを使用するコンピューターでこのようなソフトウェアをコンパイルすると、32 ビット (x86) AMD または Intel プロセッサーでは実行できません。生成されるパッケージには、名前でアーキテクチャーが指定されています。
2.2.2. 解釈されたコード リンクのコピーリンクがクリップボードにコピーされました!
bash や Python などの一部のプログラミング言語は、マシンのコードにコンパイルしません。代わりに、プログラムのソースコードは、言語インタープリターまたは言語仮想マシンにより、事前の変換なしで順を追って実行されます。
インタープリター型のプログラミング言語でのみ書かれたソフトウェアは、アーキテクチャーに依存しません。そのため、作成される RPM パッケージの名前には noarch 文字列が付きます。
インタープリター言語は、raw インタープリタープログラム または バイトコンパイル言語 です。この 2 つは、パッケージ化作業のプログラムビルドプロセスにおいて異なります。
2.2.2.1. raw インタープリタープログラム リンクのコピーリンクがクリップボードにコピーされました!
raw インタープリター言語プログラムはコンパイルする必要はなく、インタープリターにより直接実行されます。
2.2.2.2. バイトコンパイルプログラム リンクのコピーリンクがクリップボードにコピーされました!
バイトコンパイル言語は、バイトコードにコンパイルして、その言語の仮想マシンにより実行される必要があります。
一部の言語では、raw インタープリターとバイトコンパイルを選ぶことができます。
2.3. ソースからのソフトウェア構築 リンクのコピーリンクがクリップボードにコピーされました!
このセクションでは、ソースコードからソフトウェアを構築する方法を説明します。
コンパイル言語で書かれたソフトウェアの場合、ソースコードはビルドプロセスを経て、マシンコードを生成します。このプロセスは、コンパイルまたはトランスレートと呼ばれ、言語によって異なります。その結果構築されるソフトウェアは実行できるようになります。これにより、プログラマーが指定したタスクをコンピューターが実行するようになります。
raw インタープリター言語で書かれたソフトウェアの場合、ソースコードは構築されず、直接実行します。
バイトコンパイル型のインタープリター言語で書かれたソフトウェアの場合、ソースコードがバイトコードにコンパイルされ、その言語の仮想マシンによって実行されます。
2.3.1. ネイティブにコンパイルされたコード リンクのコピーリンクがクリップボードにコピーされました!
本セクションでは、C 言語で書かれた cello.c プログラムの実行可能なファイルへの構築方法を紹介します。
cello.c
2.3.1.1. 手動による構築 リンクのコピーリンクがクリップボードにコピーされました!
cello.c プログラムを手動で構築する場合は、以下の手順を使用します。
手順
GNU コンパイラーコレクション から C コンパイラーを起動し、ソースコードをバイナリーにコンパイルします。
gcc -g -o cello cello.c
gcc -g -o cello cello.cCopy to Clipboard Copied! Toggle word wrap Toggle overflow 生成された出力バイナリー
celloを実行します。./cello Hello World
$ ./cello Hello WorldCopy to Clipboard Copied! Toggle word wrap Toggle overflow
2.3.1.2. 自動化ビルド リンクのコピーリンクがクリップボードにコピーされました!
大規模なソフトウェアは通常、Makefile ファイルを作成し、GNU make ユーティリティーを実行して自動ビルドを使用します。
自動ビルドを使用して cello.c プログラムを構築する場合は、以下の手順を使用します。
手順
自動ビルドを設定するには、次の内容の
Makefileファイルをcello.cと同じディレクトリーに作成します。makefilecello: gcc -g -o cello cello.c clean: rm cello
cello: gcc -g -o cello cello.c clean: rm celloCopy to Clipboard Copied! Toggle word wrap Toggle overflow cello:およびclean:の行は、タブスペースで始まる必要があります。ソフトウェアを構築するには、
makeコマンドを実行します。make make: 'cello' is up to date.
$ make make: 'cello' is up to date.Copy to Clipboard Copied! Toggle word wrap Toggle overflow ビルドはすでに利用できるため、
make cleanコマンドを実行してから、makeコマンドを再び実行します。make clean rm cello make gcc -g -o cello cello.c
$ make clean rm cello $ make gcc -g -o cello cello.cCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記別のビルドに影響がなければ、プログラムの構築を試行します。
make make: 'cello' is up to date.
$ make make: 'cello' is up to date.Copy to Clipboard Copied! Toggle word wrap Toggle overflow プログラムを実行します。
./cello Hello World
$ ./cello Hello WorldCopy to Clipboard Copied! Toggle word wrap Toggle overflow
これで、ビルドツールを使用した手動によるプログラムのコンパイルが完了しました。
2.3.2. コードの解釈 リンクのコピーリンクがクリップボードにコピーされました!
本セクションでは、Python で書かれたプログラムをバイトコンパイルして、bash で書かれたプログラムをそのまま解釈する方法を示しています。
以下の 2 つの例では、ファイルの一番上の #! 行は、シバン (shebang) と呼ばれるもので、プログラミング言語ソースコードの一部ではありません。
シバン により、実行ファイルとしてテキストファイルを使用できるようになります。システムプログラムローダーは、シバンを含む行を解析して、バイナリーの実行ファイルへのパスを取得します。これは、プログラミング言語インタープリターとして使用されます。この場合は、テキストファイルを実行ファイルとしてマークする必要があります。
2.3.2.1. コードのバイトコンパイル リンクのコピーリンクがクリップボードにコピーされました!
本セクションでは、Python で書かれた pello.py プログラムをバイトコードにコンパイルし、Python 言語の仮想マシンで実行する方法を説明します。
Python のソースコードは、そのまま解釈することもできすが、バイトにコンパイルした方が高速です。したがって、RPM パッケージャーは、エンドユーザーが配布するバージョンにはバイトコンパイルのパッケージ化を推奨しています。
pello.py
#!/usr/bin/python3
print("Hello World")
#!/usr/bin/python3
print("Hello World")
プログラムのバイトコンパイル手順は、以下の要素によって異なります。
- プログラミング言語
- 言語の仮想マシン
- その言語で使用するツールおよびプロセス
Python は、多くの場合バイトコンパイルが行われますが、ここでは説明しません。以下の手順は、コミュニティーの標準に準拠するのではなく、簡潔さを重視しています。実際の Python ガイドラインは Software Packaging and Distribution を参照してください。
この手順に従って pello.py をバイトコードにコンパイルします。
手順
pello.pyファイルをバイトコンパイルします。python -m compileall pello.py file pello.pyc pello.pyc: python 2.7 byte-compiled
$ python -m compileall pello.py $ file pello.pyc pello.pyc: python 2.7 byte-compiledCopy to Clipboard Copied! Toggle word wrap Toggle overflow pello.pycのバイトコードを実行します。python pello.pyc Hello World
$ python pello.pyc Hello WorldCopy to Clipboard Copied! Toggle word wrap Toggle overflow
2.3.2.2. raw-interpreting code リンクのコピーリンクがクリップボードにコピーされました!
本セクションでは、bash シェルの組み込み言語で書かれた bello プログラムをそのまま解釈する方法を示しています。
bello
#!/bin/bash printf "Hello World\n"
#!/bin/bash
printf "Hello World\n"
bashなどのシェルスクリプト言語で書かれたプログラムはそのまま解釈されます。
手順
ソースコードの実行ファイルでファイルを作成して実行します。
chmod +x bello ./bello Hello World
$ chmod +x bello $ ./bello Hello WorldCopy to Clipboard Copied! Toggle word wrap Toggle overflow
2.4. ソフトウェアへのパッチの適用 リンクのコピーリンクがクリップボードにコピーされました!
本セクションでは、ソフトウェアにパッチを適用する方法を説明します。
RPM のパッケージ化では、元のソースコードを変更するのではなく、コードを維持し、コードにパッチを使用します。
パッチは、ソースコードを更新するソースコードです。これは、2 つのバージョンのテキストの差を示すため、diff としてフォーマットされます。diff は、diff ユーティリティーを使用して作成されます。これは、パッチ ユーティリティーを使用してソースコードに適用されます。
ソフトウェア開発者は多くの場合、git などのバージョン管理システムを使用してコードベースを管理します。このようなツールでは、diff やパッチソフトウェアを独自の方法で作成できます。
以下の例は、diff を使用して元のソースコードからパッチを作成する方法と、パッチ でパッチを適用する方法を示しています。後続のセクションで RPM を作成するときにパッチを適用します。「SPEC ファイルでの作業」 を参照してください。
この手順では、cello.c の元のソースコードからパッチを作成する方法を説明します。
手順
元のソースコードを保持します。
cp -p cello.c cello.c.orig
$ cp -p cello.c cello.c.origCopy to Clipboard Copied! Toggle word wrap Toggle overflow -pオプションは、モード、所有権、およびタイムスタンプを保持するために使用されます。必要に応じて
cello.cを変更します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow diffユーティリティーを使用してパッチを生成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow -で始まる行は、元のソースコードから削除され、+で始まる行に置き換えられます。通常のユースケースの多くに適切なため、
diffコマンドにNaurオプションを指定することが推奨されます。ただし、この場合は、-uオプションのみが必要になります。特定のオプションにより、以下が確保されます。-
-N(または--new-file) - 存在しないファイルを、空のファイルであるかのように処理します。 -
-a(または--text) - すべてのファイルをテキストとして処理します。そのため、diffがバイナリーとして分類するファイルは無視されません。 -
-u(もしくは-U NUMまたは--unified[=NUM]) - 統一されたコンテキストの出力の NUM (デフォルトは 3) 行の形式で、出力を返します。これは、変更したソースツリーにパッチを適用する際に、あいまい一致を可能にする読みやすい形式です。 -r(または--recursive) - 検出されたサブディレクトリーを再帰的に比較します。diffユーティリティーの一般的な引数は、man ページのdiffを参照してください。
-
ファイルにパッチを保存します。
diff -Naur cello.c.orig cello.c > cello-output-first-patch.patch
$ diff -Naur cello.c.orig cello.c > cello-output-first-patch.patchCopy to Clipboard Copied! Toggle word wrap Toggle overflow 元の
cello.cを復元します。cp cello.c.orig cello.c
$ cp cello.c.orig cello.cCopy to Clipboard Copied! Toggle word wrap Toggle overflow RPM を構築するときは変更後のファイルではなく、元のファイルが使用されるため、元の
cello.cを保持する必要があります。詳細は、「SPEC ファイルでの作業」 を参照してください。
以下の手順は、output-first-patch.patch を使用して cello.c にパッチを適用して、パッチプログラムを構築し、これを実行する方法を示しています。
パッチファイルの出力先を
patchコマンド変更します。patch < cello-output-first-patch.patch patching file cello.c
$ patch < cello-output-first-patch.patch patching file cello.cCopy to Clipboard Copied! Toggle word wrap Toggle overflow cello.cの内容がパッチを反映していることを確認します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow パッチが適用された
cello.cを構築して実行します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.5. 任意のアーティファクトのインストール リンクのコピーリンクがクリップボードにコピーされました!
UNIX のようなシステムでは、ファイルシステム階層標準 (FHS) を使用して、特定のファイルに適したディレクトリーを指定します。
RPM パッケージからインストールしたファイルは、FHS に従って配置されます。たとえば、実行ファイルは、システム $PATH 変数のディレクトリーに置く必要があります。
このドキュメントのコンテキストでは、任意アーティファクト は RPM からシステムにインストールされたものを意味します。RPM およびシステムの場合は、スクリプト、パッケージのソースコードからコンパイルしたバイナリー、事前にコンパイルしたバイナリー、またはその他のファイルを意味します。
本セクションでは、システムに 任意アーティファクト を配置する一般的な 2 つの方法を説明します。
2.5.1. install コマンドの使用 リンクのコピーリンクがクリップボードにコピーされました!
パッケージャーは、GNU make などのビルド自動化ツールが最適ではない場合に install コマンドを使用することがよくあります。たとえば、パッケージ化したプログラムに余分なオーバーヘッドが必要ない場合などが考えられます。
coreutils により、install コマンドをシステムで利用できます。このコマンドは、指定のパーミッションセットで、ファイルシステム内の指定したディレクトリーにアーティファクトを配置します。
以下の手順では、このインストール方法に、任意アーティファクトとして以前に作成された bello ファイルを使用します。
手順
installコマンドを実行して、実行可能スクリプトに共通のパーミッションを持つ/usr/binディレクトリーにbelloファイルを配置します。sudo install -m 0755 bello /usr/bin/bello
$ sudo install -m 0755 bello /usr/bin/belloCopy to Clipboard Copied! Toggle word wrap Toggle overflow これにより、
belloは、$PATH変数にリスト表示されているディレクトリーに置かれます。完全パスを指定せずに、任意のディレクトリーから
belloを実行します。cd ~ bello Hello World
$ cd ~ $ bello Hello WorldCopy to Clipboard Copied! Toggle word wrap Toggle overflow
2.5.2. make install コマンドの使用 リンクのコピーリンクがクリップボードにコピーされました!
make install コマンドを使用することで、ビルドしたソフトウェアをシステムに自動的にインストールできます。この場合、開発者が作成する Makefile 内のシステムにおいて、任意アーティファクトをシステムにインストールする方法を指定する必要があります。
この手順では、システム上の任意の場所にビルドアーティクトをインストールする方法を説明します。
手順
Makefileにインストールセクションを追加します。makefileCopy to Clipboard Copied! Toggle word wrap Toggle overflow cello:、clean:、およびinstall:の行は、行頭にタブスペースを追加する必要があります。注記$(DESTDIR) 変数は GNU make の組み込みで、一般的には、root ディレクトリーとは異なるディレクトリーへのインストールを指定するために使用されます。
これで、
Makefileを使用してソフトウェアを構築するだけでなく、ターゲットシステムへのインストールも可能になります。cello.cプログラムを構築してインストールします。make gcc -g -o cello cello.c sudo make install install -m 0755 cello /usr/bin/cello
$ make gcc -g -o cello cello.c $ sudo make install install -m 0755 cello /usr/bin/celloCopy to Clipboard Copied! Toggle word wrap Toggle overflow これにより、
cello変数に記載されているディレクトリーにcelloが置かれます。完全パスを指定せずに、任意のディレクトリーから
celloを実行します。cd ~ cello Hello World
$ cd ~ $ cello Hello WorldCopy to Clipboard Copied! Toggle word wrap Toggle overflow
2.6. パッケージ化を行うためのソースコードの準備 リンクのコピーリンクがクリップボードにコピーされました!
開発者は、ソースコードの圧縮アーカイブとしてソフトウェアを配布するため、パッケージの作成に使用されます。RPM パッケージャーは、準備の整ったソースコードアーカイブと連携します。
ソフトウェアは、ソフトウェアライセンスとともに配布する必要があります。
この手順では、LICENSE ファイルのサンプルコンテンツとして GPLv3 ライセンステキストを使用します。
手順
LICENSEファイルを作成し、以下の内容が含まれることを確認します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
関連情報
- このセクションで作成したコードは、こちら にあります。
2.7. ソースコードを tarball へ追加 リンクのコピーリンクがクリップボードにコピーされました!
本セクションでは、「ソースコードの例」 で紹介されている 3 つの Hello World プログラムをそれぞれ gzip で圧縮した tarball にまとめる方法を説明します。これは、後で配布用にパッケージ化するソフトウェアをリリースする一般的な方法です。
2.7.1. bello プロジェクトを tarball へ追加 リンクのコピーリンクがクリップボードにコピーされました!
bello プロジェクトは、bash で Hello World を実装しています。この実装には bello シェルスクリプトのみが含まれるため、生成される tar.gz アーカイブには LICENSE ファイルとは別のファイルのみが含まれます。
この手順では、配布用に bello を準備する方法を示しています。
前提条件
このプログラムのバージョンが 0.1 であることを考慮してください。
手順
必要なファイルをすべて 1 つのディレクトリーに追加します。
mkdir /tmp/bello-0.1 mv ~/bello /tmp/bello-0.1/ cp /tmp/LICENSE /tmp/bello-0.1/
$ mkdir /tmp/bello-0.1 $ mv ~/bello /tmp/bello-0.1/ $ cp /tmp/LICENSE /tmp/bello-0.1/Copy to Clipboard Copied! Toggle word wrap Toggle overflow 配布用のアーカイブを作成し、これを
~/rpmbuild/SOURCES/ディレクトリーに移動します。このディレクトリーは、rpmbuildコマンドがパッケージを構築するファイルを保存するデフォルトディレクトリーです。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
bash で書かれたサンプルソースコードの詳細は 「bash で書かれた Hello World」 を参照してください。
2.7.2. pello プロジェクトを tarball へ追加 リンクのコピーリンクがクリップボードにコピーされました!
pello プロジェクトは、Python に Hello World を実装します。この実装には pello.py プログラムのみが含まれるため、生成された tar.gz アーカイブには LICENSE ファイルとは異なる 1 つのファイルのみが含まれます。
この手順では、pello プロジェクトを配布するために準備する方法を示します。
前提条件
このプログラムのバージョンが 0.1.1 であることを考慮する。
手順
必要なファイルをすべて 1 つのディレクトリーに追加します。
mkdir /tmp/pello-0.1.2 mv ~/pello.py /tmp/pello-0.1.2/ cp /tmp/LICENSE /tmp/pello-0.1.2/
$ mkdir /tmp/pello-0.1.2 $ mv ~/pello.py /tmp/pello-0.1.2/ $ cp /tmp/LICENSE /tmp/pello-0.1.2/Copy to Clipboard Copied! Toggle word wrap Toggle overflow 配布用のアーカイブを作成し、これを
~/rpmbuild/SOURCES/ディレクトリーに移動します。このディレクトリーは、rpmbuildコマンドがパッケージを構築するファイルを保存するデフォルトディレクトリーです。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Python で書かれたサンプルソースコードの詳細は 「Python で書かれた Hello World」 を参照してください。
2.7.3. cello プロジェクトを tarball へ追加 リンクのコピーリンクがクリップボードにコピーされました!
cello プロジェクトは、C の Hello World を実装します。この実装には、cello.c および Makefile ファイルだけが含まれます。そのため、生成される tar.gz アーカイブには、LICENSE ファイル以外にファイルが 2 つ含まれます。
パッチ ファイルは、プログラムとともにアーカイブで配布されません。RPM Packager は、RPM を構築する際にパッチを適用します。パッチは、.tar.gz アーカイブとともに、~/rpmbuild/SOURCES/ ディレクトリーに配置されます。
この手順では、cello プロジェクトを配布するために準備する方法を示します。
前提条件
このプログラムのバージョンが 1.0 であることを考慮してください。
手順
必要なファイルをすべて 1 つのディレクトリーに追加します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 配布用のアーカイブを作成し、これを
~/rpmbuild/SOURCES/ディレクトリーに移動します。このディレクトリーは、rpmbuildコマンドがパッケージを構築するファイルを保存するデフォルトディレクトリーです。Copy to Clipboard Copied! Toggle word wrap Toggle overflow パッチを追加します。
mv ~/cello-output-first-patch.patch ~/rpmbuild/SOURCES/
$ mv ~/cello-output-first-patch.patch ~/rpmbuild/SOURCES/Copy to Clipboard Copied! Toggle word wrap Toggle overflow
C で書かれたサンプルソースコードの詳細は 「C で書かれた Hello World」 を参照してください。
第3章 ソフトウェアのパッケージ化 リンクのコピーリンクがクリップボードにコピーされました!
3.1. RPM パッケージ リンクのコピーリンクがクリップボードにコピーされました!
このセクションでは、RPM パッケージ形式の基本を説明します。
3.1.1. RPM とは リンクのコピーリンクがクリップボードにコピーされました!
RPM パッケージは、他のファイルとそのメタデータ (システムが必要とするファイルに関する情報) を含むファイルです。
特に、RPM パッケージは cpio アーカイブで設定されています。
cpio アーカイブには以下が含まれます。
- ファイル
RPM ヘッダー (パッケージのメタデータ)
rpmパッケージマネージャーはこのメタデータを使用して依存関係、ファイルのインストール先、およびその他の情報を決定します。
RPM パッケージの種類
RPM パッケージには 2 つの種類があります。いずれも、同じファイル形式とツールを使用しますが、コンテンツが異なるため、目的が異なります。
ソース RPM (SRPM)
SRPM には、ソースコードと SPEC ファイルが含まれます。これには、ソースコードをバイナリー RPM にビルドする方法が書かれています。必要に応じて、ソースコードへのパッチも含まれます。
バイナリー RPM
バイナリー RPM には、ソースおよびパッチから構築されたバイナリーが含まれます。
3.1.2. RPM パッケージ化ツールのユーティリティーのリスト表示 リンクのコピーリンクがクリップボードにコピーされました!
以下の手順では、rpmdevtools パッケージが提供するユーティリティーのリストを表示する方法を示しています。
前提条件
RPM パッケージ化ツールを使用できるようにするには、rpmdevtools パッケージをインストールする必要があります。
yum install rpmdevtools
# yum install rpmdevtools
手順
RPM パッケージ化ツールのユーティリティーをリスト表示します。
rpm -ql rpmdevtools | grep bin
$ rpm -ql rpmdevtools | grep binCopy to Clipboard Copied! Toggle word wrap Toggle overflow
追加情報
- 上記のユーティリティーの詳細は、各マニュアルページまたはヘルプダイアログを参照してください。
3.1.3. RPM パッケージ化を行うためのワークスペースの設定 リンクのコピーリンクがクリップボードにコピーされました!
本セクションでは、rpmdev-setuptree ユーティリティーを使用して、RPM のパッケージ化ワークスペースとなるディレクトリーレイアウトを設定する方法を説明します。
前提条件
rpmdevtools パッケージがシステムにインストールされている必要があります。
yum install rpmdevtools
# yum install rpmdevtools
手順
-
rpmdev-setuptreeユーティリティーを実行します。
作成されたディレクトリーは、以下の目的で使用します。
| ディレクトリー | 目的 |
| BUILD |
パッケージを構築すると、ここにさまざまな |
| RPMS |
バイナリー RPM は、さまざまなアーキテクチャーのサブディレクトリー (例: |
| SOURCES |
ここでは、このパッケージャーは、圧縮したソースコードアーカイブとパッチを配置します。 |
| SPECS | パッケージャーは、SPEC ファイルをここに配置します。 |
| SRPMS |
|
3.1.4. SPEC ファイルの概要 リンクのコピーリンクがクリップボードにコピーされました!
SPEC ファイルには、RPM を構築するのに rpmbuild ユーティリティーが使用するレシピが含まれています。SPEC ファイルは、一連のセクションで命令を定義することで、ビルドシステムに必要な情報を提供します。このセクションは、Preamble と Body で定義されます。Preamble では、Body に使用されている一連のメタデータ項目が含まれています。Body は、命令の主要部分を示しています。
3.1.4.1. Preamble 項目 リンクのコピーリンクがクリップボードにコピーされました!
以下の表では、RPM SPEC ファイルの Preamble セクションで頻繁に使用されるディレクティブの一部を示しています。
| SPEC ディレクティブ | 定義 |
|---|---|
|
| SPEC ファイル名と一致する必要があるパッケージのベース名。 |
|
| ソフトウェアのアップストリームのバージョン番号。 |
|
|
このバージョンのソフトウェアがリリースされた回数。通常、初期値は 1%{?dist} に設定し、パッケージの新規リリースごとに増加させます。新しい |
|
| パッケージの 1 行の概要 |
|
| パッケージ化しているソフトウェアのライセンス。 |
|
| プログラムに関する詳細情報の完全な URL。多くの場合、この URL は、パッケージ化しているソフトウェアのアップストリームプロジェクトの Web サイトです。 |
|
| アップストリームのソースコードの圧縮アーカイブへのパスまたは URL (パッチを適用していないものや、パッチは別の場所で処理されます)。これは、たとえば、パッケージャーのローカルストレージではなく、アップストリームページなどのアーカイブの、アクセス可能で信頼できるストレージを参照している必要があります。必要に応じて、SourceX ディレクティブを追加して、たとえば、Source1、Source2、Source3 など、毎回数を増やすことができます。 |
|
| 必要に応じて、ソースコードに適用する最初のパッチの名前。 ディレクティブは、パッチの末尾に数字を付けて、または付けずに適用できます。 数値を指定しないと、内部的にエントリーに割り当てられます。Patch0、Patch1、Patch2、Patch3 などを使用して、明示的に数字を指定することもできます。 このパッチは、%patch0、%patch1、%patch2 といったマクロを使用して、1 つずつ適用できます。マクロは、RPM SPEC ファイルの Body セクションの %prep ディレクティブ内で適用されます。または、%autounconfined マクロを使用できます。これは、SPEC ファイルに指定されている順序ですべてのパッチを自動的に適用します。 |
|
|
パッケージがアーキテクチャーに依存していない場合は (たとえば、インタープリター型のプログラミング言語ですべて書かれた場合など)、これを |
|
|
コンパイル言語で書かれたプログラムを構築するのに必要なコンマ区切りまたは空白区切りのリスト。 |
|
|
インストール後のソフトウェアの実行に必要なパッケージのコンマ区切りまたは空白区切りのリスト。 |
|
| ソフトウェアの一部が特定のプロセッサーアーキテクチャーで動作しない場合には、そのアーキテクチャーを除外できます。 |
|
|
|
|
|
このディレクティブでは、 |
|
|
|
Name のディレクティブ、Version のディレクティブ、および Release のディレクティブは、RPM パッケージのファイル名から設定されます。RPM パッケージの担当者やシステム管理者は、これら 3 つのディレクティブを N-V-R または NVR と呼びます。これは、RPM パッケージのファイル名に NAME-VERSION-RELEASE 形式が含まれるためです。
以下の例は、rpm コマンドを実行して、特定のパッケージの NVR 情報を取得する方法を示しています。
例3.1 bash パッケージの NVR 情報を出力する rpm のクエリー
rpm -q bash bash-4.2.46-34.el7.x86_64
$ rpm -q bash
bash-4.2.46-34.el7.x86_64
ここでは、bash がパッケージ名で 4.2.46 がバージョン、34.el7 がリリースです。最後のマーカーの x86_64 は、アーキテクチャーを意味しています。NVR とは異なり、アーキテクチャーのマーカーは RPM パッケージャーで直接管理されていませんが、rpmbuild ビルド環境で定義されます。ただし、これはアーキテクチャーに依存しない noarch パッケージです。
3.1.4.2. Body 項目 リンクのコピーリンクがクリップボードにコピーされました!
RPM SPEC ファイルの Body セクション の項目を以下の表にリスト表示します。
| SPEC ディレクティブ | 定義 |
|---|---|
|
| RPM でパッケージ化されているソフトウェアの完全な説明。この説明は、複数の行や、複数の段落にまでわたることがあります。 |
|
|
|
|
| ソフトウェアをマシンコード (コンパイル言語用) またはバイトコード (インタープリター言語) に構築するための 1 つまたは一連のコマンド。 |
|
|
|
|
| ソフトウェアをテストする単一または一連のコマンド。これには通常、ユニットテストなどが含まれます。 |
|
| エンドユーザーのシステムにインストールされるファイルのリスト。 |
|
|
異なる |
3.1.4.3. 高度な項目 リンクのコピーリンクがクリップボードにコピーされました!
SPEC ファイルには、Scriptlets や Triggers などの高度な項目を追加することもできます。これは、ビルドプロセスではなく、エンドユーザーのシステムのインストールプロセスのさまざまな地点で有効になります。
3.1.5. BuildRoots リンクのコピーリンクがクリップボードにコピーされました!
RPM のパッケージ化のコンテキストでは、buildroot が chroot 環境となります。つまり、ビルドのアーティファクトが、エンドユーザーシステムの今後の階層と同じファイルシステム階層を使用して配置され、buildroot がルートディレクトリーとして機能します。ビルドアーティファクトの配置は、エンドユーザーシステムのファイルシステム階層の基準に準拠する必要があります。
buildroot のファイルは、後で dhcpd アーカイブに置かれ、RPM の主要部分になります。RPM がエンドユーザーのシステムにインストールされている場合、これらのファイルは root ディレクトリーに抽出され、階層が正しく保持されます。
6 以降では、rpmbuild プログラムには独自のデフォルトが設定されています。このデフォルト値を上書きすると、問題が発生することがあります。{RH} では、このマクロの値を自身で定義することを推奨していません。%{buildroot} マクロは、rpmbuild ディレクトリーのデフォルトで使用できます。
3.1.6. RPM マクロ リンクのコピーリンクがクリップボードにコピーされました!
rpm マクロ は、特定の組み込み機能が使用されている場合に、ステートメントのオプションの評価に基づいて、条件付きで割り当てられる直接的なテキスト置換です。したがって、RPM は、ユーザーに変わってテキストの置換を行うことができます。
使用例では、SPEC ファイルでパッケージ化されたソフトウェアの Version を複数回参照しています。%{version} マクロで 1 回だけ Version を定義し、SPEC ファイル全体でこのマクロを使用します。すべては、以前に定義した Version に自動的に置き換えられます。
見たことのないマクロが表示されている場合は、次のコマンドを使用してマクロを評価できます。
rpm --eval %{_MACRO}
$ rpm --eval %{_MACRO}
%{_bindir} マクロおよび %{_libexecdir} マクロの評価
rpm --eval %{_bindir}
/usr/bin
rpm --eval %{_libexecdir}
/usr/libexec
$ rpm --eval %{_bindir}
/usr/bin
$ rpm --eval %{_libexecdir}
/usr/libexec
一般的に使用されるマクロには、%{?dist} マクロがあります。これは、ビルドに使用されるディストリビューション (ディストリビューションタグ) を示します。
# On a RHEL 8.x machine
rpm --eval %{?dist}
.el8
# On a RHEL 8.x machine
$ rpm --eval %{?dist}
.el8
3.2. SPEC ファイルでの作業 リンクのコピーリンクがクリップボードにコピーされました!
このセクションでは、SPEC ファイルを作成して変更する方法を説明します。
前提条件
このセクションでは、「ソースコードの例」 で説明された Hello World! の 3 つの実装例を使用します。
各プログラムは、以下の表で詳細に説明しています。
| ソフトウェアの名前 | 例の説明 |
| bello | raw インタープリタープログラミング言語で書かれたプログラム。ソースコードを構築する必要はなく、インストールのみが必要である場合を示しています。事前にコンパイル済みのバイナリーをパッケージ化する必要がある場合、バイナリーは単なるファイルであるため、この方法を使用することもできます。 |
| pello | バイトコンパイルインタプリタ-プログラム言語で書かれたプログラム。これは、ソースコードのバイトコンパイルと、生成される事前処理ファイルのバイトコードのインストールを示しています。 |
| cello | ネイティブコンパイル言語で書かれたプログラム。これは、ソースコードをマシンコードにコンパイルし、生成される実行ファイルをインストールする一般的なプロセスを示しています。 |
Hello World! の実装は次のとおりです。
前提条件として、これらの実装は、~/rpmbuild/SOURCES ディレクトリーに置く必要があります。
3.2.1. 新しい SPEC ファイルを作成する方法 リンクのコピーリンクがクリップボードにコピーされました!
新しいソフトウェアをパッケージ化するには、新しい SPEC ファイルを作成する必要があります。
これをアーカイブするには、2 つの方法があります。
- 手動による SPEC ファイルの新規作成
rpmdev-newspecユーティリティーの使用このユーティリティーは、空の SPEC ファイルを作成し、必要なディレクティブとフィールドを入力します。
プログラマーに焦点を合わせたテキストエディターの中には、独自の SPEC テンプレートで新しい .spec ファイルを事前に準備しているものもあります。rpmdev -newspec ユーティリティーでは、エディターに依存しないアプローチを利用できます。
3.2.2. rpmdev-newspec を使用した新規 SPEC ファイルの作成 リンクのコピーリンクがクリップボードにコピーされました!
以下の手順は、rpmdev -newspec ユーティリティーを使用して、上記の 3 つの Hello World! プログラムごとに SPEC ファイルを作成する方法を示しています。
手順
~/rpmbuild/specsディレクトリーに移動し、rpmdev -newspecユーティリティーを使用します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ~/rpmbuild/specs/ディレクトリーには、bello.spec、cello.spec、およびpello.specという名前の 3 つの SPEC ファイルが含まれています。
fd。ファイルを調べます。
+
rpmdev-newspec ユーティリティーは、特定の Linux ディストリビューションに固有のガイドラインや規則を使用しません。ただし、本ドキュメントは Red Hat Enterprise Linux を対象にしています。そのため、SPEC ファイル全体にわたり定義または提供したその他のすべてのマクロとの一貫性を確立するために、RPM のビルドルートを参照する際には、$RPM_BUILD_ROOT において %{buildroot} の記述が推奨されます。
3.2.3. RPM を作成するための、元の SPEC ファイルの変更 リンクのコピーリンクがクリップボードにコピーされました!
以下の手順では、RPM を作成する rpmdev- newspec による SPEC 出力ファイルを修正する方法を示しています。
前提条件
以下の点を確認してください。
-
特定のプログラムのソースコードが、
~/rpmbuild/SOURCES/ディレクトリーに置かれている。 -
空の SPEC ファイル (
~/rpmbuild/specs/<name>.specファイル) が、rpmdev -newspecユーティリティーで作成されている。
手順
-
rpmdev -newspecユーティリティーで生成される~/rpmbuild/specs/<name>.specファイルの出力テンプレートを開きます。 SPEC ファイルの最初のセクションを作成します。
最初のセクションには、
rpmdev -newspecがグループ化される以下のディレクティブが含まれます。-
Name -
Version -
Release SummaryNameはすでにrpmdev -newspecの引数として指定されています。Versionを、ソースコードのアップストリームのリリースバージョンと一致するように設定します。Releaseは、1%{?dist}に自動的に設定されます。最初は1となります。パッチを追加する場合など、アップストリームリリースのVersionを変更せずにパッケージを更新するたびに、初期値を増やします。新しいアップストリームリリースが行われた際に、Releaseが1にリセットされます。Summaryは、ソフトウェアに関する 1 行の短い説明です。
-
License、URL、およびSource0ディレクティブを入力します。Licenseフィールドは、アップストリームリリースのソースコードに関連するソフトウェアライセンスです。SPEC ファイルでLicenseにラベルを付ける方法は、使用する RPM ベースの特定の Linux ディストリビューションガイドラインによって異なります。たとえば、GPLv3+ を使用できます。
URLフィールドは、アップストリームのソフトウェア Web サイトへの URL を指定します。一貫性を保つために、%{name}の RPM マクロ変数を利用し、https://example.com/%{name} を使用します。Source0フィールドは、アップストリームのソフトウェアソースコードへの URL を指定します。これは、パッケージ化している特定のバージョンのソフトウェアに直接リンクする必要があります。本ドキュメントの URL の例には、将来変更される可能性があるハードコーディングした値が含まれています。同様に、リリースのバージョンも変更される可能性があります。今後の変更を簡素化するには、%{name}マクロと%{version}マクロを使用します。これらを使用して、SPEC ファイルの 1 つのフィールドのみを更新する必要があります。BuildRequiresディレクティブ、Requiresディレクティブ、およびBuildArchディレクティブを入力します。BuildRequiresは、パッケージのビルドタイム依存関係を指定します。Requiresは、パッケージのランタイム依存関係を指定します。これは、ネイティブにコンパイルされた拡張機能がない、インタープリター型プログラミング言語で書かれたソフトウェアです。したがって、
noarch値とともにBuildArchディレクティブを追加します。これは、このパッケージを構築するプロセッサーアーキテクチャーに制限する必要がないことを RPM に指定します。%description、%prep、%build、%install、%files、%licenseディレクティブを入力します。これらのディレクティブは、マルチライン、マルチインストラクション、または実行するスクリプト処理タスクを定義することができるため、セクションの見出しと考えることができます。
%descriptionは、ソフトウェアの完全な説明でSummaryよりも長く、複数の段落が含まれています。% prepセクションでは、ビルド環境の準備方法を指定します。通常、これには、ソースコードの圧縮アーカイブのデプロイメント、パッチの適用、および SPEC ファイルの後半で使用するためにソースコードでによる情報の解析が含まれます。このセクションでは、ビルトインの% setup -qマクロを使用できます。%buildセクション では、ソフトウェアを構築する方法を指定します。%installセクションには、ソフトウェアを構築してからBUILDROOTディレクトリーにインストールする方法に関するrpmbuildの説明が記載されています。このディレクトリーは空の chroot ベースディレクトリーで、エンドユーザーの root ディレクトリーに似ています。ここでは、インストールしたファイルを格納するディレクトリーを作成できます。このようなディレクトリーを作成するには、パスをハードコードせずに RPM マクロを使用します。
%filesセクションは、この RPM によるファイルのリストと、エンドユーザーシステム上のファイルの完全なパス場所を指定します。このセクションでは、組み込みのマクロを使用して、さまざまなファイルのロールを示すことができます。これは、command[]
rpmコマンドを使用したパッケージファイルマニフェストのメタデータの照会に役立ちます。たとえば、LICENSE ファイルがソフトウェアライセンスファイルであることを示すには、%licenseマクロを使用します。最後のセクションの
%changelogは、パッケージの各 Version-Release に対する日付入りのエントリーのリストです。これらは、ソフトウェアの変更ではなく、パッケージの変更を記録します。パッケージ変更の例: パッチの追加、%buildセクションのビルド手順の変更。最初の行は、以下の形式に従います。
*文字でで始まり、Day-of-Week Month Day Year Name Surname <email> - Version-Releaseが続きます。実際の変更エントリーには、以下の形式に従います。
- 各変更エントリーには、変更ごとに複数の項目を含めることができます。
- 各項目は新しい行で始まります。
-
各項目は
-文字で始まります。
これで、必要なプログラム用に SPEC ファイル全体を作成できるようになりました。
異なるプログラミング言語で書かれた SPEC ファイルの例は、以下を参照してください。
3.2.4. bash で書かれたプログラム用の SPEC ファイルサンプル リンクのコピーリンクがクリップボードにコピーされました!
このセクションでは、bash 書かれた bello プログラムの SPEC ファイルの例を示しています。bello の詳細は 「ソースコードの例」 を参照してください。
bash で記載された bello の SPEC ファイルの例
bello のビルドステップがないため、パッケージのビルドタイム依存関係を指定する BuildRequires ディレクティブが削除されました。bash は、raw インタープリタープログラミング言語で、ファイルはシステム上のその場所にインストールされます。
パッケージのランタイム依存関係を指定する Requires ディレクティブは、bash のみを含めます。これは、bello スクリプトを実行するには bash シェル環境のみが必要なためです。
bash はビルド不要のため、ソフトウェアの構築方法を示す %build セクションは空白です。
bello をインストールする場合は、インストール先のディレクトリーを作成し、そこに実行可能な bash スクリプトファイルをインストールする必要があります。よって、%install セクションで install コマンドを使用できます。RPM マクロを使用すると、パスをハードコーディングせずにこれを実行できます。
3.2.5. Python で書かれたプログラムの SPEC ファイルサンプル リンクのコピーリンクがクリップボードにコピーされました!
このセクションでは、Python プログラミング言語で書かれた pello プログラムの SPEC ファイルの例を示します。pello の詳細は 「ソースコードの例」 を参照してください。
Python で書かれた pello プログラムの SPEC ファイルサンプル
pello バイトコンパイルインタープリター言語で書かれたプログラムです。よって、生成されるファイルにはエントリーが含まれていないため、シバンは使いません。
シバンは使わないため、以下のアプローチのいずれかを適用する必要があります。
- 実行ファイルを呼び出す、バイトコンパイル以外のシェルスクリプトを作成します。
- プログラムの実行にエントリーポイントとしてバイトコンパイルされない小規模の Python コードを提供します。
これらのアプローチは特に、事前にコンパイルされたコードのパフォーマンス向上が大きい、数千行ものコードを含む大規模ソフトウェアプロジェクトに便利です。
パッケージのビルドタイム依存関係を指定する BuildRequires ディレクティブには、以下の 2 つのパッケージが含まれます。
-
pythonパッケージが、バイトコンパイルのビルドプロセスを実行する必要がある。 -
小規模なエントリーポイントスクリプトを実行するには、
bashパッケージが必要。
パッケージのランタイム依存関係を指定する Requires ディレクティブには、python パッケージのみが含まれます。pello プログラムは、実行時にバイトコンパイルコードを実行するために python パッケージを必要とします。
%build セクションは、ソフトウェアを構築する方法を指定します。つまり、ソフトウェアがバイトコンパイルされるということになります。
pello をインストールするには、ラッパースクリプトを作成する必要があります。これは、シバンがバイトコンパイル言語で該当しないためです。これを行うには、以下のような複数のオプションを利用できます。
-
個別のスクリプトを作成し、それを個別の
SourceXディレクティブとして使用します。 - SPEC ファイルにファイルをインラインで作成。
この例では、SPEC ファイルにラッパースクリプトのインラインを作成し、SPEC ファイル自体がスクリプト可能であるこを示しています。このラッパースクリプトは、こちら のドキュメントを使用して Python バイトコンパイルコードを実行します。
この例の %install セクションは、アクセスできるように、バイトコンパイルファイルをシステム上のライブラリーディレクトリーにインストールする必要があるという事実に一致します。
3.2.6. C で書かれたプログラムの SPEC ファイルサンプル リンクのコピーリンクがクリップボードにコピーされました!
このセクションでは、C プログラミング言語で書かれた cello プログラム用の SPEC ファイルの例を示します。cello の詳細は 「ソースコードの例」 を参照してください。
C 言語で書かれた cello の SPEC ファイルの例
パッケージのビルド時依存関係を指定する BuildRequires ディレクティブには、コンパイルビルドプロセスを実行するために必要な 2 つのパッケージが含まれます。
-
gccパッケージ -
makeパッケージ
この例では、パッケージにランタイム依存関係を指定する Requires ディレクティブは省略されています。すべてのランタイム要件は rpmbuild により処理されます。cello プログラムはコア C 標準ライブラリー以外のものは必要としません。
%build セクションは、この例では、cello プログラムの Makefile が書かれているため、rpmdev-newspec ユーティリティーによる GNU make コマンドを使用できます。ただし、設定スクリプトを指定していないため、%configure に対する呼び出しを削除する必要があります。
cello プログラムのインストールは、rpmdev-newspec コマンドによる %make_install マクロを使用して行うことができます。これは、cello プログラムの Makefile が利用できるため可能です。
3.3. RPM のビルド リンクのコピーリンクがクリップボードにコピーされました!
本セクションでは、プログラム用の SPEC ファイルを作成した後に RPM を構築する方法を説明します。
RPM は、rpmbuild コマンドで構築されます。このコマンドは、特定のディレクトリーと rpmdev -setuptree ユーティリティーで設定された構造と同じファイル構造を想定します。
rpmbuild コマンドでは、ユースケースや期待する結果によって組み合わせる引数が異なります。本セクションでは、主なユースケースを 2 つ説明します。
- ソース RPM のビルド
- バイナリー RPM のビルド
3.3.1. ソース RPM のビルド リンクのコピーリンクがクリップボードにコピーされました!
この段落は、手順モジュールの紹介 (手順の簡単な説明) です。
前提条件
パッケージ化するプログラムの SPEC ファイルがすでに存在している必要があります。SPEC ファイルの作成方法は SPEC ファイルでの作業 を参照してください。
手順
次の手順では、ソース RPM のビルド方法を説明します。
指定の SPEC ファイルを使用して
rpmbuildコマンドを実行します。rpmbuild -bs SPECFILE
$ rpmbuild -bs SPECFILECopy to Clipboard Copied! Toggle word wrap Toggle overflow SPECFILE を SPEC ファイルに置き換えます。
-bsオプションは、ビルドソースを表します。
以下の例は、bello プロジェクト、pello プロジェクト、および cello プロジェクトのソース RPM のビルドを示しています。
bello、pello、および cello のソース RPM のビルド。
検証手順
-
生成されたソース RPM が
rpmbuild/SRPMSディレクトリーに含まれていることを確認してください。ディレクトリーは、rpmbuildで必要な構造の一部です。
3.3.2. バイナリー RPM のビルド リンクのコピーリンクがクリップボードにコピーされました!
バイナリー RPM のビルドには、以下の方法を使用できます。
- ソース RPM からのバイナリー RPM の再ビルド
- SPEC ファイルからのバイナリー RPM のビルド
- ソース RPM からのバイナリー RPM のビルド
3.3.2.1. ソース RPM からのバイナリー RPM の再ビルド リンクのコピーリンクがクリップボードにコピーされました!
以下の手順は、ソース RPM (SRPM) からバイナリー RPM を再構築する方法を示しています。
手順
SRPMS から
bello、pello、およびcelloを再構築するには、以下を実行します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
rpmbuild --rebuild を起動すると、以下が関係します。
-
SRPM の内容 (SPEC ファイルおよびソースコード) の、
~/rpmbuild/ディレクトリーへのインストール。 - インストール済みコンテンツを使用したビルド。
- SPEC ファイルとソースコードの削除
SPEC ファイルとソースコードをビルド後も維持するには、以下を行います。
-
ビルド時には、
--rebuildオプションの代わりに、--recompileオプションを指定してrpmbuildコマンドを使用します。 以下のコマンドを使用して SRPM をインストールします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
バイナリー RPM の作成時に生成される出力は詳細なもので、これはデバッグに役立ちます。この出力は各種例によって異なり、SPEC ファイルに一致します。
生成されるバイナリー RPM は、YOURARCH がアーキテクチャーとなる ~/rpmbuild/RPMS/YOURARCH ディレクトリーか、パッケージがアーキテクチャー固有でなければ、~/rpmbuild/RPMS/noarch/ ディレクトリーに位置します。
3.3.2.2. SPEC ファイルからのバイナリー RPM のビルド リンクのコピーリンクがクリップボードにコピーされました!
以下の手順では、SPEC ファイルから bello、pello、および cello バイナリー RPM のビルド方法を示しています。
手順
bbオプションを指定して、rpmbuildコマンドを実行します。rpmbuild -bb ~/rpmbuild/SPECS/bello.spec rpmbuild -bb ~/rpmbuild/SPECS/pello.spec rpmbuild -bb ~/rpmbuild/SPECS/cello.spec
$ rpmbuild -bb ~/rpmbuild/SPECS/bello.spec $ rpmbuild -bb ~/rpmbuild/SPECS/pello.spec $ rpmbuild -bb ~/rpmbuild/SPECS/cello.specCopy to Clipboard Copied! Toggle word wrap Toggle overflow
3.3.2.3. ソース RPM からの RPM のビルド リンクのコピーリンクがクリップボードにコピーされました!
ソース RPM からあらゆる種類の RPM をビルドすることもできます。これを行うには、以下の手順を行います。
手順
以下のオプションのいずれかと、ソースパッケージを指定して、
rpmbuildコマンドを実行します。rpmbuild {-ra|-rb|-rp|-rc|-ri|-rl|-rs} [rpmbuild-options] SOURCEPACKAGE# rpmbuild {-ra|-rb|-rp|-rc|-ri|-rl|-rs} [rpmbuild-options] SOURCEPACKAGECopy to Clipboard Copied! Toggle word wrap Toggle overflow
関連情報
ソース RPM から RPM をビルドする方法は、man ページの rpmbuild(8) の BUILDING PACKAGES セクションを参照してください。
3.4. RPM のサニティーチェック リンクのコピーリンクがクリップボードにコピーされました!
パッケージを作成したら、パッケージの品質を確認します。
パッケージの品質をチェックする主要なツールは、rpmlint です。
rpmlint ツールは、以下のことを行います。
- RPM の保守性の向上。
- RPM の静的な分析の実行によるサニティーチェック。
- RPM の静的な分析の実行による、エラーチェック。
rpmlint ツールはバイナリー RPM、ソース RPM (SRPMS) 、SPEC ファイルをチェックできるため、以下の例で示すように、パッケージ化のすべての段階で役に立ちます。
rpmlint には非常に厳密なガイドラインがあるため、以下の例にあるように、一部のエラーや警告をスキップできる場合もあることに注意してください。
以下の例では、rpmlint はオプションを指定せずに実行し、詳細でない出力を生成します。それぞれのエラーや警告の詳細な説明は、rpmlint -i を実行してください。
3.4.1. bello によるサニティーチェック リンクのコピーリンクがクリップボードにコピーされました!
本セクションでは、bello SPEC ファイルおよび bello バイナリー RPM の例で RPM のサニティーチェックを行う際に発生する可能性のある警告およびエラーを示します。
3.4.1.1. bello の SPEC ファイルの確認 リンクのコピーリンクがクリップボードにコピーされました!
例3.2 bello の SPEC ファイルでの rpmlint コマンド実行の出力
rpmlint bello.spec bello.spec: W: invalid-url Source0: https://www.example.com/bello/releases/bello-0.1.tar.gz HTTP Error 404: Not Found 0 packages and 1 specfiles checked; 0 errors, 1 warnings.
$ rpmlint bello.spec
bello.spec: W: invalid-url Source0: https://www.example.com/bello/releases/bello-0.1.tar.gz HTTP Error 404: Not Found
0 packages and 1 specfiles checked; 0 errors, 1 warnings.
bello.spec には、Source0 ディレクティブにリスト表示される URL に到達できないことを示す警告が 1 つのみあります。example.com URL は存在しないため、この出力は当然です。今後、この URL が機能すると仮定して、この警告を無視します。
例3.3 bello の SRPM で rpmlint コマンドを実行した場合の出力
rpmlint ~/rpmbuild/SRPMS/bello-0.1-1.el8.src.rpm bello.src: W: invalid-url URL: https://www.example.com/bello HTTP Error 404: Not Found bello.src: W: invalid-url Source0: https://www.example.com/bello/releases/bello-0.1.tar.gz HTTP Error 404: Not Found 1 packages and 0 specfiles checked; 0 errors, 2 warnings.
$ rpmlint ~/rpmbuild/SRPMS/bello-0.1-1.el8.src.rpm
bello.src: W: invalid-url URL: https://www.example.com/bello HTTP Error 404: Not Found
bello.src: W: invalid-url Source0: https://www.example.com/bello/releases/bello-0.1.tar.gz HTTP Error 404: Not Found
1 packages and 0 specfiles checked; 0 errors, 2 warnings.
bello SRPM については、URL ディレクティブで指定された URL に到達できないことを示す新しい警告が表示されます。今後、リンクが機能すると仮定して、この警告を無視します。
3.4.1.2. bello バイナリー RPM の確認 リンクのコピーリンクがクリップボードにコピーされました!
バイナリー RPM をチェックする場合、rpmlint は以下の項目をチェックします。
- ドキュメント
- man ページ
- ファイルシステム階層規格の一貫した使用
例3.4 bello のバイナリー RPM での rpmlint コマンドの実行の出力
rpmlint ~/rpmbuild/RPMS/noarch/bello-0.1-1.el8.noarch.rpm bello.noarch: W: invalid-url URL: https://www.example.com/bello HTTP Error 404: Not Found bello.noarch: W: no-documentation bello.noarch: W: no-manual-page-for-binary bello 1 packages and 0 specfiles checked; 0 errors, 3 warnings.
$ rpmlint ~/rpmbuild/RPMS/noarch/bello-0.1-1.el8.noarch.rpm
bello.noarch: W: invalid-url URL: https://www.example.com/bello HTTP Error 404: Not Found
bello.noarch: W: no-documentation
bello.noarch: W: no-manual-page-for-binary bello
1 packages and 0 specfiles checked; 0 errors, 3 warnings.
no-documentation および no-manual-page-for-binary の警告では、RPM にドキュメントや man ページがないことが表示されます。これは指定しないため当然です。上記の警告とは別に、RPM は rpmlint チェックに合格しています。
3.4.2. pello のサニティーチェック リンクのコピーリンクがクリップボードにコピーされました!
本セクションでは、pello の SPEC ファイルおよび pello のバイナリー RPM の例で RPM のサニティーチェックを行う際に発生する可能性のある警告およびエラーを示します。
3.4.2.1. pello の SPEC ファイルの確認 リンクのコピーリンクがクリップボードにコピーされました!
例3.5 pello の SPEC ファイルで rpmlint コマンドを実行した場合の出力
invalid-url Source0 警告では、Source0 ディレクティブにリスト表示される URL にアクセスできないことが書かれています。example.com URL は存在しないため、この出力は当然です。この URL が今後機能すると仮定して、この警告を無視します。
hardcoded-library-path エラーでは、ライブラリーパスをハードコーディングするのではなく、%{_libdir} マクロを使用することが推奨されます。この例では、これらのエラーは無視しても問題はありません。ただし、実際のパッケージの場合は、すべてのエラーが慎重にチェックされていることを確認してください。
例3.6 pello の SRPM で rpmlint コマンドを実行した場合の出力
ここでの新しい invalid-url URL エラーは、到達できない URL ディレクティブに関するものです。今後、この URL が有効であると仮定して、この警告を無視しても問題はありません。
3.4.2.2. pello バイナリー RPM の確認 リンクのコピーリンクがクリップボードにコピーされました!
バイナリー RPM をチェックする場合、rpmlint は以下の項目をチェックします。
- ドキュメント
- man ページ
- ファイルシステム階層規格の一貫した使用
例3.7 pello のバイナリー RPM での rpmlint コマンドの実行の出力
no-documentation および no-manual-page-for-binary の警告では、RPM にドキュメントや man ページがないことが表示されます。これは指定しないため当然です。
only-non-binary-in-usr-lib 警告では、/usr/lib/ にバイナリーでないアーティクトのみを提供していることが表示されます。このディレクトリーは通常、バイナリーファイルである共有オブジェクトファイル用に予約されています。したがって、rpmlint は、/usr/lib/ ディレクトリー内の少なくとも 1 つ以上のファイルがバイナリーであることを想定します。
これは、ファイルシステム階層規格への準拠についての rpmlint チェック例です。通常、ファイルを正しく配置するには RPM マクロを使用します。この例では、この警告は無視しても問題はありません。
non-executable-script エラーは、/usr/lib/pello/pello.py ファイルに実行権限がないことを警告します。ファイルにシバンが含まれているため、rpmlint ツールは、ファイルが実行ファイルであること想定します。この例では、このファイルは実行権限なしのままにし、このエラーを無視します。
上記の警告およびエラーとは別に、RPM は rpmlint チェックに合格しています。
3.4.3. cello のサニティーチェック リンクのコピーリンクがクリップボードにコピーされました!
本セクションでは、cello の SPEC ファイルおよび pello のバイナリー RPM の例で RPM のサニティーチェックを行う際に発生する可能性のある警告およびエラーを示します。
3.4.3.1. cello の SPEC ファイルの確認 リンクのコピーリンクがクリップボードにコピーされました!
例3.8 cello の SPEC で rpmlint コマンドを実行した場合の出力
rpmlint ~/rpmbuild/SPECS/cello.spec /home/<username>/rpmbuild/SPECS/cello.spec: W: invalid-url Source0: https://www.example.com/cello/releases/cello-1.0.tar.gz HTTP Error 404: Not Found 0 packages and 1 specfiles checked; 0 errors, 1 warnings.
$ rpmlint ~/rpmbuild/SPECS/cello.spec
/home/<username>/rpmbuild/SPECS/cello.spec: W: invalid-url Source0: https://www.example.com/cello/releases/cello-1.0.tar.gz HTTP Error 404: Not Found
0 packages and 1 specfiles checked; 0 errors, 1 warnings.
cello.spec には、Source0 ディレクティブにリスト表示される URL に到達できないことを示す警告が 1 つのみあります。example.com URL は存在しないため、この出力は当然です。この URL が今後機能すると仮定して、この警告を無視します。
例3.9 cello の SRPM で rpmlint コマンドを実行した場合の出力
rpmlint ~/rpmbuild/SRPMS/cello-1.0-1.el8.src.rpm cello.src: W: invalid-url URL: https://www.example.com/cello HTTP Error 404: Not Found cello.src: W: invalid-url Source0: https://www.example.com/cello/releases/cello-1.0.tar.gz HTTP Error 404: Not Found 1 packages and 0 specfiles checked; 0 errors, 2 warnings.
$ rpmlint ~/rpmbuild/SRPMS/cello-1.0-1.el8.src.rpm
cello.src: W: invalid-url URL: https://www.example.com/cello HTTP Error 404: Not Found
cello.src: W: invalid-url Source0: https://www.example.com/cello/releases/cello-1.0.tar.gz HTTP Error 404: Not Found
1 packages and 0 specfiles checked; 0 errors, 2 warnings.
cello SRPM については、URL ディレクティブで指定された URL に到達できないことを示す新しい警告が表示されます。今後、リンクが機能すると仮定して、この警告を無視することができます。
3.4.3.2. cello バイナリー RPM の確認 リンクのコピーリンクがクリップボードにコピーされました!
バイナリー RPM をチェックする場合、rpmlint は以下の項目をチェックします。
- ドキュメント
- man ページ
- ファイルシステム階層規格の一貫した使用
例3.10 cello のバイナリー RPM で rpmlint コマンドを実行した場合の出力
rpmlint ~/rpmbuild/RPMS/x86_64/cello-1.0-1.el8.x86_64.rpm cello.x86_64: W: invalid-url URL: https://www.example.com/cello HTTP Error 404: Not Found cello.x86_64: W: no-documentation cello.x86_64: W: no-manual-page-for-binary cello 1 packages and 0 specfiles checked; 0 errors, 3 warnings.
$ rpmlint ~/rpmbuild/RPMS/x86_64/cello-1.0-1.el8.x86_64.rpm
cello.x86_64: W: invalid-url URL: https://www.example.com/cello HTTP Error 404: Not Found
cello.x86_64: W: no-documentation
cello.x86_64: W: no-manual-page-for-binary cello
1 packages and 0 specfiles checked; 0 errors, 3 warnings.
no-documentation および no-manual-page-for-binary の警告では、RPM にドキュメントや man ページがないことが表示されます。これは指定しないため当然です。上記の警告とは別に、RPM は rpmlint チェックに合格しています。
第4章 高度なトピック リンクのコピーリンクがクリップボードにコピーされました!
本セクションでは、入門的なチュートリアルの範囲外のトピックについて説明しますが、実際の RPM パッケージ化で役に立ちます。
4.1. パッケージの署名 リンクのコピーリンクがクリップボードにコピーされました!
サードパーティーがそのコンテンツを変更できないようにパッケージに署名を行います。ユーザーは、パッケージをダウンロードする際に HTTPS プロトコルを使用して、セキュリティーをさらに強化できます。
パッケージの署名には、以下の 3 つの方法があります。
4.1.1. GPG キーの作成 リンクのコピーリンクがクリップボードにコピーされました!
手順
GNU Privacy Guard (GPG) キーペアを生成します。
gpg --gen-key
# gpg --gen-keyCopy to Clipboard Copied! Toggle word wrap Toggle overflow 生成したキーを確認し、表示します。
gpg --list-keys
# gpg --list-keysCopy to Clipboard Copied! Toggle word wrap Toggle overflow 公開鍵をエクスポートします。
gpg --export -a '<Key_name>' > RPM-GPG-KEY-pmanager
# gpg --export -a '<Key_name>' > RPM-GPG-KEY-pmanagerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記<Key_name> の代わりにキーに対して選択した実際の名前を含めます。
エクスポートした公開鍵を RPM データベースにインポートします。
rpm --import RPM-GPG-KEY-pmanager
# rpm --import RPM-GPG-KEY-pmanagerCopy to Clipboard Copied! Toggle word wrap Toggle overflow
4.1.2. 既存パッケージへの署名の追加 リンクのコピーリンクがクリップボードにコピーされました!
このセクションでは、署名なしでパッケージを構築する場合に最も役立つケースを説明します。この署名は、パッケージのリリースの直前に追加されます。
パッケージに署名を追加するには、rpm -sign パッケージで使用できる --addsign を指定します。
複数の署名があると、パッケージ作成者からエンドユーザーに、パッケージの所有権のパスを記録できます。
手順
パッケージに署名を追加します。
rpm --addsign blather-7.9-1.x86_64.rpm
$ rpm --addsign blather-7.9-1.x86_64.rpmCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記署名の秘密鍵のロックを解除するには、パスワードを入力する必要があります。
4.1.3. 複数の署名のあるパッケージの署名の確認 リンクのコピーリンクがクリップボードにコピーされました!
手順
複数の署名を持つパッケージの署名を確認するには、以下のコマンドを実行します。
rpm --checksig blather-7.9-1.x86_64.rpm blather-7.9-1.x86_64.rpm: size pgp pgp md5 OK
$ rpm --checksig blather-7.9-1.x86_64.rpm blather-7.9-1.x86_64.rpm: size pgp pgp md5 OKCopy to Clipboard Copied! Toggle word wrap Toggle overflow rpm --checksigコマンドの出力の 2 つのpgp文字列は、パッケージが回署名されていることを示しています。
4.1.4. 既存のパッケージに署名を追加する実用的な例 リンクのコピーリンクがクリップボードにコピーされました!
本セクションでは、既存のパッケージへの署名の追加が役立つ状況の例を示します。
ある会社の部門が、パッケージを作成し、その部門のキーで署名を行います。次に、本社がパッケージの署名を確認します。次に、そのパッケージにコーポレート署名を追加し、その署名されたパッケージが本物であることを表明します。
これら 2 つの署名が付いた状態で、パッケージが小売商に送られます。この小売商は、署名をチェックし、一致を確認して自身の署名も追加します。
そして、このパッケージは、このパッケージをデプロイメントしたいと思う会社へと向かいます。パッケージ上の署名をすべて確認すれば、その署名が正式コピーであることが分かります。パッケージが企業の承認を受けたことを従業員に通知するために、その会社独自の署名を追加するかどうかは、パッケージ導入を行う会社の内部管理によって決まります。
4.1.5. 既存のパッケージの署名の置き換え リンクのコピーリンクがクリップボードにコピーされました!
この手順では、各パッケージを再構築せずに公開鍵を変更する方法を説明します。
手順
公開鍵を変更するには、次のコマンドを実行します。
rpm --resign blather-7.9-1.x86_64.rpm
$ rpm --resign blather-7.9-1.x86_64.rpmCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記署名の秘密鍵のロックを解除するには、パスワードを入力する必要があります。
また、以下の手順で示しているように、--resign オプションを指定すると、複数のパッケージの公開鍵を変更できます。
手順
複数のパッケージの公開鍵を変更するには、以下のコマンドを実行します。
rpm --resign b*.rpm
$ rpm --resign b*.rpmCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記署名の秘密鍵のロックを解除するには、パスワードを入力する必要があります。
4.1.6. ビルド時のパッケージの署名 リンクのコピーリンクがクリップボードにコピーされました!
手順
rpmbuildコマンドを使用して、パッケージを構築します。rpmbuild blather-7.9.spec
$ rpmbuild blather-7.9.specCopy to Clipboard Copied! Toggle word wrap Toggle overflow --addsignオプションを指定して、rpmsignコマンドでパッケージに署名します。rpmsign --addsign blather-7.9-1.x86_64.rpm
$ rpmsign --addsign blather-7.9-1.x86_64.rpmCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 必要に応じて、パッケージの署名を確認します。
rpm --checksig blather-7.9-1.x86_64.rpm blather-7.9-1.x86_64.rpm: size pgp md5 OK
$ rpm --checksig blather-7.9-1.x86_64.rpm
blather-7.9-1.x86_64.rpm: size pgp md5 OK
複数のパッケージのビルドと署名を行う場合は、以下の構文を使用して Pretty good Privacy (PGP) パスフレーズを複数回入力しないようにします。
rpmbuild -ba --sign b*.spec
$ rpmbuild -ba --sign b*.spec
署名の秘密鍵のロックを解除にはパスワードを入力する必要があることに注意してください。
4.2. マクロの詳細 リンクのコピーリンクがクリップボードにコピーされました!
本セクションでは、選択したビルトイン RPM マクロについて説明します。このようなマクロの完全なリストは、RPM ドキュメンテーション を参照してください。
4.2.1. 独自のマクロの定義する リンクのコピーリンクがクリップボードにコピーされました!
次のセクションでは、カスタムマクロの作成方法を説明します。
手順
RPM SPEC ファイルに以下の行を含めます。
%global <name>[(opts)] <body>
%global <name>[(opts)] <body>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
\ の周りの空白すべてが削除されます。名前は英数字と _ で設定できます。最低でも 3 文字で指定する必要があります。(opts) フィールドの指定は任意です。
-
Simpleマクロには、(opts)フィールドは含まれません。この場合、再帰的なマクロ拡張のみが実行されます。 -
Parametrizedマクロには、(opts)フィールドが含まれます。括弧で囲まれているopts文字列は、マクロ呼び出しの開始時にargc/argv処理のgetopt (3)に渡されます。
古い RPM SPEC ファイルは、代わりに % define <name> <body> マクロパターンを使用します。%define マクロと %global マクロの違いは次のとおりです。
-
%defineにはローカルスコープがあります。これは、SPEC ファイルの特定の部分に適用されます。使用時に、%defineマクロの本文がデプロイメントされます。 -
%globalにはグローバルスコープがあります。これは SPEC ファイル全体に適用されます。%globalマクロの本文は、定義時にデプロイメントされます。
マクロは、コメントアウトされた場合でも、マクロ名が SPEC ファイルの %changelog に指定されている場合でも評価されます。マクロをコメントアウトするには %% を使用します。例: %%global
関連情報
マクロ機能に関する包括的な情報は、RPM ドキュメント を参照してください。
4.2.2. %setup マクロの使用 リンクのコピーリンクがクリップボードにコピーされました!
このセクションでは、%setup マクロの異なるバリアントを使用して、ソースコード tarball でパッケージを構築する方法を説明します。マクロのバリアントは組み合わせることができることに注意してください。rpmbuild の出力は、%setup マクロの標準的な動作を示しています。各フェーズの開始時に、マクロは以下の例のように Executing(%…) を出力します。
例4.1 %setup マクロの出力例
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.DhddsG
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.DhddsG
シェルの出力は、set -x enabled で設定されます。/var/tmp/rpm-tmp.DhddsG の内容を表示するには、--debug オプションを指定します。これは、rpmbuild により、ビルドの作成後に一時ファイルが削除されるためです。環境変数の設定の後に、以下のような設定が表示されます。
%setup マクロ:
- 正しいディレクトリーで作業していることを確認します。
- 以前のビルドで残ったファイルを削除します。
- ソース tarball をデプロイメントします。
- 一部のデフォルト権限を設定します。
4.2.2.1. %setup -q マクロの使用 リンクのコピーリンクがクリップボードにコピーされました!
-q オプションでは、%setup マクロの冗長性が制限されます。tar -xvof の代わりに tar -xof のみが実行されます。このオプションは、最初のオプションとして使用します。
4.2.2.2. %setup -n マクロの使用 リンクのコピーリンクがクリップボードにコピーされました!
- n オプションは、拡張 tarball からディレクトリー名を指定します。
デプロイメントした tarball のディレクトリーの名前が、想定される名前 (%{name}-%{version} と異なる場合に、これを使用すると、%setup マクロのエラーが発生することがあります。
たとえば、パッケージ名が cello で、ソースコードが hello-1.0.tgz でアーカイブされ、hello/ ディレクトリーが含まれている場合、SPEC ファイルのコンテンツは次のようになります。
Name: cello
Source0: https://example.com/%{name}/release/hello-%{version}.tar.gz
…
%prep
%setup -n hello
Name: cello
Source0: https://example.com/%{name}/release/hello-%{version}.tar.gz
…
%prep
%setup -n hello
4.2.2.3. %setup -c マクロの使用 リンクのコピーリンクがクリップボードにコピーされました!
-c オプションは、ソースコード tarball にサブディレクトリーが含まれておらず、デプロイメント後に、アーカイブのファイルで現在のディレクトリーを埋める場合に使用されます。
次に、-c オプションによりディレクトリーが作成され、以下のようにアーカイブデプロイメント手順に映ります。
/usr/bin/mkdir -p cello-1.0 cd 'cello-1.0'
/usr/bin/mkdir -p cello-1.0
cd 'cello-1.0'
このディレクトリーは、アーカイブ拡張後も変更されません。
4.2.2.4. %setup -D マクロおよび %setup -T マクロの使用 リンクのコピーリンクがクリップボードにコピーされました!
- D オプションは、ソースコードのディレクトリーの削除を無効するため、%setup マクロを複数回使用する場合に特に便利です。-D オプションでは、次の行は使用されません。
rm -rf 'cello-1.0'
rm -rf 'cello-1.0'
- T オプションは、スクリプトから以下の行を削除して、ソースコード tarball の拡張を無効にします。
/usr/bin/gzip -dc '/builddir/build/SOURCES/cello-1.0.tar.gz' | /usr/bin/tar -xvvof -
/usr/bin/gzip -dc '/builddir/build/SOURCES/cello-1.0.tar.gz' | /usr/bin/tar -xvvof -
4.2.2.5. %setup -a マクロおよび %setup -b マクロの使用 リンクのコピーリンクがクリップボードにコピーされました!
-a オプションおよび -b オプションは、特定のソースを拡張します。
-b オプションは before を意味し、作業ディレクトリーに移動する前に特定のソースをデプロイメントします。-a オプションは after を意味し、移動後にそのソースをデプロイメントします。これらの引数は、SPEC ファイルのプリアンブルからのソース番号です。
以下の例では、cello-1.0.tar.gz アーカイブに空の example ディレクトリーが含まれています。サンプルは、別の example.tar.gz tarball に同梱されており、同じ名前のディレクトリーにデプロイメントされます。この場合、作業ディレクトリーに移動してから Source1 を展開する場合は、-a 1 を指定します。
Source0: https://example.com/%{name}/release/%{name}-%{version}.tar.gz
Source1: examples.tar.gz
…
%prep
%setup -a 1
Source0: https://example.com/%{name}/release/%{name}-%{version}.tar.gz
Source1: examples.tar.gz
…
%prep
%setup -a 1
以下の例では、サンプルは cello-1.0-examples.tar.gz tarball にあり、cello-1.0/examples にデプロイメントされます。この場合、作業ディレクトリーに移動する前に、-b 1 を指定して Source1 をデプロイメントします。
Source0: https://example.com/%{name}/release/%{name}-%{version}.tar.gz
Source1: %{name}-%{version}-examples.tar.gz
…
%prep
%setup -b 1
Source0: https://example.com/%{name}/release/%{name}-%{version}.tar.gz
Source1: %{name}-%{version}-examples.tar.gz
…
%prep
%setup -b 1
4.2.3. %files セクション共通の RPM マクロ リンクのコピーリンクがクリップボードにコピーされました!
このセクションでは、SPEC ファイルの %files セクションで必要となる高度な RPM マクロを紹介します。
| マクロ | 定義 |
|---|---|
| %license |
マクロは、LICENSE ファイルとしてリストされているファイルを識別します。そしてインストールされ、RPM などとしてラベルが付けられます。例: |
| %doc |
マクロは、ドキュメントとしてリストされるファイルを識別して、RPM によりインストールされ、ラベル付けされます。このマクロは、パッケージソフトウェアに関するドキュメントや、コード例や、付随するさまざまなアイテムに使用されます。コードの例が含まれる場合は、実行ファイルから実行可能モードを削除するように注意してください。例: |
| %dir |
このマクロは、そのパスが、この RPM が所有するディレクトリーとなるようにします。これは、RPM ファイルマニフェストが、アンインストール時にどのディレクトリーをクリーンアップするかを正確に認識できるようにするために重要です。例: |
| %config (noreplace) |
このマクロにより、次のファイルが設定ファイルであることが保証されます。そのため、ファイルを元のインストールチェックサムから修正しても、パッケージのインストールまたは更新で上書き (または置き換え) しないでください。変更がある場合は、アップグレード時またはインストール時にファイル名の末尾に |
4.2.4. ビルトインマクロの表示 リンクのコピーリンクがクリップボードにコピーされました!
複数のビルトイン RPM マクロを指定します。
手順
ビルトイン RPM マクロをすべて表示するには、以下のコマンドを実行します。
rpm --showrc
rpm --showrcCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記出力のサイズは非常に大きくなります。結果を絞り込むには、
grepコマンドとともに上記のコマンドを使用します。システムの RPM バージョン用の RPM マクロに関する情報を確認するには、以下のコマンドを実行します。
rpm -ql rpm
rpm -ql rpmCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記RPM マクロは、出力ディレクトリー構造の
macrosというタイトルのファイルです。
4.2.5. RPM ディストリビューションマクロ リンクのコピーリンクがクリップボードにコピーされました!
パッケージ化しているソフトウェアの言語実装や、ディストリビューションの特定のガイドラインに基づいて提供する推奨 RPM マクロセットは、ディストリビューションによって異なります。
多くの場合、推奨される RPM マクロセットは RPM パッケージとして提供され、yum パッケージマネージャーでインストールできます。
インストールすると、マクロファイルは、/usr/lib/rpm/macros.d/ ディレクトリーに配置されます。
raw RPM マクロ定義を表示するには、以下のコマンドを実行します。
rpm --showrc
rpm --showrc
上記の出力では、raw RPM マクロ定義が表示されます。
RPM のパッケージ化を行う際のマクロの機能や、マクロがどう役立つかを確認するには、rpm --eval コマンドに、引数として使用するマクロの名前を付けて実行します。
rpm --eval %{_MACRO}
rpm --eval %{_MACRO}
詳細は rpm の man ページを参照してください。
4.2.5.1. カスタムマクロの作成 リンクのコピーリンクがクリップボードにコピーされました!
~/.rpmmacros ファイル内のディストリビューションマクロは、カスタムマクロで上書きできます。加えた変更は、マシン上のすべてのビルドに影響します。
~/.rpmmacros ファイルで新しいマクロを定義することは推奨されません。このようなマクロは、ユーザーがパッケージを再構築する可能性がある他のマシンには存在しません。
マクロを上書きするには、次のコマンドを実行します。
%_topdir /opt/some/working/directory/rpmbuild
%_topdir /opt/some/working/directory/rpmbuild
上記の例から、rpmde-setuptree ユーティリティーを使用して、すべてのサブディレクトリーを含むディレクトリーを作成できます。このマクロの値は、デフォルトでは ~/rpmbuild です。
%_smp_mflags -l3
%_smp_mflags -l3
上記のマクロは、Makefile に渡すためによく使用されます。たとえば、make %{?_smp_mflags} と、ビルドフェーズ時に多数の同時プロセスを設定します。デフォルトでは、-jX に設定されています。X は多数のコアです。コア数を変すると、パッケージビルドの速度アップまたはダウンを行うことができます。
4.3. Epoch、Scriptlets、Triggers リンクのコピーリンクがクリップボードにコピーされました!
このセクションでは、RMP SPEC ファイルの高度なディレクティブを表す Epoch、Scriptlet、Triggers について説明します。
これらのディレクティブはすべて、SPEC ファイルだけでなく、生成された RPM がインストールされているエンドマシンにも影響します。
4.3.1. Epoch ディレクティブ リンクのコピーリンクがクリップボードにコピーされました!
Epoch ディレクティブでは、バージョン番号に基づいて加重依存関係を定義できます。
このディレクティブが RPM SPEC ファイルにない場合、Epoch ディレクティブは全く設定されません。これは、Epoch を設定しないと Epoch が 0 になるという一般的な考え方に反しています。ただし、YUM ユーティリティーは、depsolve の目的で、0 の Epoch と同様に設定されていない Epoch を処理します。
ただし、SPEC ファイルでの Epoch の リストは通常省略されます。これは、多くの場合、Epoch 値を導入すると、パッケージのバージョンを比較する際に、想定される RPM 動作がスキューされるためです。
例4.2 Epoch の使用
Epoch: 1 および Version: 1.0 で foobar パッケージをインストールし、他のユーザーが Version 2.0 で foobar をパッケージ化します。ただし、Epoch ディレクティブがない場合、新しいバージョンは更新とはみなされません。RPM パッケージ用のバージョン管理を示す従来の Name-Version-Release ラッパーよりも、Epoch バージョンが推奨されている理由。
Epoch を使用することはほとんどありません。ただし、Epoch は 、通常、アップグレードの順序の問題を解決するために使用されます。この問題は、ソフトウェアバージョン番号のスキームや、エンコードに基づいて確実に比較できないアルファベット文字を組み込んだバージョンにおける、アップストリームによる変更の副次的効果として見られる場合があります。
4.3.2. Scriptlets リンクのコピーリンクがクリップボードにコピーされました!
Scriptlets は、パッケージがインストールまたは削除される前または後に実行される一連の RPM ディレクティブです。
Scriptlets は、ビルド時またはスタートアップスクリプト内で実行できないタスクにのみ使用します。
4.3.2.1. Scriptlets ディレクティブ リンクのコピーリンクがクリップボードにコピーされました!
共通の Scriptlet ディレクティブのセットがあります。これは、SPEC ファイルセクションのヘッダー (%build、%install など) と似ています。これは、標準の POSIX シェルスクリプトとしてよく書かれる、マルチラインのコードセグメントによって定義されます。ただし、ターゲットマシンのディストリビューションの RPM が対応する他のプログラミング言語で書くこともできます。RPM ドキュメントには、利用可能な言語の完全なリストが含まれます。
以下の表には、実行順の Scriptlet ディレクティブのリストが含まれます。スクリプトを含むパッケージは、%pre と %post ディレクティブの間にインストールされ、%preun ディレクティブと %postun ディレクティブ間でアンインストールされることに注意してください。
| ディレクティブ | 定義 |
|---|---|
|
| パッケージのインストールまたは削除の直前に実行されるスクリプトレット。 |
|
| ターゲットシステムにパッケージをインストールする直前に実行されるスクリプトレット。 |
|
| ターゲットシステムにパッケージがインストールされた直後に実行されるスクリプトレット。 |
|
| ターゲットシステムからパッケージをアンインストールする直前に実行されるスクリプトレット。 |
|
| ターゲットシステムからパッケージをアンインストールした直後に実行されるスクリプトレット。 |
|
| トランザクションの最後に実行されるスクリプトレット。 |
4.3.2.2. スクリプトレット実行の無効化 リンクのコピーリンクがクリップボードにコピーされました!
スクリプトレットの実行を無効にするには、rpm コマンドに --no_scriptlet_name_ オプションを指定して使用します。
手順
たとえば、
%pretransスクリプトレットの実行を無効にするには、次のコマンドを実行します。rpm --nopretrans
# rpm --nopretransCopy to Clipboard Copied! Toggle word wrap Toggle overflow -- noscriptsオプションも使用できます。これは、以下のすべてと同等になります。-
--nopre -
--nopost -
--nopreun -
--nopostun -
--nopretrans -
--noposttrans
-
関連情報
-
詳細は、man ページの
rpm(8)を参照してください。
4.3.2.3. スクリプトレットマクロ リンクのコピーリンクがクリップボードにコピーされました!
Scriptlets ディレクティブは、RPM マクロでも機能します。
以下の例は、systemd スクリプトレットマクロの使用を示しています。これにより、systemd は新しいユニットファイルについて通知されるようになります。
4.3.3. Triggers ディレクティブ リンクのコピーリンクがクリップボードにコピーされました!
Triggers は、パッケージのインストールおよびアンインストール時に対話できる手段を提供する RPM ディレクティブです。
Triggers は、含まれるパッケージの更新など、予期できないタイミングで実行できます。Triggers はデバッグが難しいため、予期せず実行されたときに破損しないように、安定したな方法で実装する必要があります。このため、Red Hat では、 of Triggers の使用は最小限に抑えることを推奨します。
実行の順序と、既存の各 Triggers の詳細を以下に示します。
上記の項目は、/usr/share/doc/rpm-4.*/triggers ファイルにあります。
4.3.4. SPEC ファイルでのシェルスクリプト以外のスクリプトの使用 リンクのコピーリンクがクリップボードにコピーされました!
SPEC ファイルの -p スクリプトレットオプションを指定すると、ユーザーはデフォルトのシェルスクリプトインタープリター (-p /bin/sh) の代わりに特定のインタープリターを起動することができます。
次の手順では、pello.py プログラムのインストール後にメッセージを出力するスクリプトの作成方法を説明します。
手順
-
pello.specファイルを開きます。 以下の行を見つけます。
install -m 0644 %{name}.py* %{buildroot}/usr/lib/%{name}/install -m 0644 %{name}.py* %{buildroot}/usr/lib/%{name}/Copy to Clipboard Copied! Toggle word wrap Toggle overflow 上記の行の下に、以下を挿入します。
%post -p /usr/bin/python3 print("This is {} code".format("python"))%post -p /usr/bin/python3 print("This is {} code".format("python"))Copy to Clipboard Copied! Toggle word wrap Toggle overflow パッケージをインストールします。
yum install /home/<username>/rpmbuild/RPMS/noarch/pello-0.1.2-1.el8.noarch.rpm
# yum install /home/<username>/rpmbuild/RPMS/noarch/pello-0.1.2-1.el8.noarch.rpmCopy to Clipboard Copied! Toggle word wrap Toggle overflow インストール後に出力メッセージを確認します。
Installing : pello-0.1.2-1.el8.noarch 1/1 Running scriptlet: pello-0.1.2-1.el8.noarch 1/1 This is python code
Installing : pello-0.1.2-1.el8.noarch 1/1 Running scriptlet: pello-0.1.2-1.el8.noarch 1/1 This is python codeCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Python 3 スクリプトを使用するには、SPEC ファイルの install -m に次の行を含めます。
%post -p /usr/bin/python3
%post -p /usr/bin/python3
Lua スクリプトを使用するには、SPEC ファイルの install -m に次の行を含めます。
%post -p <lua>
%post -p <lua>
これにより、SPEC ファイル内で任意のインタープリターを指定できます。
4.4. RPM 条件 リンクのコピーリンクがクリップボードにコピーされました!
RPM 条件により、さまざまなバージョンの SPEC ファイルを条件付きで含めることができます。
条件を含めるには通常、次を処理します。
- アーキテクチャー固有のセクション
- オペレーティングシステム固有のセクション
- さまざまなバージョンのオペレーティング間の互換性の問題
- マクロの存在と定義
4.4.1. RPM 条件構文 リンクのコピーリンクがクリップボードにコピーされました!
RPM 条件では、次の構文を使用します。
expression が真であれば、以下のアクションを実行します。
%if expression … %endif
%if expression
…
%endif
expression が真であれば、別のアクションを実行し、別の場合には別のアクションを実行します。
%if expression … %else … %endif
%if expression
…
%else
…
%endif
4.4.2. RPM 条件例 リンクのコピーリンクがクリップボードにコピーされました!
このセクションでは、RPM 条件の例を複数示します。
4.4.2.1. %if 条件 リンクのコピーリンクがクリップボードにコピーされました!
例4.3 RHEL 8 と他のオペレーティングシステム間の互換性を処理するために %if 条件を使用
%if 0%{?rhel} == 8
sed -i '/AS_FUNCTION_DESCRIBE/ s/^//' configure.in sed -i '/AS_FUNCTION_DESCRIBE/ s/^//' acinclude.m4
%endif
%if 0%{?rhel} == 8
sed -i '/AS_FUNCTION_DESCRIBE/ s/^//' configure.in sed -i '/AS_FUNCTION_DESCRIBE/ s/^//' acinclude.m4
%endif
この条件では、AS_FUNCTION_DESCRIBE マクロのサポート上、RHEL 8 と他のオペレーティングシステム間の互換性が処理されます。パッケージが RHEL 用に構築されている場合は、%rhel マクロが定義され、RHEL バージョンにデプロイメントされます。値が 8 の場合、パッケージは RHEL 8 用にビルドされ、RHEL 8 で対応していない AS_FUNCTION_DESCRIBE への参照が autoconfig スクリプトから削除されます。
例4.4 %if 条件を使用したマクロの定義の処理す
%define ruby_archive %{name}-%{ruby_version}
%if 0%{?milestone:1}%{?revision:1} != 0
%define ruby_archive %{ruby_archive}-%{?milestone}%{?!milestone:%{?revision:r%{revision}}}
%endif
%define ruby_archive %{name}-%{ruby_version}
%if 0%{?milestone:1}%{?revision:1} != 0
%define ruby_archive %{ruby_archive}-%{?milestone}%{?!milestone:%{?revision:r%{revision}}}
%endif
この条件では、マクロの定義を処理します。%milestone マクロまたは %revision マクロが設定されている場合は、アップストリームの tarball の名前を定義する %ruby_archive マクロが再定義されます。
4.4.2.2. %if 条件の特殊なバリアント リンクのコピーリンクがクリップボードにコピーされました!
%ifarch 条件、%ifnarch 条件、%ifos 条件は、%if 条件の特殊なバリアントです。これらのバリアントは一般的に使用されるため、独自のマクロがあります。
4.4.2.2.1. %ifarch 条件 リンクのコピーリンクがクリップボードにコピーされました!
%ifarch 条件は、アーキテクチャー固有の SPEC ファイルのブロックを開始するために使用されます。この後に、アーキテクチャー指定子が続きます。これらは、それぞれコンマまたは空白で区切ります。
例4.5 %ifarch 条件の使用例
%ifarch i386 sparc … %endif
%ifarch i386 sparc
…
%endif
%ifarch と %endif の間にある SPEC ファイルのすべてのコンテンツは、32 ビット AMD および Intel のアーキテクチャー、または SunMAJOROS ベースのシステムでのみ処理されます。
4.4.2.2.2. %ifnarch 条件 リンクのコピーリンクがクリップボードにコピーされました!
% ifnarch 条件には、%ifarch 条件よりもリバース論理があります。
例4.6 %ifnarch 条件の使用例
%ifnarch alpha … %endif
%ifnarch alpha
…
%endif
SPEC ファイルの % ifnarch と % endif との間のすべてのコンテンツは、Digital Alpha/AXP ベースのシステムで処理されない場合に限り処理されます。
4.4.2.2.3. %ifos 条件 リンクのコピーリンクがクリップボードにコピーされました!
%ifos 条件は、ビルドのオペレーティングシステムに基づいて処理を制御するために使用されます。その後に複数のオペレーティングシステム名を指定できます。
例4.7 %ifos 条件の使用例
%ifos linux … %endif
%ifos linux
…
%endif
SPEC ファイルの %ifos と %endif と の間のすべてのコンテンツは、ビルドが Linux システムで実行された場合にのみ処理されます。
付録A RHEL 7 の RPM の新機能 リンクのコピーリンクがクリップボードにコピーされました!
このリストでは、Red Hat Enterprise Linux 6 と 7 の間の RPM パッケージ化における最も重要な変更が記載されています。
-
キーリングのインポートおよび署名検証に使用される新しいコマンド
rpmkeysが追加されました。 -
spec クエリーおよび解析出力に使用される新しいコマンド
rpmspecが追加されました。 -
パッケージ署名に使用される新しいコマンド
rpmsignが追加されました。 -
posix.fork()スクリプトレットで作成された子プロセスから呼び出されない限り、%{lua:…}スクリプトに埋め込まれたposix.exec()およびos.exit()エクステンションはスクリプトに失敗します。 -
%pretransスクリプトレットの失敗により、パッケージのインストールはスキップされます。 - スクリプトレットは、ランタイム時にデプロイメントされたマクロおよびクエリー形式が考えられます。
-
トランザクション前およびトランザクション後のスクリプトレット依存関係は、
Requires(pretrans)およびRequires(posttrans)スクリプトレットで正確に表記されるようになっています。 -
追加の順序付けヒントを提供するための
OrderWithRequiresタグが追加されました。タグはRequiresタグ構文に従いますが、実際の依存関係を生成しません。順序付けヒントは、関係するパッケージが同じトランザクションに存在する場合のみ、トランザクションの順序を計算する際にRequiresであるかのように処理されます。 -
%licenseフラグは、%filesセクションで使用できます。このフラグは、%docフラグと同様に使用して、ファイルをライセンスとしてマークできます。これは、--nodocsオプションを指定してもインストールする必要があります。 -
パッチアプリケーションの自動化用の
%autosetupマクロが、オプションの分散バージョン制御システム統合とともに追加されました。 - 自動依存関係ジェネレーターは、ビルトインフィルター付きで、拡張可能かつカスタマイズ可能なルールベースのシステムに書き換えられました。
- OpenPGP V3 公開鍵に対応しなくなりました。
第5章 RPM のパッケージ化の関連情報 リンクのコピーリンクがクリップボードにコピーされました!
本セクションでは、RPM、RPM のパッケージ化、RPM ビルドに関連するさまざまなトピックの参考資料を紹介します。これらの一部は高度なもので、本書に記載されている入門資料の発展となります。
Red Hat Software Collections Overview - Red Hat Software Collections は、最新の安定したバージョンで継続的に更新される開発ツールを提供します。
Red Hat Software Collections - Packaging Guide は、Software Collections の概要と、これらの構築およびパッケージする方法について説明しています。RPM を使用したソフトウェアパッケージングの基本知識がある開発者およびシステム管理者は、このガイドを使用して Software Collections を開始できます。
Mock - Mock は、さまざまなアーキテクチャー向けのコミュニティー対応パッケージビルドソリューションと、ビルドホストと異なる Fedora または RHEL バージョンを提供します。
RPM ドキュメント - 公式の RPM ドキュメント
Fedora Packaging Guidelines - Fedora の公式パッケージングガイドラインで、RPM ベースのすべてのディストリビューションに役に立ちます。