第6章 ソフトウェアのパッケージ化


RPM パッケージマネージャーを使ったパッケージングプロセスの基本を学びましょう。

6.1. spec ファイルについて

spec ファイルは、rpmbuild ユーティリティーが RPM パッケージをビルドするために使用する指示が記述されたファイルです。

仕様 ファイルは、一連のセクションで手順を定義することにより、ビルドシステムに必要な情報を提供する。これらのセクションは、spec ファイルの Preamble 部分と Body 部分で定義されます。

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

6.1.1. spec ファイルの Preamble の項目

RPM 仕様 ファイルの Preamble セクションで、以下の指示を使用してください。

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

Name

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

Version

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

Release

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

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

Summary

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

License

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

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

URL

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

Source

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

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

Patch

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

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

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

6.1.2. spec ファイルの Body の項目

RPM 仕様 ファイルの 本文 セクションで、以下の指示を使用してください。

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

%description

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

%prep

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

%conf

ビルド用にソフトウェアを設定するための 1 つまたは一連のコマンド。

%build

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

%install

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

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

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

%check

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

%files

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

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

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

%changelog

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

6.1.3. spec ファイルの高度な項目

仕様 ファイルには、スクリプトレット、ファイルトリガー、トリガーなどの高度な項目を含めることができます。これらのディレクティブは、spec ファイルに影響するだけでなく、RPM からの情報を使用してシステムを更新することにより、結果として生成される RPM がインストールされるターゲットオペレーティングシステムにも影響します。

スクリプトレット、ファイルトリガー、およびトリガーは、ビルドプロセスではなく、ターゲットシステムへのインストールプロセスのさまざまな段階で有効になります。

  • スクリプトレットは、パッケージがインストールまたは削除される前または後に無条件に実行されます。
  • トリガーは、指定されたトリガー条件が、インストール済みのシステム上またはトランザクション内の他のパッケージと一致した場合に、条件付きで実行されます。
  • ファイルトリガーは、指定されたパス接頭辞が、インストール先のシステム上またはトランザクション内の他のファイルと一致した場合に、条件付きで実行されます。

6.1.3.1. スクリプトレットのディレクティブ

スクリプトレットは、パッケージのライフサイクルに関連する、あらかじめ決められたタイミング (パッケージのインストールや削除の前後など) で実行される任意のプログラムです。スクリプトレットは、ビルド時または起動スクリプトでは実行できないタスクにのみ使用してください。

デフォルトでは、スクリプトレットは、spec ファイル内のさまざまな %pre または %post ディレクティブによって宣言される短いシェルスクリプトです。

一般的なスクリプトレットのディレクティブは、%build%install などの spec ファイルのセクションヘッダーに似ています。複数行のコードのまとまりとして定義され、多くの場合、標準の POSIX シェルスクリプトとして記述されます。ただし、ターゲットマシンのディストリビューションの RPM が対応している他のプログラミング言語で記述することもできます。

6.1.3.2. スクリプトレットのディレクティブの実行順序

パッケージのアップグレード中にスクリプトレットが実行される順序を確認してください。

Expand
表6.3 スクリプトレットのディレクティブ
ディレクティブ説明

%pretrans

%pretrans スクリプトレットは、パッケージをインストールまたは削除する前に実行されます。

%pre

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

%post

%post スクリプトレットは、パッケージがターゲットシステムにインストールされた後に実行されます。

%preun

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

%postun

%postun スクリプトレットは、パッケージがターゲットシステムからアンインストールされた後に実行されます。

%posttrans

%posttrans スクリプトレットは、トランザクションの終了時に実行されます。

6.1.3.3. スクリプトレットの実行をオフにする

スクリプトレット名に --no オプションを指定することで、任意のスクリプトレットの実行を無効にできます。

--noscripts オプションを使用することもできます。これは、次のすべてのスクリプトレットの実行をオフにするのと同じです。

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

詳細は、システム上の rpm man ページを参照してください。

