Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

第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

パッケージを構築すると、ここにさまざまな %buildroot ディレクトリーが作成されます。これは、ログ出力で十分な情報を得られない場合に、失敗したビルドを調べるのに場合に便利です。

RPMS

バイナリー RPM は、さまざまなアーキテクチャーのサブディレクトリー (例: x86_64 および noarch) に作成されます。

SOURCES

ここでは、このパッケージャーは、圧縮したソースコードアーカイブとパッチを配置します。rpmbuild コマンドは、これらを検索します。

SPECS

パッケージャーは、SPEC ファイルをここに配置します。

SRPMS

rpmbuild を使用してバイナリー RPM の代わりに SRPM を構築すると、生成される SRPM がここに作成されます。

3.1.4. SPEC ファイルの概要

SPEC ファイルには、RPM を構築するのに rpmbuild ユーティリティーが使用するレシピが含まれています。SPEC ファイルは、一連のセクションで命令を定義することで、ビルドシステムに必要な情報を提供します。このセクションは、PreambleBody で定義されます。Preamble では、Body に使用されている一連のメタデータ項目が含まれています。Body は、命令の主要部分を示しています。

3.1.4.1. Preamble 項目

以下の表では、RPM SPEC ファイルの Preamble セクションで頻繁に使用されるディレクティブの一部を示しています。

表3.1 RPM SPEC ファイルの Preamble セクションで使用される項目

SPEC ディレクティブ定義

Name

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

Version

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

Release

このバージョンのソフトウェアがリリースされた回数。通常、初期値は 1%{?dist} に設定し、パッケージの新規リリースごとに増加させます。新しい Version のソフトウェアを構築するときに、1 にリセットされます。

Summary

パッケージの 1 行の概要

License

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

URL

プログラムに関する詳細情報の完全な URL。多くの場合、この URL は、パッケージ化しているソフトウェアのアップストリームプロジェクトの Web サイトです。

Source0

アップストリームのソースコードの圧縮アーカイブへのパスまたは URL (パッチを適用していないものや、パッチは別の場所で処理されます)。これは、たとえば、パッケージャーのローカルストレージではなく、アップストリームページなどのアーカイブの、アクセス可能で信頼できるストレージを参照している必要があります。必要に応じて、SourceX ディレクティブを追加して、たとえば、Source1、Source2、Source3 など、毎回数を増やすことができます。

Patch

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

ディレクティブは、パッチの末尾に数字を付けて、または付けずに適用できます。

数値を指定しないと、内部的にエントリーに割り当てられます。Patch0、Patch1、Patch2、Patch3 などを使用して、明示的に数字を指定することもできます。

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

BuildArch

パッケージがアーキテクチャーに依存していない場合は (たとえば、インタープリター型のプログラミング言語ですべて書かれた場合など)、これを BuildArch: noarch に設定します。設定しないと、パッケージは構築されるマシンのアーキテクチャー (x86_64など) を自動的に継承します。

BuildRequires

コンパイル言語で書かれたプログラムを構築するのに必要なコンマ区切りまたは空白区切りのリスト。BuildRequires のエントリーは複数になる場合があります。各エントリーに対する行が、SPEC ファイル行に含まれます。

Requires

インストール後のソフトウェアの実行に必要なパッケージのコンマ区切りまたは空白区切りのリスト。Requires のエントリーは複数ある場合があります。これらは、SPEC ファイル行に独自の行を持ちます。

ExcludeArch

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

Conflicts

ConflictsRequires と逆の意味を持ちます。Conflicts に一致するパッケージが存在すると、既にインストールされているパッケージに Conflict タグがあるか、インストールされるパッケージにある場合は、そのパッケージを独立してインストールすることができません。

Obsoletes

このディレクティブでは、rpm コマンドが直接コマンドラインで使用されるか、更新が更新または依存関係リゾルバーにより実行されるかによって、更新の方法が変更されます。コマンドラインで使用すると、RPM により、インストールしているパッケージに一致するすべての古いパッケージが削除されます。更新または依存関係リゾルバーを使用する場合は、一致する Obsoletes: を含むパッケージが更新として追加され、一致するパッケージを置き換えます。

Provides

Provides がパッケージに追加されると、名前以外の依存関係でパッケージを参照できます。

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 セクション の項目を以下の表に一覧表示します。

表3.2 RPM SPEC ファイルの Body セクションで使用される項目

SPEC ディレクティブ定義

%description

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

%prep

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

%build

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

%install

%builddir (ビルドが行われた場所) から、パッケージ化するファイルのディレクトリー構造を含む %buildroot ディレクトリーに、希望のビルドアーティファクトをコピーする単一または一連のコマンド。これは通常、ファイルを ~/rpmbuild/BUILD から /rpmbuild/buildroot にコピーして、必要なディレクトリーを /rpmbuild/buildroot に作成することを意味します。これは、エンドユーザーがパッケージをインストールするときではなく、パッケージを作成する時にのみ実行されます。詳細は「SPEC ファイルでの作業」を参照してください。

%check

ソフトウェアをテストする単一または一連のコマンド。これには通常、ユニットテストなどが含まれます。

%files

エンドユーザーのシステムにインストールされるファイルの一覧。

%changelog

異なる Version または Release ビルド間でパッケージに行われた変更の記録。

3.1.4.3. 高度な項目

SPEC ファイルには、ScriptletsTriggers などの高度な項目を追加することもできます。これは、ビルドプロセスではなく、エンドユーザーのシステムのインストールプロセスのさまざまな地点で有効になります。

