第3章 ソフトウェアのパッケージ化
3.1. RPM パッケージ
このセクションでは、RPM パッケージ形式の基本を説明します。
3.1.1. RPM とは
RPM パッケージは、他のファイルとそのメタデータ (システムが必要とするファイルに関する情報) を含むファイルです。
特に、RPM パッケージは cpio
アーカイブで構成されています。
cpio
アーカイブには以下が含まれます。
- ファイル
RPM ヘッダー (パッケージのメタデータ)
rpm
パッケージマネージャーはこのメタデータを使用して依存関係、ファイルのインストール先、およびその他の情報を決定します。
RPM パッケージの種類
RPM パッケージには 2 つの種類があります。いずれも、同じファイル形式とツールを使用しますが、コンテンツが異なるため、目的が異なります。
ソース RPM (SRPM)
SRPM には、ソースコードと SPEC ファイルが含まれます。これには、ソースコードをバイナリー RPM にビルドする方法が書かれています。必要に応じて、ソースコードへのパッチも含まれます。
バイナリー RPM
バイナリー RPM には、ソースおよびパッチから構築されたバイナリーが含まれます。
3.1.2. RPM パッケージ化ツールのユーティリティーの一覧表示
以下の手順では、rpmdevtools
パッケージが提供するユーティリティーの一覧を表示する方法を示しています。
前提条件
RPM パッケージ化ツールを使用できるようにするには、rpmdevtools
パッケージをインストールする必要があります。
# yum install rpmdevtools
手順
RPM パッケージ化ツールのユーティリティーを一覧表示します。
$ rpm -ql rpmdevtools | grep bin
関連情報
- 上記のユーティリティーの詳細は、各マニュアルページまたはヘルプダイアログを参照してください。
3.1.3. RPM パッケージ化を行うためのワークスペースの設定
本セクションでは、rpmdev-setuptree
ユーティリティーを使用して、RPM のパッケージ化ワークスペースとなるディレクトリーレイアウトを設定する方法を説明します。
前提条件
rpmdevtools
パッケージがシステムにインストールされている。
# yum install rpmdevtools
手順
-
rpmdev-setuptree
ユーティリティーを実行します。
$ rpmdev-setuptree $ tree ~/rpmbuild/ /home/<username>/rpmbuild/ |-- BUILD |-- RPMS |-- SOURCES |-- SPECS `-- SRPMS 5 directories, 0 files
作成されたディレクトリーは、以下の目的で使用します。
ディレクトリー | 目的 |
BUILD |
パッケージを構築すると、ここにさまざまな |
RPMS |
バイナリー RPM は、さまざまなアーキテクチャーのサブディレクトリー (例: |
SOURCES |
ここでは、このパッケージャーは、圧縮したソースコードアーカイブとパッチを配置します。 |
SPECS | パッケージャーは、SPEC ファイルをここに配置します。 |
SRPMS |
|
3.1.4. SPEC ファイルの概要
SPEC ファイルには、RPM を構築するのに rpmbuild
ユーティリティーが使用するレシピが含まれています。SPEC ファイルは、一連のセクションで命令を定義することで、ビルドシステムに必要な情報を提供します。このセクションは、Preamble と Body で定義されます。Preamble では、Body に使用されている一連のメタデータ項目が含まれています。Body は、命令の主要部分を示しています。
3.1.4.1. Preamble 項目
以下の表では、RPM SPEC ファイルの Preamble セクションで頻繁に使用されるディレクティブの一部を示しています。
表3.1 RPM SPEC ファイルの Preamble
セクションで使用される項目
SPEC ディレクティブ | 定義 |
---|---|
| SPEC ファイル名と一致する必要があるパッケージのベース名。 |
| ソフトウェアのアップストリームのバージョン番号。 |
|
このバージョンのソフトウェアがリリースされた回数。通常、初期値は 1%{?dist} に設定し、パッケージの新規リリースごとに増加させます。新しい |
| パッケージの 1 行の概要 |
| パッケージ化しているソフトウェアのライセンス。 |
| プログラムに関する詳細情報の完全な URL。多くの場合、この URL は、パッケージ化しているソフトウェアのアップストリームプロジェクトの Web サイトです。 |
| アップストリームのソースコードの圧縮アーカイブへのパスまたは URL (パッチを適用していないものや、パッチは別の場所で処理されます)。これは、たとえば、パッケージャーのローカルストレージではなく、アップストリームページなどのアーカイブの、アクセス可能で信頼できるストレージを参照している必要があります。必要に応じて、その他の SourceX ディレクティブを追加することができます。たとえば、Source1、Source2、Source3 など、その都度に数を増やすことができます。 |
| 必要に応じて、ソースコードに適用する最初のパッチの名前。 ディレクティブは、パッチの末尾に数字を付けて、または付けずに適用できます。 数値を指定しないと、内部的にエントリーに割り当てられます。Patch0、Patch1、Patch2、Patch3 などを使用して、明示的に数字を指定することもできます。 このパッチは、%patch0、%patch1、%patch2 といったマクロを使用して、1 つずつ適用できます。マクロは、RPM SPEC ファイルの Body セクションの %prep ディレクティブ内で適用されます。または、%autounconfined マクロを使用できます。これは、SPEC ファイルに指定されている順序ですべてのパッチを自動的に適用します。 |
|
パッケージがアーキテクチャーに依存していない場合は (たとえば、インタープリター型のプログラミング言語ですべて書かれた場合など)、これを |
|
コンパイル言語で書かれたプログラムを構築するのに必要なコンマ区切りまたは空白区切りのリスト。 |
|
インストール後のソフトウェアの実行に必要なパッケージのコンマ区切りまたは空白区切りのリスト。 |
| ソフトウェアの一部が特定のプロセッサーアーキテクチャーで動作しない場合には、そのアーキテクチャーを除外できます。 |
|
|
|
このディレクティブでは、 |
|
|
Name
、Version
および Release
ディレクティブは、RPM パッケージのファイル名で構成されます。RPM パッケージの担当者やシステム管理者は、これら 3 つのディレクティブを N-V-R または NVR と呼びます。これは、RPM パッケージのファイル名に NAME-VERSION-RELEASE
形式が含まれるためです。
以下の例は、rpm
コマンドを実行して、特定のパッケージの NVR 情報を取得する方法を示しています。
例3.1 bash パッケージの NVR 情報を出力する rpm のクエリー
# rpm -q bash bash-4.4.19-7.el8.x86_64
ここでは、bash
はパッケージ名、4.4.19
はバージョン番号、7.el8
はリリースを指します。最後のマーカーの x86_64
は、アーキテクチャーを意味しています。NVR とは異なり、アーキテクチャーのマーカーは RPM パッケージャーで直接管理されていませんが、rpmbuild
ビルド環境で定義されます。ただし、これはアーキテクチャーに依存しない noarch
パッケージです。
3.1.4.2. Body 項目
RPM SPEC ファイルの Body section
の項目を以下の表に一覧表示します。
表3.2 RPM SPEC ファイルの Body セクションで使用される項目
SPEC ディレクティブ | 定義 |
---|---|
| RPM でパッケージ化されているソフトウェアの完全な説明。この説明は、複数の行や、複数の段落にまでわたることがあります。 |
|
|
| ソフトウェアをマシンコード (コンパイル言語用) またはバイトコード (インタープリター言語) に構築するための 1 つまたは一連のコマンド。 |
|
|
| ソフトウェアをテストする単一または一連のコマンド。これには通常、ユニットテストなどが含まれます。 |
| エンドユーザーのシステムにインストールされるファイルの一覧。 |
|
異なる |
3.1.4.3. 高度な項目
SPEC ファイルには、Scriptlets や Triggers などの高度な項目を追加することもできます。これは、ビルドプロセスではなく、エンドユーザーのシステムのインストールプロセスのさまざまな地点で有効になります。
3.1.5. BuildRoots
RPM パッケージングのコンテキストでは、buildroot
が chroot 環境となります。つまり、ビルドのアーティファクトが、エンドユーザーシステムの今後の階層と同じファイルシステム階層を使用して配置され、buildroot
がルートディレクトリーとして機能します。ビルドアーティファクトの配置は、エンドユーザーシステムのファイルシステム階層の基準に準拠する必要があります。
buildroot
のファイルは、後で cpio
アーカイブに配置され、RPM の主要部分になります。RPM がエンドユーザーのシステムにインストールされている場合、これらのファイルは root
ディレクトリーに抽出され、階層が正しく保持されます。
6 以降では、rpmbuild
プログラムには独自のデフォルトが設定されています。このデフォルト値を上書きすると、問題が発生することがあります。{RH} では、このマクロの値を自身で定義することを推奨していません。%{buildroot}
マクロは、rpmbuild
ディレクトリーのデフォルト値と使用できます。
3.1.6. RPM マクロ
rpm マクロ は、特定の組み込み機能が使用されている場合に、ステートメントのオプションの評価に基づいて、条件付きで割り当てられる直接的なテキスト置換です。したがって、RPM は、ユーザーに変わってテキストの置換を行うことができます。
使用例では、SPEC ファイルでパッケージ化されたソフトウェアの Version を複数回参照しています。%{version} マクロで 1 回だけ %{version}
を定義し、SPEC ファイル全体でこのマクロを使用します。すべては、以前に定義した Version に自動的に置き換えられます。
見たことのないマクロが表示されている場合は、次のコマンドを使用してマクロを評価できます。
$ rpm --eval %{_MACRO}
%{_bindir} マクロおよび %{_libexecdir} マクロの評価
$ rpm --eval %{_bindir} /usr/bin $ rpm --eval %{_libexecdir} /usr/libexec
一般的に使用されるマクロには、%{?dist}
マクロがあります。これは、ビルドに使用されるディストリビューション (ディストリビューションタグ) を示します。
# On a RHEL 8.x machine $ rpm --eval %{?dist} .el8
3.2. SPEC ファイルでの作業
このセクションでは、SPEC ファイルを作成して変更する方法を説明します。
前提条件
このセクションでは、「ソースコードの例」 の Hello World!
プログラムを実装した 3 つの例を使用します。
各プログラムは、以下の表で詳細に説明しています。
ソフトウェアの名前 | 例の説明 |
bello | raw インタープリタープログラミング言語で書かれたプログラム。ソースコードを構築する必要はなく、インストールのみが必要である場合を示しています。事前にコンパイル済みのバイナリーをパッケージ化する必要がある場合、バイナリーは単なるファイルであるため、この方法を使用することもできます。 |
pello | バイトコンパイルインタプリタ-プログラム言語で書かれたプログラム。これは、ソースコードのバイトコンパイルと、生成される事前処理ファイルのバイトコードのインストールを示しています。 |
cello | ネイティブコンパイル言語で書かれたプログラム。これは、ソースコードをマシンコードにコンパイルし、生成される実行ファイルをインストールする一般的なプロセスを示しています。 |
Hello World!
の実装は次のとおりです。
前提条件として、これらの実装は、~/rpmbuild/SOURCES
ディレクトリーに置く必要があります。
3.2.1. 新しい SPEC ファイルを作成する方法
新しいソフトウェアをパッケージ化するには、新しい SPEC ファイルを作成する必要があります。
これをアーカイブするには、2 つの方法があります。
- 手動による SPEC ファイルの新規作成
rpmdev-newspec
ユーティリティーを使用します。このユーティリティーは、空の SPEC ファイルを作成し、必要なディレクティブとフィールドを入力します。
プログラマーに焦点を合わせたテキストエディターの中には、独自の SPEC テンプレートで新しい .spec
ファイルを事前に準備しているものもあります。rpmdev-newspec
ユーティリティーでは、エディターに依存しないアプローチを利用できます。
3.2.2. rpmdev-newspec を使用した新規 SPEC ファイルの作成
以下の手順は、rpmdev-newspec
ユーティリティーを使用して、上記の 3 つの Hello World!
プログラムごとに SPEC ファイルを作成する方法を示しています。
手順
~/rpmbuild/SPECS
ディレクトリーに移動し、rpmdev-newspec
ユーティリティーを使用します。$ cd ~/rpmbuild/SPECS $ 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 pello pello.spec created; type minimal, rpm version >= 4.11.
~/rpmbuild/SPECS/
ディレクトリーには、bello.spec
、cello.spec
およびpello.spec
の 3 つの SPEC ファイルが含まれるようになりました。
fd。ファイルを調べます。
+
rpmdev-newspec
ユーティリティーは、特定の Linux ディストリビューションに固有のガイドラインや規則を使用しません。ただし、本ドキュメントは Red Hat Enterprise Linux を対象にしているので、SPEC ファイル全体にわたり定義または指定したその他のすべてのマクロとの一貫性を確立するために、RPM のビルドルートを参照する場合には、%{buildroot}
において $RPM_BUILD_ROOT
の記述が推奨されます。
3.2.3. RPM を作成するための、元の SPEC ファイルの変更
以下の手順では、RPM を作成する rpmdev-newspec
による SPEC 出力ファイルを修正する方法を示しています。
前提条件
以下の点を確認してください。
-
特定のプログラムのソースコードが、
~/rpmbuild/SOURCES/
ディレクトリーに置かれている。 -
データが投入されていない SPEC ファイル (
~/rpmbuild/SPECS/<name>.spec
) がrpmdev-newspec
ユーティリティーで作成されている。
手順
-
rpmdev-newspec
ユーティリティーが提供する~/rpmbuild/SPECS/<name>.spec
ファイルの出力テンプレートを開きます。 SPEC ファイルの最初のセクションを作成します。
最初のセクションには、
rpmdev-newspec
がグループ化される以下のディレクティブが含まれます。-
Name
-
Version
-
Release
Summary
Name
にはすでに、rpmdev-newspec
の引数として指定されています。Version
は、ソースコードのアップストリームのリリースバージョンと一致するように設定します。Release
は自動的に1%{?dist}
され、最初は1
です。パスを含めるなど、アップストリームのリリースのVersion
を変更せずにパッケージを更新する場合は初期値を増加させます。新しいアップストリームがリリースされた場合には、Release
は1
にリセットされます。Summary
は 1 行の短い説明です。
-
License
、URL
およびSource0
ディレクティブに入力します。License
フィールドは、アップストリームリリースのソースコードに関連するソフトウェアライセンスです。SPEC ファイルでLicense
にラベルを付ける方法は、使用する RPM ベースの特定の Linux ディストリビューションガイドラインによって異なります。たとえば、GPLv3+ を使用できます。
URL
フィールドは、アップストリームのソフトウェア Web サイトへの URL を指定します。一貫性を保つために、%{name}
の RPM マクロ変数を利用して、https://example.com/%{name}
を使用します。Source0
フィールドは、アップストリームのソフトウェアソースコードへの URL を指定します。これは、パッケージ化している特定のバージョンのソフトウェアに直接リンクする必要があります。本ドキュメントの URL の例には、将来変更される可能性があるハードコーディングした値が含まれています。同様に、リリースのバージョンも変更される可能性があります。今後の変更を簡素化するには、%{name}
および%{version}
マクロを使用します。これらを使用して、SPEC ファイルの 1 つのフィールドのみを更新する必要があります。BuildRequires
Requires
およびBuildArch
ディレクティブに入力します。BuildRequires
は、パッケージのビルドタイム依存関係を指定します。Requires
は、パッケージのランタイム依存関係を指定します。これは、ネイティブにコンパイルされた拡張機能がない、インタープリター型プログラミング言語で書かれたソフトウェアです。したがって、
BuildArch
のディレクティブにnoarch
の値を指定して追加します。これは、このパッケージを構築するプロセッサーアーキテクチャーに制限する必要がないことを RPM に指定します。%description
、%prep
、%build
、%install
、%files
および%license
ディレクティブに入力します。これらのディレクティブは、マルチライン、マルチインストラクション、または実行するスクリプト処理タスクを定義することができるため、セクションの見出しと考えることができます。
%description
は、ソフトウェアの完全な説明でSummary
よりも長く、1 つ以上の段落が含まれています。%prep
セクションでは、ビルド環境の準備方法を指定します。通常、これには、ソースコードの圧縮アーカイブの展開、パッチの適用、および SPEC ファイルの後半で使用するためにソースコードでによる情報の解析が含まれます。このセクションでは、ビルトインの%setup -q
マクロを使用できます。%build
セクション では、ソフトウェアを構築する方法を指定します。%install
セクションには、ソフトウェアを構築してからBUILDROOT
ディレクトリーにソフトウェアをインストールする手順に関するrpmbuild
の説明が記載されています。このディレクトリーは空の chroot ベースディレクトリーで、エンドユーザーの root ディレクトリーに似ています。ここでは、インストールしたファイルを格納するディレクトリーを作成できます。このようなディレクトリーを作成するには、パスをハードコードせずに RPM マクロを使用します。
%files
セクションは、この RPM によるファイルのリストと、エンドユーザーシステム上のファイルの完全なパス場所を指定します。このセクションでは、組み込みのマクロを使用して、さまざまなファイルの役割を示すことができます。これは、command[]
rpm
コマンドを使用したパッケージファイルマニフェストのメタデータの照会に役立ちます。たとえば、LICENSE ファイルがソフトウェアライセンスファイルであることを示すには、%license
マクロを使用します。最後のセクションの
%changelog
は、パッケージの各 Version-Release に対する日付入りのエントリーの一覧です。これらは、ソフトウェアの変更ではなく、パッケージの変更を記録します。パッケージ変更の例: パッチの追加、%build
セクションのビルド手順の変更。最初の行は、以下の形式に従います。
*
文字で始め、その後にDay-of-Week Month Day Year Name Surname <email> - Version-Release
を指定します。実際の変更エントリーには、以下の形式に従います。
- 各変更エントリーには、変更ごとに複数の項目を含めることができます。
- 各項目は新しい行で始まります。
-
各項目は
-
文字で始まります。
これで、必要なプログラム用に SPEC ファイル全体を作成できるようになりました。
異なるプログラミング言語で書かれた SPEC ファイルの例は、以下を参照してください。
3.2.4. bash で書かれたプログラム用の SPEC ファイルサンプル
このセクションでは、bash 書かれた bello プログラムの SPEC ファイルの例を示しています。bello の詳細は「ソースコードの例」を参照してください。
bash で記載された bello の SPEC ファイルの例
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 %setup -q %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
bello
のビルドステップがないため、パッケージのビルドタイム依存関係を指定する BuildRequires
ディレクティブが削除されました。bash は、raw インタープリタープログラミング言語で、ファイルはシステム上のその場所にインストールされます。
パッケージのランタイム依存関係を指定する Requires
ディレクティブは、bash
のみを含めます。これは、bello
スクリプトを実行するには bash
シェル環境のみが必要なためです。
bash
はビルド不要のため、ソフトウェアの構築方法を示す %build
セクションは空白です。
bello
をインストールする場合は、インストール先のディレクトリーを作成し、そこに実行可能な bash
スクリプトファイルをインストールする必要があります。したがって、%install
セクションで install
コマンドを使用できます。RPM マクロを使用すると、パスをハードコーディングせずにこれを実行できます。
3.2.5. Python で書かれたプログラムの SPEC ファイルサンプル
このセクションでは、Python プログラミング言語で書かれた pello プログラムの SPEC ファイルの例を示します。pello の詳細は「ソースコードの例」を参照してください。
Python で書かれた pello プログラムの SPEC ファイルサンプル
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
pello バイトコンパイルインタープリター言語で書かれたプログラムです。よって、生成されるファイルにはエントリーが含まれていないため、シバンは使いません。
シバンは使わないため、以下のアプローチのいずれかを適用する必要があります。
- 実行ファイルを呼び出す、バイトコンパイル以外のシェルスクリプトを作成します。
- プログラムの実行にエントリーポイントとしてバイトコンパイルされない小規模の Python コードを提供します。
これらのアプローチは特に、事前にコンパイルされたコードのパフォーマンス向上が大きい、数千行ものコードを含む大規模ソフトウェアプロジェクトに便利です。
パッケージのビルドタイム依存関係を指定する BuildRequires
ディレクティブには、以下の 2 つのパッケージが含まれます。
-
python
パッケージが、バイトコンパイルのビルドプロセスを実行する必要がある。 -
小規模なエントリーポイントスクリプトを実行するには、
bash
パッケージが必要。
パッケージのランタイム依存関係を指定する Requires
ディレクティブには、python
パッケージのみが含まれます。pello
プログラムは、実行時にバイトコンパイルコードを実行するために python
パッケージを必要とします。
%build
セクションは、ソフトウェアを構築する方法を指定します。つまり、ソフトウェアがバイトコンパイルされるということになります。
pello
をインストールするには、ラッパースクリプトを作成する必要があります。これは、シバンがバイトコンパイル言語で該当しないためです。これを行うには、以下のような複数のオプションを利用できます。
-
個別のスクリプトを作成し、それを個別の
SourceX
ディレクティブとして使用します。 - SPEC ファイルにファイルをインラインで作成。
この例では、SPEC ファイルにラッパースクリプトのインラインを作成し、SPEC ファイル自体がスクリプト可能であるこを示しています。このラッパースクリプトは、こちら
のドキュメントを使用して Python バイトコンパイルコードを実行します。
この例の %install
セクションは、アクセスできるように、バイトコンパイルファイルをシステム上のライブラリーディレクトリーにインストールする必要があるという事実に一致します。
3.2.6. C で書かれたプログラムの SPEC ファイルサンプル
このセクションでは、C プログラミング言語で書かれた cello プログラム用の SPEC ファイルの例を示します。cello の詳細は「ソースコードの例」を参照してください。
C 言語で書かれた cello の SPEC ファイルの例
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-output-first-patch.patch BuildRequires: gcc BuildRequires: make %description The long-tail description for our Hello World Example implemented in C. %prep %setup -q %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
パッケージのビルド時依存関係を指定する BuildRequires
ディレクティブには、コンパイルビルドプロセスを実行するために必要な 2 つのパッケージが含まれます。
-
gcc
パッケージ -
make
パッケージ
この例では、パッケージにランタイム依存関係を指定する Requires
ディレクティブは省略されています。すべてのランタイム要件は rpmbuild
により処理されます。cello
プログラムはコア C 標準ライブラリー以外のものは必要としません。
%build
セクションは、この例では、cello プログラムの Makefile
が書かれているため、rpmdev-newspec
ユーティリティーによる GNU make コマンドを使用できます。ただし、設定スクリプトを指定していないため、%configure
に対する呼び出しを削除する必要があります。
cello プログラムのインストールは、rpmdev-newspec
コマンドによる %make_install
マクロを使用して実行できます。これは、cello プログラムの Makefile
が利用できるため可能です。
3.3. RPM のビルド
本セクションでは、プログラム用の SPEC ファイルを作成した後に RPM を構築する方法を説明します。
RPM は、rpmbuild
コマンドで構築されます。このコマンドは、特定のディレクトリーと rpmdev-setuptree
ユーティリティーで設定された構造と同じファイル構造を想定します。
rpmbuild
コマンドでは、ユースケースや期待する結果によって組み合わせる引数が異なります。本セクションでは、主なユースケースを 2 つ説明します。
- ソース RPM のビルド
- バイナリー RPM のビルド
3.3.1. ソース RPM のビルド
この段落は、手順モジュールの紹介 (手順の簡単な説明) です。
前提条件
パッケージ化するプログラムの SPEC ファイルが既に存在している必要があります。SPEC ファイルの作成方法は「SPEC ファイルでの作業」を参照してください。
手順
次の手順では、ソース RPM のビルド方法を説明します。
指定の SPEC ファイルを使用して
rpmbuild
コマンドを実行します。$ rpmbuild -bs SPECFILE
SPECFILE を SPEC ファイルに置き換えます。
-bs
オプションは、ビルドソースを表します。
以下の例は、bello
、pello
、cello
プロジェクトのソース RPM のビルドを示しています。
bello、pello、および cello のソース RPM のビルド。
$ cd ~/rpmbuild/SPECS/ 8$ rpmbuild -bs bello.spec Wrote: /home/<username>/rpmbuild/SRPMS/bello-0.1-1.el8.src.rpm $ rpmbuild -bs pello.spec Wrote: /home/<username>/rpmbuild/SRPMS/pello-0.1.2-1.el8.src.rpm $ rpmbuild -bs cello.spec Wrote: /home/<username>/rpmbuild/SRPMS/cello-1.0-1.el8.src.rpm
検証手順
-
生成されたソース RPM が
rpmbuild/SRPMS
ディレクトリーに含まれていることを確認してください。ディレクトリーは、rpmbuild
で必要な構造の一部です。
3.3.2. バイナリー RPM のビルド
バイナリー RPM のビルドには、以下の方法を使用できます。
- ソース RPM からのバイナリー RPM の再ビルド
- SPEC ファイルからのバイナリー RPM のビルド
- ソース RPM からのバイナリー RPM のビルド
3.3.2.1. ソース RPM からのバイナリー RPM の再ビルド
以下の手順は、ソース RPM (SRPM) からバイナリー RPM を再構築する方法を示しています。
手順
SRPM から
cello
、bello
およびpello
を再構築するには、以下を実行します。$ rpmbuild --rebuild ~/rpmbuild/SRPMS/bello-0.1-1.el8.src.rpm [output truncated] $ rpmbuild --rebuild ~/rpmbuild/SRPMS/pello-0.1.2-1.el8.src.rpm [output truncated] $ rpmbuild --rebuild ~/rpmbuild/SRPMS/cello-1.0-1.el8.src.rpm [output truncated]
rpmbuild --rebuild
を呼び出すには、以下を行います。
-
SRPM の内容 (SPEC ファイルおよびソースコード) の
~/rpmbuild/
ディレクトリーへのインストール。 - インストール済みコンテンツを使用したビルド。
- SPEC ファイルとソースコードの削除
SPEC ファイルとソースコードをビルド後も維持するには、以下を行います。
-
ビルド時には、
--rebuild
オプションの代わりに--recompile
オプションを指定してrpmbuild
コマンドを実行します。 以下のコマンドを使用して 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/pello-0.1.2-1.el8.src.rpm Updating / installing… …1:pello-0.1.2-1.el8 [100%] $ rpm -Uvh ~/rpmbuild/SRPMS/cello-1.0-1.el8.src.rpm Updating / installing… …1:cello-1.0-1.el8 [100%]
バイナリー RPM の作成時に生成される出力は詳細なもので、これはデバッグに役立ちます。この出力は各種例によって異なり、SPEC ファイルに一致します。
生成されるバイナリー RPM は、YOURARCH
がアーキテクチャーとなる ~/rpmbuild/RPMS/YOURARCH
ディレクトリーか、パッケージがアーキテクチャー固有でない場合には、~/rpmbuild/RPMS/noarch/
ディレクトリーにあります。
3.3.2.2. SPEC ファイルからのバイナリー RPM のビルド
以下の手順では、SPEC ファイルから bello
、pello
、および cello
バイナリー RPM を構築する方法を説明します。
手順
bb
オプションを指定してrpmbuild
コマンドを実行します。$ rpmbuild -bb ~/rpmbuild/SPECS/bello.spec $ rpmbuild -bb ~/rpmbuild/SPECS/pello.spec $ rpmbuild -bb ~/rpmbuild/SPECS/cello.spec
3.3.2.3. ソース RPM からの RPM のビルド
ソース RPM からあらゆる種類の RPM をビルドすることもできます。これを行うには、以下の手順を行います。
手順
以下のオプションのいずれかと、ソースパッケージを指定して、
rpmbuild
コマンドを実行します。# rpmbuild {-ra|-rb|-rp|-rc|-ri|-rl|-rs} [rpmbuild-options] SOURCEPACKAGE
関連情報
ソース RPM から RPM を構築する方法は、rpmbuild(8)
man ページの BUILDING PACKAGES
セクションを参照してください。
3.4. RPM のサニティーチェック
パッケージを作成したら、パッケージの品質を確認します。
パッケージの品質をチェックする主要なツールは、rpmlint です。
rpmlint
ツールは、以下を行います。
- RPM の保守性の向上。
- RPM の静的な分析の実行によるサニティーチェック。
- RPM の静的な分析の実行による、エラーチェック。
rpmlint
ツールはバイナリー RPM、ソース RPM (SRPMS) 、SPEC ファイルをチェックできるため、以下の例で示すように、パッケージ化の全段階で役に立ちます。
rpmlint
には非常に厳密なガイドラインがあるため、以下の例にあるように、一部のエラーや警告をスキップできる場合もあることに注意してください。
以下の例では、rpmlint
はオプションを指定せずに実行し、詳細でない出力を生成します。それぞれのエラーや警告の詳細な説明は、rpmlint -i
を実行してください。
3.4.1. bello によるサニティーチェック
本セクションでは、bello SPEC ファイルおよび bello バイナリー RPM の例で RPM のサニティーチェックを行う際に発生する可能性のある警告およびエラーを示します。
3.4.1.1. bello の SPEC ファイルのチェック
例3.2 bello の SPEC ファイルでの rpmlint
コマンド実行の出力
$ rpmlint bello.spec bello.spec: W: invalid-url Source0: https://www.example.com/bello/releases/bello-0.1.tar.gz HTTP Error 404: Not Found 0 packages and 1 specfiles checked; 0 errors, 1 warnings.
bello.spec
には、Source0
ディレクティブに一覧表示される URL に到達できないことを示す警告が 1 つのみあります。指定した example.com
URL は存在しないため、この出力は当然です。今後、この URL が機能すると仮定して、この警告を無視します。
例3.3 cello の 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.
bello
SRPM については、URL
ディレクティブで指定された URL に到達できないことを示す新しい警告が表示されます。今後、リンクが機能すると仮定して、この警告を無視します。
3.4.1.2. bello バイナリー RPM の確認
バイナリー RPM をチェックする場合には、rpmlint
は以下の項目をチェックします。
- Documentation
- man ページ
- ファイルシステム階層規格の一貫した使用
例3.4 bello のバイナリー RPM での rpmlint
コマンドの実行の出力
$ rpmlint ~/rpmbuild/RPMS/noarch/bello-0.1-1.el8.noarch.rpm bello.noarch: W: invalid-url URL: https://www.example.com/bello HTTP Error 404: Not Found bello.noarch: W: no-documentation bello.noarch: W: no-manual-page-for-binary bello 1 packages and 0 specfiles checked; 0 errors, 3 warnings.
no-documentation
および no-manual-page-for-binary
の警告では、RPM にドキュメントや man ページがないことが表示されます。これは指定していないので当然です。上記の警告とは別に、RPM は rpmlint
チェックに合格しています。
3.4.2. pello のサニティーチェック
本セクションでは、pello の SPEC ファイルおよび pello のバイナリー RPM の例で RPM のサニティーチェックを行う際に発生する可能性のある警告およびエラーを示します。
3.4.2.1. cello の SPEC ファイルの確認
例3.5 pello の SPEC ファイルで rpmlint
コマンドを実行した場合の出力
$ rpmlint pello.spec pello.spec:30: E: hardcoded-library-path in %{buildroot}/usr/lib/%{name} pello.spec:34: E: hardcoded-library-path in /usr/lib/%{name}/%{name}.pyc pello.spec:39: E: hardcoded-library-path in %{buildroot}/usr/lib/%{name}/ pello.spec:43: E: hardcoded-library-path in /usr/lib/%{name}/ pello.spec:45: E: hardcoded-library-path in /usr/lib/%{name}/%{name}.py* pello.spec: W: invalid-url Source0: https://www.example.com/pello/releases/pello-0.1.2.tar.gz HTTP Error 404: Not Found 0 packages and 1 specfiles checked; 5 errors, 1 warnings.
invalid-url Source0
の警告は、Source0
ディレクティブに一覧表示される URL に到達できないことを示します。指定した example.com
URL は存在しないため、この出力は当然です。この URL が今後機能すると仮定して、この警告を無視します。
hardcoded-library-path
エラーは、ライブラリーパスをハードコーディングするのではなく、%{_libdir}
マクロを使用することが推奨されます。この例では、これらのエラーは無視しても問題はありません。ただし、実際のパッケージの場合は、すべてのエラーが慎重にチェックされていることを確認してください。
例3.6 cello の SRPM で rpmlint
コマンドを実行した場合の出力
$ rpmlint ~/rpmbuild/SRPMS/pello-0.1.2-1.el8.src.rpm pello.src: W: invalid-url URL: https://www.example.com/pello HTTP Error 404: Not Found pello.src:30: E: hardcoded-library-path in %{buildroot}/usr/lib/%{name} pello.src:34: E: hardcoded-library-path in /usr/lib/%{name}/%{name}.pyc pello.src:39: E: hardcoded-library-path in %{buildroot}/usr/lib/%{name}/ pello.src:43: E: hardcoded-library-path in /usr/lib/%{name}/ pello.src:45: E: hardcoded-library-path in /usr/lib/%{name}/%{name}.py* pello.src: W: invalid-url Source0: https://www.example.com/pello/releases/pello-0.1.2.tar.gz HTTP Error 404: Not Found 1 packages and 0 specfiles checked; 5 errors, 2 warnings.
ここでの新しい invalid-url URL
エラーは、到達できないという、URL
ディレクティブに関するものです。今後、この URL が有効であると仮定して、この警告を無視しても問題はありません。
3.4.2.2. cello バイナリー RPM の確認
バイナリー RPM をチェックする場合には、rpmlint
は以下の項目をチェックします。
- Documentation
- man ページ
- ファイルシステム階層規格の一貫した使用
例3.7 pello のバイナリー RPM での rpmlint
コマンドの実行の出力
$ rpmlint ~/rpmbuild/RPMS/noarch/pello-0.1.2-1.el8.noarch.rpm pello.noarch: W: invalid-url URL: https://www.example.com/pello HTTP Error 404: Not Found pello.noarch: W: only-non-binary-in-usr-lib pello.noarch: W: no-documentation pello.noarch: E: non-executable-script /usr/lib/pello/pello.py 0644L /usr/bin/env pello.noarch: W: no-manual-page-for-binary pello 1 packages and 0 specfiles checked; 1 errors, 4 warnings.
no-documentation
および no-manual-page-for-binary
の警告では、RPM にドキュメントや man ページがないことが表示されます。これは指定していないので当然です。
only-non-binary-in-usr-lib
警告では、/usr/lib/
にバイナリーでないアーティファクトのみを提供していることを表示されます。このディレクトリーは通常、バイナリーファイルである共有オブジェクトファイル用に予約されています。したがって、rpmlint
は、/usr/lib/
ディレクトリー内の少なくとも 1 つ以上のファイルがバイナリーであることを想定します。
これは、ファイルシステム階層規格への準拠についての rpmlint
チェック例です。通常、ファイルを正しく配置するには RPM マクロを使用します。この例では、この警告は無視しても問題はありません。
non-executable-script
エラーは、/usr/lib/pello/pello.py
ファイルに実行権限がないことを警告します。ファイルにシバンが含まれているため、rpmlint
ツールは、ファイルが実行ファイルであること想定します。この例では、このファイルは実行権限なしのままにし、このエラーを無視します。
上記の警告およびエラーとは別に、RPM は rpmlint
チェックに合格しています。
3.4.3. cello のサニティーチェック
本セクションでは、cello の SPEC ファイルおよび pello のバイナリー RPM の例で RPM のサニティーチェックを行う際に発生する可能性のある警告およびエラーを示します。
3.4.3.1. cello の SPEC ファイルの確認
例3.8 cello の SRPM で rpmlint
コマンドを実行した場合の出力
$ rpmlint ~/rpmbuild/SPECS/cello.spec /home/<username>/rpmbuild/SPECS/cello.spec: W: invalid-url Source0: https://www.example.com/cello/releases/cello-1.0.tar.gz HTTP Error 404: Not Found 0 packages and 1 specfiles checked; 0 errors, 1 warnings.
cello.spec
には、Source0
ディレクティブに一覧表示される URL に到達できないことを示す警告が 1 つのみあります。指定した example.com
URL は存在しないため、この出力は当然です。この URL が今後機能すると仮定して、この警告を無視します。
例3.9 cello の SRPM で rpmlint
コマンドを実行した場合の出力
$ rpmlint ~/rpmbuild/SRPMS/cello-1.0-1.el8.src.rpm cello.src: W: invalid-url URL: https://www.example.com/cello HTTP Error 404: Not Found cello.src: W: invalid-url Source0: https://www.example.com/cello/releases/cello-1.0.tar.gz HTTP Error 404: Not Found 1 packages and 0 specfiles checked; 0 errors, 2 warnings.
cello
SRPM については、URL
ディレクティブで指定された URL に到達できないことを示す新しい警告が表示されます。今後、リンクが機能すると仮定して、この警告を無視することができます。
3.4.3.2. cello バイナリー RPM の確認
バイナリー RPM をチェックする場合には、rpmlint
は以下の項目をチェックします。
- Documentation
- man ページ
- ファイルシステム階層規格の一貫した使用
例3.10 cello のバイナリー RPM で rpmlint
コマンドを実行した場合の出力
$ rpmlint ~/rpmbuild/RPMS/x86_64/cello-1.0-1.el8.x86_64.rpm cello.x86_64: W: invalid-url URL: https://www.example.com/cello HTTP Error 404: Not Found cello.x86_64: W: no-documentation cello.x86_64: W: no-manual-page-for-binary cello 1 packages and 0 specfiles checked; 0 errors, 3 warnings.
no-documentation
および no-manual-page-for-binary
の警告では、RPM にドキュメントや man ページがないことが表示されます。これは指定していないため当然です。上記の警告とは別に、RPM は rpmlint
チェックに合格しています。
このページには機械翻訳が使用されている場合があります (詳細はこちら)。