Packaging and distributing software | Packaging and distributing software | Red Hat Enterprise Linux | 10

第1章 RPM の概要
リンクのコピー

RPM Package Manager (RPM) は、Red Hat Enterprise Linux (RHEL)、CentOS、および Fedora で実行できるパッケージ管理システムです。RPM を使用すると、これらのオペレーティングシステム用に作成したソフトウェアを配布、管理、および更新できます。

RPM パッケージ管理システムには、従来のアーカイブファイルでソフトウェアを配布する場合と比べて、次のような利点があります。

RPM は、ソフトウェアを個別にインストール、更新、または削除できるパッケージの形式で管理されるため、オペレーティングシステムのメンテナンスが容易になります。
RPM パッケージは圧縮アーカイブと同様にスタンドアロンのバイナリーファイルであるため、RPM によりソフトウェアの配布が簡素化されます。これらのパッケージは、特定のオペレーティングシステムとハードウェアアーキテクチャー向けにビルドされています。RPM には、コンパイルされた実行可能ファイルやライブラリーなどのファイルが含まれています。これらのファイルは、パッケージのインストール時にファイルシステム上の適切なパスに配置されます。

RPM を使用すると、次のタスクを実行できます。

パッケージ化されたソフトウェアをインストール、アップグレード、削除する。
パッケージソフトウェアの詳細情報を問い合わせる。
パッケージ化されたソフトウェアの整合性を検証する。
ソフトウェアソースから独自のパッケージをビルドし、ビルド手順を完了する。
GNU Privacy Guard (GPG) ユーティリティーを使用して、パッケージにデジタル署名する。
パッケージを DNF リポジトリーに公開する。

RHEL では、RPM は DNF や PackageKit といった上位レベルのパッケージ管理ソフトウェアに完全に統合されています。RPM には独自のコマンドラインインターフェイスが用意されていますが、ほとんどのユーザーはこのようなソフトウェアを通じて RPM を操作するだけで済みます。ただし、RPM パッケージをビルドする場合は、rpmbuild(8) などの RPM ユーティリティーを使用する必要があります。

1.1. RPM パッケージ
リンクのコピー

RPM パッケージは、Red Hat Enterprise Linux (RHEL) にこれらのファイルをインストールおよび削除するために使用されるファイルとメタデータのアーカイブで設定されています。

具体的には、RPM パッケージには次の要素が含まれています。

GPG 署名
GPG 署名は、パッケージの整合性を検証するために使用されます。
ヘッダー (パッケージのメタデータ)
RPM パッケージマネージャーは、このメタデータを使用して、パッケージの依存関係、ファイルのインストール先、その他の情報を確認します。
ペイロード
ペイロードは、システムにインストールするファイルを含む cpio アーカイブです。

RPM パッケージには 2 つの種類があります。いずれも、同じファイル形式とツールを使用しますが、コンテンツが異なるため、目的が異なります。

ソース RPM (SRPM)
SRPM には、ソースコードと、ソースコードをバイナリー RPM にビルドする方法を記述した spec ファイルが含まれています。必要に応じて、SRPM にはソースコードへのパッチを含めることができます。
バイナリー RPM
バイナリー RPM には、ソースおよびパッチから構築されたバイナリーが含まれます。

1.2. RPM パッケージ化ユーティリティーのリスト
リンクのコピー

パッケージをビルドするための rpmbuild(8) プログラムに加えて、RPM は Red Hat Enterprise Linux (RHEL) 上でパッケージを作成するプロセスを容易にするための他のユーティリティーも提供しています。

rpmdevtools パッケージには、その他の RPM パッケージングユーティリティーが含まれています。詳細は、お使いのシステムの rpmdevtools の man ページを参照してください。

前提条件

rpmdevtools パッケージがインストールされている。
```
# dnf install rpmdevtools
```

手順

RPM パッケージ化ユーティリティーをリスト表示するには、次のいずれかの方法を使用します。
- rpmdevtools パッケージによって提供される特定のユーティリティーとその簡単な説明をリストするには、次のように入力します。
  $ rpm -qi rpmdevtools
- すべてのユーティリティーをリストするには、次のように入力します。
  $ rpm -ql rpmdevtools | grep ^/usr/bin

第2章 RPM パッケージ化ワークスペースのセットアップ
リンクのコピー

RPM パッケージをビルドするには、まず、特別なワークスペースを作成する必要があります。このワークスペースは、さまざまなパッケージ化のために使用するディレクトリーで構成されています。

2.1. RPM パッケージ化ワークスペースの設定
リンクのコピー

RPM パッケージングワークスペースを設定して、ソフトウェアパッケージングのための環境を準備します。

RPM パッケージ化ワークスペースを設定するには、rpmdev-setuptree ユーティリティーを使用してディレクトリーレイアウトを設定できます。

前提条件

RPM をパッケージ化するためのユーティリティーを提供する rpmdevtools パッケージをインストールした。
```
# dnf install rpmdevtools
```

手順

rpmdev-setuptree ユーティリティーを実行します。
```
$ rpmdev-setuptree
```

パッケージングワークスペースディレクトリーを設定します。

$ tree ~/rpmbuild/

/home/user/rpmbuild/
|-- BUILD
|-- RPMS
|-- SOURCES
|-- SPECS
`-- SRPMS

5 directories, 0 files

2.2. RPM パッケージ化ワークスペースディレクトリー
リンクのコピー

RPM パッケージングワークスペースを設定するために rpmdev-setuptree ユーティリティーが作成する以下のディレクトリーを確認してください。

Expand

表2.1 RPM パッケージ化ワークスペースディレクトリー
ディレクトリー	目的
`BUILD`	`SOURCES` ディレクトリーのソースファイルからコンパイルされたビルドアーティファクトが格納されます。
`RPMS`	バイナリー RPM は、さまざまなアーキテクチャー用のサブディレクトリーの `RPMS` ディレクトリー配下に作成されます。たとえば、`x86_64` や `noarch` サブディレクトリーです。
`SOURCES`	圧縮されたソースコードのアーカイブとパッチが格納されます。`rpmbuild` コマンドによって、このディレクトリー内のアーカイブとパッチが検索されます。
`SPECS`	パッケージャーによって作成された `spec` ファイルが格納されます。このファイルはパッケージのビルドに使用されます。
`SRPMS`	`rpmbuild` コマンドを使用してバイナリー RPM ではなく SRPM をビルドすると、結果の SRPM がこのディレクトリー配下に作成されます。

第3章 RPM マクロ
リンクのコピー

RPM マクロは、単純なテキスト置換に加えて、さまざまな文字列操作、式の評価、オペレーティングシステム (OS) との対話、その他のアクションを実行できる、直接的なテキスト置換です。

3.1. 組み込みの RPM マクロの表示
リンクのコピー

Red Hat Enterprise Linux (RHEL) システムに組み込まれている RPM マクロのリストを表示します。RPM には、複数の組み込みマクロが用意されています。これを使用すると、パッケージのメンテナンスを簡素化し、パッケージ間で一貫性を保つことができます。

手順

組み込みの RPM マクロを表示します。
```
$ rpm --showrc|grep "<builtin>”
```

3.2. RPM ディストリビューションマクロの表示
リンクのコピー

お使いの Red Hat Enterprise Linux (RHEL) システムの RPM ディストリビューションマクロを表示します。

各ディストリビューションは、パッケージ化の対象となるソフトウェアの実装言語や、そのディストリビューション固有のガイドラインに基づき、それぞれ異なる推奨 RPM マクロのセットを提供しています。推奨される RPM マクロのセットは、多くの場合、DNF パッケージマネージャーを使用してインストールできる RPM パッケージの形式で提供されます。インストール済みのマクロファイルは /usr/lib/rpm/macros.d/ ディレクトリーにあります。

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

手順

RPM マクロの定義そのものを表示します。
```
$ rpm --showrc
```
マクロの機能と、RPM をパッケージ化するときにマクロがどのように役立つかを確認します。
```
$ rpm --showrc | grep <macro_name>
```
オプション: お使いのシステムの RPM バージョンに対応する RPM マクロに関する情報を表示します。
```
$ rpm -ql rpm | grep macros
```

3.3. マクロを使用した RPM の動作のカスタマイズ
リンクのコピー

RPM マクロを編集することで、RPM の動作をカスタマイズできます。

組み込みのマクロを除き、~/.rpmmacros ファイル内のすべてのマクロをカスタムマクロでオーバーライドできます。行った変更は、同じホームディレクトリーを共有するすべてのシステム上のあらゆるビルドに影響します。

注記

マシンごとにマクロをオーバーライドするには、そのマクロを /etc/rpm/macros.* ファイルに配置してください。

警告

パッケージ化の際に ~/.rpmmacros ファイルで定義した新しいマクロを使用することは推奨しません。そのようなマクロは他のマシンにはおそらく存在しませんが、そのマシン上で他のユーザーがパッケージの再ビルドを試みる可能性があります。

手順

マクロをカスタマイズします。
```
%_topdir /opt/<directory>/rpmbuild
```
rpmdev-setuptree ユーティリティーを使用して、すべてのサブディレクトリーを含む <directory> を作成できます。
このマクロの値はデフォルトでは ~/rpmbuild であることに注意してください。

3.4. spec ファイルでのカスタム RPM マクロの定義
リンクのコピー

パッケージのメンテナンスを簡素化し、パッケージ間で一貫性を保つために、組み込みの RPM マクロや配布用 RPM マクロに加えて、カスタム RPM マクロを定義します。RPM の spec ファイルでは、%define マクロと %global マクロのいずれかを使用できます。

%define マクロと %global マクロの違いは次のとおりです。

%define はグローバルスコープを持ちます。ただし、パラメトリックマクロ内で使用される場合、そのスコープはそのマクロ内に限定されます。%define マクロの本体は使用時に展開されます。
%global はグローバルスコープを持ちます。%global マクロの本体は定義時に展開されます。

重要

次の操作を行う場合は、%global マクロを使用してください。

重複した複数の評価を避ける
パラメトリックマクロ内でグローバルマクロを定義する

それ以外の場合は、%define マクロを使用してください。

%define および %global マクロは、%global <name> <body> または %define <name>[(opts)] <body> というパターンを使用します。

<body> を囲む前後のすべての空白は、マクロの展開時に削除されます。
マクロ名は、英数字とアンダースコア (_) 文字で構成されている場合があります。
(opts) フィールドの指定は任意です。
- 単純なマクロには (opts) フィールドは含まれません。この場合、再帰的なマクロ展開のみが実行されます。
- パラメトリックオプションを指定したマクロは、引数や使用可能なオプションを受け取る関数のようなマクロです。詳細は、/usr/share/doc/rpm/macros.md ファイルを参照してください。

重要

マクロは、ハッシュ (#) を使用してコメント化された行や、%changelog などの spec ファイルのセクション内でも、spec ファイル内のすべての場所で評価および展開されます。

マクロの展開をエスケープするには、次の新しい行までの内容をすべてコメントアウトする %dnl マクロを使用できます。

マクロの前にパーセント記号 (%) をもう 1 つ配置することで、マクロの展開をエスケープすることもできます (例: %%{name})。

マクロの詳細は、/usr/share/doc/rpm/macros.md ファイルを参照してください。

手順

マクロを定義します。たとえば、RPM spec ファイルに次の行を含めることができます。
```
%define date 20241114
%define upstream_version 2.5.4-pre1
```

3.5. spec の %files セクションの一般的な RPM ディレクティブ
リンクのコピー

spec ファイルの %files セクションで、以下の RPM ディレクティブを使用してください。

Expand

表3.1 %files セクションのディレクティブ
マクロ	定義
`%license`	`%license` マクロは、ライセンスとしてリストされているファイルを識別します。RPM は、このファイルをインストールし、ライセンスとしてラベル付けします (例: `%license LICENSE`)。
`%doc`	`%doc` マクロは、ドキュメントファイルとしてリストされているファイルを識別します。RPM は、このファイルをインストールし、ドキュメントファイルとしてラベル付けします (例: `%doc README`)。重要ドキュメントは、イメージのディスク領域節約などのために、パッケージのインストール時に除外することができます。ライセンスファイルはドキュメントファイルのように見えるかもしれませんが、常にソフトウェアと一緒にインストールする必要があります。したがって、ライセンスファイルには `%doc` ではなく `%license` マクロを使用する必要があります。 `%doc` マクロは、パッケージ化するソフトウェア、コード例、およびさまざまな付随項目に関するドキュメントに使用されます。なお、コード例が含まれている場合は、ファイルから実行モードを削除するときに注意する必要があります。
`%dir`	`%dir` マクロは、パスが RPM パッケージによって所有されているディレクトリーであることを確認します。これにより、RPM のファイルマニフェストが、アンインストール操作中にクリーンアップするディレクトリーを正確に検出するようになります。使用例: `%dir %{_libdir}/%{name}`
`%config(noreplace)`	`%config(noreplace)` マクロは、ファイルが設定ファイルであることを確認します。そのため、このファイルが元のインストールチェックサムから変更されている場合は、パッケージのインストールまたは更新中にこのファイルを上書きまたは置き換えないでください。変更があった場合は、アップグレードまたはインストール時に、ファイル名の末尾に `.rpmnew` が追加されたファイルが作成されます。したがって、ターゲットシステム上の既存または変更されたファイルは、変更されないまま残ります。使用例: `%config(noreplace) %{_sysconfdir}/%{name}/%{name}.conf`

3.6. %autosetup および %setup マクロ
リンクのコピー

%patch ディレクティブを使用して各パッチを手動で指定する代わりに、%autosetup マクロを使用してソースアーカイブを展開し、パッチを自動的に適用します。

重要

%autosetup は、spec ファイル内に記載されている順序でパッチを適用します。予期しない動作を回避するために、spec 内ではソースとパッチを常にその番号順に並べるようにしてください。または、%patchlist や番号なしの Patch エントリーを使用して、番号付けそのものを避けるようにしてください。

%setup マクロを使用して、RPM パッケージをビルドするためのソースアーカイブを展開することもできます。

重要

可能な場合は、%setup マクロの代わりに %autosetup マクロを使用してください。

3.6.1. %autosetup マクロのオプション
リンクのコピー

以下の %autosetup マクロオプションを使用して、その動作を制御します。%autosetup はすべての %setup マクロオプションも受け取ります。

注記

%autosetup マクロのオプションは、組み合わせて使用できます。

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

Expand

表3.2 %autosetup マクロのオプション
マクロのオプション	説明
`-v`	`-v` オプションは、`%autosetup` マクロの詳細出力を有効にするために使用します。
`-N`	`-N` オプションは、自動パッチ適用を無効にするために使用します。
`-S<vcs_name>`	`-S<vcs_name>` オプションは、使用するバージョン管理システム (VCS) (例: `git_am`、`git`、`patch`、`gendiff`) を指定するために使用します。
`-p`	`-p` オプションは、パッチ接頭辞の除去を制御するために使用します。詳細は、システム上の `patch(1)` man ページを参照してください。

3.6.2. %autopatch マクロのオプション
リンクのコピー

%autopatch マクロは、spec ファイルで指定されている順序ですべてのパッチを適用します。以下の %autopatch マクロオプションを使用して、その動作を制御します。

注記

%autopatch マクロのオプションは、組み合わせて使用できます。

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

Expand

表3.3 %autopatch マクロのオプション
マクロのオプション	説明
`-v`	`-v` オプションは、`%autopatch` マクロの詳細出力を有効にするために使用します。
`-q`	`-q` オプションは、一致するパッチが検出されない場合の警告をオフにするために使用します。
`-p`	`-p` オプションは、パッチ接頭辞の除去を制御するために使用します。詳細は、システム上の `patch(1)` man ページを参照してください。
`-m<patch_number>`	`-m<patch_number>` オプションは、指定したパッチ番号から始まるパッチの範囲を適用するために使用します。
`-M<patch_number`>	`-M<patch_number>` は、指定したパッチ番号までのパッチの範囲を適用するために使用します。

3.6.3. %setup マクロのオプション
リンクのコピー

ソースアーカイブの展開を制御するには、以下の %setup マクロオプションを使用してください。

注記

%setup マクロのオプションは、組み合わせて使用できます。

Expand

表3.4 %setup マクロのオプション
マクロのオプション	説明
`-q`	`-q` オプションは、`%setup` マクロの詳細出力を制限するために使用します。このオプションは、`%setup` マクロの最初のオプションとして渡してください。
`-n`	`-n` オプションは、ソースコードアーカイブを展開した際に生成されるディレクトリー名を指定するために使用します。たとえば、このオプションは、展開したソースコードアーカイブのディレクトリーの名前が、想定されるもの (`%{<name>}-%{<version>}`) と異なる場合に使用できます。このような場合、%setup マクロのエラーが発生する可能性があります。たとえば、パッケージ名が `cello` であるが、ソースコードアーカイブ名が `hello-1.0.tgz` で、そのアーカイブに `hello/` ディレクトリーが含まれている場合、`spec` ファイルの内容を次のようにする必要があります。 `Name: cello Source0: https://example.com/%{name}/release/hello-%{version}.tar.gz ... %prep %setup -n hello`
`-c`	`-c` オプションは、ソースを展開する前に、ディレクトリーを作成してそのディレクトリーに移動するために使用します。次に例を示します。 `/usr/bin/mkdir -p cello-1.0 cd 'cello-1.0'` このディレクトリーはアーカイブの展開後も変更されません。
`-D`	`-D` オプションは、ソースコードディレクトリーの削除を無効にするために使用します。たとえば、`%setup` マクロを複数回使用する場合は、このオプションを使用できます。`-D` オプションを使用する場合、次の行は使用されません。 `rm -rf 'cello-1.0'`
`-T`	`-T` オプションは、`%setup` マクロのデフォルトの操作 (最初のソースアーカイブの展開を含む) をスキップするために使用します。このオプションはスクリプトから次の行を削除します。 `/usr/bin/gzip -dc '/builddir/build/SOURCES/cello-1.0.tar.gz' \| /usr/bin/tar -xvvof -`
`-b`	`-b` (before) オプションは、作業ディレクトリーに移動する前に特定のソースを展開するために使用します。たとえば、サンプルが別の `cello-1.0-examples.tar.gz` アーカイブで提供されており、そのアーカイブが `cello-1.0/examples` に展開されるとします。このような場合は、`-b 1` を使用して、作業ディレクトリーに移動する前に `Source1` を展開します。 `Source0: https://example.com/%{name}/release/%{name}-%{version}.tar.gz Source1: %{name}-%{version}-examples.tar.gz ... %prep %setup -b 1`
`-a`	`-a` (after) は、作業ディレクトリーに移動した後に特定のソースを展開するために使用します。引数として、`spec` ファイルの Preamble セクションのソース番号を指定します。たとえば、`cello-1.0.tar.gz` というアーカイブに、空の `examples` ディレクトリーが含まれているとします。また、サンプルが `examples.tar.gz` という別のアーカイブで提供されており、同じ名前のディレクトリーに展開されるとします。このような場合は、`-a 1` を使用して、作業ディレクトリーに移動した後に `Source1` を展開します。 `Source0: https://example.com/%{name}/release/%{name}-%{version}.tar.gz Source1: examples.tar.gz ... %prep %setup -a 1`