手順

  • スクリプトレットの実行をオフにします。

    # rpm --no<scriptlet_name>

    たとえば、%pretrans スクリプトレットの実行をオフにするには、次のように入力します。

    # rpm --nopretrans

6.1.3.4. スクリプトレットのマクロの例

以下は、spec ファイル内のスクリプトレットに使用できるマクロの例です。これらのマクロは、systemd-rpm-macros パッケージによって提供される実際のマクロです。これらのマクロは、systemd 関連の処理をパッケージ化するために使用できます。同様の原則を他のパッケージに適用することもできます。

systemd ユニットファイルを含むパッケージは、systemd サービスを適切に処理するために、スクリプトレットを使用する必要があります。systemd パッケージは、systemd のスクリプトレット操作を処理するための一連のマクロを提供しています。以下に例を示します。

%post
%systemd_post httpd.service

%preun
%systemd_preun httpd.service

これらのマクロはパッケージ内で次のように展開されます。

$ rpm --eval "%systemd_preun httpd.service"
if [ $1 -eq 0 ] && [ -x "/usr/lib/systemd/systemd-update-helper" ]; then
    # Package removal, not upgrade
    /usr/lib/systemd/systemd-update-helper remove-system-units httpd.service || :
fi
注記

マクロの動作は変更される可能性があります。たとえば、マクロの動作はパッケージの開発に応じて変更される可能性があります。

6.1.4. Epoch ディレクティブ

Version spec ファイルディレクティブを設定するだけではパッケージのバージョンを比較できない場合は、Epoch ディレクティブを使用できます。たとえば、Epoch を 使用すると、上流でのバージョン番号付け方式の変更が互換性のない方法で行われたために発生したアップグレードパスの問題を解決できます。

Epoch は数値フィールドです。Epoch に値を割り当てると、パッケージのバージョンを比較するときに RPM が使用する修飾子が追加されます。spec ファイルに Epoch ディレクティブが記載されていないことは、Epoch が未設定であることを意味します。これは、Epoch を設定しないと Epoch0 になる、という一般的な認識とは異なります。ただし、処理上の理由から、RPM は Epoch が未設定であっても、Epoch0 に設定されている場合と同じように扱います。その逆も同様です。

重要

通常、spec ファイル内での Epoch の使用は省略されます。これは、ほとんどの場合、Epoch 値を導入すると、パッケージのバージョンを比較するときに RPM の動作が予想と異なるものになるためです。したがって、Epoch の使用は最後の手段として検討してください。

たとえば、Epoch: 1 および Version: 1.0foobar パッケージをインストールしたとします。このとき、別のパッケージ作成者が、Epoch ディレクティブを指定せずに、foobarVersion: 2.0 でパッケージ化したとします。この場合、この新しいバージョンが更新版とみなされることは決してありません。RPM パッケージのバージョン管理を表す従来の Name-Version-Release マーカーよりも、Epoch のバージョンが優先されるためです。

6.1.5. パッケージのバージョン管理の基本

パッケージの説明の基本的な要素は、spec ファイルのディレクティブである NameVersion、および Release (NVR) で定義されている情報です。RPM はこの情報を使用してパッケージのバージョンを比較し、パッケージの依存関係を追跡します。

RPM を扱っていると、EVR (epoch-version-release)NEVR (name-epoch-version-release)、NEVRA (name-epoch-version-release-architecture) という表記を目にすることもあるでしょう。EVR は、RPM が比較の際に常に使用するパッケージの完全なバージョン情報です。RPM は、最初のコンポーネントから 1 つずつコンポーネントを比較します。RPM は、コンポーネントの違いを検出すると比較を停止します。たとえば、Epoch が異なる場合、RPM は残りの EVR コンポーネントを比較しません。

RPM データベースを照会することで、特定のパッケージの NVR 情報を表示できます。次に例を示します。

# rpm -q bash
bash-4.4.19-7.el8.x86_64

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

注記

rpm -q コマンドは、NEVRA 形式のパッケージ情報をデフォルトで表示します。

Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2026 Red Hat
トップに戻る