検索

4.2. spec ファイルについて

download PDF

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

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

4.2.1. Preamble 項目

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

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

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

rpm コマンドを使用して 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 パッケージは例外です。

4.2.2. Body 項目

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

表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 ファイルには、ScriptletsTriggers などの高度な項目を含めることができます。

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

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.