第4章 RPM パッケージ化を行うためのソフトウェアの作成
リンクのコピー

Red Hat Enterprise Linux (RHEL) 上での RPM パッケージング用に、ソフトウェアのソースコードを準備してください。

4.1. ソースコードとは
リンクのコピー

ソースコードとは、人間が判読できるコンピューターへの命令で、計算の実行方法を記述したものです。ソースコードは、プログラミング言語で書かれています。

3 つの異なるプログラミング言語で書かれた次のバージョンの Hello World プログラムにより、RPM パッケージマネージャーの主な使用例を説明します。

Bash で書かれた Hello World
bello プロジェクトでは、Bash で Hello World を実装します。この実装には bello シェルスクリプトのみが含まれています。このプログラムの目的は、コマンドラインで Hello World を出力することです。
bello ファイルには次の内容が含まれています。
```
#!/bin/bash

printf "Hello World\n"
```

Python で書かれた Hello World
pello プロジェクトでは、Python で Hello World を実装します。この実装には pello.py プログラムのみが含まれています。このプログラムの目的は、コマンドラインで Hello World を出力することです。
pello.py ファイルには次の内容が含まれています。
```
#!/usr/bin/python3

print("Hello World")
```

C で書かれた Hello World
cello プロジェクトは、C で Hello World を実装しています。この実装には cello.c と Makefile ファイルのみが含まれています。したがって、作成される tar.gz アーカイブには、LICENSE ファイルに加えて 2 つのファイルが含まれます。このプログラムの目的は、コマンドラインで Hello World を出力することです。
cello.c ファイルには次の内容が含まれています。
```
#include <stdio.h>

int main(void) {
    printf("Hello World\n");
    return 0;
}
```

注記

パッケージ化プロセスは、Hello World プログラムのバージョンごとに異なります。

4.2. ソフトウェアの作成方法
リンクのコピー

人間が読めるソースコードを、ソフトウェアをネイティブコンパイルまたはインタープリター方式でコンパイルすることにより、機械語に変換できます。

4.2.1. ネイティブにコンパイルされたソフトウェア
リンクのコピー

ネイティブにコンパイルされたソフトウェアは、生成されたバイナリーの実行ファイルでマシンコードにコンパイルされるプログラミング言語で書かれたソフトウェアです。ネイティブにコンパイルされたソフトウェアはスタンドアロンソフトウェアです。

注記

ネイティブにコンパイルされた RPM パッケージは、アーキテクチャー固有のパッケージです。

64 ビット (x86_64) AMD または Intel のプロセッサーを使用するコンピューターでこのようなソフトウェアをコンパイルすると、32 ビット (x86) AMD または Intel プロセッサーでは実行できません。生成されるパッケージには、名前でアーキテクチャーが指定されています。

4.2.2. インタープリター型ソフトウェア
リンクのコピー

Bash や Python などの一部のプログラミング言語は、マシンコードにコンパイルされません。代わりに、言語インタープリターまたは言語仮想マシンが、事前の変換を行わずにプログラムのソースコードを逐次実行します。

注記

インタープリター型のプログラミング言語でのみ書かれたソフトウェアは、アーキテクチャーに依存しません。そのため、作成される RPM パッケージの名前には noarch 文字列が付きます。

インタープリター言語で書かれたソフトウェアは、そのまま解釈することも、バイトコンパイルすることもできます。

そのまま解釈されるソフトウェア
このタイプのソフトウェアをコンパイルする必要はありません。そのまま解釈されるソフトウェアは、インタープリターによって直接実行されます。
バイトコンパイルされるソフトウェア
このタイプのソフトウェアはまずバイトコードにコンパイルする必要があり、その後言語仮想マシンによって実行されます。
注記
一部のバイトコンパイル言語は、そのまま解釈することも、バイトコンパイルすることもできます。

RPM を使用してソフトウェアをビルドおよびパッケージ化する方法は、これら 2 つのソフトウェアタイプで異なることに注意してください。

4.3. ソースからのソフトウェアのビルド
リンクのコピー

コンパイル言語で記述されたソフトウェアをソースコードから実行可能なソフトウェアアーティファクトにビルドします。

4.3.1. ネイティブにコンパイルされたコードからのソフトウェアのビルド
リンクのコピー

コンパイル言語で記述されたソフトウェアを、手動または自動ビルドを使用して実行可能ファイルに変換する。

4.3.1.1. サンプル C プログラムを手動ビルド
リンクのコピー

コンパイル言語で書かれたソフトウェアを手動でビルドする。

C で書かれたサンプルの Hello World プログラム (cello.c) には次の内容が含まれています。

#include <stdio.h>

int main(void) {
    printf("Hello World\n");
    return 0;
}

手順

GNU コンパイラーコレクションから C コンパイラーを呼び出して、ソースコードをバイナリーにコンパイルします。
```
$ gcc -g -o cello cello.c
```
作成されたバイナリー cello を実行します。
```
$ ./cello
```
```
Hello World
```

4.3.1.2. サンプル C プログラムの自動ビルドの設定
リンクのコピー

実際には、すべてのソフトウェアは自動ビルドを利用している。Makefile ファイルを作成し、GNU make ユーティリティーを実行することで、自動ビルドを設定します。

手順

次の内容を含む Makefile ファイルを cello.c と同じディレクトリーに作成します。
```
cello:
	gcc -g -o cello cello.c
clean:
	rm cello
```
cello: と clean: の下の行は、行頭にタブ文字 (タブ) を追加する必要があることに注意してください。
ソフトウェアをビルドします。
```
$ make
```
```
make: 'cello' is up to date.
```
すでにカレントディレクトリーにビルドが存在するため、以下の手順を繰り返してください。
1. make clean コマンドを入力してください。
  $ make clean
  rm cello
2. make コマンドを入力してください。
  $ make
  gcc -g -o cello cello.c
  GNU make システムが既存のバイナリーを検出するため、この時点でプログラムを再度ビルドしても効果がないことに注意してください。
  $ make
  make: 'cello' is up to date.
プログラムを実行します。
```
$ ./cello
```
```
Hello World
```

4.3.2. ソースコードの解釈
リンクのコピー

コンパイル言語で書かれたソースコードをバイトコンパイルし、シェルスクリプト言語で書かれたソースコードを直接実行可能にする。

バイトコンパイル

ソフトウェアのバイトコンパイル手順は、次の要素によって異なります。

プログラミング言語
言語の仮想マシン
その言語で使用するツールおよびプロセス

注記

たとえば Python で書かれたソフトウェアをバイトコンパイルできます。配布を目的とした Python ソフトウェアは多くの場合バイトコンパイルされますが、このドキュメントで説明されている方法では行われません。説明されている手順は、コミュニティー標準に準拠することではなく、簡素化することを目的としたものです。実際の Python ガイドラインは Software Packaging and Distribution を参照してください。

Python ソースコードは、そのまま解釈することもできます。ただし、バイトコンパイルされたバージョンの方が高速です。したがって、RPM パッケージの作成者は、エンドユーザーに配布するために、バイトコンパイルされたバージョンをパッケージ化する傾向があります。

直接解釈

Bash などのシェルスクリプト言語で書かれたソフトウェアは、常に直接解釈によって実行されます。

4.3.2.1. サンプル Python プログラムのバイトコンパイル
リンクのコピー

ソフトウェアのパフォーマンスを向上させるために、サンプル Python ソースコードをバイトコンパイルします。Python コードは生のコードを直接解釈することもできますが、バイトコンパイルされたコードの方が高速に動作します。

Python ソースコードの直接解釈ではなくバイトコンパイルを選択すると、より高速なソフトウェアを作成できます。

Python プログラミング言語で書かれたサンプルの Hello World プログラム (pello.py) には、次の内容が含まれています。

print("Hello World")

手順

pello.py ファイルをバイトコンパイルします。
```
$ python -m compileall pello.py
```
ファイルのバイトコンパイルされたバージョンが作成されたことを確認します。
```
$ ls pass:[pycache]
```
```
pello.cpython-311.pyc
```
出力内のパッケージのバージョンは、インストールされている Python のバージョンによって異なる場合があることに注意してください。
pello.py でプログラムを実行します。
```
$ python pello.py
```
```
Hello World
```

4.3.2.2. サンプル Bash プログラムの直接解釈
リンクのコピー

Bash のソースコードを直接実行可能にする。

Bash シェルの組み込み言語で書かれたサンプルの Hello World プログラム (bello) には、次の内容が含まれています。

#!/bin/bash

printf "Hello World\n"

注記

