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

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 ディレクティブを指定すると、次の要因に応じて更新の動作が変わります。

Provides

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

%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 セクションでのビルド手順の変更など、パッケージの変更を記録します。