Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

ソフトウェアのパッケージ化および配布

Red Hat Enterprise Linux 8

RPM パッケージ管理システムを使用したソフトウェアのパッケージ化

Red Hat Customer Content Services

概要

RPM パッケージマネージャーを使用して、ソフトウェアを RPM パッケージにパッケージ化します。パッケージ化用のソースコードを準備し、ソフトウェアをパッケージ化して、Python プロジェクトや RubyGems を RPM パッケージにパッケージ化するなど、高度なパッケージ化シナリオを調査します。

Red Hat ドキュメントへのフィードバック (英語のみ)
リンクのコピー

Red Hat ドキュメントに関するご意見やご感想をお寄せください。また、改善点があればお知らせください。

Jira からのフィードバック送信 (アカウントが必要)

  1. Jira の Web サイトにログインします。
  2. 上部のナビゲーションバーで Create をクリックします。
  3. Summary フィールドにわかりやすいタイトルを入力します。
  4. Description フィールドに、ドキュメントの改善に関するご意見を記入してください。ドキュメントの該当部分へのリンクも追加してください。
  5. ダイアログの下部にある Create をクリックします。

第1章 RPM の概要
リンクのコピー

RPM Package Manager (RPM) は、Red Hat Enterprise Linux (RHEL)、CentOS、および Fedora で実行できるパッケージ管理システムです。RPM を使用すると、これらのオペレーティングシステム用に作成したソフトウェアを配布、管理、および更新できます。

RPM パッケージ管理システムには、従来のアーカイブファイルでソフトウェアを配布する場合と比べて、次のような利点があります。

  • RPM は、ソフトウェアを個別にインストール、更新、または削除できるパッケージの形式で管理されるため、オペレーティングシステムのメンテナンスが容易になります。
  • RPM パッケージは圧縮アーカイブと同様にスタンドアロンのバイナリーファイルであるため、RPM によりソフトウェアの配布が簡素化されます。これらのパッケージは、特定のオペレーティングシステムとハードウェアアーキテクチャー向けにビルドされています。RPM には、コンパイルされた実行可能ファイルやライブラリーなどのファイルが含まれています。これらのファイルは、パッケージのインストール時にファイルシステム上の適切なパスに配置されます。

RPM を使用すると、次のタスクを実行できます。

  • パッケージ化されたソフトウェアをインストール、アップグレード、削除する。
  • パッケージソフトウェアの詳細情報を問い合わせる。
  • パッケージ化されたソフトウェアの整合性を検証する。
  • ソフトウェアソースから独自のパッケージをビルドし、ビルド手順を完了する。
  • GNU Privacy Guard (GPG) ユーティリティーを使用して、パッケージにデジタル署名する。
  • パッケージを YUM リポジトリーに公開する。

Red Hat Enterprise Linux では、RPM は YUM や PackageKit などの上位レベルのパッケージ管理ソフトウェアに完全に統合されています。RPM には独自のコマンドラインインターフェイスが用意されていますが、ほとんどのユーザーはこのようなソフトウェアを通じて RPM を操作するだけで済みます。ただし、RPM パッケージをビルドする場合は、rpmbuild(8) などの RPM ユーティリティーを使用する必要があります。

1.1. RPM パッケージ
リンクのコピー

RPM パッケージは、ファイルのアーカイブと、これらのファイルのインストールと消去に使用されるメタデータで構成されます。具体的には、RPM パッケージには次の要素が含まれています。

GPG 署名
GPG 署名は、パッケージの整合性を検証するために使用されます。
ヘッダー (パッケージのメタデータ)
RPM パッケージマネージャーは、このメタデータを使用して、パッケージの依存関係、ファイルのインストール先、その他の情報を確認します。
ペイロード
ペイロードは、システムにインストールするファイルを含む cpio アーカイブです。

RPM パッケージには 2 つの種類があります。いずれも、同じファイル形式とツールを使用しますが、コンテンツが異なるため、目的が異なります。

  • ソース RPM (SRPM)

    SRPM には、ソースコードと、ソースコードをバイナリー RPM にビルドする方法を記述した spec ファイルが含まれています。必要に応じて、SRPM にはソースコードへのパッチを含めることができます。

  • バイナリー RPM

    バイナリー RPM には、ソースおよびパッチから構築されたバイナリーが含まれます。

1.2. RPM パッケージ化ユーティリティーのリスト
リンクのコピー

パッケージを構築するための rpmbuild(8) プログラムに加えて、RPM はパッケージの作成プロセスを容易にするその他のユーティリティーを提供します。これらのプログラムは rpmdevtools パッケージにあります。

前提条件

  • rpmdevtools パッケージがインストールされている。 

    # yum install rpmdevtools
    Copy to Clipboard Toggle word wrap

手順

  • RPM パッケージ化ユーティリティーをリスト表示するには、次のいずれかの方法を使用します。

    • rpmdevtools パッケージによって提供される特定のユーティリティーとその簡単な説明をリストするには、次のように入力します。 

      $ rpm -qi rpmdevtools
      Copy to Clipboard Toggle word wrap

    • すべてのユーティリティーをリストするには、次のように入力します。 

      $ rpm -ql rpmdevtools | grep ^/usr/bin
      Copy to Clipboard Toggle word wrap

第2章 RPM パッケージ化を行うためのソフトウェアの作成
リンクのコピー

RPM パッケージ化用のソフトウェアを準備するには、ソースコードとは何か、およびソースコードからソフトウェアを作成する方法を理解する必要があります。

2.1. ソースコードとは
リンクのコピー

ソースコードとは、人間が判読できるコンピューターへの命令で、計算の実行方法を記述したものです。ソースコードは、プログラミング言語で書かれています。

3 つの異なるプログラミング言語で書かれた次のバージョンの Hello World プログラムにより、RPM パッケージマネージャーの主な使用例を説明します。

  • Bash で書かれた Hello World

    bello プロジェクトでは、Bash で Hello World を実装します。この実装には bello シェルスクリプトのみが含まれています。このプログラムの目的は、コマンドラインで Hello World を出力することです。

    bello ファイルには次の内容が含まれています。 

    #!/bin/bash

printf "Hello World\n"
    Copy to Clipboard Toggle word wrap

  • Python で書かれた Hello World

    pello プロジェクトでは、Python で Hello World を実装します。この実装には pello.py プログラムのみが含まれています。このプログラムの目的は、コマンドラインで Hello World を出力することです。

    pello.py ファイルには次の内容が含まれています。 

    #!/usr/bin/python3

print("Hello World")
    Copy to Clipboard Toggle word wrap

  • C で書かれた Hello World

    cello プロジェクトでは、C で Hello World を実装します。この実装には cello.c と Makefile ファイルのみが含まれています。したがって、作成される tar.gz アーカイブには、LICENSE ファイルに加えて 2 つのファイルが含まれます。このプログラムの目的は、コマンドラインで Hello World を出力することです。

    cello.c ファイルには次の内容が含まれています。 

    #include<stdio.h>

int main(void){
    printf("Hello World!\n");
    return 0;
}
    Copy to Clipboard Toggle word wrap
注記

パッケージ化プロセスは、Hello World プログラムのバージョンごとに異なります。

2.2. ソフトウェアの作成方法
リンクのコピー

次のいずれかの方法を使用して、人間が判読できるソースコードをマシンコードに変換できます。

  • ソフトウェアをネイティブにコンパイルします。
  • 言語インタープリターまたは言語仮想マシンを使用してソフトウェアを解釈します。ソフトウェアは、そのまま解釈することも、バイトコンパイルすることもできます。

2.2.1. ネイティブにコンパイルされたソフトウェア
リンクのコピー

ネイティブにコンパイルされたソフトウェアは、生成されたバイナリーの実行ファイルでマシンコードにコンパイルされるプログラミング言語で書かれたソフトウェアです。ネイティブにコンパイルされたソフトウェアはスタンドアロンソフトウェアです。

注記

ネイティブにコンパイルされた RPM パッケージは、アーキテクチャー固有のパッケージです。

64 ビット (x86_64) AMD または Intel のプロセッサーを使用するコンピューターでこのようなソフトウェアをコンパイルすると、32 ビット (x86) AMD または Intel プロセッサーでは実行できません。生成されるパッケージには、名前でアーキテクチャーが指定されています。

2.2.2. インタープリター型ソフトウェア
リンクのコピー

Bash や Python などの一部のプログラミング言語は、マシンコードにコンパイルされません。代わりに、言語インタープリターまたは言語仮想マシンが、事前の変換を行わずにプログラムのソースコードを逐次実行します。

注記

インタープリター型のプログラミング言語でのみ書かれたソフトウェアは、アーキテクチャーに依存しません。そのため、作成される RPM パッケージの名前には noarch 文字列が付きます。

インタープリター言語で書かれたソフトウェアは、そのまま解釈することも、バイトコンパイルすることもできます。

  • そのまま解釈されるソフトウェア

    このタイプのソフトウェアをコンパイルする必要はありません。そのまま解釈されるソフトウェアは、インタープリターによって直接実行されます。

  • バイトコンパイルされるソフトウェア

    このタイプのソフトウェアはまずバイトコードにコンパイルする必要があり、その後言語仮想マシンによって実行されます。

    注記

    一部のバイトコンパイル言語は、そのまま解釈することも、バイトコンパイルすることもできます。

RPM を使用してソフトウェアをビルドおよびパッケージ化する方法は、これら 2 つのソフトウェアタイプで異なることに注意してください。

2.3. ソースからのソフトウェアのビルド
リンクのコピー

ソフトウェア構築プロセス中に、ソースコードは、RPM を使用してパッケージ化できるソフトウェアアーティファクトに変換されます。

2.3.1. ネイティブにコンパイルされたコードからのソフトウェアのビルド
リンクのコピー

次のいずれかの方法を使用して、コンパイル言語で書かれたソフトウェアを実行可能ファイルにビルドできます。

  • 手動ビルド
  • 自動ビルド
2.3.1.1. サンプル C プログラムを手動ビルド
リンクのコピー

手動ビルドを使用して、コンパイル言語で書かれたソフトウェアをビルドできます。

C で書かれたサンプルの Hello World プログラム (cello.c) には次の内容が含まれています。 

#include <stdio.h>

int main(void) {
    printf("Hello World\n");
    return 0;
}
Copy to Clipboard Toggle word wrap

手順

  1. GNU コンパイラーコレクションから C コンパイラーを呼び出して、ソースコードをバイナリーにコンパイルします。 

    $ gcc -g -o cello cello.c
    Copy to Clipboard Toggle word wrap

  2. 作成されたバイナリー cello を実行します。 

    $ ./cello
Hello World
    Copy to Clipboard Toggle word wrap
2.3.1.2. サンプル C プログラムの自動ビルドの設定
リンクのコピー

大規模なソフトウェアでは、自動ビルドが一般的に使用されます。Makefile ファイルを作成し、GNU make ユーティリティーを実行することで、自動ビルドを設定できます。

手順

  1. 次の内容を含む Makefile ファイルを cello.c と同じディレクトリーに作成します。 

    cello:
	gcc -g -o cello cello.c

clean:
	rm cello

install:
       mkdir -p $(DESTDIR)/usr/bin
       install -m 0755 cello $(DESTDIR)/usr/bin/cello
    Copy to Clipboard Toggle word wrap

    cello:、clean:、install: の下の行は、行頭にタブ文字 (タブ) を追加する必要があることに注意してください。

  2. ソフトウェアをビルドします。 

    $ make
make: 'cello' is up to date.
    Copy to Clipboard Toggle word wrap

  3. ビルドが現在のディレクトリーですでに利用可能であるため、make clean コマンドを入力してから、make コマンドを再度入力します。 

    $ make clean
rm cello

$ make
gcc -g -o cello cello.c
    Copy to Clipboard Toggle word wrap

    GNU make システムが既存のバイナリーを検出するため、この時点でプログラムを再度ビルドしても効果がないことに注意してください。 

    $ make
make: 'cello' is up to date.
    Copy to Clipboard Toggle word wrap

  4. プログラムを実行します。 

    $ ./cello
Hello World
    Copy to Clipboard Toggle word wrap

2.3.2. ソースコードの解釈
リンクのコピー

次のいずれかの方法を使用して、インタープリター型プログラミング言語で記述されたソースコードをマシンコードに変換できます。

  • バイトコンパイル

    ソフトウェアのバイトコンパイル手順は、次の要素によって異なります。

    • プログラミング言語
    • 言語の仮想マシン

    • その言語で使用するツールおよびプロセス

      注記

      たとえば Python で書かれたソフトウェアをバイトコンパイルできます。配布を目的とした Python ソフトウェアは多くの場合バイトコンパイルされますが、このドキュメントで説明されている方法では行われません。説明されている手順は、コミュニティー標準に準拠することではなく、簡素化することを目的としたものです。実際の Python ガイドラインは Software Packaging and Distribution を参照してください。

    Python ソースコードは、そのまま解釈することもできます。ただし、バイトコンパイルされたバージョンの方が高速です。したがって、RPM パッケージの作成者は、エンドユーザーに配布するために、バイトコンパイルされたバージョンをパッケージ化する傾向があります。

  • 直接解釈

    Bash などのシェルスクリプト言語で書かれたソフトウェアは、常に直接解釈によって実行されます。

2.3.2.1. サンプル Python プログラムのバイトコンパイル
リンクのコピー

Python ソースコードの直接解釈ではなくバイトコンパイルを選択すると、より高速なソフトウェアを作成できます。

Python プログラミング言語で書かれたサンプルの Hello World プログラム (pello.py) には、次の内容が含まれています。 

print("Hello World")
Copy to Clipboard Toggle word wrap

手順

  1. pello.py ファイルをバイトコンパイルします。 

    $ python -m compileall pello.py
    Copy to Clipboard Toggle word wrap

  2. ファイルのバイトコンパイルされたバージョンが作成されたことを確認します。 

    $ ls __pycache__
pello.cpython-311.pyc
    Copy to Clipboard Toggle word wrap

    出力内のパッケージのバージョンは、インストールされている Python のバージョンによって異なる場合があることに注意してください。

  3. pello.py でプログラムを実行します。 

    $ python pello.py
Hello World
    Copy to Clipboard Toggle word wrap
2.3.2.2. サンプル Bash プログラムの直接解釈
リンクのコピー

Bash シェルの組み込み言語で書かれたサンプルの Hello World プログラム (bello) には、次の内容が含まれています。 

#!/bin/bash

printf "Hello World\n"
Copy to Clipboard Toggle word wrap
注記