bello ファイルの先頭にある シバン (#!) 記号は、プログラミング言語のソースコードの一部ではありません。

シバン を使用して、テキストファイルを実行可能ファイルに変換します。システムのプログラムローダーが、シバン を含む行を解析してバイナリー実行可能ファイルへのパスを取得し、それがプログラミング言語インタープリターとして使用されます。

手順

ソースコードを含むファイルを実行可能ファイルにします。
```
$ chmod +x bello
```
作成したファイルを実行します。
```
$ ./bello
```
```
Hello World
```

第5章 RPM パッケージ化を行うためのソフトウェアの準備
リンクのコピー

RPM を使用してソフトウェアをパッケージ化する準備をするには、まずソフトウェアにパッチを適用し、LICENSE ファイルを作成して、それを tarball 形式でアーカイブします。

5.1. ソフトウェアへのパッチの適用
リンクのコピー

ソフトウェアをパッケージ化する場合、バグの修正や設定ファイルの変更など、元のソースコードに特定の変更を加えることが必要になる場合があります。RPM パッケージでは、元のソースコードを変更せずにそのままにして、パッチを適用することができます。

パッチは、ソースコードファイルを更新するテキストです。パッチは 2 つのバージョンのテキストの差を示すものであるため、diff 形式を使用します。diff ユーティリティーを使用してパッチを作成し、patch ユーティリティーを使用してそのパッチをソースコードに適用できます。

注記

ソフトウェア開発者は多くの場合、Git などのバージョン管理システムを使用してコードベースを管理します。このようなツールでは、diff やパッチソフトウェアを独自の方法で作成できます。

5.1.1. サンプル C プログラムのパッチファイルの作成
リンクのコピー

diff ユーティリティーを使用して、C 言語で書かれたサンプル Hello World プログラム (cello.c) の元のソースコードからパッチを作成します。このパッチを適用することで、元のソースコードを変更することなく、パッケージ化されたソフトウェアに変更を加えることができます。

詳細は、お使いのシステムの diff(1) man ページを参照してください。

前提条件

システムに diff ユーティリティーをインストールした。
```
# dnf install diffutils
```

手順

元のソースコードをバックアップします。
```
$ cp -p cello.c cello.c.orig
```
-p オプションは、モード、所有権、およびタイムスタンプを保持します。

必要に応じて cello.c を変更します。

#include <stdio.h>

int main(void) {
    printf("Hello World from my very first patch!\n");
    return 0;
}

パッチを生成します。
```
$ diff -Naur cello.c.orig cello.c
```
```
--- cello.c.orig        2016-05-26 17:21:30.478523360 -0500
+++ cello.c     2016-05-27 14:53:20.668588245 -0500
@@ -1,6 +1,6 @@
 #include<stdio.h>

 int main(void){
-    printf("Hello World!\n");
+    printf("Hello World from my very first patch!\n");
     return 0;
 }
\ No newline at end of file
```
+ で始まる行は、- で始まる行を置き換えます。
注記
diff コマンドには Naur オプションを指定することを推奨します。ほとんどのユースケースに適しているためです。
- -N (--new-file)
  -N オプションは、存在しないファイルを空のファイルとして処理します。
- -a (--text)
  -a オプションは、すべてのファイルをテキストとして扱います。その結果、diff ユーティリティーがバイナリーとして分類されたファイルを無視しなくなります。
- -u (-U NUM または --unified[=NUM])
  -u オプションは、統一されたコンテキストの出力の NUM 行 (デフォルトは 3 行) の形式で出力を返します。これは、パッチファイルで一般的に使用される、コンパクトで読みやすい形式です。
- -r (--recursive)
  -r オプションは、diff ユーティリティーが検出したサブディレクトリーを再帰的に比較します。
ただし、この場合は、-u オプションのみが必要であることに注意してください。

ファイルにパッチを保存します。

$ diff -Naur cello.c.orig cello.c > cello.patch

元の cello.c を復元します。
```
$ mv cello.c.orig cello.c
```
重要
RPM パッケージマネージャーは RPM パッケージをビルドするときに、変更されたファイルではなく元のファイルを使用するため、元の cello.c を保持する必要があります。詳細は、spec ファイルでの作業を参照してください。

5.1.2. サンプル C プログラムへのパッチ適用
リンクのコピー

パッチ ユーティリティーを使用して、C 言語で書かれたサンプル Hello World プログラム (cello.c) にコードパッチを適用します。

前提条件

システムに patch ユーティリティーをインストールした。
```
# dnf install patch
```
元のソースコードからパッチを作成した。手順は、サンプル C プログラムのパッチファイルの作成参照してください。

手順

パッチファイルの出力先を patch コマンド変更します。
```
$ patch < cello.patch
```
```
patching file cello.c
```

cello.c の内容に必要な変更が反映されていることを確認します。

$ cat cello.c

#include<stdio.h>

int main(void){
    printf("Hello World from my very first patch!\n");
    return 1;
}

検証

パッチを適用した cello.c プログラムをビルドします。
```
$ make
```
```
gcc -g -o cello cello.c
```
ビルドした cello.c プログラムを実行します。
```
$ ./cello
```
```
Hello World from my very first patch!
```

5.2. LICENSE ファイルの作成
リンクのコピー

ソフトウェアを適切に使用できるようにするには、RPM パッケージに必要な著作権情報と法的情報を含むライセンスファイルを作成してください。パッケージ化の目的上、パッケージ化するソフトウェアにはライセンスファイルも同梱する必要があります。

ソフトウェアは、ソフトウェアライセンスとともに配布することを推奨します。ソフトウェアライセンスファイルには、ユーザーがソースコードに関して何ができるか、何ができないかが記載されています。ソースコードに対するライセンスがないということは、そのコードに対するすべての権利を作成者が保持し、誰もソースコードから複製、配布、または派生著作物を作成できないことを意味します。

手順

必要なライセンスステートメントを含む LICENSE ファイルを作成します。

$ vim LICENSE

たとえば、GPLv3 LICENSE ファイルには次のようなテキストが含まれています。

$ cat /tmp/LICENSE

This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program. If not, see \http://www.gnu.org/licenses/.

5.3. 配布用ソースコードアーカイブの作成
リンクのコピー

ソフトウェアを配布用に準備するには、ソースコードと必要なコンポーネントをアーカイブファイルにまとめてください。

アーカイブファイルは、.tar.gz または .tgz 接尾辞を持つファイルです。ソースコードのアーカイブは、後で配布用にパッケージ化するソフトウェアのリリース方法として一般的です。

5.3.1. サンプル Bash プログラムのソースコードアーカイブの作成
リンクのコピー

配布用のサンプル Bash プログラムを作成するには、ソースコードと必要なコンポーネントをアーカイブファイルにまとめます。

bello プロジェクトは、Bash の Hello World ファイルです。次の例には、bello シェルスクリプトのみが含まれています。したがって、作成される tar.gz アーカイブには、LICENSE ファイルのほかにファイルが 1 つだけ含まれます。

注記

patch ファイルは、プログラムとともにアーカイブで配布されません。RPM パッケージマネージャーは、RPM のビルド時にパッチを適用します。パッチは、tar.gz アーカイブとともに ~/rpmbuild/SOURCES/ ディレクトリーに配置されます。

前提条件

bello プログラムのバージョン 0.1 を使用する。
LICENSE ファイルを作成した。手順は、LICENSE ファイルの作成を参照してください。

手順

必要なファイルをすべて 1 つのディレクトリーに移動します。
```
$ mkdir bello-0.1
```
```
$ mv ~/bello bello-0.1/
```
```
$ mv LICENSE bello-0.1/
```

配布用のアーカイブを作成します。

$ tar -cvzf bello-0.1.tar.gz bello-0.1

bello-0.1/
bello-0.1/LICENSE
bello-0.1/bello

作成したアーカイブを ~/rpmbuild/SOURCES/ ディレクトリーに移動します。これは、rpmbuild コマンドがパッケージをビルドするためのファイルを保存するデフォルトのディレクトリーです。
```
$ mv bello-0.1.tar.gz ~/rpmbuild/SOURCES/
```

5.3.2. サンプル Python プログラムのソースコードアーカイブの作成
リンクのコピー

配布用のサンプル Python プログラムを作成するには、ソースコードと必要なコンポーネントをアーカイブファイルにまとめます。

pello プロジェクトは、Python の Hello World ファイルです。次の例には、pello.py プログラムのみが含まれています。したがって、作成される tar.gz アーカイブには、LICENSE ファイルのほかにファイルが 1 つだけ含まれます。

注記

patch ファイルは、プログラムとともにアーカイブで配布されません。RPM パッケージマネージャーは、RPM のビルド時にパッチを適用します。パッチは、tar.gz アーカイブとともに ~/rpmbuild/SOURCES/ ディレクトリーに配置されます。

前提条件

pello プログラムのバージョン 0.1.1 を使用する。
LICENSE ファイルを作成した。手順は、LICENSE ファイルの作成を参照してください。

手順

必要なファイルをすべて 1 つのディレクトリーに移動します。
```
$ mkdir pello-0.1.1
```
```
$ mv pello.py pello-0.1.1/
```
```
$ mv LICENSE pello-0.1.1/
```

配布用のアーカイブを作成します。

$ tar -cvzf pello-0.1.1.tar.gz pello-0.1.1

pello-0.1.1/
pello-0.1.1/LICENSE
pello-0.1.1/pello.py

作成したアーカイブを ~/rpmbuild/SOURCES/ ディレクトリーに移動します。これは、rpmbuild コマンドがパッケージをビルドするためのファイルを保存するデフォルトのディレクトリーです。
```
$ mv pello-0.1.1.tar.gz ~/rpmbuild/SOURCES/
```

5.3.3. サンプル C プログラムのソースコードアーカイブの作成
リンクのコピー

配布用のサンプル C プログラムを作成するには、ソースコードと必要なコンポーネントをアーカイブファイルにまとめます。

cello プロジェクトは、C 言語で書かれた Hello World ファイルです。以下の例には、cello.c ファイルと Makefile ファイルのみが含まれています。したがって、作成される tar.gz アーカイブには、LICENSE ファイルに加えて 2 つのファイルが含まれます。

注記

patch ファイルは、プログラムとともにアーカイブで配布されません。RPM パッケージマネージャーは、RPM のビルド時にパッチを適用します。パッチは、tar.gz アーカイブとともに ~/rpmbuild/SOURCES/ ディレクトリーに配置されます。

前提条件

cello プログラムのバージョン 1.0 を使用する。
LICENSE ファイルを作成した。手順は、LICENSE ファイルの作成を参照してください。

手順

必要なファイルをすべて 1 つのディレクトリーに移動します。

$ mkdir cello-1.0

$ mv cello.c cello-1.0/

$ mv Makefile cello-1.0/

$ mv LICENSE cello-1.0/

配布用のアーカイブを作成します。

$ tar -cvzf cello-1.0.tar.gz cello-1.0

cello-1.0/
cello-1.0/Makefile
cello-1.0/cello.c
cello-1.0/LICENSE

作成したアーカイブを ~/rpmbuild/SOURCES/ ディレクトリーに移動します。これは、rpmbuild コマンドがパッケージをビルドするためのファイルを保存するデフォルトのディレクトリーです。
```
$ mv cello-1.0.tar.gz ~/rpmbuild/SOURCES/
```

第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` ディレクティブは、ディレクティブ名の末尾に数字を付けても付けなくても適用できます。番号が指定されていない場合は、エントリーに内部的に番号が割り当てられます。`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` ディレクティブを指定すると、次の要因に応じて更新の動作が変わります。 `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 を設定しないと Epoch は 0 になる、という一般的な認識とは異なります。ただし、処理上の理由から、RPM は Epoch が未設定であっても、Epoch が 0 に設定されている場合と同じように扱います。その逆も同様です。

重要

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

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

6.1.5. パッケージのバージョン管理の基本
リンクのコピー

パッケージの説明の基本的な要素は、spec ファイルのディレクティブである Name、Version、および 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 形式のパッケージ情報をデフォルトで表示します。

6.2. spec ファイルの条件分岐
リンクのコピー

仕様ファイルの条件式を使用することで、仕様 ファイルのさまざまなセクションを条件付きで含めることを可能にします。

通常、条件分岐は次の側面を扱います。

アーキテクチャー固有のセクション
オペレーティングシステム固有のセクション
さまざまなバージョンのオペレーティングシステム間の互換性に関する問題

spec の条件分岐はさまざまな目的で使用できます。次に例を示します。

条件式 (%if)。%if は複数の目的で使用できます。たとえば、次のような構文で使用できます。
- “式が真であれば、ある操作を実行する”:
  %if expression ... %endif
- “式が真であればある操作を実行し、そうでない場合は別の操作を実行する”:
  %if expression ... %elsif expression ... %else ... %endif
- %if の後には、任意の数の %elif 条件分岐 (ネストされた %elsif) を指定することもできます。次に例を示します。
  %if expression %elif expression ... %else %endif
システムアーキテクチャー (%ifarch、%ifnarch)。%ifarch は、現在のターゲットシステムのアーキテクチャーが一致するかどうかをテストします。%ifarch を使用すると、複数のプラットフォーム用の RPM パッケージをビルドできます。次に例を示します。
```
%ifarch s390 s390x
BuildRequires: s390utils-devel
%endif
```
オペレーティングシステム (%ifos、%ifnos)。%ifos は、ビルド対象のオペレーティングシステムに応じて spec ファイルの処理を制御します。

6.2.1. %if 条件分岐の使用例
リンクのコピー

仕様 ファイル内で %if 条件式を使用する方法を示す以下の例を確認してください。

例6.1 %if 条件分岐を使用して Red Hat Enterprise Linux 10 と他のオペレーティングシステム間の互換性を処理する

%if 0%{?rhel} == 10
sed -i '/AS_FUNCTION_DESCRIBE/ s/^/#/' configure.in
sed -i '/AS_FUNCTION_DESCRIBE/ s/^/#/' acinclude.m4
%endif

RHEL 10 でパッケージをビルドする際、この条件分岐により、%rhel マクロの値が 10 に設定されている場合に、対象となる autoconf スクリプトから AS_FUNCTION_DESCRIBE 行がコメントアウトされます。

例6.2 %if 条件分岐を使用してマクロの定義を処理する

%define ruby_archive %{name}-%{ruby_version}
%if 0%{?milestone:1}%{?revision:1} != 0
%define ruby_archive %{ruby_archive}-%{?milestone}%{?!milestone:%{?revision:r%{revision}}}
%endif

この条件分岐はマクロの定義を処理します。%milestone または %revision マクロが設定されている場合、アップストリームのアーカイブの名前を定義する %ruby_archive マクロが再定義されます。

6.2.2. %if 条件分岐の特殊なバリアント
リンクのコピー

システムアーキテクチャーやオペレーティングシステムを指定するために 仕様 ファイル内で使用できる、以下の特殊な %if 条件文を確認してください。

%if 条件分岐の特殊なバリアントとして、%ifarch、%ifnarch、および %ifos 条件があります。これらの条件分岐はよく使用されるため、独自のマクロが用意されています。

Expand

表6.4 表
条件分岐	説明
`%ifarch`	`%ifarch` 条件分岐は、アーキテクチャー固有の `spec` ファイルのブロックを開始するために使用されます。この条件分岐の後に、1 つ以上のアーキテクチャー指定子をコンマまたは空白区切りで指定します。次に例を示します。 `%ifarch i386 sparc ... %endif` `%ifarch` と `%endif` の間にある `spec` ファイルのすべての内容は、32 ビット AMD および Intel アーキテクチャーまたは Sun SPARC ベースのシステムでのみ処理されます。
`%ifnarch`	`%ifnarch` 条件分岐は `%ifarch` 条件分岐とは逆のロジックを持ちます。 `%ifnarch aarch64 ... %endif` `%ifnarch` と `%endif` の間にある `spec` ファイルのすべての内容は、64 ビット ARM アーキテクチャー以外のシステムでビルドが実行された場合にのみ処理されます。
`%ifos`	`%ifos` 条件分岐は、ビルドのオペレーティングシステムに基づいて処理を制御するために使用します。条件分岐の後に 1 つ以上のオペレーティングシステム名を指定できます。次に例を示します。 `%ifos linux ... %endif` `%ifos` と `%endif` の間にある spec ファイルのすべての内容は、Linux システムでビルドが実行された場合にのみ処理されます。

6.3. BuildRoots
リンクのコピー

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

buildroot 内のファイルは、後で RPM ペイロードに組み込まれ、RPM の主要部分となる。RPM がエンドユーザーのシステムにインストールされている場合、これらのファイルは root ディレクトリーに抽出され、階層が正しく保持されます。

注記

rpmbuild プログラムには独自のデフォルト設定があります。このデフォルト設定をオーバーライドすると、特定の問題が発生する可能性があります。したがって、buildroot マクロの独自の値を定義することは避けてください。代わりにデフォルトの %{buildroot} マクロを使用してください。

6.4. spec ファイルでの作業
リンクのコピー

RPM パッケージを使って新しいソフトウェアをパッケージ化するには、仕様 ファイルを作成する必要があります。

仕様 ファイルは以下のいずれかの方法で作成できます。

新しい spec ファイルを最初から手動で作成します。
rpmdev-newspec ユーティリティーを使用します。このユーティリティーは、空の spec ファイルを作成します。このファイルに必要なディレクティブとフィールドを入力します。

注記

プログラマー向けのテキストエディターの中には、新しい spec ファイルに独自の spec テンプレートを事前に入力するものもあります。rpmdev-newspec ユーティリティーでは、エディターに依存しないアプローチを利用できます。

6.4.1. サンプルの Bash、Python、および C プログラム用の新しい spec ファイルを作成する
リンクのコピー

rpmdev-newspec ユーティリティーを使用して、Hello World! プログラムの 3 つのサンプル実装それぞれに対応する spec ファイルを作成します。

前提条件

次の Hello World! プログラム実装が、~/rpmbuild/SOURCES ディレクトリーに配置されている。

手順

~/rpmbuild/SPECS ディレクトリーに移動します。
```
$ cd ~/rpmbuild/SPECS
```
Hello World! プログラムの 3 つの実装それぞれに spec ファイルを作成します。
```
$ 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 ファイルが追加されます。
作成されたファイルを調べます。
ファイル内のディレクティブは、spec ファイルについてで説明されているものです。次のセクションでは、rpmdev-newspec の出力ファイルの特定のセクションを作成します。

6.4.2. 元の spec ファイルの変更
リンクのコピー

rpmdev-newspec ユーティリティーによって生成された元の出力 仕様 ファイルを変更することにより、rpmbuild ユーティリティーに必要な指示を提供します。rpmbuild は、その指示を使用して RPM パッケージをビルドします。

前提条件

未入力の ~/rpmbuild/SPECS/<name>.spec spec ファイルを、rpmdev-newspec ユーティリティーを使用して作成した。詳細は、サンプルの Bash、Python、および C プログラム用の新しい spec ファイルを作成するを参照してください。

手順

rpmdev-newspec ユーティリティーによって提供される ~/rpmbuild/SPECS/<name>.spec ファイルを開きます。
spec ファイルの Preamble セクションに次のディレクティブを入力します。
- 名前: 名前は すでに rpmdev-newspec の引数として指定されています。
- バージョン: ソースコードのアップストリームリリースバージョンと一致するように バージョン を設定してください。
- リリース: リリース は自動的に 1%{?dist} に設定され、初期値は 1 です。
- 概要: パッケージの説明を 1 行で入力してください。
- ライセンス: ソースコードに関連付けられているソフトウェアライセンスを入力してください。
- URL: 上流ソフトウェアのウェブサイトの URL を入力してください。一貫性を保つために、%{name} RPM マクロ変数を利用し、https://example.com/%{name} 形式を使用します。
- ソース: 上流のソフトウェアソースコードへの URL を入力してください。パッケージ化するソフトウェアバージョンに直接リンクします。
  注記
  このドキュメントのサンプル URL には、ハードコードされた値が含まれています。この値は将来変更される可能性があります。同様に、リリースのバージョンも変更される可能性があります。今後の変更を簡素化するには、%{name} マクロと %{version} マクロを使用します。これらのマクロを使用すると、更新する必要がある箇所が、spec ファイル内の 1 つのフィールドだけになります。
- BuildRequires: パッケージのビルド時依存関係を指定します。
- 必須: パッケージの実行時依存関係を指定します。
- BuildArch: ソフトウェアアーキテクチャーを指定します。
spec ファイルの Body セクションに次のディレクティブを入力します。これらのディレクティブは、実行する複数行、複数指示のタスクやスクリプト処理タスクを定義できるため、セクションの見出しと考えることができます。
- %description: ソフトウェアの完全な説明を入力してください。
- %prep: ソフトウェアをビルド用に準備するためのコマンドまたは一連のコマンドを入力します。
- %conf: ソフトウェアをビルド用に設定するためのコマンドまたは一連のコマンドを入力します。
- %build: ソフトウェアをビルドするためのコマンドまたは一連のコマンドを入力します。
- %install: rpmbuild コマンドにソフトウェアを BUILDROOT ディレクトリーにインストールする方法を指示するコマンドまたは一連のコマンドを入力します。
- %files: RPM パッケージによって提供される、システムにインストールするファイルのリストを指定します。
- %changelog: パッケージの各 バージョンリリースに対応する、 日付付きエントリーのリストを入力します。
  %changelog セクションの最初の行は、アスタリスク (*) 文字で始め、その後に Day-of-Week Month Day Year Name Surname <email> - Version-Release を入力します。
  実際の変更エントリーは、次のルールに従ってください。
  - 各変更エントリーには、変更ごとに複数の項目を含めることができます。
  - 各項目は新しい行で始まります。
  - 各項目の先頭にハイフン (-) 文字を付けます。

6.4.3. サンプル Bash プログラムの spec ファイルの例
リンクのコピー

Bash プログラミング言語 (bello) で書かれたサンプルプログラムのアノテーション付きサンプル 仕様 ファイルを確認してください。

bello をインストールするには、インストール先ディレクトリーを作成し、そこに実行可能な bash スクリプトファイルをインストールする必要があります。したがって、%install セクションで install コマンドを使用できます。RPM マクロを使用すると、パスをハードコーディングせずにこれを行うことができます。

例6.3 bello プログラムの仕様ファイルの例

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 シェル環境のみが必要であるためです。
ソフトウェアのビルド方法を指定する %build セクションは空白です。これは bash スクリプトはビルドする必要がないためです。

6.4.4. サンプル Python プログラムの spec ファイルの例
リンクのコピー

Python プログラミング言語 (pello) で書かれたサンプルプログラムのアノテーション付きサンプル 仕様 ファイルを確認してください。

spec ファイル内にインラインでラッパースクリプトを作成するこの例は、spec ファイル自体がスクリプト可能であることを示しています。このラッパースクリプトは、ヒア ドキュメントを使用して、Python のバイトコンパイルされたコードを実行します。

例6.4 pello プログラムの仕様ファイルの例

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

Requires ディレクティブ (パッケージにランタイム依存関係を指定) には、以下の 2 つのパッケージが含まれます。
- 実行時にバイトコンパイルされたコードを実行するために必要な Python パッケージ。
- 小さなエントリーポイントスクリプトを実行するために必要な bash パッケージ。
BuildRequires ディレクティブは、パッケージのビルド時の依存関係を指定し、python パッケージのみを含みます。Pello プログラムは、バイトコンパイルのビルドプロセスを実行するために Python を必要とします。
ソフトウェアのビルド方法を指定する %build セクションでは、スクリプトのバイトコンパイルバージョンを作成します。実際のパッケージングでは、使用されるディストリビューションに応じて、通常は自動的に実行されることに注意してください。
%install セクションは、バイトコンパイルされたファイルをシステム上のライブラリーディレクトリーにインストールしてアクセスできるようにする必要があるという事実に一致しています。

6.4.5. サンプル C プログラムの spec ファイルの例
リンクのコピー

C プログラミング言語 (cello) で書かれたサンプルプログラムのアノテーション付きサンプル 仕様 ファイルを確認してください。

cello プログラムは、%make_install マクロを使用してインストールできます。これが可能なのは、cello プログラムの Makefile を利用できるためです。

例6.5 チェロプログラムの仕様ファイルの例

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 ディレクティブには、コンパイルビルドプロセスを実行するために必要な次のパッケージが含まれています。
- gcc
- make
この例では、パッケージにランタイム依存関係を指定する Requires ディレクティブは省略されています。すべてのランタイム要件は rpmbuild により処理されます。cello プログラムはコア C 標準ライブラリー以外のものは必要としません。
%build セクションは、この例で cello プログラム用の Makefile ファイルを作成したことを反映しています。したがって、GNU make コマンドを使用できます。ただし、設定スクリプトを指定していないため、%configure への呼び出しを削除する必要があります。

6.5. RPM のビルド
リンクのコピー

rpmbuild ユーティリティーを使用して、サンプルプログラムである bello、pello、cello の RPM パッケージを作成します。

rpmbuild コマンドでは、ユースケースや期待する結果によって組み合わせる引数が異なります。主な使用例は次のとおりです。

ソース RPM をビルドします。
バイナリー RPM をビルドします。
- ソース RPM からバイナリー RPM を再ビルドします。
- spec ファイルからバイナリー RPM をビルドします。

注記

rpmbuild コマンドを使用する場合、特定のディレクトリー構造とファイル構造が想定されます。これは 、rpmdev-setuptree ユーティリティーによって設定された構造と同じです。

6.5.1. ソース RPM のビルド
リンクのコピー

rpmbuild ユーティリティーを使用して、bello、pello、cello サンプルプログラムのソースコードを Source RPM(SRPM) パッケージに格納します。

SRPM を構築することには、以下の利点があります。

環境にデプロイされた RPM ファイルの特定の 名前 - バージョン - リリース (NVR) の正確なソースを保存できます。これには、正確な spec ファイル、ソースコード、および関連するすべてのパッチが含まれます。これは追跡とデバッグに役立ちます。
異なるハードウェアプラットフォームまたはアーキテクチャー上でバイナリー RPM をビルドできます。

前提条件

システムに rpmbuild ユーティリティーをインストールしました。
```
# dnf install rpm-build
```
あなたは以下の Hello World! 実装を ~/rpmbuild/SOURCES/ ディレクトリーに配置しました。
パッケージ化するプログラムの spec ファイルが存在する。

手順

作成した spec ファイルが含まれている ~/rpmbuild/SPECS/ ディレクトリーに移動します。
```
$ cd ~/rpmbuild/SPECS/
```
rpmbuild コマンドを入力し、spec ファイルを指定して、ソース RPM をビルドします。
```
$ rpmbuild -bs <specfile>
```
-bs オプションは ビルドソース を表します。
たとえば、bello、pello、cello プログラムのソース RPM を作成するには、以下の手順を実行します。
1. bello プログラムのソース RPM を作成します。
  $ rpmbuild -bs bello.spec
  Wrote: /home/admiller/rpmbuild/SRPMS/bello-0.1-1.el8.src.rpm
2. pello プログラムのソース RPM パッケージを作成します。
  $ rpmbuild -bs pello.spec
  Wrote: /home/admiller/rpmbuild/SRPMS/pello-0.1.2-1.el8.src.rpm
3. チェロ プログラムのソース RPM を作成します。
  $ rpmbuild -bs cello.spec
  Wrote: /home/admiller/rpmbuild/SRPMS/cello-1.0-1.el8.src.rpm

検証

rpmbuild/SRPMS ディレクトリーに、生成されたソース RPM が含まれていることを確認します。ディレクトリーは、rpmbuild で必要な構造の一部です。

6.5.2. ソース RPM からのバイナリー RPM の再ビルド
リンクのコピー

rpmbuild ユーティリティーを使用して、サンプルプログラムである bello、pello、cello の バイナリー RPM パッケージを、元の RPM(SRPM) パッケージから再構築します。その後、バイナリーパッケージを複数のシステムにインストールして実行できます。

バイナリー RPM の作成時に生成される出力は詳細なもので、デバッグに役立ちます。出力は例によって異なり、それぞれの spec ファイルに対応したものになります。

生成されたバイナリー RPM は、次のいずれかのディレクトリーにあります。

~/rpmbuild/RPMS/YOURARCH (YOURARCH はアーキテクチャーを表します)
パッケージがアーキテクチャー固有でない場合 、~/rpmbuild/RPMS/noarch/を使用します。

前提条件

システムに rpmbuild ユーティリティーをインストールしました。
```
# dnf install rpm-build
```

手順

SRPM が含まれる ~/rpmbuild/SRPMS/ ディレクティブに移動します。
```
$ cd ~/rpmbuild/SRPMS/
```
SRPM からバイナリー RPM を再ビルドします。
```
$ rpmbuild --rebuild <srpm>
```
たとえば、bello、pello、cello を それぞれの SRPM ファイルから再構築するには、以下の手順を実行します。
1. ベロ プログラムを再構築する:
  $ rpmbuild --rebuild bello-0.1-1.el8.src.rpm
2. ペロ プログラムを再構築する:
  $ rpmbuild --rebuild pello-0.1.2-1.el8.src.rpm
3. チェロ プログラムを再構築する:
  $ rpmbuild --rebuild cello-1.0-1.el8.src.rpm
注記
rpmbuild --rebuild を呼び出すと、次のプロセスが実行されます。
- SRPM の内容 (spec ファイルとソースコード) を ~/rpmbuild/ ディレクトリーにインストールします。
- インストールされたコンテンツを使用して RPM をビルドします。
- spec ファイルとソースコードを削除します。
次のいずれかの方法でビルドすると、spec ファイルとソースコードを保持できます。
- RPM をビルドするときに、--rebuild オプションではなく --recompile オプションを指定した rpmbuild コマンドを使用します。
- bello、pello、cello プログラムの SRPM をインストールしてください。
  bello 用の SRPM をインストールしてください。
  
  $ rpm -Uvh ~/rpmbuild/SRPMS/bello-0.1-1.el8.src.rpm
  
  Updating / installing... 1:bello-0.1-1.el8 [100%]
  
  pello 用の SRPM をインストールしてください。
  
  $ rpm -Uvh ~/rpmbuild/SRPMS/pello-0.1.2-1.el8.src.rpm
  
  Updating / installing... ...1:pello-0.1.2-1.el8 [100%]
  
  チェロ 用の SRPM をインストールしてください:
  
  $ rpm -Uvh ~/rpmbuild/SRPMS/cello-1.0-1.el8.src.rpm
  
  Updating / installing... ...1:cello-1.0-1.el8 [100%]

6.5.3. spec ファイルからバイナリー RPM をビルドする
リンクのコピー

rpmbuild コマンドを使用して、サンプルプログラムである bello、pello、cello の仕様 ファイルからバイナリー RPM パッケージを作成します。

前提条件

システムに rpmbuild ユーティリティーがインストールされている。
```
# dnf install rpm-build
```

手順

spec ファイルが含まれている ~/rpmbuild/SPECS/ ディレクトリーに移動します。
```
$ cd ~/rpmbuild/SPECS/
```
spec からバイナリー RPM をビルドします。
```
$ rpmbuild -bb <spec_file>
```
たとえば、spec ファイルから bello、pello、cello の バイナリー RPM をビルドするには、以下の手順を実行します。
1. bello プログラムを構築する:
  $ rpmbuild -bb bello.spec
2. ペロ プログラムを作成する:
  $ rpmbuild -bb pello.spec
3. チェロ プログラムを作成する:
  $ rpmbuild -bb cello.spec

6.6. RPM アクティビティーの syslog へのロギング
リンクのコピー

RPM のアクティビティーやトランザクションは、システムロギングプロトコル (syslog) を使用してログに記録します。

前提条件

syslog プラグインがシステムにインストールされている。
```
# dnf install rpm-plugin-syslog
```
注記
syslog メッセージのデフォルトの場所は、/var/log/messages ファイルです。ただし、メッセージを別の場所に保存するように syslog を設定することもできます。

手順

syslog メッセージを保存するように設定したファイルを開きます。
または、デフォルトの syslog 設定を使用する場合は、/var/log/messages ファイルを開きます。
[RPM] 文字列を含む新しい行を検索します。

6.7. RPM コンテンツの抽出
リンクのコピー

場合によってはパッケージのコンテンツを抽出する必要があります。たとえば、RPM に必要なパッケージが破損している場合などです。この場合、RPM インストールが破損しているにもかかわらず機能している場合は、rpm2archive ユーティリティーを使用して、.rpm ファイルを tar アーカイブに変換し、パッケージのコンテンツを使用できます。

注記

RPM インストールが著しく破損している場合は、rpm2cpio ユーティリティーを使用して RPM パッケージファイルを cpio アーカイブに変換できます。

手順

RPM ファイルを tar アーカイブに変換します。
```
$ rpm2archive <filename>.rpm
```
作成されたファイルには .tgz 接尾辞が付きます。たとえば、bash パッケージからアーカイブを作成するには、以下の手順を実行します。
1. bash RPM パッケージを tar アーカイブに変換する:
  $ rpm2archive bash-4.4.19-6.el8.x86_64.rpm
2. アーカイブファイルの内容を表示します。
  $ ls bash-4.4.19-6.el8.x86_64.rpm.tgz
  bash-4.4.19-6.el8.x86_64.rpm.tgz

6.8. RPM パッケージへの署名
リンクのコピー

RPM パッケージに署名することで、第三者がその内容を改変できないようにします。

以下のいずれかのソフトウェアを使用して、RPM パッケージに署名できます。

Sequoia PGP は OpenPGP 標準をサポートしています。RPM はソフトウェア署名の検証にも Sequoia PGP を使用します。
GNU Privacy Guard (GnuPG) は古い OpenPGP 標準バージョンをサポートしています。そのため、GnuPG は RHEL 9 以前のバージョンとの互換性に優れています。

警告

RHEL バージョン 10.1 以降では、OpenPGPv6 および RPMv6 署名がサポートされています。これらの署名は、以前のバージョンの RHEL とは互換性がありません。以前のバージョンの RPM はこれらの署名を無視します。パッケージに RPMv4 署名が含まれている場合、RPM は代わりにその署名を使用します。

ただし、RHEL 9.7 以降の RHEL 9 バージョンでは、multisig DNF プラグインを使用して OpenPGPv6 および RPMv6 署名のサポートを有効にできます。

6.8.1. GnuPG を使用した RPM パッケージへの署名
リンクのコピー

GNU Privacy Guard (GnuPG) を使用して RPM パッケージに署名することで、第三者がパッケージの内容を改変できないようにします。

6.8.1.1. GnuPG を使用してパッケージに署名するための OpenPGP 鍵の作成
リンクのコピー

GNU Privacy Guard (GnuPG) ソフトウェアを使用して RPM パッケージに署名するには、まず OpenPGP キーを作成する必要があります。

前提条件

システムに rpm-sign および pinentry パッケージがインストールされている。

手順

OpenPGP 鍵ペアを生成します。
```
$ gpg --gen-key
```
生成された鍵ペアを確認します。
```
$ gpg --list-keys
```

公開鍵をエクスポートします。

$ gpg --export -a '<public_key_name>' > RPM-GPG-KEY-pmanager

6.8.1.2. GnuPG を使用してパッケージに署名するための RPM の設定
リンクのコピー

GNU Privacy Guard (GnuPG) ソフトウェアを使用して RPM パッケージに署名するには、%_gpg_name RPM マクロを指定して RPM を設定します。

前提条件

GnuPG 用の OpenPGP 鍵を作成した。詳細は、GnuPG を使用してパッケージに署名するための OpenPGP 鍵の作成を参照してください。

手順

$HOME/.rpmmacros ディレクトリーで %_gpg_name マクロを定義します。
```
%_gpg_name <key_ID>
```
GnuPG の有効な鍵 ID 値は、鍵のフィンガープリント、フルネーム、または鍵の作成時に指定したメールアドレスです。

6.8.1.3. RPM パッケージへの署名の追加
リンクのコピー

パッケージは通常、署名なしでビルドします。荷物が発送される前に第三者が内容物を改ざんできないように、荷物に署名を追加してください。

前提条件

GnuPG 用の OpenPGP 鍵を作成した。詳細は、GnuPG を使用してパッケージに署名するための OpenPGP 鍵の作成を参照してください。
パッケージに署名するように RPM を設定した。詳細は、GnuPG を使用してパッケージに署名するための RPM の設定を参照してください。
システムに rpm-sign パッケージがインストールされている。

手順

パッケージに署名を追加します。
```
$ rpmsign --addsign <package-name>.rpm
```

検証

エクスポートした OpenPGP 公開鍵を RPM キーリングにインポートします。
```
# rpmkeys --import RPM-GPG-KEY-pmanager
```
GnuPG で鍵 ID を表示します。
```
$ gpg --list-keys
```
```
[...]
pub   rsa3072 2025-05-13 [SC] [expires: 2028-05-12]
      A8AF1C39AC67A1501450734F6DE8FC866DE0394D
[...]
```
鍵 ID は、コマンド出力の 40 文字の文字列です (例: A8AF1C39AC67A1501450734F6DE8FC866DE0394D)。

RPM ファイルに対応する署名があることを確認します。

$ rpm -Kv <package_name>.rpm

<package_name>.rpm:
    Header V4 RSA/SHA256 Signature, key ID 6de0394d: OK
    Header SHA256 digest: OK
    Header SHA1 digest: OK
    Payload SHA256 digest: OK
    MD5 digest: OK

署名の鍵 ID は、OpenPGP の鍵 ID の末尾と一致します。

6.8.2. Sequoia PGP を使用した RPM パッケージへの署名
リンクのコピー

RPM パッケージに Sequoia PGP を使用して署名することで、第三者がパッケージの内容を改ざんできないようにします。

6.8.2.1. Sequoia PGP を使用してパッケージに署名するための OpenPGP 鍵の作成
リンクのコピー

Sequoia PGP ソフトウェアを使用してパッケージに署名するには、まず OpenPGP キーを作成する必要があります。

手順

Sequoia PGP ツールをインストールします。
```
# dnf install sequoia-sq
```

OpenPGP 鍵ペアを生成します。

$ sq key generate --own-key --userid <key_name>

生成された鍵ペアを確認します。
```
$ sq key list
```

公開鍵をエクスポートします。

$ sq cert export --cert-userid '<key_name>' > RPM-PGP-KEY-pmanager

6.8.2.2. Sequoia PGP を使用してパッケージに署名するための RPM の設定
リンクのコピー

Sequoia PGP ソフトウェアを使用して RPM パッケージに署名するには、RPM を Sequoia PGP を使用するように設定し、%_gpg_name マクロを指定します。

前提条件

システムに rpm-sign パッケージがインストールされている。

手順

macros.rpmsign-sequoia ファイルを /etc/rpm ディレクトリーにコピーします。
```
# cp /usr/share/doc/rpm/macros.rpmsign-sequoia /etc/rpm/
```
鍵リストの出力から有効な OpenPGP 鍵のフィンガープリント値を取得します。
```
$ sq cert list --cert-userid '<key_name>'
```
```
 - 7E4B52101EB3DB08967A1E5EB595D12FDA65BA50
   - created 2025-05-13 10:33:29 UTC
   - will expire 2028-05-13T03:59:50Z

   - [    ✓    ] <key_name>
```
鍵のフィンガープリントは、出力の最初の行にある 40 文字の文字列です (例: 7E4B52101EB3DB08967A1E5EB595D12FDA65BA50)。
次のように、$HOME/.rpmmacros ファイルで %_gpg_name マクロを定義します。
```
%_gpg_name <key_fingerprint>
```
フィンガープリントの代わりに完全な鍵 ID を使用することもできます。
注記
GnuPG とは異なり、Sequoia PGP では完全な鍵 ID またはフィンガープリントしか使用できません。

6.8.2.3. RPM パッケージへの署名の追加
リンクのコピー

パッケージは通常、署名なしでビルドします。荷物が発送される前に第三者が内容物を改ざんできないように、荷物に署名を追加してください。

前提条件

OpenPGP 鍵を作成した。詳細は、Sequoia PGP を使用してパッケージに署名するための OpenPGP 鍵の作成を参照してください。
パッケージに署名するように RPM を設定した。詳細は、Sequoia PGP を使用してパッケージに署名するための RPM の設定を参照してください。
システムに rpm-sign パッケージがインストールされている。

手順

パッケージに署名を追加します。
```
$ rpmsign --addsign <package-name>.rpm
```

検証

エクスポートした OpenPGP 公開鍵を RPM キーリングにインポートします。
```
# rpmkeys --import RPM-PGP-KEY-pmanager
```

署名鍵のフィンガープリントを表示します。

$ sq key list --cert-userid <key_name>

 - 7E4B52101EB3DB08967A1E5EB595D12FDA65BA50
   - user ID: <key_name> (authenticated)
   - created 2025-05-13 10:33:29 UTC
   - will expire 2028-05-13T03:59:50Z
   - usable for signing
   - @softkeys/7E4B52101EB3DB08967A1E5EB595D12FDA65BA50: available, unlocked

   - 78E56DD2E12E02CFEEA27F8B9FE57972D6BCEA6F
     - created 2025-05-13 10:33:29 UTC
     - will expire 2028-05-13T03:59:50Z
     - usable for decryption
     - @softkeys/7E4B52101EB3DB08967A1E5EB595D12FDA65BA50: available, unlocked
   - C06E45F8ABC3E59F44A9E811578DDDB66422E345
     - created 2025-05-13 10:33:29 UTC
     - will expire 2028-05-13T03:59:50Z
     - usable for signing
     - @softkeys/7E4B52101EB3DB08967A1E5EB595D12FDA65BA50: available, unlocked
   - E0BD231AB350AD6802D44C0A270E79FFC39C3B25
     - created 2025-05-13 10:33:29 UTC
     - will expire 2028-05-13T03:59:50Z
     - usable for signing
     - @softkeys/7E4B52101EB3DB08967A1E5EB595D12FDA65BA50: available, unlocked

鍵のフィンガープリントは、通常 sq key list --cert-userid <key_name> コマンド出力内の署名サブキーです (例: E0BD231AB350AD6802D44C0A270E79FFC39C3B25)。

RPM ファイルに対応する署名があることを確認します。次に例を示します。

$ rpm -Kv <package_name>.rpm

<package_name>.rpm:
    Header V4 EdDSA/SHA512 Signature, key ID c39c3b25: OK
    Header SHA256 digest: OK
    Header SHA1 digest: OK
    Payload SHA256 digest: OK
    MD5 digest: OK

署名の鍵 ID は、鍵のフィンガープリントの末尾と一致します。

6.8.3. Sequoia PGP での PQC を使用した RPM パッケージへの署名
リンクのコピー

Sequoia PGP を使用して PQC アルゴリズムで RPM パッケージに署名することで、第三者がパッケージの内容を改ざんできないようにします。

耐量子計算機暗号 (PQC) は、量子コンピューターからの攻撃に耐えるように設計された一連のアルゴリズムであり、ソフトウェアのセキュリティーを強化します。

RPM パッケージマネージャーは、OpenPGP 標準を使用してパッケージに署名します。OpenPGPv6 では、ハイブリッド方式の鍵および署名のサポートが導入されています。これは、現在の暗号化アルゴリズムと PQC アルゴリズムを組み合わせることで、単一障害点を回避し、生成される署名の信頼性を高めます。

RHEL バージョン 10.1 以降では、RPMv6 署名がサポートされています。この形式を使用すると、パッケージに複数の OpenPGP 署名を追加して、RPM レベルで冗長性を高めることができます。

パッケージへの署名は、RPMv4 署名と RPMv6 署名の両方を組み合わせて行うことができます。この機能を使用すると、複数の異なる RPM バージョンを使用して同じ署名を検証できます。RHEL 10.1 以降、RPM は RPMv6 署名が存在する場合はそれだけを検証し、RPMv4 署名は無視します。パッケージに RPMv6 署名が存在しない場合、RPM は RPMv4 署名を使用します。以前の RHEL バージョンでは、RPM はデフォルトで RPMv4 の署名を検証し、RPMv6 の署名を無視していました。RHEL 9.7 以降の RHEL 9 バージョンでは、RPMv6 署名のサポートを有効にできます。

6.8.3.1. PQC 鍵の作成
リンクのコピー

耐量子計算機暗号 (PQC) アルゴリズムを使用してパッケージに署名するには、まず Sequoia PGP でハイブリッドキーペアを作成します。

別のアルゴリズムを指定することも可能です。たとえば、次の手順では ML-DSA-87-Ed448 アルゴリズムを使用します。

手順

Sequoia PGP ツールをインストールします。
```
# dnf install sequoia-sq
```
OpenPGP 鍵ペアを生成します。
```
$ sq key generate --own-key --expiration=never \ --cannot-authenticate --cannot-encrypt \ --email <vendor_email> --name "<vendor_name>" \ --cipher-suite mldsa87 --profile rfc9580
```
<vendor_email> と <vendor_name> を、RPM パッケージを提供するソフトウェアベンダーのメールと名前に置き換えます。
このコマンドは、プライマリーキーと署名用のサブキーを生成します。

生成された鍵ペアを確認します。

$ sq key list --cert-email <vendor_email>

 - <ml_dsa_fingerprint>
   - user IDs:
     - <vendor_email> (authenticated)
     - <vendor_name> (authenticated)
   - created 2025-10-03 14:36:44 UTC
   - usable for signing
   - @softkeys/<ml_dsa_fingerprint>: available, unlocked

   - <subkey_fingerprint>
     - created 2025-10-03 14:36:44 UTC
     - usable for signing
     - @softkeys/<subkey_fingerprint>: available, unlocked

PQC OpenPGP 証明書をエクスポートします。

$ sq cert export --cert-email '<vendor_email>' > RPM-PGP-KEY-VENDOR

次のステップ

PQC 用の RPM の設定

6.8.3.2. PQC 用の RPM の設定
リンクのコピー

パッケージの署名に使用する PQC キーを生成したら、RPM がこのキーを使用するように設定してください。

ビルドシステム外部の別の署名サーバー上で RPM を設定してください。RPM は、Sequoia PGP によるパッケージの署名をサポートするために、マクロを必要とします。このマクロはテンプレートファイルで提供されています。

前提条件

PQC 鍵ペアを作成した。詳細は、PQC 鍵の作成を参照してください。
システムに rpm-sign パッケージがインストールされている。

手順

macros.rpmsign-sequoia ファイルを /etc/rpm ディレクトリーにコピーします。
```
# cp /usr/share/doc/rpm/macros.rpmsign-sequoia /etc/rpm/
```

生成された鍵ペアを確認します。

$ sq key list --cert-email <vendor_email>

 - <ml_dsa_fingerprint>
   - user IDs:
     - <vendor_email> (authenticated)
     - <vendor_name> (authenticated)
   - created 2025-10-03 14:36:44 UTC
   - usable for signing
   - @softkeys/<ml_dsa_fingerprint>: available, unlocked

   - <subkey_fingerprint>
     - created 2025-10-03 14:36:44 UTC
     - usable for signing
     - @softkeys/<subkey_fingerprint>: available, unlocked

鍵のフィンガープリントを ~/.rpmmacros ファイルにエクスポートします。
```
$ echo "%_gpg_name <ml_dsa_fingerprint>" > ~/.rpmmacros
```

次のステップ

RPM に複数の署名を追加する

6.8.3.3. RPM に複数の署名を追加する
リンクのコピー

RHEL バージョン 10.1 以降では、RPMv6 署名がサポートされています。この形式を使用すると、RPM パッケージに複数の署名を追加できます。これにより、いずれかの鍵が侵害された場合や、いずれかの暗号化アルゴリズムがセキュアでなくなった場合でも、セキュリティーが強化されます。

複数の異なる鍵で RPM に署名するには、rpmsign --addsign --rpmv6 コマンドを複数回実行します。通常は OpenPGPv4 RSA 鍵を使用して生成され、RPMv4 と互換性のある最初の RPMv6 署名は、RPMv4 署名としても保存されることに注意してください。これにより、古いバージョンの RPM でもパッケージの署名を信頼することが可能になります。

重要

PQC アルゴリズムを使用する RPMv6 署名を追加する前に、必ず RPMv4 互換の署名をパッケージに追加することを検討してください。これにより、バージョンが RHEL 10.1 より前の RHEL 上の RPM によって検証可能な署名が、パッケージに確実に含まれるようになります。

前提条件

PQC 鍵ペアを生成した。詳細は、PQC 鍵の作成を参照してください。
PQC 鍵を使用するように RPM を設定した。詳細は、PQC 用の RPM の設定を参照してください。

手順

パッケージに署名を追加します。

$ rpmsign --addsign --rpmv6 <package_name>.rpm

複数の RPMv6 署名を使用してパッケージに署名するために、最初のステップを繰り返します。

検証

エクスポートした PQC OpenPGP 証明書を RPM キーリングにインポートします。
```
# rpmkeys --import RPM-PGP-KEY-VENDOR
```

RPM ファイルに対応する署名があることを確認します。次に例を示します。

$ rpmkeys -Kv <package_name>.rpm

<package_name>.rpm:
    Header OpenPGP V6 ML-DSA-87+Ed448/SHA512 signature, key fingerprint: <ml_dsa_fingerprint>: OK
    Header OpenPGP V4 RSA/SHA512 signature, key fingerprint: <rsa_fingerprint>: OK
    Header SHA256 digest: OK
    Payload SHA256 digest: OK

第7章 Python 3 RPM のパッケージ化
リンクのコピー

DNF パッケージマネージャーを使用すると、システムに Python パッケージをインストールできます。DNF は RPM パッケージ形式を使用します。これにより、ソフトウェアのダウンストリーム制御が強化されます。

Python プロジェクトを RPM パッケージにパッケージ化すると、ネイティブ Python パッケージと比較して次の利点が得られます。

DNF パッケージマネージャーは、Python パッケージおよび Python 以外のパッケージへの依存関係を可能にし、それらを厳密に管理します。
パッケージに暗号で署名できます。暗号化署名を使用すると、RPM パッケージのコンテンツを、オペレーティングシステムの他の部分を使用して検証、統合、およびテストできます。
ビルドプロセス中にテストを実行できます。

ネイティブ Python パッケージのパッケージ形式は、Python Packaging Authority (PyPA) 仕様によって定義されています。歴史的に、ほとんどの Python プロジェクトでは、パッケージ化に distutils または setuptools ユーティリティーを使用し、setup.py ファイルでパッケージ情報を定義していました。ただし、ネイティブ Python パッケージ作成の可能性は、時間の経過とともに進化しています。

setup.py ファイルを使用する Python ソフトウェアをパッケージ化するには、このドキュメントに従ってください。
pyproject.toml ファイルを使用してより新しいパッケージをパッケージ化するには、pyproject-rpm-macros の README ファイルを参照してください。pyproject-rpm-macros は、サポート対象外のパッケージを含む CodeReady Linux Builder (CRB) リポジトリーに含まれており、より新しい Python パッケージング標準への対応のために時間の経過とともに変更される可能性があることに注意してください。

7.1. Python パッケージの例に対する spec ファイルの説明
リンクのコピー

python3-pello パッケージの以下の例にある、Python RPM 仕様 ファイルの詳細に関する注記を確認してください。

Python プロジェクトの RPM 仕様 ファイルには、Python 以外の RPM 仕様 ファイルと比較していくつかの特有の点があります。たとえば、Python ライブラリーの RPM パッケージ名には、python3- という 接頭辞を含めることが推奨されます。

例7.1 Python で書かれたプログラムの SPEC ファイルの例

%global python3_pkgversion 3

Name:           python-pello
Version:        1.0.2
Release:        1%{?dist}
Summary:        Example Python library

License:        MIT
URL:            https://github.com/fedora-python/Pello
Source:         %{url}/archive/v%{version}/Pello-%{version}.tar.gz

BuildArch:      noarch
BuildRequires:  python%{python3_pkgversion}-devel

# Build dependencies need to be specified manually
BuildRequires:  python%{python3_pkgversion}-setuptools

# Test dependencies need to be specified manually
# Runtime dependencies need to be BuildRequired manually to run tests during build
BuildRequires:  python%{python3_pkgversion}-pytest >= 3


%global _description %{expand:
Pello is an example package with an executable that prints Hello World! on the command line.}

%description %_description

%package -n python%{python3_pkgversion}-pello
Summary:        %{summary}

%description -n python%{python3_pkgversion}-pello %_description


%prep
%autosetup -p1 -n Pello-%{version}


%build
# The macro only supports projects with setup.py
%py3_build


%install
# The macro only supports projects with setup.py
%py3_install


%check
%pytest


# Note that there is no %%files section for python-pello
%files -n python%{python3_pkgversion}-pello
%doc README.md
%license LICENSE.txt
%{_bindir}/pello_greeting

# The library files needed to be listed manually
%{python3_sitelib}/pello/

# The metadata files needed to be listed manually
%{python3_sitelib}/Pello-*.egg-info/

python3_pkgversion マクロを定義することで、このパッケージがビルドされる Python バージョンを設定します。デフォルトの Python バージョン 3.12 用にビルドするには、行を削除します。
Python プロジェクトを RPM にパッケージ化するときは、常に python- 接頭辞をプロジェクトの元の名前に追加してください。ここでは元の名前が Pello であるため、ソース RPM (SRPM) の名前は python-pello になります。
BuildRequires は、このパッケージのビルドおよびテストに必要なパッケージを指定します。BuildRequires には、Python パッケージのビルドに必要なツールを提供するアイテム python3-devel と、パッケージ化する特定のソフトウェアに必要な関連プロジェクト (python3-setuptools、または %check セクションでテストを実行するのに必要なランタイムとテストの依存関係) を常に含めます。
バイナリー RPM (ユーザーがインストールできるパッケージ) の名前を選択する際には、バージョン管理された Python 接頭辞を追加します。デフォルトの Python 3.12 の場合は、python3- 接頭辞を使用します。%{python3_pkgversion} マクロを使用できます。このマクロは、デフォルトの Python バージョン 3.12 に対して 3 と評価されます。ただし、たとえば、より新しいバージョンの Python が利用可能な場合など、明示的にバージョンを指定すればその値に設定されます (脚注 1 を参照)。
%py3_build マクロおよび %py3_install マクロは、インストール場所、使用するインタープリター、その他の詳細を指定する追加の引数を使用して、setup.py build コマンドおよび setup.py install コマンドをそれぞれ実行します。
注記
setuptools パッケージの setup.py build コマンドと setup.py install コマンドの使用は非推奨となり、今後の RHEL メジャーリリースでは削除される予定です。代わりに pyproject-rpm-macros を使用できます。
%check セクションでは、パッケージ化されたプロジェクトのテストを実行します。正確なコマンドはプロジェクト自体によって異なりますが、%pytest マクロを使用して、RPM に適した方法で pytest コマンドを実行できます。

7.2. Python 3 RPM の一般的なマクロ
リンクのコピー

Python RPM spec ファイルでは、値をハードコーディングするのではなく、常に Python 3 RPM のマクロを使用します。

spec ファイルの冒頭で python3_pkgversion マクロを定義することで、これらのマクロで使用する Python 3 バージョンを再定義できます。詳細は、Python パッケージの例の仕様ファイルの説明を参照してください。python3_pkgversion マクロを定義すると、以下の表で説明されているマクロの値は、指定された Python 3 バージョンを反映します。

Expand

表7.1 Python 3 RPM 用のマクロ
マクロ	一般的な定義	説明
%{python3_pkgversion}	3	他のすべてのマクロで使用される Python バージョン。今後追加される Python バージョンに合わせて再定義できます。
%{python3}	/usr/bin/python3	Python3 インタープリター
%{python3_version}	3.12	Python3 インタープリターの major.minor バージョン
%{python3_sitelib}	/usr/lib/python3.12/site-packages	pure-Python モジュールがインストールされている場所
%{python3_sitearch}	/usr/lib64/python3.12/site-packages	アーキテクチャー固有の拡張モジュールを含むモジュールがインストールされている場所
%py3_build		RPM パッケージに適した引数で `setup.py build` コマンドに展開されます。
%py3_install		RPM パッケージに適した引数で `setup.py install` コマンドに展開されます。
%{py3_shebang_flags}	sP	Python インタープリターディレクティブマクロのデフォルトのフラグセット `%py3_shebang_fix`
%py3_shebang_fix		Python インタープリターディレクティブを `#! %{python3}` に変更すると、既存のフラグ (見つかった場合) を保持し、`%{py3_shebang_flags}` マクロで定義されたフラグを追加します。

7.3. Python RPM の自動生成された依存関係の使用
リンクのコピー

アップストリームが提供するメタデータを使用して、Python RPM の依存関係の自動生成を有効にします。

前提条件

RPM の spec ファイルが存在する。詳細は、Python パッケージの例の仕様ファイルの説明を参照してください。

手順

生成された RPM に次のいずれかのディレクトリーを含めます。
- .dist-info
- .egg-info
  RPM ビルドプロセスは、これらのディレクトリーから仮想 pythonX.Ydist Provides を自動的に生成します。次に例を示します。
  python3.12dist(pello)
  次に、Python 依存関係ジェネレーターはアップストリームメタデータを読み取り、生成された pythonX.Ydist 仮想 Provides を使用して各 RPM パッケージのランタイム要件を生成します。生成された要件タグの例:
  Requires: python3.12dist(requests)
生成された Requires を検査します。
生成された Requires の一部を削除するには、spec ファイルの %prep セクションでアップストリーム提供のメタデータを変更します。
自動要件ジェネレーターを無効にするには、メインパッケージの %description 宣言の上に %{?python_disable_dependency_generator} マクロを含めます。

第8章 Python スクリプトでのインタープリターディレクティブの変更
リンクのコピー

パッケージ化した Python スクリプトを、想定される形式に準拠するように変更します。

Red Hat Enterprise Linux (RHEL) 10 では、実行可能な Python スクリプトは、ハッシュバンまたはシェバンとも呼ばれるインタープリターディレクティブを使用して、少なくとも Python のメジャーバージョンを明示的に指定することが求められます。以下に例を示します。

#!/usr/bin/python3
#!/usr/bin/python3.12

/usr/lib/rpm/redhat/brp-mangle-shebangs buildroot ポリシー BRP (buildroot policy) スクリプトは、RPM パッケージをビルドする際に自動的に実行され、実行可能なすべてのファイルでインタープリターディレクティブを修正しようとします。BRP スクリプトは、#!/usr/bin/python や #!/usr/bin/env python などのあいまいなインタープリターディレクティブを持つ Python スクリプトを検出するとエラーを生成します。

前提条件

Python スクリプトのインタープリターディレクティブの一部でビルドエラーが発生する。

手順

シナリオに応じて、次のいずれかの手順を実行してインタープリターディレクティブを変更します。
- spec ファイルの %prep セクションで次のマクロを使用します。
  %py3_shebang_fix <SCRIPTNAME> ...
  SCRIPTNAME には、任意のファイル、ディレクトリー、またはファイルおよびディレクトリーのリストを指定できます。
  その結果、リストされたすべてのファイルと、リストされたディレクトリー内のすべての .py ファイルのインタープリターディレクティブが %{python3} を指すように変更されます。元のインタープリターディレクティブの既存のフラグは保持され、%{py3_shebang_flags} マクロで定義された追加のフラグが追加されます。spec ファイルの %{py3_shebang_flags} マクロを再定義すると、追加されるフラグを変更できます。
- パッケージ化した Python スクリプトを、想定される形式に準拠するように変更します。

第9章 Ruby gem のパッケージ化
リンクのコピー

Ruby プロジェクトを RPM ファイルとしてパッケージ化する。

Ruby は、インタープリター型の汎用プログラミング言語です。Ruby で記述されたプログラムは通常、特定の Ruby パッケージ形式を提供する RubyGems ソフトウェアを使用してパッケージ化されます。

RubyGems によって作成されたパッケージは gem と呼ばれます。gem を RPM パッケージに再パッケージ化することができます。

注記

このドキュメントは、gem 接頭辞とともに RubyGems の概念に関する用語を参照します。たとえば、.gemspec は gem specification に使用され、RPM に関連する用語は修飾されません。

9.1. RubyGems が RPM に関連している仕組み
リンクのコピー

RubyGems は、Ruby 独自のパッケージ形式を表します。ただし、RubyGems には RPM に必要なメタデータに類似したメタデータが含まれています。このメタデータにより、gem を RPM としてパッケージ化することが効率化されます。gem から再パッケージ化された RPM は、他のディストリビューションと整合性が取れています。エンドユーザーは、適切な RPM パッケージ化された gem やその他のシステムライブラリーをインストールすることで、gem の依存関係を満たすこともできます。

RubyGems では、spec ファイル、パッケージ名、依存関係などの項目について、RPM パッケージと同様の用語が使用されます。

RHEL RPM ディストリビューションの他の部分に準拠するには、RubyGems によって作成されたパッケージは次のルールに準拠する必要があります。

パッケージに名前を付けるときは、rubygem-%{gem_name} のパターンに従ってください。
インタープリターディレクティブとして #!/usr/bin/ruby 文字列を使用します。

9.2. RubyGems spec ファイルの規則
リンクのコピー

RubyGems の spec ファイルの構造例と、そのような spec ファイルを作成する際に従うべき具体的な事項を確認してください。

RubyGems の 仕様 ファイルは、以下の規則に従う必要があります。

ファイルには、gem の仕様からの名前である %{gem_name} の定義が含まれています。
パッケージのソースは、リリースされた gem アーカイブへの完全な URL である必要があります。
パッケージのバージョンは gem のバージョンと同じである必要があります。
ファイルには次の BuildRequires: ディレクティブが含まれています。
```
BuildRequires: rubygems-devel
```
rubygems-devel パッケージにはビルドに必要なマクロが含まれています。
このファイルには、追加の rubygem(foo) Requires または Provides ディレクティブは含まれていません。これらのディレクティブは gem のメタデータから自動生成されるためです。

9.2.1. RubyGems spec ファイルの例
リンクのコピー

以下の、gem をビルドするためのサンプル 仕様 ファイルのうち、RubyGems 固有の部分の詳細を確認してください。なお、仕様 ファイルの残りの部分は、一般的な 仕様 ファイル作成ガイドラインに従っています。

例9.1 サンプル spec ファイルの RubyGems 固有の部分

%prep
%setup -q -n  %{gem_name}-%{version}

# Modify the gemspec if necessary
# Also apply patches to code if necessary
%patch 0 -p1

%build
# Create the gem as gem install only works on a gem file
gem build ../%{gem_name}-%{version}.gemspec

# %%gem_install compiles any C extensions and installs the gem into ./%%gem_dir
# by default, so that we can move it into the buildroot in %%install
%gem_install

%install
mkdir -p %{buildroot}%{gem_dir}
cp -a ./%{gem_dir}/* %{buildroot}%{gem_dir}/

# If there were programs installed:
mkdir -p %{buildroot}%{_bindir}
cp -a ./%{_bindir}/* %{buildroot}%{_bindir}

# If there are C extensions, copy them to the extdir.
mkdir -p %{buildroot}%{gem_extdir_mri}
cp -a .%{gem_extdir_mri}/{gem.build_complete,*.so} %{buildroot}%{gem_extdir_mri}/

9.2.2. RubyGems spec ファイルのディレクティブ
リンクのコピー

spec ファイルの RubyGems 固有の部分にある、特定の項目に関する以下の詳細を確認してください。

Expand

表9.1 RubyGems の spec のディレクティブ詳細
ディレクティブ	RubyGems の詳細
`%prep`	RPM は gem アーカイブを直接展開できます。`%setup -n %{gem_name}-%{version}` マクロは、gem が展開されたディレクトリーを提供します。同じディレクトリーレベルで、`%{gem_name}-%{version}.gemspec` ファイルが自動的に作成されます。このファイルを使用して、次のアクションを実行できます。 `.gemspec` ファイルを変更する。コードにパッチを適用する。
`%build`	このセクションには、ソフトウェアをマシンコードにビルドするためのコマンドが含まれています。`%gem_install` マクロは gem アーカイブでのみ動作します。したがって、まず `gem build ../%{gem_name}-%{version}.gemspec` コマンドを使用してアーカイブを再作成する必要があります。再作成された gem ファイルは `%gem_install` によって使用され、gem コードをビルドしてデフォルトの `./%{gem_dir}` 一時ディレクトリーにインストールします。ビルドしたソースはインストール前に、自動的に作成される一時ディレクトリーに配置されます。
`%install`	インストールは、`%{buildroot}` 階層で実行されます。必要なディレクトリーを作成し、インストールされたコードを一時ディレクトリーから `%{buildroot}` 階層にコピーできます。この gem が共有オブジェクトを作成すると、これらはアーキテクチャー固有の `%{gem_extdir_mri}` パスに移動されます。

9.3. RubyGems マクロ
リンクのコピー

RubyGems で作成されたパッケージに役立つ以下のマクロを確認してください。これらのマクロは、rubygems-devel パッケージで提供されています。

Expand

表9.2 RubyGems マクロ
マクロ名	拡張パス	使用方法
`%{gem_dir}`	`/usr/share/gems`	gem 構造のトップディレクトリー。
`%{gem_instdir}`	`%{gem_dir}/gems/%{gem_name}-%{version}`	gem の実際のコンテンツが含まれるディレクトリー。
`%{gem_libdir}`	`%{gem_instdir}/lib`	gem のライブラリーディレクトリー。
`%{gem_cache}`	`%{gem_dir}/cache/%{gem_name}-%{version}.gem`	キャッシュした gem。
`%{gem_spec}`	`%{gem_dir}/specifications/%{gem_name}-%{version}.gemspec`	gem 仕様ファイル。
`%{gem_docdir}`	`%{gem_dir}/doc/%{gem_name}-%{version}`	gem の RDoc ドキュメンテーション。
`%{gem_extdir_mri}`	`%{_libdir}/gems/ruby/%{gem_name}-%{version}`	gem 拡張のディレクトリー。

9.4. gem2rpm を使用して spec ファイルを生成する
リンクのコピー

gem2rpm ユーティリティーを使用して、gem をビルドするための RPM 仕様 ファイルを作成します。

9.4.1. Ruby gem の RPM spec ファイルを作成する
リンクのコピー

gem2rpm ユーティリティーを使用して、RubyGems パッケージの RPM 仕様 ファイルを生成します。

前提条件

システムに gem2rpm ユーティリティーがインストールされている。
```
$ gem install gem2rpm
```

手順

最新バージョンの gem をダウンロードし、この gem の RPM spec ファイルを生成します。
```
$ gem2rpm --fetch <gem_name> > <gem_name>.spec
```
生成された spec ファイルを編集して、ライセンスや変更ログなどの不足している情報を追加します。

9.4.2. カスタム gem2rpm テンプレートを使用して spec ファイルを生成する
リンクのコピー

gem2rpm テンプレートは、RPM spec ファイルを生成できる標準の Embedded Ruby (ERB) ファイルです。生成された 仕様 ファイルを編集するのではなく、RPM 仕様 ファイルが生成されるテンプレートを編集してください。

前提条件

システムに gem2rpm ユーティリティーがインストールされている。
```
$ gem install gem2rpm
```

手順

すべての gem2rpm 組み込みテンプレートを表示します。
```
$ gem2rpm --templates
```
組み込みテンプレートの 1 つを選択し、カスタムテンプレートとして保存します。
```
$ gem2rpm -t <template> -T > rubygem-<gem_name>.spec.template
```
RHEL 10 Beta の場合は、fedora-27-rawhide テンプレートが推奨される点に注意してください。
必要に応じてテンプレートを編集します。詳細は、gem2rpm テンプレート変数を参照してください。

編集したテンプレートを使用して spec ファイルを生成します。

$ gem2rpm -t rubygem-<gem_name>.spec.template <gem_name>-<latest_version>.gem > <gem_name>-GEM.spec

9.4.3. gem2rpm テンプレート変数
リンクのコピー

RPM 仕様 ファイル生成用の gem2rpm テンプレートに含まれる以下の変数を確認してください。

Expand

表9.3 gem2rpm テンプレート内の変数
変数	詳細
`package`	gem の `Gem::Package` 変数。
`spec`	gem の `Gem::Specification` 変数 (`format.spec` と同じ)。
`config`	`spec` テンプレートヘルパーで使用されるデフォルトのマクロまたはルールを再定義できる `Gem2Rpm::Configuration` 変数。
`runtime_dependencies`	パッケージランタイム依存関係のリストを提供する `Gem2Rpm::RpmDependencyList` 変数。
`development_dependencies`	パッケージ開発依存関係のリストを提供する `Gem2Rpm::RpmDependencyList` 変数。
`tests`	実行を許可するテストフレームワークのリストを提供する `Gem2Rpm::TestSuite` 変数。
`files`	パッケージ内のフィルタリングされていないファイルリストを提供する `Gem2Rpm::RpmFileList` 変数。
`main_files`	メインパッケージに適したファイルのリストを提供する `Gem2Rpm::RpmFileList` 変数。
`doc_files`	`-doc` サブパッケージに適したファイルのリストを提供する `Gem2Rpm::RpmFileList` 変数。

ソフトウェアのパッケージ化および配布

RPM パッケージ管理システムを使用したソフトウェアのパッケージ化

Red Hat ドキュメントへのフィードバック (英語のみ)リンクのコピーリンクがクリップボードにコピーされました!

第1章 RPM の概要リンクのコピーリンクがクリップボードにコピーされました!

1.1. RPM パッケージリンクのコピーリンクがクリップボードにコピーされました!

1.2. RPM パッケージ化ユーティリティーのリストリンクのコピーリンクがクリップボードにコピーされました!

第2章 RPM パッケージ化ワークスペースのセットアップリンクのコピーリンクがクリップボードにコピーされました!

2.1. RPM パッケージ化ワークスペースの設定リンクのコピーリンクがクリップボードにコピーされました!

2.2. RPM パッケージ化ワークスペースディレクトリーリンクのコピーリンクがクリップボードにコピーされました!

第3章 RPM マクロリンクのコピーリンクがクリップボードにコピーされました!

3.1. 組み込みの RPM マクロの表示リンクのコピーリンクがクリップボードにコピーされました!

3.2. RPM ディストリビューションマクロの表示リンクのコピーリンクがクリップボードにコピーされました!

3.3. マクロを使用した RPM の動作のカスタマイズリンクのコピーリンクがクリップボードにコピーされました!

3.4. spec ファイルでのカスタム RPM マクロの定義リンクのコピーリンクがクリップボードにコピーされました!

3.5. spec の %files セクションの一般的な RPM ディレクティブリンクのコピーリンクがクリップボードにコピーされました!

3.6. %autosetup および %setup マクロリンクのコピーリンクがクリップボードにコピーされました!

3.6.1. %autosetup マクロのオプションリンクのコピーリンクがクリップボードにコピーされました!

3.6.2. %autopatch マクロのオプションリンクのコピーリンクがクリップボードにコピーされました!

3.6.3. %setup マクロのオプションリンクのコピーリンクがクリップボードにコピーされました!

第4章 RPM パッケージ化を行うためのソフトウェアの作成リンクのコピーリンクがクリップボードにコピーされました!

4.1. ソースコードとはリンクのコピーリンクがクリップボードにコピーされました!

4.2. ソフトウェアの作成方法リンクのコピーリンクがクリップボードにコピーされました!

4.2.1. ネイティブにコンパイルされたソフトウェアリンクのコピーリンクがクリップボードにコピーされました!

4.2.2. インタープリター型ソフトウェアリンクのコピーリンクがクリップボードにコピーされました!

4.3. ソースからのソフトウェアのビルドリンクのコピーリンクがクリップボードにコピーされました!

4.3.1. ネイティブにコンパイルされたコードからのソフトウェアのビルドリンクのコピーリンクがクリップボードにコピーされました!

4.3.1.1. サンプル C プログラムを手動ビルドリンクのコピーリンクがクリップボードにコピーされました!

4.3.1.2. サンプル C プログラムの自動ビルドの設定リンクのコピーリンクがクリップボードにコピーされました!

4.3.2. ソースコードの解釈リンクのコピーリンクがクリップボードにコピーされました!

4.3.2.1. サンプル Python プログラムのバイトコンパイルリンクのコピーリンクがクリップボードにコピーされました!

4.3.2.2. サンプル Bash プログラムの直接解釈リンクのコピーリンクがクリップボードにコピーされました!

第5章 RPM パッケージ化を行うためのソフトウェアの準備リンクのコピーリンクがクリップボードにコピーされました!

5.1. ソフトウェアへのパッチの適用リンクのコピーリンクがクリップボードにコピーされました!

5.1.1. サンプル C プログラムのパッチファイルの作成リンクのコピーリンクがクリップボードにコピーされました!

5.1.2. サンプル C プログラムへのパッチ適用リンクのコピーリンクがクリップボードにコピーされました!

5.2. LICENSE ファイルの作成リンクのコピーリンクがクリップボードにコピーされました!

5.3. 配布用ソースコードアーカイブの作成リンクのコピーリンクがクリップボードにコピーされました!

5.3.1. サンプル Bash プログラムのソースコードアーカイブの作成リンクのコピーリンクがクリップボードにコピーされました!

5.3.2. サンプル Python プログラムのソースコードアーカイブの作成リンクのコピーリンクがクリップボードにコピーされました!

5.3.3. サンプル C プログラムのソースコードアーカイブの作成リンクのコピーリンクがクリップボードにコピーされました!

第6章 ソフトウェアのパッケージ化リンクのコピーリンクがクリップボードにコピーされました!

6.1. spec ファイルについてリンクのコピーリンクがクリップボードにコピーされました!

6.1.1. spec ファイルの Preamble の項目リンクのコピーリンクがクリップボードにコピーされました!

6.1.2. spec ファイルの Body の項目リンクのコピーリンクがクリップボードにコピーされました!

6.1.3. spec ファイルの高度な項目リンクのコピーリンクがクリップボードにコピーされました!

6.1.3.1. スクリプトレットのディレクティブリンクのコピーリンクがクリップボードにコピーされました!

6.1.3.2. スクリプトレットのディレクティブの実行順序リンクのコピーリンクがクリップボードにコピーされました!

6.1.3.3. スクリプトレットの実行をオフにするリンクのコピーリンクがクリップボードにコピーされました!

6.1.3.4. スクリプトレットのマクロの例リンクのコピーリンクがクリップボードにコピーされました!

6.1.4. Epoch ディレクティブリンクのコピーリンクがクリップボードにコピーされました!

6.1.5. パッケージのバージョン管理の基本リンクのコピーリンクがクリップボードにコピーされました!

6.2. spec ファイルの条件分岐リンクのコピーリンクがクリップボードにコピーされました!

6.2.1. %if 条件分岐の使用例リンクのコピーリンクがクリップボードにコピーされました!

6.2.2. %if 条件分岐の特殊なバリアントリンクのコピーリンクがクリップボードにコピーされました!

6.3. BuildRootsリンクのコピーリンクがクリップボードにコピーされました!

6.4. spec ファイルでの作業リンクのコピーリンクがクリップボードにコピーされました!

6.4.1. サンプルの Bash、Python、および C プログラム用の新しい spec ファイルを作成するリンクのコピーリンクがクリップボードにコピーされました!

6.4.2. 元の spec ファイルの変更リンクのコピーリンクがクリップボードにコピーされました!

6.4.3. サンプル Bash プログラムの spec ファイルの例リンクのコピーリンクがクリップボードにコピーされました!

6.4.4. サンプル Python プログラムの spec ファイルの例リンクのコピーリンクがクリップボードにコピーされました!

6.4.5. サンプル C プログラムの spec ファイルの例リンクのコピーリンクがクリップボードにコピーされました!

6.5. RPM のビルドリンクのコピーリンクがクリップボードにコピーされました!

6.5.1. ソース RPM のビルドリンクのコピーリンクがクリップボードにコピーされました!

6.5.2. ソース RPM からのバイナリー RPM の再ビルドリンクのコピーリンクがクリップボードにコピーされました!

6.5.3. spec ファイルからバイナリー RPM をビルドするリンクのコピーリンクがクリップボードにコピーされました!

6.6. RPM アクティビティーの syslog へのロギングリンクのコピーリンクがクリップボードにコピーされました!

6.7. RPM コンテンツの抽出リンクのコピーリンクがクリップボードにコピーされました!

6.8. RPM パッケージへの署名リンクのコピーリンクがクリップボードにコピーされました!

6.8.1. GnuPG を使用した RPM パッケージへの署名リンクのコピーリンクがクリップボードにコピーされました!

6.8.1.1. GnuPG を使用してパッケージに署名するための OpenPGP 鍵の作成リンクのコピーリンクがクリップボードにコピーされました!

6.8.1.2. GnuPG を使用してパッケージに署名するための RPM の設定リンクのコピーリンクがクリップボードにコピーされました!

6.8.1.3. RPM パッケージへの署名の追加リンクのコピーリンクがクリップボードにコピーされました!

6.8.2. Sequoia PGP を使用した RPM パッケージへの署名リンクのコピーリンクがクリップボードにコピーされました!

6.8.2.1. Sequoia PGP を使用してパッケージに署名するための OpenPGP 鍵の作成リンクのコピーリンクがクリップボードにコピーされました!

6.8.2.2. Sequoia PGP を使用してパッケージに署名するための RPM の設定リンクのコピーリンクがクリップボードにコピーされました!

6.8.2.3. RPM パッケージへの署名の追加リンクのコピーリンクがクリップボードにコピーされました!

6.8.3. Sequoia PGP での PQC を使用した RPM パッケージへの署名リンクのコピーリンクがクリップボードにコピーされました!

6.8.3.1. PQC 鍵の作成リンクのコピーリンクがクリップボードにコピーされました!

6.8.3.2. PQC 用の RPM の設定リンクのコピーリンクがクリップボードにコピーされました!

6.8.3.3. RPM に複数の署名を追加するリンクのコピーリンクがクリップボードにコピーされました!

Red Hat ドキュメントへのフィードバック (英語のみ)
リンクのコピー

第1章 RPM の概要
リンクのコピー

1.1. RPM パッケージ
リンクのコピー

1.2. RPM パッケージ化ユーティリティーのリスト
リンクのコピー

第2章 RPM パッケージ化ワークスペースのセットアップ
リンクのコピー

2.1. RPM パッケージ化ワークスペースの設定
リンクのコピー

2.2. RPM パッケージ化ワークスペースディレクトリー
リンクのコピー

第3章 RPM マクロ
リンクのコピー

3.1. 組み込みの RPM マクロの表示
リンクのコピー

3.2. RPM ディストリビューションマクロの表示
リンクのコピー

3.3. マクロを使用した RPM の動作のカスタマイズ
リンクのコピー

3.4. spec ファイルでのカスタム RPM マクロの定義
リンクのコピー

3.5. spec の %files セクションの一般的な RPM ディレクティブ
リンクのコピー

3.6. %autosetup および %setup マクロ
リンクのコピー

3.6.1. %autosetup マクロのオプション
リンクのコピー

3.6.2. %autopatch マクロのオプション
リンクのコピー

3.6.3. %setup マクロのオプション
リンクのコピー

第4章 RPM パッケージ化を行うためのソフトウェアの作成
リンクのコピー

4.1. ソースコードとは
リンクのコピー

4.2. ソフトウェアの作成方法
リンクのコピー

4.2.1. ネイティブにコンパイルされたソフトウェア
リンクのコピー

4.2.2. インタープリター型ソフトウェア
リンクのコピー

4.3. ソースからのソフトウェアのビルド
リンクのコピー

4.3.1. ネイティブにコンパイルされたコードからのソフトウェアのビルド
リンクのコピー

4.3.1.1. サンプル C プログラムを手動ビルド
リンクのコピー

4.3.1.2. サンプル C プログラムの自動ビルドの設定
リンクのコピー

4.3.2. ソースコードの解釈
リンクのコピー

4.3.2.1. サンプル Python プログラムのバイトコンパイル
リンクのコピー

4.3.2.2. サンプル Bash プログラムの直接解釈
リンクのコピー

第5章 RPM パッケージ化を行うためのソフトウェアの準備
リンクのコピー

5.1. ソフトウェアへのパッチの適用
リンクのコピー

5.1.1. サンプル C プログラムのパッチファイルの作成
リンクのコピー

5.1.2. サンプル C プログラムへのパッチ適用
リンクのコピー

5.2. LICENSE ファイルの作成
リンクのコピー

5.3. 配布用ソースコードアーカイブの作成
リンクのコピー

5.3.1. サンプル Bash プログラムのソースコードアーカイブの作成
リンクのコピー

5.3.2. サンプル Python プログラムのソースコードアーカイブの作成
リンクのコピー

5.3.3. サンプル C プログラムのソースコードアーカイブの作成
リンクのコピー

第6章ソフトウェアのパッケージ化
リンクのコピー

6.1. spec ファイルについて
リンクのコピー

6.1.1. spec ファイルの Preamble の項目
リンクのコピー

6.1.2. spec ファイルの Body の項目
リンクのコピー

6.1.3. spec ファイルの高度な項目
リンクのコピー

6.1.3.1. スクリプトレットのディレクティブ
リンクのコピー

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

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

6.1.3.4. スクリプトレットのマクロの例
リンクのコピー

6.1.4. Epoch ディレクティブ
リンクのコピー

6.1.5. パッケージのバージョン管理の基本
リンクのコピー

6.2. spec ファイルの条件分岐
リンクのコピー

6.2.1. %if 条件分岐の使用例
リンクのコピー

6.2.2. %if 条件分岐の特殊なバリアント
リンクのコピー

6.3. BuildRoots
リンクのコピー

6.4. spec ファイルでの作業
リンクのコピー

6.4.1. サンプルの Bash、Python、および C プログラム用の新しい spec ファイルを作成する
リンクのコピー

6.4.2. 元の spec ファイルの変更
リンクのコピー

6.4.3. サンプル Bash プログラムの spec ファイルの例
リンクのコピー

6.4.4. サンプル Python プログラムの spec ファイルの例
リンクのコピー

6.4.5. サンプル C プログラムの spec ファイルの例
リンクのコピー

6.5. RPM のビルド
リンクのコピー

6.5.1. ソース RPM のビルド
リンクのコピー

6.5.2. ソース RPM からのバイナリー RPM の再ビルド
リンクのコピー

6.5.3. spec ファイルからバイナリー RPM をビルドする
リンクのコピー

6.6. RPM アクティビティーの syslog へのロギング
リンクのコピー

6.7. RPM コンテンツの抽出
リンクのコピー

6.8. RPM パッケージへの署名
リンクのコピー

6.8.1. GnuPG を使用した RPM パッケージへの署名
リンクのコピー

6.8.1.1. GnuPG を使用してパッケージに署名するための OpenPGP 鍵の作成
リンクのコピー

6.8.1.2. GnuPG を使用してパッケージに署名するための RPM の設定
リンクのコピー

6.8.1.3. RPM パッケージへの署名の追加
リンクのコピー

6.8.2. Sequoia PGP を使用した RPM パッケージへの署名
リンクのコピー

6.8.2.1. Sequoia PGP を使用してパッケージに署名するための OpenPGP 鍵の作成
リンクのコピー

6.8.2.2. Sequoia PGP を使用してパッケージに署名するための RPM の設定
リンクのコピー

6.8.2.3. RPM パッケージへの署名の追加
リンクのコピー

6.8.3. Sequoia PGP での PQC を使用した RPM パッケージへの署名
リンクのコピー

6.8.3.1. PQC 鍵の作成
リンクのコピー

6.8.3.2. PQC 用の RPM の設定
リンクのコピー

6.8.3.3. RPM に複数の署名を追加する
リンクのコピー

第7章 Python 3 RPM のパッケージ化
リンクのコピー

7.1. Python パッケージの例に対する spec ファイルの説明
リンクのコピー