3.1.5. BuildRoots

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

buildroot のファイルは、後で dhcpd アーカイブに置かれ、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 ファイルを作成する方法を示しています。

手順

  1. ~/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.speccello.spec、および pello.spec という名前の 3 つの SPEC ファイルが含まれています。

fd。ファイルを調べます。

+

注記

rpmdev-newspec ユーティリティーは、特定の Linux ディストリビューションに固有のガイドラインや規則を使用しません。ただし、本ドキュメントは buildroot} を対象にしています。そのため、SPEC ファイル全体にわたり定義または提供したその他のすべてのマクロとの一貫性を確立するために、RPM のビルドルートを参照する際には、$RPM_BUILD_ROOT において%{buildroot} の記述が推奨されます。

3.2.3. RPM を作成するための、元の SPEC ファイルの変更

以下の手順では、RPM を作成する rpmdev- newspec による SPEC 出力ファイルを修正する方法を示しています。

前提条件

以下の点を確認してください。

  • 特定のプログラムのソースコードが、~/rpmbuild/SOURCES/ ディレクトリーに置かれている。
  • 空の SPEC ファイル (~/rpmbuild/specs/<name>.spec ファイル) が、rpmdev -newspec ユーティリティーで作成されている。

手順

  1. rpmdev -newspec ユーティリティーで生成される ~/rpmbuild/specs/<name>.spec ファイルの出力テンプレートを開きます。
  2. SPEC ファイルの最初のセクションを作成します。

    最初のセクションには、rpmdev -newspec がグループ化される以下のディレクティブが含まれます。

    • 名前
    • Version
    • Release
    • Summary

      Name は既に rpmdev -newspec の引数として指定されています。

      Version を、ソースコードのアップストリームのリリースバージョンと一致するように設定します。

      Release は、1%{?dist} に自動的に設定されます。最初は 1 となります。パッチを追加する場合など、アップストリームリリースの Version を変更せずにパッケージを更新するたびに、初期値を増やします。新しいアップストリームリリースが行われた際に、Release1 にリセットされます。

      Summary は、ソフトウェアに関する 1 行の短い説明です。

  3. LicenseURL、および Source0 ディレクティブを入力します。

    License フィールドは、アップストリームリリースのソースコードに関連するソフトウェアライセンスです。SPEC ファイルで License にラベルを付ける方法は、使用する RPM ベースの特定の Linux ディストリビューションガイドラインによって異なります。

    たとえば、GPLv3+ を使用できます。

    URL フィールドは、アップストリームのソフトウェア Web サイトへの URL を指定します。一貫性を保つために、%{name} の RPM マクロ変数を利用して、https://example.com/% {name} を使用します。

    Source0 フィールドは、アップストリームのソフトウェアソースコードへの URL を指定します。これは、パッケージ化している特定のバージョンのソフトウェアに直接リンクする必要があります。本ドキュメントの URL の例には、将来変更される可能性があるハードコーディングした値が含まれています。同様に、リリースのバージョンも変更される可能性があります。今後の変更を簡素化するには、%{name} マクロと %{version} マクロを使用します。これらを使用して、SPEC ファイルの 1 つのフィールドのみを更新する必要があります。

  4. BuildRequires ディレクティブ、Requires ディレクティブ、および BuildArch ディレクティブを入力します。

    BuildRequires は、パッケージのビルドタイム依存関係を指定します。

    Requires は、パッケージのランタイム依存関係を指定します。

    これは、ネイティブにコンパイルされた拡張機能がない、インタープリター型プログラミング言語で書かれたソフトウェアです。したがって、noarch 値とともに BuildArch ディレクティブを追加します。これは、このパッケージを構築するプロセッサーアーキテクチャーに制限する必要がないことを RPM に指定します。

  5. %description%prep%build%install%files%license ディレクティブを入力します。

    これらのディレクティブは、マルチライン、マルチインストラクション、または実行するスクリプト処理タスクを定義することができるため、セクションの見出しと考えることができます。

    %description は、ソフトウェアの完全な説明で Summary よりも長く、複数の段落が含まれています。

    % prep セクションでは、ビルド環境の準備方法を指定します。通常、これには、ソースコードの圧縮アーカイブの展開、パッチの適用、および SPEC ファイルの後半で使用するためにソースコードでによる情報の解析が含まれます。このセクションでは、ビルトインの % setup -q マクロを使用できます。

    %build セクション では、ソフトウェアを構築する方法を指定します。

    %install セクションには、ソフトウェアを構築してから BUILDROOT ディレクトリーにインストールする方法に関する rpmbuild の説明が記載されています。

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

    %files セクションは、この RPM によるファイルのリストと、エンドユーザーシステム上のファイルの完全なパス場所を指定します。

    このセクションでは、組み込みのマクロを使用して、さまざまなファイルの役割を示すことができます。これは、command[]rpm コマンドを使用したパッケージファイルマニフェストのメタデータの照会に役立ちます。たとえば、LICENSE ファイルがソフトウェアライセンスファイルであることを示すには、%license マクロを使用します。

  6. 最後のセクションの %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 を再構築する方法を示しています。

手順

  • SRPMS から bellopello、および cello を再構築するには、以下を実行します。

    $ 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 ファイルから bellopello、および 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 をビルドする方法は、man ページの rpmbuild(8)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. cello の 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 は以下の項目をチェックします。

  • ドキュメント
  • 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 は以下の項目をチェックします。

  • ドキュメント
  • 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 は以下の項目をチェックします。

  • ドキュメント
  • 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 チェックに合格しています。