bello ファイルの先頭にある シバン (#!) 記号は、プログラミング言語のソースコードの一部ではありません。

シバン を使用して、テキストファイルを実行可能ファイルに変換します。システムのプログラムローダーが、シバン を含む行を解析してバイナリー実行可能ファイルへのパスを取得し、それがプログラミング言語インタープリターとして使用されます。

手順

  1. ソースコードを含むファイルを実行可能ファイルにします。 

    $ chmod +x bello
    Copy to Clipboard Toggle word wrap

  2. 作成したファイルを実行します。 

    $ ./bello
Hello World
    Copy to Clipboard Toggle word wrap

第3章 RPM パッケージ化を行うためのソフトウェアの準備
リンクのコピー

RPM を使用してソフトウェアをパッケージ化する準備をするには、まずソフトウェアにパッチを適用し、LICENSE ファイルを作成し、それを tarball 形式でアーカイブします。

3.1. ソフトウェアへのパッチの適用
リンクのコピー

ソフトウェアをパッケージ化する場合、バグの修正や設定ファイルの変更など、元のソースコードに特定の変更を加えることが必要になる場合があります。RPM パッケージでは、元のソースコードを変更せずにそのままにして、パッチを適用することができます。

パッチは、ソースコードファイルを更新するテキストです。パッチは 2 つのバージョンのテキストの差を示すものであるため、diff 形式を使用します。diff ユーティリティーを使用してパッチを作成し、patch ユーティリティーを使用してそのパッチをソースコードに適用できます。

注記

ソフトウェア開発者は多くの場合、Git などのバージョン管理システムを使用してコードベースを管理します。このようなツールでは、diff やパッチソフトウェアを独自の方法で作成できます。

3.1.1. サンプル C プログラムのパッチファイルの作成
リンクのコピー

diff ユーティリティーを使用して、元のソースコードからパッチを作成できます。たとえば、C で書かれた Hello world プログラム (cello.c) にパッチを適用するには、次の手順を実行します。

前提条件

  • システムに diff ユーティリティーをインストールした。 

    # yum install diffutils
    Copy to Clipboard Toggle word wrap

手順

  1. 元のソースコードをバックアップします。 

    $ cp -p cello.c cello.c.orig
    Copy to Clipboard Toggle word wrap

    -p オプションは、モード、所有権、およびタイムスタンプを保持します。

  2. 必要に応じて cello.c を変更します。 

    #include <stdio.h>

int main(void) {
    printf("Hello World from my very first patch!\n");
    return 0;
}
    Copy to Clipboard Toggle word wrap

  3. パッチを生成します。 

    $ diff -Naur cello.c.orig cello.c
--- cello.c.orig        2016-05-26 17:21:30.478523360 -0500
+ cello.c     2016-05-27 14:53:20.668588245 -0500
@@ -1,6 +1,6 @@
 #include<stdio.h>

 int main(void){
-    printf("Hello World!\n");
+    printf("Hello World from my very first patch!\n");
     return 0;
 }
\ No newline at end of file
    Copy to Clipboard Toggle word wrap

    + で始まる行は、- で始まる行を置き換えます。

    注記

    diff コマンドには Naur オプションを指定することを推奨します。ほとんどのユースケースに適しているためです。

    • -N (--new-file)

      -N オプションは、存在しないファイルを空のファイルとして処理します。

    • -a (--text)

      -a オプションは、すべてのファイルをテキストとして扱います。その結果、diff ユーティリティーがバイナリーとして分類されたファイルを無視しなくなります。

    • -u (-U NUM または --unified[=NUM])

      -u オプションは、統一されたコンテキストの出力の NUM 行 (デフォルトは 3 行) の形式で出力を返します。これは、パッチファイルで一般的に使用される、コンパクトで読みやすい形式です。

    • -r (--recursive)

      -r オプションは、diff ユーティリティーが検出したサブディレクトリーを再帰的に比較します。

    ただし、この場合は、-u オプションのみが必要であることに注意してください。

  4. ファイルにパッチを保存します。 

    $ diff -Naur cello.c.orig cello.c > cello.patch
    Copy to Clipboard Toggle word wrap

  5. 元の cello.c を復元します。 

    $ mv cello.c.orig cello.c
    Copy to Clipboard Toggle word wrap
    重要

    RPM パッケージマネージャーは RPM パッケージをビルドするときに、変更されたファイルではなく元のファイルを使用するため、元の cello.c を保持する必要があります。詳細は、spec ファイルでの作業 を参照してください。

3.1.2. サンプル C プログラムへのパッチ適用
リンクのコピー

ソフトウェアにコードパッチを適用するには、patch ユーティリティーを使用できます。

前提条件

  • システムに patch ユーティリティーをインストールした。 

    # yum install patch
    Copy to Clipboard Toggle word wrap
  • 元のソースコードからパッチを作成した。手順は、サンプル C プログラムのパッチファイルの作成 参照してください。

手順

次の手順では、以前に作成した cello.patch ファイルを cello.c ファイルに適用します。

  1. パッチファイルの出力先を patch コマンド変更します。 

    $ patch < cello.patch
patching file cello.c
    Copy to Clipboard Toggle word wrap

  2. cello.c の内容に必要な変更が反映されていることを確認します。 

    $ cat cello.c
#include<stdio.h>

int main(void){
    printf("Hello World from my very first patch!\n");
    return 1;
}
    Copy to Clipboard Toggle word wrap

検証

  1. パッチを適用した cello.c プログラムをビルドします。 

    $ make
gcc -g -o cello cello.c
    Copy to Clipboard Toggle word wrap

  2. ビルドした cello.c プログラムを実行します。 

    $ ./cello
Hello World from my very first patch!
    Copy to Clipboard Toggle word wrap

3.2. LICENSE ファイルの作成
リンクのコピー

ソフトウェアは、ソフトウェアライセンスとともに配布することを推奨します。

ソフトウェアライセンスファイルは、ソースコードで何ができるか、何ができないかをユーザーに通知するものです。ソースコードに対するライセンスがないということは、そのコードに対するすべての権利を作成者が保持し、誰もソースコードから複製、配布、または派生著作物を作成できないことを意味します。

手順

  • 必要なライセンスステートメントを含む LICENSE ファイルを作成します。 

    $ vim LICENSE
    Copy to Clipboard Toggle word wrap

    以下は LICENSE ファイルの内容の例です。

    例3.1 GPLv3 LICENSE ファイルのテキストの例

    $ cat /tmp/LICENSE
This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program. If not, see http://www.gnu.org/licenses/.
    Copy to Clipboard Toggle word wrap

3.3. 配布用ソースコードアーカイブの作成
リンクのコピー

アーカイブファイルは、.tar.gz または .tgz 接尾辞を持つファイルです。ソースコードのアーカイブは、後で配布用にパッケージ化するソフトウェアのリリース方法として一般的です。

3.3.1. サンプル Bash プログラムのソースコードアーカイブの作成
リンクのコピー

bello プロジェクトは、Bash の Hello World ファイルです。

次の例には、bello シェルスクリプトのみが含まれています。したがって、作成される tar.gz アーカイブには、LICENSE ファイルのほかにファイルが 1 つだけ含まれます。

注記

patch ファイルは、プログラムとともにアーカイブで配布されません。RPM パッケージマネージャーは、RPM のビルド時にパッチを適用します。パッチは、tar.gz アーカイブとともに ~/rpmbuild/SOURCES/ ディレクトリーに配置されます。

前提条件

手順

  1. 必要なファイルをすべて 1 つのディレクトリーに移動します。 

    $ mkdir bello-0.1

$ mv bello bello-0.1/

$ mv LICENSE bello-0.1/
    Copy to Clipboard Toggle word wrap

  2. 配布用のアーカイブを作成します。 

    $ tar -cvzf bello-0.1.tar.gz bello-0.1
bello-0.1/
bello-0.1/LICENSE
bello-0.1/bello
    Copy to Clipboard Toggle word wrap

  3. 作成したアーカイブを ~/rpmbuild/SOURCES/ ディレクトリーに移動します。これは、rpmbuild コマンドがパッケージをビルドするためのファイルを保存するデフォルトのディレクトリーです。 

    $ mv bello-0.1.tar.gz ~/rpmbuild/SOURCES/
    Copy to Clipboard Toggle word wrap

3.3.2. サンプル C プログラムのソースコードアーカイブの作成
リンクのコピー

cello プロジェクトは、C 言語の Hello World ファイルです。

次の例には、cello.c と Makefile ファイルのみが含まれています。したがって、作成される tar.gz アーカイブには、LICENSE ファイルに加えて 2 つのファイルが含まれます。

注記

patch ファイルは、プログラムとともにアーカイブで配布されません。RPM パッケージマネージャーは、RPM のビルド時にパッチを適用します。パッチは、tar.gz アーカイブとともに ~/rpmbuild/SOURCES/ ディレクトリーに配置されます。

前提条件

手順

  1. 必要なファイルをすべて 1 つのディレクトリーに移動します。 

    $ mkdir cello-1.0

$ mv cello.c cello-1.0/

$ mv Makefile cello-1.0/

$ mv LICENSE cello-1.0/
    Copy to Clipboard Toggle word wrap

  2. 配布用のアーカイブを作成します。 

    $ tar -cvzf cello-1.0.tar.gz cello-1.0
cello-1.0/
cello-1.0/Makefile
cello-1.0/cello.c
cello-1.0/LICENSE
    Copy to Clipboard Toggle word wrap

  3. 作成したアーカイブを ~/rpmbuild/SOURCES/ ディレクトリーに移動します。これは、rpmbuild コマンドがパッケージをビルドするためのファイルを保存するデフォルトのディレクトリーです。 

    $ mv cello-1.0.tar.gz ~/rpmbuild/SOURCES/
    Copy to Clipboard Toggle word wrap

第4章 ソフトウェアのパッケージ化
リンクのコピー

次のセクションでは、RPM パッケージマネージャーを使用したパッケージ化プロセスの基本を説明します。

4.1. RPM パッケージ化ワークスペースのセットアップ
リンクのコピー

RPM パッケージをビルドするには、まず、特別なワークスペースを作成する必要があります。このワークスペースは、さまざまなパッケージ化のために使用するディレクトリーで構成されています。

4.1.1. RPM パッケージ化ワークスペースの設定
リンクのコピー

RPM パッケージ化ワークスペースを設定するには、rpmdev-setuptree ユーティリティーを使用してディレクトリーレイアウトを設定できます。

前提条件

  • RPM をパッケージ化するためのユーティリティーを提供する rpmdevtools パッケージをインストールした。 

    # yum install rpmdevtools
    Copy to Clipboard Toggle word wrap

手順

  • rpmdev-setuptree ユーティリティーを実行します。 

    $ rpmdev-setuptree

$ tree ~/rpmbuild/
/home/user/rpmbuild/
|-- BUILD
|-- RPMS
|-- SOURCES
|-- SPECS
`-- SRPMS

5 directories, 0 files
    Copy to Clipboard Toggle word wrap

4.1.2. RPM パッケージ化ワークスペースディレクトリー
リンクのコピー

以下は、rpmdev-setuptree ユーティリティーで作成される RPM パッケージ化ワークスペースディレクトリーです。

Expand
表4.1 RPM パッケージ化ワークスペースディレクトリー
ディレクトリー目的

BUILD

SOURCES ディレクトリーのソースファイルからコンパイルされたビルドアーティファクトが格納されます。

RPMS

バイナリー RPM は、さまざまなアーキテクチャー用のサブディレクトリーの RPMS ディレクトリー配下に作成されます。たとえば、x86_64 や noarch サブディレクトリーです。

SOURCES

圧縮されたソースコードのアーカイブとパッチが格納されます。rpmbuild コマンドによって、このディレクトリー内のアーカイブとパッチが検索されます。

SPECS

パッケージャーによって作成された spec ファイルが格納されます。このファイルはパッケージのビルドに使用されます。

SRPMS

rpmbuild コマンドを使用してバイナリー RPM ではなく SRPM をビルドすると、結果の SRPM がこのディレクトリー配下に作成されます。

4.2. spec ファイルについて
リンクのコピー

spec ファイルは、rpmbuild ユーティリティーが RPM パッケージをビルドするために使用する指示が記述されたファイルです。このファイルは、一連のセクションで指示を定義することにより、ビルドシステムに必要な情報を提供します。これらのセクションは、spec ファイルの Preamble 部分と Body 部分で定義されます。

  • Preamble セクションには、Body セクションで使用される一連のメタデータ項目が含まれています。
  • Body セクションは、指示の主要部分を表します。

4.2.1. Preamble 項目
リンクのコピー

以下は、RPM spec ファイルの Preamble セクションで使用できるディレクティブの一部です。

Expand
表4.2 Preamble セクションのディレクティブ
ディレクティブ定義

Name

パッケージのベース名。spec ファイル名と一致する必要があります。

Version

ソフトウェアのアップストリームのバージョン番号。

Release

パッケージのバージョンがリリースされた回数。

初期値を 1%{?dist} に設定し、パッケージの新しいリリースごとに値を増やします。新しい Version のソフトウェアをビルドするときに 1 にリセットします。

Summary

パッケージの簡単な一行の概要。

License

パッケージ化するソフトウェアのライセンス。

spec ファイルで License にラベルを付ける方法は、GPLv3+ など、準拠する RPM ベースの Linux ディストリビューションのガイドラインによって異なります。

URL

ソフトウェアの詳細情報の完全な URL (パッケージ化するソフトウェアのアップストリームプロジェクトの Web サイトなど)。

Source

パッチが適用されていないアップストリームソースコードの圧縮アーカイブへのパスまたは URL。このリンクの参照先は、パッケージャーのローカルストレージではなく、アクセスしやすく信頼性の高いアーカイブ保存場所 (アップストリームのページなど) である必要があります。

たとえば、ソースコードとデータアーカイブが別々に公開されているソフトウェアの場合は、複数の Source ディレクティブを定義できます。Source ディレクティブは、ディレクティブ名の末尾に数字を付けても付けなくても適用できます。番号が指定されていない場合は、エントリーに内部的に番号が割り当てられます。Source0、Source1、Source2、Source3 などのように、番号を明示的に指定することもできます。

Patch

必要に応じて、ソースコードに適用する最初のパッチの名前。

Patch ディレクティブは、ディレクティブ名の末尾に数字を付けても付けなくても適用できます。番号が指定されていない場合は、エントリーに内部的に番号が割り当てられます。Patch0、Patch1、Patch2、Patch3 などのように、番号を明示的に指定することもできます。

%patch0、%patch1、%patch2 マクロなどを使用して、パッチを個別に適用できます。マクロは、RPM spec ファイルの Body セクションの %prep ディレクティブ内で適用します。または、%autopatch マクロを使用できます。このマクロは、spec ファイルに指定されている順序ですべてのパッチを自動的に適用します。

BuildArch

ソフトウェアのビルド対象アーキテクチャー。

ソフトウェアがアーキテクチャーに依存しない場合、たとえば、ソフトウェア全体をインタープリター型プログラミング言語で記述した場合は、値を BuildArch: noarch に設定します。この値を設定しないと、x86_64 など、ビルド対象のマシンのアーキテクチャーをソフトウェアが自動的に継承します。

BuildRequires

コンパイル言語で記述されたプログラムをビルドするために必要なパッケージのコンマまたは空白区切りのリスト。複数の BuildRequires のエントリーを SPEC ファイル内の別の行にそれぞれ含めることができます。

Requires

インストール後のソフトウェアの実行に必要なパッケージのコンマ区切りまたは空白区切りのリスト。複数の Requires のエントリーを spec ファイル内の別の行にそれぞれ含めることができます。

ExcludeArch

ソフトウェアが特定のプロセッサーアーキテクチャーで動作しない場合は、ExcludeArch ディレクティブでそのアーキテクチャーを除外できます。

Conflicts

ソフトウェアをインストールしたときに正常に機能させるために、システムにインストールしてはならないパッケージのコンマまたは空白区切りのリスト。複数の Conflicts のエントリーを spec ファイル内の別の行にそれぞれ含めることができます。

Obsoletes

Obsoletes ディレクティブを指定すると、次の要因に応じて更新の動作が変わります。

  • rpm コマンドをコマンドラインで直接使用した場合、インストールされているパッケージの古いバージョンに一致するすべてのパッケージが削除されるか、更新または依存関係ソルバーによって更新が実行されます。
  • 更新または依存関係リゾルバー (DNF) を使用した場合、一致する Obsoletes: を含んでいるパッケージが更新対象として追加され、一致するパッケージが置き換えられます。

Provides

パッケージに Provides ディレクティブを追加すると、そのパッケージが名前以外の依存関係によって参照できるようになります。

Name、Version、および Release (NVR) ディレクティブは、name-version-release という形式の RPM パッケージのファイル名で構成されます。

rpm コマンドを使用して RPM データベースをクエリーすることにより、特定のパッケージの NVR 情報を表示できます。次に例を示します。 

# rpm -q bash
bash-4.4.19-7.el8.x86_64
Copy to Clipboard Toggle word wrap

ここでは、bash がパッケージ名で、4.4.19 がバージョン番号を示し、7.el8 がリリースを意味しています。x86_64 は、パッケージアーキテクチャーを示すマーカーです。アーキテクチャーマーカーは、NVR とは異なり、RPM パッケージャーが直接制御するものではなく、rpmbuild ビルド環境によって定義されます。アーキテクチャーに依存しない noarch パッケージは例外です。

4.2.2. Body 項目
リンクのコピー

以下は、RPM spec ファイルの Body セクションで使用される項目です。

Expand
表4.3 Body セクションの項目
ディレクティブ定義

%description

RPM でパッケージ化されているソフトウェアの完全な説明。この説明は、複数の行や、複数の段落にまでわたることがあります。

%prep

ソフトウェアのビルドを準備するための 1 つまたは一連のコマンド。たとえば、Source ディレクティブでのアーカイブの展開などです。%prep ディレクティブにはシェルスクリプトを含めることができます。

%build

ソフトウェアをマシンコード (コンパイル言語の場合) またはバイトコード (一部のインタープリター言語の場合) にビルドするための 1 つまたは一連のコマンド。

%install

ソフトウェアのビルド後に、rpmbuild ユーティリティーがソフトウェアを BUILDROOT ディレクトリーにインストールする際に使用する 1 つまたは一連のコマンド。これらのコマンドにより、ビルドが行われる %_builddir ディレクトリーから、パッケージ化されるファイルとディレクトリー構造を含む %buildroot ディレクトリーに、必要なビルドアーティファクトがコピーされます。これには、~/rpmbuild/BUILD から ~/rpmbuild/BUILDROOT へのファイルのコピーと、~/rpmbuild/BUILDROOT での必要なディレクトリーの作成が含まれます。

%install ディレクトリーは、エンドユーザーの root ディレクトリーに似た空の chroot ベースディレクトリーです。ここに、インストールされるファイルを格納する任意のディレクトリーを作成できます。このようなディレクトリーを作成するには、パスをハードコードせずに RPM マクロを使用できます。

%install は、パッケージのインストール時ではなく、パッケージの作成時にのみ実行されることに注意してください。詳細は、spec ファイルでの作業 を参照してください。

%check

ソフトウェアをテストするための 1 つまたは一連のコマンド (ユニットテストなど)。

%files

RPM パッケージによって提供され、ユーザーのシステムにインストールされるファイルのリストと、システム上におけるファイル配置場所のフルパスのリスト。

ビルド中に、%buildroot ディレクトリーに %files にリストされていないファイルがある場合、パッケージ化されていないファイルが存在する可能性があるという警告が表示されます。

%files セクション内には、組み込みマクロを使用してさまざまなファイルの役割を指定できます。これは、rpm コマンドを使用してパッケージファイルのマニフェストメタデータをクエリーする場合に便利です。たとえば、LICENSE ファイルがソフトウェアライセンスファイルであることを示すには、%license マクロを使用します。

%changelog

異なる Version または Release ビルドの間でパッケージに行われた変更の記録。この変更には、パッケージの各 Version-Release の日付入りエントリーのリストを含めます。これらのエントリーには、ソフトウェアの変更ではなく、パッチの追加や %build セクションでのビルド手順の変更など、パッケージの変更を記録します。

4.2.3. 高度な項目
リンクのコピー

spec ファイルには、Scriptlets や Triggers などの高度な項目を含めることができます。

Scriptlets と Triggers は、ビルドプロセスではなく、エンドユーザーのシステムにおけるインストールプロセス中のさまざまな時点で有効になります。

4.3. BuildRoots
リンクのコピー

RPM のパッケージ化のコンテキストでは、buildroot が chroot 環境となります。ビルドアーティファクトは、エンドユーザーシステムの将来の階層と同じファイルシステム階層を使用してここに配置され、buildroot はルートディレクトリーとして機能します。ビルドアーティファクトの配置は、エンドユーザーシステムのファイルシステム階層の標準に準拠する必要があります。

buildroot のファイルは、後で cpio アーカイブに置かれ、RPM の主要部分になります。RPM がエンドユーザーのシステムにインストールされている場合、これらのファイルは root ディレクトリーに抽出され、階層が正しく保持されます。

注記

rpmbuild プログラムには独自のデフォルト設定があります。このデフォルト設定をオーバーライドすると、特定の問題が発生する可能性があります。したがって、buildroot マクロの独自の値を定義することは避けてください。代わりにデフォルトの %{buildroot} マクロを使用してください。

4.4. RPM マクロ
リンクのコピー

rpm マクロ は、特定の組み込み機能が使用されている場合に、ステートメントのオプションの評価に基づいて、条件付きで割り当てられる直接的なテキスト置換です。したがって、RPM は、ユーザーに変わってテキストの置換を行うことができます。

たとえば、パッケージ化するソフトウェアの Version を %{version} マクロで 1 回だけ定義し、このマクロを spec ファイル全体で使用することができます。該当するすべてのテキストが、マクロで定義した Version に自動的に置き換えられます。

注記

見たことのないマクロが表示されている場合は、次のコマンドを使用してマクロを評価できます。 

$ rpm --eval %{MACRO}
Copy to Clipboard Toggle word wrap

たとえば、%{_bindir} マクロと %{_libexecdir} マクロを評価するには、次のように入力します。 

$ rpm --eval %{_bindir}
/usr/bin

$ rpm --eval %{_libexecdir}
/usr/libexec
Copy to Clipboard Toggle word wrap

4.5. spec ファイルでの作業
リンクのコピー

新しいソフトウェアをパッケージ化するには、spec ファイルを作成する必要があります。spec ファイルは次のいずれかの方法で作成できます。

  • 新しい spec ファイルを最初から手動で作成します。
  • rpmdev-newspec ユーティリティーを使用します。このユーティリティーは、空の spec ファイルを作成します。このファイルに必要なディレクティブとフィールドを入力します。
注記

プログラマー向けのテキストエディターの中には、新しい spec ファイルに独自の spec テンプレートを事前に入力するものもあります。rpmdev-newspec ユーティリティーでは、エディターに依存しないアプローチを利用できます。

4.5.1. サンプルの Bash、Python、および C プログラム用の新しい spec ファイルを作成する
リンクのコピー

rpmdev-newspec ユーティリティーを使用して、Hello World! プログラムの 3 つの実装それぞれに spec ファイルを作成できます。

前提条件

手順

  1. ~/rpmbuild/SPECS ディレクトリーに移動します。 

    $ cd ~/rpmbuild/SPECS
    Copy to Clipboard Toggle word wrap

  2. Hello World! プログラムの 3 つの実装それぞれに spec ファイルを作成します。 

    $ rpmdev-newspec bello
bello.spec created; type minimal, rpm version >= 4.11.

$ rpmdev-newspec cello
cello.spec created; type minimal, rpm version >= 4.11.

$ rpmdev-newspec python-pello
python-pello.spec created; type minimal, rpm version >= 4.11.
    Copy to Clipboard Toggle word wrap
    重要

    Python プロジェクトを RPM にパッケージ化するときは、常に python- 接頭辞をプロジェクトの元の名前に追加してください。ここではプロジェクト名が Pello であるため、spec の名前は python-pello になります。

    ~/rpmbuild/SPECS/ ディレクトリーに、bello.spec、cello.spec、python-pello.spec という 3 つの spec ファイルが含まれた状態になります。

  3. 作成されたファイルを調べます。

    ファイル内のディレクティブは、spec ファイルについて で説明されているものです。次のセクションでは、rpmdev -newspec の出力ファイルの特定のセクションを作成します。

4.5.2. 元の spec ファイルの変更
リンクのコピー

rpmdev-newspec ユーティリティーによって生成される元の出力 spec ファイルは、テンプレートです。このテンプレートを変更して、rpmbuild ユーティリティーに必要な指示を提供する必要があります。rpmbuild は、その指示を使用して RPM パッケージをビルドします。

前提条件

手順

  1. rpmdev-newspec ユーティリティーによって提供される ~/rpmbuild/SPECS/<name>.spec ファイルを開きます。

  2. spec ファイルの Preamble セクションに次のディレクティブを入力します。

    Name
    Name は、すでに rpmdev-newspec の引数として指定されています。
    Version
    Version は、ソースコードのアップストリームのリリースバージョンと一致するように設定します。
    Release
    Release は、1%{?dist} に自動的に設定されます。最初は 1 となります。
    Summary
    パッケージの説明を 1 行で入力します。
    License
    ソースコードに関連付けるソフトウェアライセンスを入力します。
    URL
    アップストリームのソフトウェア Web サイトの URL を入力します。一貫性を保つために、%{name} RPM マクロ変数を利用し、https://example.com/%{name} 形式を使用します。
    Source

    アップストリームのソフトウェアソースコードへの URL を入力します。パッケージ化するソフトウェアバージョンに直接リンクします。

    注記

    このドキュメントのサンプル URL には、ハードコードされた値が含まれています。この値は将来変更される可能性があります。同様に、リリースのバージョンも変更される可能性があります。今後の変更を簡素化するには、%{name} マクロと %{version} マクロを使用します。これらのマクロを使用すると、更新する必要がある箇所が、spec ファイル内の 1 つのフィールドだけになります。

    BuildRequires
    パッケージのビルド時の依存関係を指定します。
    Requires
    パッケージの実行時の依存関係を指定します。
    BuildArch
    ソフトウェアアーキテクチャーを指定します。

  3. spec ファイルの Body セクションに次のディレクティブを入力します。これらのディレクティブは、実行する複数行、複数指示のタスクやスクリプト処理タスクを定義できるため、セクションの見出しと考えることができます。

    %description
    ソフトウェアの詳細な説明を入力します。
    %prep
    ソフトウェアのビルドを準備するための 1 つまたは一連のコマンドを入力します。
    %build
    ソフトウェアをビルドするための 1 つまたは一連のコマンドを入力します。
    %install
    ソフトウェアを BUILDROOT ディレクトリーにインストールする方法を rpmbuild コマンドに指示する 1 つまたは一連のコマンドを入力します。
    %files
    システムにインストールする、RPM パッケージによって提供されるファイルのリストを指定します。
    %changelog

    パッケージの各 Version-Release の日付入りエントリーのリストを入力します。

    %changelog セクションの最初の行は、アスタリスク (*) 文字で始め、その後に Day-of-Week Month Day Year Name Surname <email> - Version-Release を入力します。

    実際の変更エントリーについては、次のルールに従ってください。

    • 各変更エントリーには、変更ごとに複数の項目を含めることができます。
    • 各項目は新しい行で始まります。
    • 各項目の先頭にハイフン (-) 文字を付けます。

これで、必要なプログラムの完全な spec ファイルが作成されました。

4.5.3. サンプル Bash プログラムの spec ファイルの例
リンクのコピー

以下に示す、bash で書かれた bello プログラムの spec ファイルの例を参考として使用できます。

bash で書かれたプログラムの spec ファイルの例

Name:           bello
Version:        0.1
Release:        1%{?dist}
Summary:        Hello World example implemented in bash script

License:        GPLv3+
URL:            https://www.example.com/%{name}
Source0:        https://www.example.com/%{name}/releases/%{name}-%{version}.tar.gz

Requires:       bash

BuildArch:      noarch

%description
The long-tail description for our Hello World Example implemented in
bash script.

%prep
%autosetup

%build

%install

mkdir -p %{buildroot}/%{_bindir}

install -m 0755 %{name} %{buildroot}/%{_bindir}/%{name}

%files
%license LICENSE
%{_bindir}/%{name}

%changelog
* Tue May 31 2016 Adam Miller <maxamillion@fedoraproject.org> - 0.1-1
- First bello package
- Example second item in the changelog for version-release 0.1-1
Copy to Clipboard Toggle word wrap

  • bello のビルドステップがないため、パッケージのビルドタイム依存関係を指定する BuildRequires ディレクティブが削除されました。bash は、raw インタープリタープログラミング言語で、ファイルはシステム上のその場所にインストールされます。
  • パッケージの実行時の依存関係を指定する Requires ディレクティブには、bash のみが含まれています。これは、bello スクリプトの実行には bash シェル環境のみが必要であるためです。
  • %autosetup マクロは、Source0 ディレクティブによって参照されるソースアーカイブを展開し、それを変更します。
  • ソフトウェアのビルド方法を指定する %build セクションは空白です。これは bash スクリプトはビルドする必要がないためです。
注記

bello をインストールするには、インストール先ディレクトリーを作成し、そこに実行可能な bash スクリプトファイルをインストールする必要があります。したがって、%install セクションで install コマンドを使用できます。RPM マクロを使用すると、パスをハードコーディングせずにこれを行うことができます。

4.5.4. サンプル Python プログラムの spec ファイルの例
リンクのコピー

以下に示す、Python プログラミング言語で書かれた pello プログラムの spec ファイルの例を参考として使用できます。

Python で書かれた pello プログラムの spec ファイルの例

Name:           pello
Version:        0.1.1
Release:        1%{?dist}
Summary:        Hello World example implemented in Python

License:        GPLv3+
URL:            https://www.example.com/%{name}
Source0:        https://www.example.com/%{name}/releases/%{name}-%{version}.tar.gz

BuildRequires:  python
Requires:       python
Requires:       bash

BuildArch:      noarch

%description
The long-tail description for our Hello World Example implemented in Python.

%prep
%setup -q

%build

python -m compileall %{name}.py

%install

mkdir -p %{buildroot}/%{_bindir}
mkdir -p %{buildroot}/usr/lib/%{name}

cat > %{buildroot}/%{_bindir}/%{name} <<EOF
#!/bin/bash
/usr/bin/python /usr/lib/%{name}/%{name}.pyc
EOF

chmod 0755 %{buildroot}/%{_bindir}/%{name}

install -m 0644 %{name}.py* %{buildroot}/usr/lib/%{name}/

%files
%license LICENSE
%dir /usr/lib/%{name}/
%{_bindir}/%{name}
/usr/lib/%{name}/%{name}.py*

%changelog
* Tue May 31 2016 Adam Miller <maxamillion@fedoraproject.org> - 0.1.1-1
  - First pello package
Copy to Clipboard Toggle word wrap

  • Requires ディレクティブ (パッケージにランタイム依存関係を指定) には、以下の 2 つのパッケージが含まれます。

    • 実行時にバイトコンパイルされたコードを実行するために必要な python パッケージ。
    • 小さなエントリーポイントスクリプトを実行するために必要な bash パッケージ。
  • BuildRequires ディレクティブは、パッケージのビルド時の依存関係を指定し、python パッケージのみを含みます。pello プログラムでは、バイトコンパイルビルドプロセスを実行するために python が必要です。
  • ソフトウェアのビルド方法を指定する %build セクションでは、スクリプトのバイトコンパイルバージョンを作成します。実際のパッケージングでは、使用されるディストリビューションに応じて、通常は自動的に実行されることに注意してください。
  • %install セクションは、バイトコンパイルされたファイルをシステム上のライブラリーディレクトリーにインストールしてアクセスできるようにする必要があるという事実に一致しています。

spec ファイル内にインラインでラッパースクリプトを作成するこの例は、spec ファイル自体がスクリプト可能であることを示しています。このラッパースクリプトは、here document を使用して Python バイトコンパイルコードを実行します。

4.5.5. サンプル C プログラムの spec ファイルの例
リンクのコピー

以下に示す、C プログラミング言語で書かれた cello プログラムの spec ファイルの例を参考として使用できます。

C 言語で書かれたプログラムの spec ファイルの例

Name:           cello
Version:        1.0
Release:        1%{?dist}
Summary:        Hello World example implemented in C

License:        GPLv3+
URL:            https://www.example.com/%{name}
Source0:        https://www.example.com/%{name}/releases/%{name}-%{version}.tar.gz

Patch0:         cello.patch

BuildRequires:  gcc
BuildRequires:  make

%description
The long-tail description for our Hello World Example implemented in
C.

%prep
%autosetup

%patch0

%build
make %{?_smp_mflags}

%install
%make_install

%files
%license LICENSE
%{_bindir}/%{name}

%changelog
* Tue May 31 2016 Adam Miller <maxamillion@fedoraproject.org> - 1.0-1
- First cello package
Copy to Clipboard Toggle word wrap

  • パッケージのビルド時の依存関係を指定する BuildRequires ディレクティブには、コンパイルビルドプロセスを実行するために必要な次のパッケージが含まれています。

    • gcc
    • make
  • この例では、パッケージにランタイム依存関係を指定する Requires ディレクティブは省略されています。すべてのランタイム要件は rpmbuild により処理されます。cello プログラムはコア C 標準ライブラリー以外のものは必要としません。
  • %autosetup マクロは、Source0 ディレクティブによって参照されるソースアーカイブを展開し、それを変更します。
  • %build セクションは、この例で cello プログラム用の Makefile ファイルを作成したことを反映しています。したがって、GNU make コマンドを使用できます。ただし、設定スクリプトを指定していないため、%configure への呼び出しを削除する必要があります。

cello プログラムは、%make_install マクロを使用してインストールできます。これが可能なのは、cello プログラムの Makefile を利用できるためです。

4.6. RPM のビルド
リンクのコピー

rpmbuild コマンドを使用して RPM パッケージをビルドできます。このコマンドを使用する場合、rpmdev-setuptree ユーティリティーによって設定された構造と同じ特定のディレクトリーおよびファイル構造が求められます。

rpmbuild コマンドでは、ユースケースや期待する結果によって組み合わせる引数が異なります。主な使用例は次のとおりです。

  • ソース RPM をビルドします。

  • バイナリー RPM をビルドします。

    • ソース RPM からバイナリー RPM を再ビルドします。
    • spec ファイルからバイナリー RPM をビルドします。

4.6.1. ソース RPM のビルド
リンクのコピー

ソース RPM (SRPM) をビルドすると、次の利点があります。

  • 環境にデプロイされた特定の Name-Version-Release を持つ RPM ファイルの正確なソースを保持できます。これには、正確な spec ファイル、ソースコード、および関連するすべてのパッチが含まれます。これは追跡とデバッグに役立ちます。
  • 異なるハードウェアプラットフォームまたはアーキテクチャー上でバイナリー RPM をビルドできます。

前提条件

  • システムに rpmbuild ユーティリティーがインストールされている。 

    # yum install rpm-build
    Copy to Clipboard Toggle word wrap

  • 次の Hello World! 実装が ~/rpmbuild/SOURCES/ ディレクトリーに配置されている。

  • パッケージ化するプログラムの spec ファイルが存在する。

手順

  1. 作成した spec ファイルが含まれている ~/rpmbuild/SPECS/ ディレクトリーに移動します。 

    $ cd ~/rpmbuild/SPECS/
    Copy to Clipboard Toggle word wrap

  2. rpmbuild コマンドを入力し、spec ファイルを指定して、ソース RPM をビルドします。 

    $ rpmbuild -bs <specfile>
    Copy to Clipboard Toggle word wrap

    -bs オプションは ソースのビルド を表します。

    たとえば、bello、pello、cello プログラムのソース RPM をビルドするには、次のように入力します。 

    $ rpmbuild -bs bello.spec
Wrote: /home/admiller/rpmbuild/SRPMS/bello-0.1-1.el8.src.rpm

$ rpmbuild -bs python-pello.spec
Wrote: /home/admiller/rpmbuild/SRPMS/python-pello-1.0.2-1.el8.src.rpm

$ rpmbuild -bs cello.spec
Wrote: /home/admiller/rpmbuild/SRPMS/cello-1.0-1.el8.src.rpm
    Copy to Clipboard Toggle word wrap

検証

  • rpmbuild/SRPMS ディレクトリーに、生成されたソース RPM が含まれていることを確認します。ディレクトリーは、rpmbuild で必要な構造の一部です。

4.6.2. ソース RPM からのバイナリー RPM の再ビルド
リンクのコピー

ソース RPM (SRPM) からバイナリー RPM を再ビルドするには、--rebuild オプションを指定した rpmbuild コマンドを使用します。

バイナリー RPM の作成時に生成される出力は詳細なもので、デバッグに役立ちます。出力は例によって異なり、それぞれの spec ファイルに対応したものになります。

生成されるバイナリー RPM は、~/rpmbuild/RPMS/YOURARCH ディレクトリー (YOURARCH はアーキテクチャー) に配置されます。パッケージがアーキテクチャー固有でない場合は ~/rpmbuild/RPMS/noarch/ ディレクトリーに配置されます。

前提条件

  • システムに rpmbuild ユーティリティーがインストールされている。 

    # yum install rpm-build
    Copy to Clipboard Toggle word wrap

手順

  1. ソース RPM が含まれている ~/rpmbuild/SRPMS/ ディレクトリーに移動します。 

    $ cd ~/rpmbuild/SRPMS/
    Copy to Clipboard Toggle word wrap

  2. ソース RPM からバイナリー RPM を再ビルドします。 

    $ rpmbuild --rebuild <srpm>
    Copy to Clipboard Toggle word wrap

    たとえば、bello、pello、cello を SRPM から再ビルドするには、次のように入力します。 

    $ rpmbuild --rebuild bello-0.1-1.el8.src.rpm
[output truncated]

$ rpmbuild --rebuild python-pello-1.0.2-1.el8.src.rpm
[output truncated]

$ rpmbuild --rebuild cello-1.0-1.el8.src.rpm
[output truncated]
    Copy to Clipboard Toggle word wrap
注記

rpmbuild --rebuild を呼び出すと、次のプロセスが実行されます。

  • SRPM の内容 (spec ファイルとソースコード) を ~/rpmbuild/ ディレクトリーにインストールします。
  • インストールされたコンテンツを使用して RPM をビルドします。
  • spec ファイルとソースコードを削除します。

次のいずれかの方法でビルドすると、spec ファイルとソースコードを保持できます。

  • RPM をビルドするときに、--rebuild オプションではなく --recompile オプションを指定した rpmbuild コマンドを使用します。

  • bello、python-pello、cello の SRPM をインストールします。 

    $ rpm -Uvh ~/rpmbuild/SRPMS/bello-0.1-1.el8.src.rpm
Updating / installing…​
   1:bello-0.1-1.el8               [100%]

$ rpm -Uvh ~/rpmbuild/SRPMS/python-pello-1.0.2-1.el8.src.rpm
Updating / installing…​
…​1:python-pello-1.0.2-1.el8              [100%]

$ rpm -Uvh ~/rpmbuild/SRPMS/cello-1.0-1.el8.src.rpm
Updating / installing…​
…​1:cello-1.0-1.el8            [100%]
    Copy to Clipboard Toggle word wrap

4.6.3. spec ファイルからのバイナリー RPM のビルド
リンクのコピー

spec ファイルからバイナリー RPM をビルドするには、-bb オプションを指定した rpmbuild コマンドを使用します。-bb オプションは バイナリーのビルド を表します。

前提条件

  • システムに rpmbuild ユーティリティーがインストールされている。 

    # yum install rpm-build
    Copy to Clipboard Toggle word wrap

手順

  1. spec ファイルが含まれている ~/rpmbuild/SPECS/ ディレクトリーに移動します。 

    $ cd ~/rpmbuild/SPECS/
    Copy to Clipboard Toggle word wrap

  2. spec からバイナリー RPM をビルドします。 

    $ rpmbuild -bb <spec_file>
    Copy to Clipboard Toggle word wrap

    たとえば、spec ファイルから bello、pello、cello バイナリー RPM をビルドするには、次のように入力します。 

    $ rpmbuild -bb bello.spec

$ rpmbuild -bb python-pello.spec

$ rpmbuild -bb cello.spec
    Copy to Clipboard Toggle word wrap

4.7. RPM の一般的なエラーのチェック
リンクのコピー

パッケージを作成したら、パッケージの品質を確認することを推奨します。パッケージの品質をチェックするための主なツールは rpmlint です。

rpmlint ツールを使用すると、次のアクションを実行できます。

  • RPM の保守性を向上する。
  • RPM の静的分析を実行してコンテンツの検証を可能にする。
  • RPM の静的分析を実行してエラーチェックを可能にする。

rpmlint では、バイナリー RPM、ソース RPM (SRPM)、および spec ファイルをチェックできます。したがって、このツールはパッケージ化のすべての段階で役立ちます。

rpmlint のガイドラインは厳密なものです。したがって、次のセクションに示すように、一部のエラーと警告をスキップすることが許容される場合もあります。

注記

以下のセクションで説明する例では、rpmlint にオプションを指定せずに実行しており、詳細な出力が得られません。各エラーまたは警告の詳細な説明は、代わりに rpmlint -i を実行してください。

4.7.1. サンプル Bash プログラムで一般的なエラーをチェックする
リンクのコピー

次のセクションでは、bello spec ファイル、bello SRPM、bello バイナリー RPM の例を使用して、RPM の一般的なエラーをチェックするときに発生する可能性のある警告とエラーを調査します。

4.7.1.1. bello spec ファイルで一般的なエラーをチェックする
リンクのコピー

次の例の出力を調べて、bello spec ファイルで一般的なエラーをチェックする方法を確認してください。

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.
Copy to Clipboard Toggle word wrap

bello.spec の場合、invalid-url Source0 という警告が 1 つだけ出力されます。この警告は、Source0 ディレクティブにリストされている URL にアクセスできないことを意味します。example.com URL は存在しないため、この出力は当然です。この URL が今後有効になると仮定して、この警告を無視します。

4.7.1.2. bello SRPM の一般的なエラーをチェックする
リンクのコピー

次の例の出力を調べて、bello ソース RPM (SRPM) で一般的なエラーをチェックする方法を確認してください。

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.
Copy to Clipboard Toggle word wrap

bello SRPM の場合、invalid-url URL 警告が出力されます。これは、URL ディレクティブで指定された URL にアクセスできないことを意味します。この URL が今後有効になると仮定して、この警告を無視します。

4.7.1.3. bello バイナリー RPM で一般的なエラーをチェックする
リンクのコピー

バイナリー RPM をチェックする場合、rpmlint コマンドは次の項目をチェックします。

  • ドキュメント
  • man ページ
  • ファイルシステム階層規格の一貫した使用

次の例の出力を調べて、bello バイナリー RPM で一般的なエラーをチェックする方法を確認してください。

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.
Copy to Clipboard Toggle word wrap

no-documentation および no-manual-page-for-binary という警告は、ユーザーがドキュメントや man ページを提供しなかったため、RPM にドキュメントや man ページがないことを意味します。出力の警告を別にすれば、RPM は rpmlint チェックに合格しています。

4.7.2. サンプル Python プログラムで一般的なエラーをチェックする
リンクのコピー

次のセクションでは、pello spec ファイル、pello SRPM、pello バイナリー RPM の例を使用して、RPM の一般的なエラーをチェックするときに発生する可能性のある警告とエラーを調査します。

4.7.2.1. pello spec ファイルで一般的なエラーをチェックする
リンクのコピー

次の例の出力を調べて、pello spec ファイルで一般的なエラーをチェックする方法を確認してください。

pello spec ファイルで rpmlint コマンドを実行した場合の出力

$ rpmlint python-pello.spec
0 packages and 1 specfiles checked; 0 errors, 0 warnings.
Copy to Clipboard Toggle word wrap

python-pello spec ファイルの場合、rpmlint ユーティリティーはエラーや警告をまったく検出しませんでした。これは、ファイルが正しく作成されたことを意味します。

重要

実稼働環境で使用するパッケージの場合は、spec ファイルでエラーや警告がないか適切に確認してください。

4.7.2.2. pello SRPM の一般的なエラーをチェックする
リンクのコピー

次の例の出力を調べて、pello ソース RPM (SRPM) で一般的なエラーをチェックする方法を確認してください。

pello の SRPM で rpmlint コマンドを実行した場合の出力

$ rpmlint ~/rpmbuild/SRPMS/pello-0.1.2-1.el8.src.rpm
python-pello.src: E: description-line-too-long C Pello is an example package with an executable that prints Hello World! on the command line.
1 packages and 0 specfiles checked; 1 errors, 0 warnings.
Copy to Clipboard Toggle word wrap

description-line-too-long というエラーは、指定した説明が許容文字数を超えていることを意味します。

出力エラーを除けば、SRPM は rpmlint チェックに合格しています。

4.7.2.3. pello バイナリー RPM で一般的なエラーをチェックする
リンクのコピー

バイナリー RPM をチェックする場合、rpmlint コマンドは次の項目をチェックします。

  • ドキュメント
  • man ページ
  • ファイルシステム階層規格の一貫した使用

次の例の出力を調べて、pello バイナリー RPM で一般的なエラーをチェックする方法を確認してください。

pello バイナリー RPM で rpmlint コマンドを実行した場合の出力

$ ~/rpmbuild/RPMS/noarch/python3.12-pello-1.0.2-1.el8.noarch.rpm
pello-1.0.2-1.el8.noarch.rpm
python3.12-pello.noarch: E: description-line-too-long C Pello is an example package with an executable that prints Hello World! on the command line.
python3.12-pello.noarch: W: no-manual-page-for-binary pello_greeting
1 packages and 0 specfiles checked; 2 errors, 1 warnings.
Copy to Clipboard Toggle word wrap

  • no-manual-page-for-binary という警告は、man ページが指定されなかったため、RPM に man ページがないことを意味します。
  • description-line-too-long というエラーは、指定した説明が許容文字数を超えていることを意味します。

出力の警告とエラーを別にすれば、RPM は rpmlint チェックに合格しています。

4.7.3. サンプル C プログラムで一般的なエラーをチェックする
リンクのコピー

次のセクションでは、cello spec ファイル、cello SRPM、cello バイナリー RPM の例を使用して、RPM の一般的なエラーをチェックするときに発生する可能性のある警告とエラーを調査します。

4.7.3.1. cello spec ファイルで一般的なエラーをチェックする
リンクのコピー

次の例の出力を調べて、cello spec ファイルで一般的なエラーをチェックする方法を確認してください。

cello spec ファイルで rpmlint コマンドを実行した場合の出力

$ rpmlint ~/rpmbuild/SPECS/cello.spec
/home/admiller/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.
Copy to Clipboard Toggle word wrap

cello.spec の場合、invalid-url Source0 という警告が 1 つだけ出力されます。この警告は、Source0 ディレクティブにリストされている URL にアクセスできないことを意味します。example.com URL は存在しないため、この出力は当然です。この URL が今後有効になると仮定して、この警告を無視します。

4.7.3.2. cello SRPM の一般的なエラーをチェックする
リンクのコピー

次の例の出力を調べて、cello ソース RPM (SRPM) で一般的なエラーをチェックする方法を確認してください。

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.
Copy to Clipboard Toggle word wrap

cello SRPM については、invalid-url URL という警告があります。この警告は、URL ディレクティブで指定された URL に到達できないことを意味します。この URL が今後有効になると仮定して、この警告を無視します。

4.7.3.3. cello バイナリー RPM で一般的なエラーをチェックする
リンクのコピー

バイナリー RPM をチェックする場合、rpmlint コマンドは次の項目をチェックします。

  • ドキュメント
  • man ページ
  • ファイルシステム階層規格の一貫した使用

次の例の出力を調べて、cello バイナリー RPM で一般的なエラーをチェックする方法を確認してください。

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.
Copy to Clipboard Toggle word wrap

no-documentation および no-manual-page-for-binary という警告は、ドキュメントや man ページが指定されていないため、RPM にドキュメントや man ページがないことを意味します。

出力の警告を別にすれば、RPM は rpmlint チェックに合格しています。

4.8. RPM アクティビティーの syslog へのロギング
リンクのコピー

System Logging プロトコル (syslog) を使用して、あらゆる RPM アクティビティーまたはトランザクションをログに記録できます。

前提条件

  • syslog プラグインがシステムにインストールされている。 

    # yum install rpm-plugin-syslog
    Copy to Clipboard Toggle word wrap
    注記

    syslog メッセージのデフォルトの場所は、/var/log/messages ファイルです。ただし、メッセージを別の場所に保存するように syslog を設定することもできます。

手順

  1. syslog メッセージを保存するように設定したファイルを開きます。

    または、デフォルトの syslog 設定を使用する場合は、/var/log/messages ファイルを開きます。

  2. [RPM] 文字列を含む新しい行を検索します。

4.9. RPM コンテンツの抽出
リンクのコピー

場合によってはパッケージのコンテンツを抽出する必要があります。たとえば、RPM に必要なパッケージが破損している場合などです。この場合、RPM インストールが破損しているにもかかわらず機能している場合は、rpm2archive ユーティリティーを使用して、.rpm ファイルを tar アーカイブに変換し、パッケージのコンテンツを使用できます。

注記

RPM インストールが著しく破損している場合は、rpm2cpio ユーティリティーを使用して RPM パッケージファイルを cpio アーカイブに変換できます。

手順

  • RPM ファイルを tar アーカイブに変換します。 

    $ rpm2archive <filename>.rpm
    Copy to Clipboard Toggle word wrap

    作成されたファイルには .tgz 接尾辞が付きます。たとえば、bash パッケージからアーカイブを作成するには、次のように入力します。 

    $ rpm2archive bash-4.4.19-6.el8.x86_64.rpm
$ ls bash-4.4.19-6.el8.x86_64.rpm.tgz
bash-4.4.19-6.el8.x86_64.rpm.tgz
    Copy to Clipboard Toggle word wrap

第5章 高度なトピック
リンクのコピー

このセクションでは、入門的なチュートリアルの範囲外のトピックを説明しますが、実際の RPM パッケージ化で役に立ちます。

5.1. RPM パッケージへの署名
リンクのコピー

RPM パッケージに署名して、第三者がコンテンツを変更できないようにすることができます。セキュリティーのレイヤーを追加するには、パッケージをダウンロードするときに HTTPS プロトコルを使用します。

rpm-sign パッケージで提供される --addsign オプションを使用して、パッケージに署名できます。

前提条件

  • GPG キーの作成 の説明に従って、GNU Privacy Guard (GPG) キーを作成しました。

5.1.1. GPG キーの作成
リンクのコピー

パッケージの署名に必要な GNU Privacy Guard (GPG) キーを作成するには、次の手順を使用します。

手順

  1. GPG キーペアを生成します。 

    # gpg --gen-key
    Copy to Clipboard Toggle word wrap

  2. 生成されたキーペアを確認します。 

    # gpg --list-keys
    Copy to Clipboard Toggle word wrap

  3. 公開鍵をエクスポートします。 

    # gpg --export -a '<Key_name>' > RPM-GPG-KEY-pmanager
    Copy to Clipboard Toggle word wrap

    <Key_name> を、選択した実際の鍵の名前に置き換えます。

  4. エクスポートした公開鍵を RPM データベースにインポートします。 

    # rpm --import RPM-GPG-KEY-pmanager
    Copy to Clipboard Toggle word wrap

5.1.2. パッケージに署名するための RPM の設定
リンクのコピー

パッケージに署名するには、%_gpg_name RPM マクロを指定する必要があります。

以下の手順では、パッケージの署名に使用する RPM を設定する方法を説明します。

手順

  • 次のように、$HOME/.rpmmacros ファイルで %_gpg_name マクロを定義します。 

    %_gpg_name Key ID
    Copy to Clipboard Toggle word wrap

    Key ID を、パッケージの署名に使用する GNU Privacy Guard (GPG) キー ID に置き換えます。有効な GPG キー ID の値は、鍵を作成したユーザーの氏名またはメールアドレスです。

5.1.3. RPM パッケージへの署名の追加
リンクのコピー

一般的に、パッケージは署名なしでビルドされます。署名はパッケージのリリース直前に追加されます。

RPM パッケージに署名を追加するには、rpm -sign パッケージで使用できる --addsign を指定します。

手順

  • パッケージに署名を追加します。 

    $ rpm --addsign package-name.rpm
    Copy to Clipboard Toggle word wrap

    package-name を、署名する RPM パッケージの名前に置き換えます。

    注記

    署名の秘密鍵のロックを解除するには、パスワードを入力する必要があります。

5.2. マクロの詳細
リンクのコピー

このセクションでは、選択したビルトイン RPM マクロを説明します。そのようなマクロの完全なリストは、RPM ドキュメンテーション を参照してください。

5.2.1. 独自のマクロの定義する
リンクのコピー

次のセクションでは、カスタムマクロの作成方法を説明します。

手順

  • RPM spec ファイルに次の行を含めます。 

    %global <name>[(opts)] <body>
    Copy to Clipboard Toggle word wrap

<body> の周りの空白すべてが削除されます。名前には英数字と文字 _ を使用できます。長さが 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

5.2.2. %setup マクロの使用
リンクのコピー

このセクションでは、%setup マクロの異なるバリアントを使用して、ソースコード tarball でパッケージを構築する方法を説明します。マクロバリアントは組み合わせることができることに注意してください。rpmbuild の出力は、%setup マクロにおける標準的な挙動を示しています。各フェーズの開始時に、マクロは以下の例のように Executing(%…​) を出力します。

例5.1 %setup マクロの出力例

Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.DhddsG
Copy to Clipboard Toggle word wrap

シェルの出力は、set -x enabled で設定されます。/var/tmp/rpm-tmp.DhddsG の内容を表示するには、--debug オプションを指定します。これは、rpmbuild により、ビルドの作成後に一時ファイルが削除されるためです。環境変数の設定の後に、以下のような設定が表示されます。 

cd '/builddir/build/BUILD'
rm -rf 'cello-1.0'
/usr/bin/gzip -dc '/builddir/build/SOURCES/cello-1.0.tar.gz' | /usr/bin/tar -xof -
STATUS=$?
if [ $STATUS -ne 0 ]; then
  exit $STATUS
fi
cd 'cello-1.0'
/usr/bin/chmod -Rf a+rX,u+w,g-w,o-w .
Copy to Clipboard Toggle word wrap

%setup マクロ:

  • 正しいディレクトリーで作業していることを確認します。
  • 以前のビルドで残ったファイルを削除します。
  • ソース tarball をデプロイメントします。
  • 一部のデフォルト権限を設定します。
5.2.2.1. %setup -q マクロの使用
リンクのコピー

-q オプションでは、%setup マクロの冗長性が制限されます。tar -xvvof の代わりに tar -xof のみが実行されます。このオプションは、最初のオプションとして使用します。

5.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
Copy to Clipboard Toggle word wrap
5.2.2.3. %setup -c マクロの使用
リンクのコピー

-c オプションは、ソースコード tarball にサブディレクトリーが含まれておらず、デプロイメント後に、アーカイブのファイルで現在のディレクトリーを埋める場合に使用されます。

次に、-c オプションによりディレクトリーが作成され、以下のようにアーカイブデプロイメント手順に映ります。 

/usr/bin/mkdir -p cello-1.0
cd 'cello-1.0'
Copy to Clipboard Toggle word wrap

このディレクトリーは、アーカイブ拡張後も変更されません。

5.2.2.4. %setup -D マクロおよび %setup -T マクロの使用
リンクのコピー

- D オプションは、ソースコードのディレクトリーの削除を無効するため、%setup マクロを複数回使用する場合に特に便利です。-D オプションでは、次の行は使用されません。 

rm -rf 'cello-1.0'
Copy to Clipboard Toggle word wrap

- T オプションは、スクリプトから以下の行を削除して、ソースコード tarball の拡張を無効にします。 

/usr/bin/gzip -dc '/builddir/build/SOURCES/cello-1.0.tar.gz' | /usr/bin/tar -xvvof -
Copy to Clipboard Toggle word wrap
5.2.2.5. %setup -a マクロおよび %setup -b マクロの使用
リンクのコピー

-a オプションおよび -b オプションは、特定のソースを拡張します。

  • -b オプションは before を表します。このオプションは、作業ディレクトリーに移動する前に特定のソースを展開します。
  • -a オプションは after を表します。このオプションは、移動した後にそれらのソースを展開します。引数は、spec ファイルの Preamble のソース番号です。

以下の例では、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
Copy to Clipboard Toggle word wrap

次の例では、サンプルは別の 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
Copy to Clipboard Toggle word wrap

5.2.3. %files セクション共通の RPM マクロ
リンクのコピー

次の表は、spec ファイルの %files セクションに必要な高度な RPM マクロを示しています。

Expand
表5.1 %files セクションの高度な RPM マクロ
マクロ定義

%license

%license マクロは、LICENSE ファイルとしてリストされているファイルを識別します。このファイルは、RPM によってインストールされ、適切にラベル付けされます。例: %license LICENSE.

%doc

%doc マクロは、ドキュメントとしてリストされているファイルを識別します。このファイルは、RPM によってインストールされ、適切にラベル付けされます。%doc マクロは、パッケージ化するソフトウェアに関するドキュメントのほか、コード例やさまざまな付随項目にも使用されます。コード例が含まれている場合は、ファイルから実行可能モードを削除するように注意する必要があります。例: %doc README

%dir

%dir マクロは、パスがこの RPM によって所有されているディレクトリーであることを確認します。これは、RPM ファイルマニフェストが、アンインストール時にどのディレクトリーをクリーンアップするかを正確に認識できるようにするために重要です。例: %dir %{_libdir}/%{name}

%config(noreplace)

%config(noreplace) マクロは、後続のファイルが設定ファイルであることを確認し、ファイルが元のインストールチェックサムから変更されている場合、パッケージのインストールまたは更新時にファイルを上書き (または置換) しないようにします。変更がある場合は、アップグレード時またはインストール時にファイル名の末尾に .rpmnew を追加してファイルが作成され、ターゲットシステム上の既存ファイルまたは変更されたファイルが変更されないようにします。例: %config(noreplace) %{_sysconfdir}/%{name}/%{name}.conf

5.2.4. ビルトインマクロの表示
リンクのコピー

Red Hat Enterprise Linux では、複数のビルトイン RPM マクロを提供しています。

手順

  1. ビルトイン RPM マクロをすべて表示するには、以下のコマンドを実行します。 

    rpm --showrc
    Copy to Clipboard Toggle word wrap
    注記

    出力のサイズは非常に大きくなります。結果を絞り込むには、grep コマンドとともに上記のコマンドを使用します。

  2. システムの RPM バージョン用の RPM マクロに関する情報を確認するには、以下のコマンドを実行します。 

    rpm -ql rpm
    Copy to Clipboard Toggle word wrap
    注記

    RPM マクロは、出力ディレクトリー構造の macros というタイトルのファイルです。

5.2.5. RPM ディストリビューションマクロ
リンクのコピー

パッケージ化しているソフトウェアの言語実装や、ディストリビューションの特定のガイドラインに基づいて提供する推奨 RPM マクロセットは、ディストリビューションによって異なります。

多くの場合、推奨される RPM マクロセットは RPM パッケージとして提供され、yum パッケージマネージャーでインストールできます。

インストールすると、マクロファイルは、/usr/lib/rpm/macros.d/ ディレクトリーに配置されます。

手順

  • raw RPM マクロ定義を表示するには、以下のコマンドを実行します。 

    rpm --showrc
    Copy to Clipboard Toggle word wrap

上記の出力では、raw RPM マクロ定義が表示されます。

  • RPM のパッケージ化を行う際のマクロの機能や、マクロがどう役立つかを確認するには、rpm --eval コマンドに、引数として使用するマクロの名前を付けて実行します。 

    rpm --eval %{_MACRO}
    Copy to Clipboard Toggle word wrap

5.2.6. カスタムマクロの作成
リンクのコピー

~/.rpmmacros ファイル内のディストリビューションマクロは、カスタムマクロで上書きできます。加えた変更は、マシン上のすべてのビルドに影響します。

警告

~/.rpmmacros ファイルで新しいマクロを定義することは推奨されません。このようなマクロは、ユーザーがパッケージを再構築する可能性がある他のマシンには存在しません。

手順

  • マクロを上書きするには、次のコマンドを実行します。 

    %_topdir /opt/some/working/directory/rpmbuild
    Copy to Clipboard Toggle word wrap

上記の例から、rpmde-setuptree ユーティリティーを使用して、すべてのサブディレクトリーを含むディレクトリーを作成できます。このマクロの値は、デフォルトでは ~/rpmbuild です。 

%_smp_mflags -l3
Copy to Clipboard Toggle word wrap

上記のマクロは、Makefile に渡すためによく使用されます。たとえば、make %{?_smp_mflags} と、ビルドフェーズ時に多数の同時プロセスを設定します。デフォルトでは、-jX に設定されています。X は多数のコアです。コア数を変すると、パッケージビルドの速度アップまたはダウンを行うことができます。

5.3. Epoch、Scriptlets、Triggers
リンクのコピー

このセクションでは、RMP spec ファイルの高度なディレクティブを表す Epoch、Scriptlets、および Triggers について説明します。

これらのディレクティブはすべて、spec ファイルだけでなく、生成される RPM がインストールされるエンドマシンにも影響します。

5.3.1. Epoch ディレクティブ
リンクのコピー

Epoch ディレクティブでは、バージョン番号に基づいて加重依存関係を定義できます。

このディレクティブが RPM の spec ファイルにない場合、Epoch ディレクティブは一切設定されません。これは、Epoch を設定しないと Epoch が 0 になるという一般的な考え方に反しています。ただし、yum ユーティリティーは、depsolve の目的で、0 の Epoch と同様に設定されていない Epoch を処理します。

ただし、spec ファイルでの Epoch のリストは通常省略されます。これは、多くの場合、Epoch 値を導入すると、パッケージのバージョンを比較するときに RPM の動作が予想と異なるものになるためです。

例5.2 Epoch の使用

Epoch: 1 および Version: 1.0 で foobar パッケージをインストールし、他のユーザーが Version 2.0 で foobar をパッケージ化します。ただし、Epoch ディレクティブがない場合、新しいバージョンは更新とはみなされません。RPM パッケージ用のバージョン管理を示す従来の Name-Version-Release ラッパーよりも、Epoch バージョンが推奨されている理由。

Epoch を使用することはほとんどありません。ただし、Epoch は通常、アップグレードの順序の問題を解決するために使用されます。この問題は、ソフトウェアバージョン番号のスキームや、エンコードに基づいて確実に比較できないアルファベット文字を組み込んだバージョンにおける、アップストリームによる変更の副次的効果として見られる場合があります。

5.3.2. Scriptlets ディレクティブ
リンクのコピー

Scriptlets は、パッケージがインストールまたは削除される前または後に実行される一連の RPM ディレクティブです。

Scriptlets は、ビルド時またはスタートアップスクリプト内で実行できないタスクにのみ使用します。

共通の Scriptlet ディレクティブのセットがあります。これらのディレクティブは、%build や %install などの spec ファイルのセクションヘッダーに似ています。これは、標準の POSIX シェルスクリプトとしてよく書かれる、マルチラインのコードセグメントによって定義されます。ただし、ターゲットマシンのディストリビューションの RPM が対応する他のプログラミング言語で書くこともできます。RPM ドキュメントには、利用可能な言語の完全なリストが含まれます。

以下の表には、実行順の Scriptlet ディレクティブのリストが含まれます。スクリプトを含むパッケージは、%pre と %post ディレクティブの間にインストールされ、%preun ディレクティブと %postun ディレクティブ間でアンインストールされることに注意してください。

Expand
表5.2 Scriptlet ディレクティブ
ディレクティブ定義

%pretrans

パッケージのインストールまたは削除の直前に実行されるスクリプトレット。

%pre

ターゲットシステムにパッケージをインストールする直前に実行されるスクリプトレット。

%post

ターゲットシステムにパッケージがインストールされた直後に実行されるスクリプトレット。

%preun

ターゲットシステムからパッケージをアンインストールする直前に実行されるスクリプトレット。

%postun

ターゲットシステムからパッケージをアンインストールした直後に実行されるスクリプトレット。

%posttrans

トランザクションの最後に実行されるスクリプトレット。

5.3.3. スクリプトレット実行の無効化
リンクのコピー

以下の手順では、rpm コマンドと --no_scriptlet_name_ オプションを使用して、スクリプトレットの実行を無効にする方法を説明します。

手順

  • たとえば、%pretrans スクリプトレットの実行を無効にするには、次のコマンドを実行します。 

    # rpm --nopretrans
    Copy to Clipboard Toggle word wrap

    -- noscripts オプションも使用できます。これは、以下のすべてと同等になります。

    • --nopre
    • --nopost
    • --nopreun
    • --nopostun
    • --nopretrans
    • --noposttrans

5.3.4. スクリプトレットマクロ
リンクのコピー

Scriptlets ディレクティブは、RPM マクロでも機能します。

以下の例は、systemd スクリプトレットマクロの使用を示しています。これにより、systemd は新しいユニットファイルについて通知されるようになります。 

$ rpm --showrc | grep systemd
-14: __transaction_systemd_inhibit      %{__plugindir}/systemd_inhibit.so
-14: _journalcatalogdir /usr/lib/systemd/catalog
-14: _presetdir /usr/lib/systemd/system-preset
-14: _unitdir   /usr/lib/systemd/system
-14: _userunitdir       /usr/lib/systemd/user
/usr/lib/systemd/systemd-binfmt %{?*} >/dev/null 2>&1 || :
/usr/lib/systemd/systemd-sysctl %{?*} >/dev/null 2>&1 || :
-14: systemd_post
-14: systemd_postun
-14: systemd_postun_with_restart
-14: systemd_preun
-14: systemd_requires
Requires(post): systemd
Requires(preun): systemd
Requires(postun): systemd
-14: systemd_user_post  %systemd_post --user --global %{?*}
-14: systemd_user_postun        %{nil}
-14: systemd_user_postun_with_restart   %{nil}
-14: systemd_user_preun
systemd-sysusers %{?*} >/dev/null 2>&1 || :
echo %{?*} | systemd-sysusers - >/dev/null 2>&1 || :
systemd-tmpfiles --create %{?*} >/dev/null 2>&1 || :

$ rpm --eval %{systemd_post}

if [ $1 -eq 1 ] ; then
        # Initial installation
        systemctl preset  >/dev/null 2>&1 || :
fi

$ rpm --eval %{systemd_postun}

systemctl daemon-reload >/dev/null 2>&1 || :

$ rpm --eval %{systemd_preun}

if [ $1 -eq 0 ] ; then
        # Package removal, not upgrade
        systemctl --no-reload disable  > /dev/null 2>&1 || :
        systemctl stop  > /dev/null 2>&1 || :
fi
Copy to Clipboard Toggle word wrap

5.3.5. Triggers ディレクティブ
リンクのコピー

Triggers は、パッケージのインストールおよびアンインストール時に対話できる手段を提供する RPM ディレクティブです。

警告

Triggers は、含まれるパッケージの更新など、予期できないタイミングで実行できます。Triggers はデバッグが難しいため、予期せず実行されたときに破損しないように、安定したな方法で実装する必要があります。このため、Red Hat では、Trigger の使用は最小限に抑えることを推奨します。

1 つのパッケージアップグレードの実行順序と、既存の各 Triggers の詳細は、以下のとおりです。 

all-%pretrans
…​
any-%triggerprein (%triggerprein from other packages set off by new install)
new-%triggerprein
new-%pre      for new version of package being installed
…​           (all new files are installed)
new-%post     for new version of package being installed

any-%triggerin (%triggerin from other packages set off by new install)
new-%triggerin
old-%triggerun
any-%triggerun (%triggerun from other packages set off by old uninstall)

old-%preun    for old version of package being removed
…​           (all old files are removed)
old-%postun   for old version of package being removed

old-%triggerpostun
any-%triggerpostun (%triggerpostun from other packages set off by old un
            install)
…​
all-%posttrans
Copy to Clipboard Toggle word wrap

上記の項目は、/usr/share/doc/rpm-4.*/triggers ファイルにあります。

5.3.6. spec ファイルでのシェルスクリプト以外のスクリプトの使用
リンクのコピー

spec ファイルの -p スクリプトレットオプションを使用すると、ユーザーはデフォルトのシェルスクリプトインタープリター (-p /bin/sh) の代わりに特定のインタープリターを呼び出すことができます。

次の手順では、pello.py プログラムのインストール後にメッセージを出力するスクリプトの作成方法を説明します。

手順

  1. pello.spec ファイルを開きます。

  2. 以下の行を見つけます。 

    install -m 0644 %{name}.py* %{buildroot}/usr/lib/%{name}/
    Copy to Clipboard Toggle word wrap

  3. 上記の行の下に、以下を挿入します。 

    %post -p /usr/bin/python3
print("This is {} code".format("python"))
    Copy to Clipboard Toggle word wrap
  4. RPM のビルド の説明に従ってパッケージをビルドします。

  5. パッケージをインストールします。 

    # yum install /home/<username>/rpmbuild/RPMS/noarch/pello-0.1.2-1.el8.noarch.rpm
    Copy to Clipboard Toggle word wrap

  6. インストール後に出力メッセージを確認します。 

    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
    Copy to Clipboard Toggle word wrap
注記

Python 3 スクリプトを使用するには、spec ファイルの install -m の下に次の行を含めます。 

%post -p /usr/bin/python3
Copy to Clipboard Toggle word wrap

Lua スクリプトを使用するには、SPEC ファイルの install -m に次の行を含めます。 

%post -p <lua>
Copy to Clipboard Toggle word wrap

このようにして、spec ファイルで任意のインタープリターを指定できます。

5.4. RPM 条件
リンクのコピー

RPM 条件により、spec ファイルのさまざまなセクションを条件付きで含めることができます。

条件を含めるには通常、次を処理します。

  • アーキテクチャー固有のセクション
  • オペレーティングシステム固有のセクション
  • さまざまなバージョンのオペレーティング間の互換性の問題
  • マクロの存在と定義

5.4.1. RPM 条件構文
リンクのコピー

RPM 条件では、次の構文を使用します。

expression が真であれば、以下のアクションを実行します。 

%if expression
…​
%endif
Copy to Clipboard Toggle word wrap

expression が真であれば、別のアクションを実行し、別の場合には別のアクションを実行します。 

%if expression
…​
%else
…​
%endif
Copy to Clipboard Toggle word wrap

5.4.2. %if 条件
リンクのコピー

次の例は、%if RPM 条件の使用法を示しています。

例5.3 Red Hat Enterprise Linux 8 と他のオペレーティングシステム間の互換性を処理するために %if を使用

%if 0%{?rhel} == 8
sed -i '/AS_FUNCTION_DESCRIBE/ s/^/#/' configure.in
sed -i '/AS_FUNCTION_DESCRIBE/ s/^/#/' acinclude.m4
%endif
Copy to Clipboard Toggle word wrap

この条件では、AS_FUNCTION_DESCRIBE マクロのサポート上、RHEL 8 と他のオペレーティングシステム間の互換性が処理されます。パッケージが RHEL 用にビルドされている場合、%rhel マクロが定義され、RHEL バージョンに展開されます。値が 8 の場合、パッケージは RHEL 8 用にビルドされ、RHEL 8 で対応していない AS_FUNCTION_DESCRIBE への参照が autoconfig スクリプトから削除されます。

例5.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
Copy to Clipboard Toggle word wrap

この条件では、マクロの定義を処理します。%milestone マクロまたは %revision マクロが設定されている場合は、アップストリームの tarball の名前を定義する %ruby_archive マクロが再定義されます。

5.4.3. %if 条件の特殊なバリアント
リンクのコピー

%ifarch 条件、%ifnarch 条件、%ifos 条件は、%if 条件の特殊なバリアントです。これらのバリアントは一般的に使用されるため、独自のマクロがあります。

%ifarch 条件

%ifarch 条件は、アーキテクチャー固有の spec ファイルのブロックを開始するために使用されます。この後に、アーキテクチャー指定子が続きます。これらは、それぞれコンマまたは空白で区切ります。

例5.5 %ifarch 条件の使用例

%ifarch i386 sparc
…​
%endif
Copy to Clipboard Toggle word wrap

%ifarch と %endif の間にある spec ファイルのすべての内容は、32 ビット AMD および Intel アーキテクチャーまたは Sun SPARC ベースのシステムでのみ処理されます。

%ifnarch 条件

% ifnarch 条件には、%ifarch 条件よりもリバース論理があります。

例5.6 %ifnarch 条件の使用例

%ifnarch alpha
…​
%endif
Copy to Clipboard Toggle word wrap

%ifnarch と %endif の間にある spec ファイルのすべての内容は、Digital Alpha/AXP ベース以外のシステムでのみ処理されます。

%ifos 条件

%ifos 条件は、ビルドのオペレーティングシステムに基づいて処理を制御するために使用されます。その後に複数のオペレーティングシステム名を指定できます。

例5.7 %ifos 条件の使用例

%ifos linux
…​
%endif
Copy to Clipboard Toggle word wrap

%ifos と %endif の間にある spec ファイルのすべての内容は、ビルドが Linux システムで実行された場合にのみ処理されます。

5.5. Python 3 RPM のパッケージ化
リンクのコピー

ほとんどの Python プロジェクトは、パッケージ化に Setuptools を使用して、setup.py ファイルにパッケージ情報を定義します。Setuptools パッケージ化の詳細は Setuptools ドキュメント を参照してください。

Python プロジェクトを RPM パッケージにパッケージ化することもできます。これには、Setuptools パッケージ化と比較して以下の利点があります。

  • その他の RPM のパッケージの依存関係の指定 (Python 以外も含む)

  • 電子署名

    電子署名を使用すると、RPM パッケージの内容は、オペレーティングシステムのその他の部分とともに検証、統合、およびテストできます。

5.5.1. Python パッケージ用の SPEC ファイルの説明
リンクのコピー

SPEC ファイルには、rpmbuild ユーティリティーが RPM をビルドする際に使用する指示を記述します。指示は一連のセクションに記述します。SPEC ファイルには、次の 2 つの主要な部分があります。各部分に複数のセクションを定義します。

  • Preamble (Body で使用される一連のメタデータ項目を記述)
  • Body (指示の主要部分を記述)

Python プロジェクトの RPM SPEC ファイルには、非 Python RPM SPEC ファイルと比較していくつかの詳細があります。特に注目すべきは、Python ライブラリーの RPM パッケージ名に、Python 3.6 の場合は python3、Python 3.8 の場合は python38、Python 3.9 の場合は python39、Python 3.11 の場合は python3.11 など、バージョンを判別する接頭辞を常に含める必要があります。

その他の詳細は、次の SPEC ファイルの python3-detox パッケージの例 に記載されています。その詳細の説明は、例の下に記載されている注意事項を参照してください。 

%global modname detox
1 


Name:           python3-detox
2 

Version:        0.12
Release:        4%{?dist}
Summary:        Distributing activities of the tox tool
License:        MIT
URL:            https://pypi.io/project/detox
Source0:        https://pypi.io/packages/source/d/%{modname}/%{modname}-%{version}.tar.gz

BuildArch:      noarch

BuildRequires:  python36-devel
3 

BuildRequires:  python3-setuptools
BuildRequires:  python36-rpm-macros
BuildRequires:  python3-six
BuildRequires:  python3-tox
BuildRequires:  python3-py
BuildRequires:  python3-eventlet

%?python_enable_dependency_generator
4 


%description

Detox is the distributed version of the tox python testing tool. It makes efficient use of multiple CPUs by running all possible activities in parallel.
Detox has the same options and configuration that tox has, so after installation you can run it in the same way and with the same options that you use for tox.

    $ detox

%prep
%autosetup -n %{modname}-%{version}

%build
%py3_build
5 


%install
%py3_install

%check
%{__python3} setup.py test
6 


%files -n python3-%{modname}
%doc CHANGELOG
%license LICENSE
%{_bindir}/detox
%{python3_sitelib}/%{modname}/
%{python3_sitelib}/%{modname}-%{version}*

%changelog
...
Copy to Clipboard Toggle word wrap
1
modname マクロには、Python プロジェクトの名前が含まれます。この例では detox となります。
2
Python プロジェクトを RPM にパッケージ化する場合は、常にプロジェクトの元の名前に接頭辞 python3 を追加する必要があります。ここでの元の名前は detox で、RPM の名前 は python3-detox です。
3
BuildRequires は、このパッケージのビルドおよびテストに必要なパッケージを指定します。BuildRequires では、Python パッケージをビルドするのに必要なツールを提供する項目 (python36-devel および python3-setuptools) が常に含まれます。/usr/bin/python3 インタープリターディレクティブを持つファイルが自動的に /usr/bin/python3.6 に変更されるように、python36-rpm-macros パッケージが必要です。
4
すべての Python パッケージが正しく動作するためには、その他のパッケージがいくつか必要です。このようなパッケージも、SPEC ファイルで指定する必要があります。依存関係を指定するには、%python_enable_dependency_generator マクロを使用して、setup.py ファイルに定義した依存関係を自動的に使用できます。パッケージに、Setuptools で指定していない依存関係がある場合は、追加の Requires ディレクティブ内に指定します。
5
%py3_build マクロおよび %py3_install マクロは、setup.py build コマンドおよび setup.py install コマンドを実行します。それぞれには、インストール場所、使用するインタープリター、その他の詳細を指定する引数を用います。
6
check セクションは、Python の正しいバージョンを実行するマクロを提供します。%{__python3} マクロには、Python 3 インタープリターのパス (/usr/bin/python3 など) が含まれます。リテラルパスではなく、マクロを使用することが常に推奨されます。

5.5.2. Python 3 RPM の一般的なマクロ
リンクのコピー

SPEC ファイルでは、値をハードコーディングするのではなく、以下の Python 3 RPM のマクロ の表で説明されているマクロを常に使用します。

マクロ名では、バージョンを指定しない python ではなく、python3 または python2 を使用してください。SPEC ファイルの BuildRequires セクションで特定の Python 3 バージョンを python36-rpm-macros、python38-rpm-macros、python39-rpm-macros、または python3.11-rpm-macros に設定します。

Expand
表5.3 Python 3 RPM 用のマクロ
マクロ一般的な定義説明

%{__python3}

/usr/bin/python3

Python 3 のインタープリター

%{python3_version}

3.6

Python 3 インタープリターのフルバージョン

%{python3_sitelib}

/usr/lib/python3.6/site-packages

pure-Python モジュールのインストール先

%{python3_sitearch}

/usr/lib64/python3.6/site-packages

アーキテクチャー固有の拡張を含むモジュールがインストールされている場合

%py3_build

 

システムパッケージに適した引数で setup.py build コマンドを実行します。

%py3_install

 

システムパッケージに適した引数で setup.py install コマンドを実行します。

5.5.3. Python RPM の自動 Provides
リンクのコピー

Python プロジェクトをパッケージ化する際、以下のディレクトリーが存在する場合は、作成される RPM に以下のディレクトリーが含まれていることを確認してください。

  • .dist-info
  • .egg-info
  • .egg-link

このディレクトリーから、RPM ビルドプロセスは自動的に仮想 pythonX.Ydist Provides (python3.6dist(detox) など) を生成します。この仮想 Provides は、%python_enable_dependency_generator マクロにより指定されるパッケージにより提供されます。

5.6. Python スクリプトでインタープリターディレクティブの処理
リンクのコピー

Red Hat Enterprise Linux 8 では、実行可能な Python スクリプトは、少なくとも主要な Python バージョンを明示的に指定するインタープリターディレクティブ (別名 hashbangs または shebangs) を使用することが想定されます。以下に例を示します。 

#!/usr/bin/python3
#!/usr/bin/python3.6
#!/usr/bin/python3.8
#!/usr/bin/python3.9
#!/usr/bin/python3.11
#!/usr/bin/python3.12
#!/usr/bin/python2
Copy to Clipboard Toggle word wrap

/usr/lib/rpm/redhat/brp-mangle-shebangs BRP (buildroot policy) スクリプトは、RPM パッケージをビルドする際に自動的に実行され、実行可能なすべてのファイルでインタープリターディレクティブを修正しようとします。

BRP スクリプトは、以下のようにあいまいなインタープリターディレクティブを含む Python スクリプトを検出すると、エラーを生成します。 

#!/usr/bin/python
Copy to Clipboard Toggle word wrap

または 

#!/usr/bin/env python
Copy to Clipboard Toggle word wrap

5.6.1. Python スクリプトでインタープリターディレクティブの変更
リンクのコピー

RPM ビルド時にビルドエラーが発生する Python スクリプト内のインタープリターディレクティブを変更します。

前提条件

  • Python スクリプトのインタープリターディレクティブの一部でビルドエラーが発生する。

手順

インタープリターディレクティブを変更するには、以下のタスクのいずれかを実行します。

  • platform-python-devel パッケージから pathfix.py スクリプトを適用します。 

    # pathfix.py -pn -i %{__python3} PATH …​
    Copy to Clipboard Toggle word wrap

    複数の PATH を指定できます。PATH がディレクトリーの場合、pathfix.py はあいまいなインタープリターディレクティブを持つスクリプトだけでなく、^[a-zA-Z0-9_]+\.py$ のパターンに一致する Python スクリプトを再帰的にスキャンします。このコマンドを %prep セクション、または %install セクションに追加します。

  • パッケージ化した Python スクリプトを、想定される形式に準拠するように変更します。この目的のために、pathfix.py は、RPM ビルドプロセス以外でも使用できます。pathfix.py を RPM ビルド以外で実行する場合は、上記の例の %{__python3} を、/usr/bin/python3 などのインタープリターディレクティブのパスに置き換えます。

パッケージ化された Python スクリプトに Python 3.6 以外のバージョンが必要な場合は、上記のコマンドを調整して必要なバージョンを含めます。

5.6.2. カスタムパッケージの /usr/bin/python3 インタープリターディレクティブの変更
リンクのコピー

デフォルトでは、/usr/bin/python3 の形式でのインタープリターディレクティブは、Red Hat Enterprise Linux のシステムツールに使用される platform-python パッケージから Python を参照するインタープリターディレクティブに置き換えられます。カスタムパッケージの /usr/bin/python3 インタープリターディレクティブを変更して、AppStream リポジトリーからインストールした特定バージョンの Python を参照できます。

手順

  • Python の特定バージョンのパッケージをビルドするには、それぞれの python パッケージの python*-rpm-macros サブパッケージを spec ファイルの BuildRequires セクションに追加します。たとえば、Python 3.6 の場合は、以下の行を追加します。 

    BuildRequires:  python36-rpm-macros
    Copy to Clipboard Toggle word wrap

    これにより、カスタムパッケージの /usr/bin/python3 インタープリターディレクティブは、自動的に /usr/bin/python3.6 に変換されます。

注記

BRP スクリプトがインタープリターディレクティブを確認したり、変更したりしないようにするには、以下の RPM ディレクティブを使用します。 

%undefine __brp_mangle_shebangs
Copy to Clipboard Toggle word wrap

5.7. RubyGems パッケージ
リンクのコピー

このセクションでは、RubyGems パッケージの概要と、RPM への再パッケージ化方法を説明します。

5.7.1. RubyGems の概要
リンクのコピー

Ruby は、ダイナミックなインタープリター言語で、反映的なオブジェクト指向の汎用プログラミング言語です。

Ruby で書かれたプログラムは、特定の Ruby パッケージ形式を提供する RubyGems プロジェクトを使用してパッケージ化されます。

RubyGems で作成したパッケージは gems と呼ばれ、RPM に再パッケージ化することもできます。

注記

このドキュメントは、gem 接頭辞とともに RubyGems の概念に関する用語を参照します。たとえば、.gemspec は gem specification に使用され、RPM に関連する用語は非修飾になります。

5.7.2. RubyGems が RPM に関連している仕組み
リンクのコピー

RubyGems は、Ruby 独自のパッケージ形式を表します。ただし、RubyGems には RPM が必要とするメタデータと同様のものが含まれ、RubyGems から RPM への変換が可能になります。

Ruby Packaging Guidelines では、以下の方法で RubyGems パッケージを RPM に再パッケージ化できます。

  • このような RPM は、残りすべてのディストリビューションに適合します。
  • RPM パッケージ化された正しい gem をインストールすると、エンドユーザーで gem の依存関係を満たすことができます。

RubyGems では、spec ファイル、パッケージ名、依存関係、その他の項目など、RPM と同様の用語を使用します。

残りの RHEL RPM ディストリビューションに合わせるには、RubyGems で作成したパッケージが以下の規則に従う必要があります。

  • gems の名前は以下のパターンに従います。 

    rubygem-%{gem_name}
    Copy to Clipboard Toggle word wrap

  • シバンの行を実装するには、以下の文字列を使用する必要があります。 

    #!/usr/bin/ruby
    Copy to Clipboard Toggle word wrap

5.7.3. RubyGems パッケージからの RPM パッケージの作成
リンクのコピー

RubyGems パッケージのソース RPM を作成するには、以下のファイルが必要です。

  • gem ファイル
  • RPM spec ファイル

次のセクションでは、RubyGems が作成したパッケージから RPM パッケージを作成する方法を説明します。

5.7.3.1. RubyGems spec ファイルの規則
リンクのコピー

RubyGems spec ファイルは、次の規則を満たしている必要があります。

  • gem の仕様の名前である %{gem_name} の定義が含まれる。
  • パッケージのソースは、リリースされた gem アーカイブの完全な URL であること。パッケージのバージョンは、gem のバージョンであること。

  • ビルドに必要なマクロをプルできるように、以下のように定義された BuildRequires: ディレクティブが含まれる。 

    BuildRequires:rubygems-devel
    Copy to Clipboard Toggle word wrap
  • RubyGems Requires または Provides は自動生成されるため、含まれません。

  • Ruby バージョンの互換性を明示的に指定しない限り、以下のように定義された BuildRequires: ディレクティブは含まれません。 

    Requires: ruby(release)
    Copy to Clipboard Toggle word wrap

    RubyGems で自動生成された依存関係 (Requires:ruby (rubygems)) で十分です。

5.7.3.2. RubyGems マクロ
リンクのコピー

以下の表は、RubyGems で作成したパッケージで役に立つマクロをリスト表示します。これらのマクロは、rubygems-devel パッケージで提供されています。

Expand
表5.4 RubyGems マクロ
マクロ名拡張パス用途

%{gem_dir}

/usr/share/gems

gem 構造のトップディレクトリー。

%{gem_instdir}

%{gem_dir}/gems/%{gem_name}-%{version}

gem の実際のコンテンツが含まれるディレクトリー。

%{gem_libdir}

%{gem_instdir}/lib

gem のライブラリーディレクトリー。

%{gem_cache}

%{gem_dir}/cache/%{gem_name}-%{version}.gem

キャッシュした gem。

%{gem_spec}

%{gem_dir}/specifications/%{gem_name}-%{version}.gemspec

gem 仕様ファイル。

%{gem_docdir}

%{gem_dir}/doc/%{gem_name}-%{version}

gem の RDoc ドキュメンテーション。

%{gem_extdir_mri}

%{_libdir}/gems/ruby/%{gem_name}-%{version}

gem 拡張のディレクトリー。

5.7.3.3. RubyGems spec ファイルの例
リンクのコピー

以下に、gem をビルドするための spec ファイルの例と、その特定のセクションの説明を示します。

RubyGems spec ファイルの例

%prep
%setup -q -n  %{gem_name}-%{version}

# Modify the gemspec if necessary
# Also apply patches to code if necessary
%patch0 -p1

%build
# Create the gem as gem install only works on a gem file
gem build ../%{gem_name}-%{version}.gemspec

# %%gem_install compiles any C extensions and installs the gem into ./%%gem_dir
# by default, so that we can move it into the buildroot in %%install
%gem_install

%install
mkdir -p %{buildroot}%{gem_dir}
cp -a ./%{gem_dir}/* %{buildroot}%{gem_dir}/

# If there were programs installed:
mkdir -p %{buildroot}%{_bindir}
cp -a ./%{_bindir}/* %{buildroot}%{_bindir}

# If there are C extensions, copy them to the extdir.
mkdir -p %{buildroot}%{gem_extdir_mri}
cp -a .%{gem_extdir_mri}/{gem.build_complete,*.so} %{buildroot}%{gem_extdir_mri}/
Copy to Clipboard Toggle word wrap

次の表は、RubyGems spec ファイルに含まれる特定の項目の詳細を説明しています。

Expand
表5.5 RubyGems の spec のディレクティブ詳細
ディレクティブRubyGems の詳細

%prep

RPM は gem アーカイブを直接デプロイメントできるため、gem unpack コマンドを実行して gem からソースを抽出できます。%setup -n %{gem_name}-%{version} マクロは、gem がデプロイメントされたディレクトリーを提供します。同じディレクトリーレベルでは、%{gem_name}-%{version}.gemspec ファイルが自動的に作成されます。このファイルは、後で gem を再構築したり、.gemspec を変更したり、コードにパッチを適用したりするために使用されます。

%build

このディレクティブには、ソフトウェアをマシンコードに構築するためのコマンドまたは一連のコマンドが含まれます。%gem_install マクロは gem アーカイブでのみ動作し、gem は次の gem ビルドで再作成されます。作成した gem ファイルは、%gem_install により使用され、一時ディレクトリー (デフォルトでは /%{gem_dir}) にコードを構築してインストールします。%gem_install マクロは両者とも、コードを 1 つのステップで構築してインストールします。ビルドしたソースはインストール前に、自動的に作成される一時ディレクトリーに配置されます。

%gem_install マクロは、2 つの追加オプションを受け付けます。そのうちの 1 つは -n <gem_file> で、インストールに使用される gem を上書きできます。もうひとつは、- d <install_dir> で、gem インストール先を上書きできます。なお、このオプションの使用は推奨されません。

%gem_install マクロは、%{buildroot} へのインストールに使用することはできません。

%install

インストールは、%{buildroot} 階層で実行されます。必要なディレクトリーを作成し、一時ディレクトリーにインストールされているものを、%{buildroot} 階層にコピーできます。この gem が共有オブジェクトを作成すると、これらはアーキテクチャー固有の %{gem_extdir_MRI} パスに移動されます。

5.7.3.4. gem2rpm を使用して RubyGems パッケージを RPM spec ファイルに変換する
リンクのコピー

gem2rpm ユーティリティーは、RubyGems パッケージを RPM spec ファイルに変換します。

以下のセクションでは、次の方法を説明します。

  • gem2rpm ユーティリティーのインストール
  • すべての gem2rpm オプションの表示
  • gem2rpm を使用して RubyGems パッケージを RPM spec ファイルに変換する
  • gem2rpm テンプレートの変更
5.7.3.4.1. GFS2 のインストール
リンクのコピー

以下の手順では、gem2rpm ユーティリティーのインストール方法を説明します。

手順

  • RubyGems.org から gem2rpm にインストールするには、以下のコマンドを実行します。 
$ gem install gem2rpm
Copy to Clipboard Toggle word wrap
5.7.3.4.2. gem2rpm のすべてのオプションの表示
リンクのコピー

以下の手順では、gem2rpm ユーティリティーのすべてのオプションを表示する方法を説明します。

手順

  • gem2rpm のすべてのオプションを表示するには、以下を実行してください。 

    $ gem2rpm --help
    Copy to Clipboard Toggle word wrap
5.7.3.4.3. gem2rpm を使用して RubyGems パッケージを RPM spec ファイルに変換する
リンクのコピー

次の手順では、gem2rpm ユーティリティーを使用して RubyGems パッケージを RPM spec ファイルに変換する方法を説明します。

手順

  • 最新バージョンの gem をダウンロードし、この gem の RPM spec ファイルを生成します。 

    $ gem2rpm --fetch <gem_name> > <gem_name>.spec
    Copy to Clipboard Toggle word wrap

上記の手順では、gem のメタデータで提供される情報に基づいて RPM spec ファイルを作成します。ただし、gem は、通常 RPM (ライセンスや変更ログなど) で提供される重要な情報に欠けています。したがって、生成された spec ファイルを編集する必要があります。

5.7.3.4.4. gem2rpm テンプレート
リンクのコピー

gem2rpm テンプレートとは、次の表に示す変数を含む標準の埋め込み Ruby (ERB) ファイルです。

Expand
表5.6 gem2rpm テンプレート内の変数
変数説明

package

gem の Gem::Package 変数。

spec

gem の Gem ::Specification 変数 (format.spec と同じ)。

config

仕様のテンプレートヘルパーで使用されるデフォルトのマクロまたはルールを再定義できる Gem 2RPM::Configuration 変数。

runtime_dependencies

パッケージランタイム依存関係のリストを示す Gem2RPM::RpmDependencyList 変数。

development_dependencies

パッケージ開発依存関係のリストを示す Gem2RPM::RpmDependencyList 変数。

tests

実行を許可するテストフレームワークのリストを示す Gem2Rpm::TestSuite 変数。

files

パッケージ内のファイルにフィルターが適用されていないリストを示す Gem 2RPM::RpmFileList 変数。

main_files

メインパッケージに適したファイルのリストを提供する Gem2RPM::RpmFileList 変数。

doc_files

-doc サブパッケージに適したファイルのリストを提供する Gem 2RPM::RpmFileList 変数。

format

gem の Gem::Format 変数。この変数は現在非推奨になっています。

5.7.3.4.5. 利用可能な gem2rpm テンプレートのリスト表示
リンクのコピー

以下の手順では、利用可能な gem2rpm テンプレートのリストを表示する方法を説明します。

手順

  • 利用可能なテンプレートをすべて表示するには、以下を実行します。 

    $ gem2rpm --templates
    Copy to Clipboard Toggle word wrap
5.7.3.4.6. gem2rpm テンプレートの編集
リンクのコピー

生成された spec ファイルを編集する代わりに、RPM spec ファイルの生成元のテンプレートを編集できます。

gem2rpm のテンプレートを変更する場合は、以下の手順を行います。

手順

  1. デフォルトのテンプレートを保存します。 

    $ gem2rpm -T > rubygem-<gem_name>.spec.template
    Copy to Clipboard Toggle word wrap
  2. 必要に応じてテンプレートを編集します。

  3. 編集したテンプレートを使用して spec ファイルを生成します。 

    $ gem2rpm -t rubygem-<gem_name>.spec.template <gem_name>-<latest_version.gem > <gem_name>-GEM.spec
    Copy to Clipboard Toggle word wrap

これで、RPM のビルド の説明に従って、編集したテンプレートを使用して RPM パッケージをビルドできるようになりました。

5.8. Perl スクリプトで RPM パッケージを処理する方法
リンクのコピー

RHEL 8 以降、Perl プログラミング言語はデフォルトの buildroot に含まれていません。したがって、Perl スクリプトを含む RPM パッケージでは、RPM spec ファイルの BuildRequires: ディレクティブを使用して、Perl への依存関係を明示的に示す必要があります。

5.8.2. 特定の Perl モジュールの使用
リンクのコピー

特定の Perl モジュールがビルド時に必要な場合は、以下の手順に従います。

手順

  • RPM spec ファイルに次の構文を適用します。 

    BuildRequires: perl(MODULE)
    Copy to Clipboard Toggle word wrap
    注記

    この構文は Perl コアモジュールにも適用します。これは、perl パッケージを同時に移動し、タイムアウトするためです。

5.8.3. 特定の Perl バージョンへのパッケージの制限
リンクのコピー

パッケージを特定の Perl バージョンに限定するには、以下の手順に従います。

手順

  • RPM spec ファイルで、必要なバージョン制約を指定した perl (:VERSION) 依存関係を使用します。

    たとえば、パッケージを Perl バージョン 5.22 以降に制限するには、以下を使用します。 

    BuildRequires: perl(:VERSION) >= 5.22
    Copy to Clipboard Toggle word wrap
警告

perl パッケージのバージョンには、エポック番号が含まれるため、バージョンに対する比較は行わないでください。

5.8.4. パッケージが正しい Perl インタープリターを使用することを確認
リンクのコピー

Red Hat は、完全に互換性がない複数の Perl インタープリターを提供しています。そのため、Perl モジュールを提供するすべてのパッケージは、ビルド時に使用されたものと同じ Perl インタープリターをランタイムで使用する必要があります。

これを確認するには、以下の手順に従います。

手順

  • Perl モジュールを提供するパッケージの RPM spec ファイルに、バージョン管理された MODULE_COMPAT Requires を含めます。 

    Requires:  perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
    Copy to Clipboard Toggle word wrap

第6章 RHEL 8 の新機能
リンクのコピー

本セクションでは、Red Hat Enterprise Linux 7 と 8 における RPM パッケージ化の主な変更点を説明します。

6.1. Weak 依存関係のサポート
リンクのコピー

Weak 依存関係 は、Requires ディレクティブのバリアントです。これらのバリアントは、Epoch-Version-Release 範囲比較で仮想 Provides: とパッケージ名に対して一致します。

Weak 依存関係 には、以下の表でまとめているように、2 つの強み (weak と hint) と 2 つの方向 (forward と backward) があります。

注記

forward 方向は Requires: に類似しています。backward には、以前の依存関係システムには類似していません。

Expand
表6.1 Weak の依存関係の強みと方向の組み合わせが可能
強み/方向ForwardBackward

Weak

推奨:

補助:

Hint

提案:

強化:

Weak 依存関係 ポリシーの主な利点は以下のとおりです。

  • デフォルトのインストール機能の豊富さを維持しつつ、最小限のインストールが可能です。
  • パッケージは、仮想の柔軟性を維持しながら、特定のプロバイダーの設定を指定できます。

6.1.1. Weak 依存関係の概要
リンクのコピー

デフォルトでは、Weak 依存関係 は、通常の Requires: と同様に扱われます。一致するパッケージが YUM トランザクションに含まれます。パッケージの追加でとエラーが発生する場合、デフォルトでは YUM は依存関係を無視します。そのため、ユーザーは Weak 依存関係 により追加されるパッケージを除外したり、後で削除したりできます。

使用の条件

Weak 依存関係 は、パッケージが依然として依存関係なしで機能している場合に限り使用できます。

注記

Weak の要件を追加することなく、非常に限定的な機能を持つパッケージを作成できます。

使用例

Weak の依存関係 は特に、目的が単一で、パッケージの全機能セットを必要としない仮想マシンやコンテナーを構築するなど、合理的なユースケースのためにインストールを最小限に抑えることができる場合に使用します。

Weak 依存関係 の一般的なユースケースは、以下のとおりです。

  • ドキュメント

    • ドキュメントビューアーがない場合でも正常に処理されるドキュメントビューアー
  • 例

  • プラグインまたはアドオン

    • 対応ファイル形式
    • 対応プロトコル

6.1.2. Hints の強度
リンクのコピー

Hints はデフォルトで、YUM で無視されます。これは、GUI ツールで使用することで、デフォルトでインストールされていないアドオンパッケージを利用できます。ただし、インストールされているパッケージと組み合わせることで役に立ちます。

パッケージの主なユースケースの要件には、Hints を使用しないでください。代わりに、このような要件を強固な依存関係または Weak 依存関係 に含めます。

パッケージ設定

YUM は Weak の依存関係 と Hints を使用して、複数の同等に有効なパッケージ間の選択肢がある場合に使用するパッケージを決定します。インストールされているパッケージまたはインストールされるパッケージの依存関係で指示されるパッケージが推奨されます。

依存関係の解決に関する通常のルールは、この機能の影響を受けないことに注意してください。たとえば、Weak 依存関係 は、古いバージョンのパッケージが強制的に選ばれるようにすることはできません。

依存関係に複数のプロバイダーがある場合は、必須となるパッケージで Suggests: を追加して、どのオプションが優先されるかについて依存関係リゾルバーにヒントを提供することができます。

メインパッケージおよび他のプロバイダーが、必要なパッケージにヒントを追加することが、より簡素化されたソリューションであるということに同意する場合にのみ Enhances: が使用されます。

例6.1 Hints を使用した、ある特定のパッケージの優先

Package A: Requires: mysql

Package mariadb: Provides: mysql

Package community-mysql: Provides: mysql
Copy to Clipboard Toggle word wrap

community-mysql パッケージよりも mariadb パッケージを優先する場合は、以下を使用します。 

Suggests: mariadb to Package A.
Copy to Clipboard Toggle word wrap

6.1.3. Forwared と Backward の依存関係
リンクのコピー

Forward 依存関係 は Requires と同様に、インストールするパッケージに対して評価されます。最も一致するパッケージもインストールされます。

一般的には、Forward 依存関係 が優先されます。システムに追加された別のパッケージを取得する場合は、この依存関係をパッケージに追加します。

Backward 依存関係 の場合、一致するパッケージもインストールされていると、その依存関係を含むパッケージがインストールされます。

Backward 依存関係 は主に、そのプラグイン、アドオン、エクステンション機能をディストリビューションやその他サードパーティーパッケージにアタッチできるサードパーティーベンダー向けに設計されています。

6.2. ブール型依存関係のサポート
リンクのコピー

バージョン 4.13 以降では、RPM は以下の依存関係でブール式を処理できます。

  • Requires
  • Recommends
  • Suggests
  • supplements
  • Enhances
  • Conflicts

このセクションでは、ブール値の依存関係構文 を説明し、ブール値演算子 のリストを紹介して、ブール値の依存関係のセマンティクス およびブール値の 依存関係のセマンティクス について説明します。

6.2.1. ブール値の依存関係構文
リンクのコピー

ブール値は、常に括弧で囲まれています。

これは、通常の依存関係から構築されます。

  • 名前のみまたは名前
  • 比較
  • バージョンの説明

6.2.2. ブール値の演算子
リンクのコピー

RPM 4.13 では、以下のブール値演算子が導入されました。

Expand
表6.2 RPM 4.13 で導入されたブール値演算子
ブール値演算子説明使用例

and

用語が真となるには、すべてのオペランドを満たす必要があります。

Conflicts: (pkgA and pkgB)

または

用語が真となるには、いずれかのオペランドを満たす必要があります。

Requires: (pkgA >= 3.2 or pkgB)

if

第 2 のオペランドが満たされる場合、第 1 オペランドも満たされる必要があります (リバースインプリケーション)

Recommends: (myPkg-langCZ if langsupportCZ)

if else

if 演算子と同じで、2 番目のオペランドが一致しない場合は、第 3 オペランドが満たされる必要があります。

Requires: myPkg-backend-mariaDB if mariaDB else sqlite

RPM 4.14 では、以下のブール値演算子がさらに導入されています。

Expand
表6.3 RPM 4.14 で導入されたブール値演算子
ブール値演算子説明使用例

with

用語が真となるには、すべてのオペランドが同じパッケージで満たされる必要があります。

Requires: (pkgA-foo with pkgA-bar)

without

最初のオペランドを満たすが、2 番目のオペランドを満たさない単一のパッケージが必要

Requires: (pkgA-foo without pkgA-bar)

unless

2 番目のオペランドが満たされない場合、最初のオペランドを満たす必要があります (リバースネガティブインプリケーション)。

Conflicts: (myPkg-driverA unless driverB)

unless else

unless 演算子と同じで、2 番目のオペランドが一致しない場合は、第 3 オペランドが満たされる必要があります。

Conflicts: (myPkg-backend-SDL1 unless myPkg-backend-SDL2 else SDL2)

重要

if 演算子と or 演算子は同じコンテキストで使用できず、unless 演算子は and と同じコンテキストで使用できません。

6.2.3. ネスト化
リンクのコピー

以下の例のように、オペランド自体をブール式として使用できます。

このような場合は、オペランドを括弧で囲む必要もあります。and と or 演算子を組み合わせて、括弧で囲った同じ 1 セットと同じ演算子を繰り返すことができます。

例6.2 ブール式として適用されるオペランドの使用例

Requires: (pkgA or pkgB or pkgC)
Copy to Clipboard Toggle word wrap 
Requires: (pkgA or (pkgB and pkgC))
Copy to Clipboard Toggle word wrap 
Supplements: (foo and (lang-support-cz or lang-support-all))
Copy to Clipboard Toggle word wrap 
Requires: (pkgA with capB) or (pkgB without capA)
Copy to Clipboard Toggle word wrap 
Supplements: ((driverA and driverA-tools) unless driverB)
Copy to Clipboard Toggle word wrap 
Recommends: myPkg-langCZ and (font1-langCZ or font2-langCZ) if langsupportCZ
Copy to Clipboard Toggle word wrap

6.2.4. セマンティクス
リンクのコピー

ブール値の依存関係 を使用しても、通常の依存関係のセマンティックは変更されません。

ブール値の依存関係 が使用されている場合は、名前が一致するものをすべてチェックし、一致する名前のブール値をブール値演算子で集計します。

重要

Conflicts: を除くすべての依存関係では、インストールを防ぐために、結果が True である必要があります。Conflicts: については、インストールを防ぐために、結果が False である必要があります。

警告

Provides は依存関係ではないため、ブール式を含めることはできません。

6.2.5. if 演算子の出力の理解
リンクのコピー

if 演算子もブール値を返します。これは、直感的に理解しやすいものです。ただし、以下の例では、if の直感的な使用が誤解を招く可能性がある場合を示しています。

例6.3 if 演算子の出力の誤解

このステートメントは、pkgB がインストールされていない場合には真になります。ただし、このステートメントを、デフォルトの結果が偽であるところで使用すると、事が複雑になります。 

Requires: (pkgA if pkgB)
Copy to Clipboard Toggle word wrap

このステートメントは、pkgB がインストールされていて、pkgA がインストールされていない場合に競合します。 

Conflicts: (pkgA if pkgB)
Copy to Clipboard Toggle word wrap

そのため、以下を使用することが推奨されます。 

Conflicts: (pkgA and pkgB)
Copy to Clipboard Toggle word wrap

if 演算子が or にネストされている場合も同様です。 

Requires: ((pkgA if pkgB) or pkgC or pkg)
Copy to Clipboard Toggle word wrap

pkgB がインストールされていない場合に if が真となるため、用語が完全に真となります。pkgB がインストールされている場合にのみ pkgA が役立つ場合は、代わりに and を使用します。 

Requires: ((pkgA and pkgB) or pkgC or pkg)
Copy to Clipboard Toggle word wrap

6.3. ファイルトリガーのサポート
リンクのコピー

File triggers は RPM スクリプトレット の一種です。

これらはパッケージの SPEC ファイルで定義されます。

Triggers と同様、これらはあるパッケージで宣言されますが、一致するファイルを含む別のパッケージをインストールまたは削除したときに実行されます。

ファイルトリガー の一般的な用途は、レジストリーまたはキャッシュを更新することです。このようなユースケースでは、レジストリーまたはキャッシュを含む、または管理するパッケージにも、単一または複数の ファイルトリガー が含まれている必要があります。ファイルトリガー を含めると、パッケージがそれ自体の更新を制御する場合と比べて時間を短縮できます。

6.3.1. ファイルトリガー構文
リンクのコピー

ファイルトリガー の構文は以下のとおりです。 

%file_trigger_tag [FILE_TRIGGER_OPTIONS] — PATHPREFIX…​
body_of_script
Copy to Clipboard Toggle word wrap

詳細は以下のようになります。

file_trigger_tag は、ファイルトリガーのタイプを定義します。使用可能なタイプは次のとおりです。

  • filetriggerin
  • filetriggerun
  • filetriggerpostun
  • transfiletriggerin
  • transfiletriggerun
  • transfiletriggerpostun

FILE_TRIGGER_OPTIONS は、-P オプションを除き、RPM スクリプトレットオプションと同じ目的で使用されます。

トリガーの優先度は数字で定義されます。この数字が大きいほど、ファイルトリガースクリプトの実行優先度が高くなります。優先度が 100000 を超えるトリガーは、標準のスクリプトレットの前に実行され、その他のトリガーは標準のスクリプトレットの後に実行されます。デフォルトの優先度は 1000000 に設定されています。

各タイプのすべてのファイルトリガーには、1 つ以上のパス接頭辞とスクリプトが含まれている必要があります。

6.3.2. ファイルトリガー構文の例
リンクのコピー

次の例は、File triggers の構文を示しています。 

%filetriggerin — /lib, /lib64, /usr/lib, /usr/lib64
/usr/sbin/ldconfig
Copy to Clipboard Toggle word wrap

このファイルトリガーは、/usr/lib または /lib で始まるパスを含むパッケージのインストール後に、/usr/bin/ldconfig を直接実行します。/usr/lib または /lib で始まるパスを持つ複数のファイルがパッケージに含まれている場合でも、ファイルトリガーは 1 度のみ実行されます。ただし、/usr/lib または /lib で始まるファイル名はすべて、以下のようにスクリプト内でフィルタリングできるように、トリガースクリプトの標準入力に渡されます。 

%filetriggerin — /lib, /lib64, /usr/lib, /usr/lib64
grep "foo" && /usr/sbin/ldconfig
Copy to Clipboard Toggle word wrap

このファイルトリガーは、/usr/lib で始まり、foo を同時に含むファイルがある各パッケージに対して /usr/bin/ldconfig を実行します。接頭辞に一致するファイルには、通常のファイル、ディレクトリー、シンボリックリンクなど、すべての種類のファイルが含まれることに注意してください。

6.3.3. ファイルトリガータイプ
リンクのコピー

ファイルトリガー には、以下の 2 つの主要タイプがあります。

ファイルトリガー は、以下のように、実行時間に基づいてさらに分割されます。

  • パッケージのインストールまたは消去の前または後
  • トランザクションの前または後
6.3.3.1. パッケージファイルトリガーごとの実行
リンクのコピー

パッケージごとに 1 回実行される ファイルトリガー:

  • %filetriggerin
  • %filetriggerun
  • %filetriggerpostun
%filetriggerin

このファイルトリガーは、このトリガーの接頭辞に一致するファイルが 1 つ以上パッケージに含まれている場合にパッケージのインストール後に実行されます。また、これはこのファイルトリガーを含むパッケージのインストール後に実行されます。rpmdb データベースにこのファイルトリガーの接頭辞に一致するファイルが 1 つ以上存在します。

%filetriggerun

このトリガーの接頭辞に一致するファイルが 1 つ以上このパッケージに含まれている場合、このファイルトリガーはパッケージのアンインストールの前に実行されます。また、これはこのファイルトリガーを含むパッケージをアンインストールする前に実行されます。rpmdb には、このファイルトリガーの接頭辞に一致するファイルが 1 つ以上あります。

%filetriggerpostun

このファイルトリガーは、このトリガーの接頭辞に一致するファイルが 1 つ以上含まれている場合に、パッケージのアンインストール後に実行されます。

6.3.3.2. トランザクションファイルトリガーごとに 1 の回実行
リンクのコピー

トランザクションごとに 1 回実行される ファイルトリガー:

  • %transfiletriggerin
  • %transfiletriggerun
  • %transfiletriggerpostun
%transfiletriggerin

このファイルトリガーはトランザクション後に、このトリガーの接頭辞に一致する 1 つ以上のファイルを含むすべてのインストール済みパッケージに対して実行されます。このトランザクションにこのファイルトリガーを含むパッケージがあり、rpmdb にこのトリガーの接頭辞に一致するファイルがつ以上ある場合は、トランザクションの後にも実行されます。

%transfiletriggerun

このファイルトリガーは、以下の条件を満たすすべてのパッケージのトランザクションの前に 1 度だけ実行されます。

  • このトランザクションでパッケージがアンインストールされます。
  • パッケージには、このトリガーの接頭辞に一致する 1 つ以上のファイルが含まれています。

このトランザクションにこのファイルトリガーを含むパッケージがあり、rpmdb にこのトリガーの接頭辞に一致するファイルが 1 つ以上ある場合は、トランザクションの前にも実行されます。

%transfiletriggerpostun

このファイルトリガーは、トランザクション後に、このトリガーの接頭辞に一致する 1 つ以上のファイルを含むすべてのアンインストール済みパッケージに対して実行されます。

注記

このトリガータイプでは、トリガーファイルのリストは利用できません。

そのため、ライブラリーを含む複数のパッケージをインストールまたはアンインストールすると、トランザクション全体の最後で ldconfig キャッシュが更新されます。これにより、キャッシュが各パッケージに対して個別に更新されていた RHEL 7 に比べて、パフォーマンスが大幅に改善されます。また、すべてのパッケージの SPEC ファイルで ldconfig と %postun を呼び出していたスクリプレットが必要ではなくなりました。

6.3.4. glibc でのファイルトリガーの使用例
リンクのコピー

次の例は、glibc パッケージ内での File triggers の実際の使用法を示しています。

RHEL 8 では、インストールまたはアンインストールトランザクションの最後に ldconfig コマンドを呼び出すために、ファイルトリガー が glibc に実装されています。

これは、glibc SPEC ファイルに以下のスクリプトレットを含めることで実現されました。 

%transfiletriggerin common -P 2000000 — /lib /usr/lib /lib64 /usr/lib64
/sbin/ldconfig
%end
%transfiletriggerpostun common -P 2000000 — /lib /usr/lib /lib64 /usr/lib64
/sbin/ldconfig
%end
Copy to Clipboard Toggle word wrap

そのため、複数のパッケージのインストールまたはアンインストールを行うと、トランザクション全体が終了してから、インストールしたすべてのライブラリーに対して ldconfig キャッシュが更新されます。そのため、個別のパッケージの RPM SPEC ファイルに ldconfig を呼び出すスクリプトレットを含める必要はありません。これにより、RHEL 7 に比べてパフォーマンスが改善され、各パッケージに対してキャッシュが別途更新されるようになりました。

6.4. より厳密な SPEC パーサー
リンクのコピー

SPEC パーサーに、いくつかの変更が行われました。したがって、以前は無視されていた新しい問題を特定できます。

6.5. 4 GB を超えるファイルのサポート
リンクのコピー

Red Hat Enterprise Linux 8 では、RPM は 64 ビットの変数とタグを使用できます。これにより、4 GB を超えるファイルやパッケージで動作可能になりました。

6.5.1. 64 ビット RPM タグ
リンクのコピー

64 ビットバージョンとそれ以前の 32 ビットバージョンには、複数の RPM タグがあります。64 ビットバージョンの名前の前には LONG 文字列があることに注意してください。

Expand
表6.4 32 ビットバージョンと 64 ビットバージョンの両方で利用可能な RPM タグ
32 ビットバリアントタグ名62 ビットバリアントタグ名タグ説明

RPMTAG_SIGSIZE

RPMTAG_LONGSIGSIZE

ヘッダーおよび圧縮ペイロードサイズ。

RPMTAG_ARCHIVESIZE

RPMTAG_LONGARCHIVESIZE

非圧縮ペイロードサイズ。

RPMTAG_FILESIZES

RPMTAG_LONGFILESIZES

ファイルサイズの配列。

RPMTAG_SIZE

RPMTAG_LONGSIZE

すべてのファイルサイズの合計。

6.5.2. コマンドラインでの 64 ビットタグの使用
リンクのコピー

LONG 拡張機能は、コマンドラインで常に有効になります。rpm -q --QF コマンドを含むスクリプトを以前使用していた場合は、これらのタグ名に long を追加できます。 

rpm -qp --qf="[%{filenames} %{longfilesizes}\n]"
Copy to Clipboard Toggle word wrap

6.6. その他の機能
リンクのコピー

Red Hat Enterprise Linux 8 の 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 ベースのすべてのディストリビューションに役に立ちます。

法律上の通知
リンクのコピー

Copyright © 2025 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2026 Red Hat