red hat enterprise linux 7 rpm パッケージングガ …...bash で書かれた hello world:...

Red Hat Enterprise Linux 7

RPM パッケージングガイド

RPM パッケージマネージャーを使用した基本および高度なソフトウェアパッケージングシナリオ

Last Updated: 2020-02-21

Red Hat Enterprise Linux 7 RPM パッケージングガイド

RPM パッケージマネージャーを使用した基本および高度なソフトウェアパッケージングシナリオ

Marie DoleželováRed Hat Customer Content [email protected]

Maxim SvistunovRed Hat Customer Content Services

Adam MillerRed Hat

Adam KvítekRed Hat Customer Content Services

Petr KovářRed Hat Customer Content Services

Miroslav SuchýRed Hat

Customer Content Services [email protected]

法律上の通知法律上の通知

Copyright © 2020 Red Hat, Inc.

The text of and illustrations in this document are licensed by Red Hat under a Creative CommonsAttribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA isavailable athttp://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you mustprovide the URL for the original version.

Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert,Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.

Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift,Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United Statesand other countries.

Linux ® is the registered trademark of Linus Torvalds in the United States and other countries.

Java ® is a registered trademark of Oracle and/or its affiliates.

XFS ® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United Statesand/or other countries.

MySQL ® is a registered trademark of MySQL AB in the United States, the European Union andother countries.

Node.js ® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by theofficial Joyent Node.js open source or commercial project.

The OpenStack ® Word Mark and OpenStack logo are either registered trademarks/service marksor trademarks/service marks of the OpenStack Foundation, in the United States and othercountries and are used with the OpenStack Foundation's permission. We are not affiliated with,endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.

All other trademarks are the property of their respective owners.

概要概要

RPM パッケージングガイドでは、RPM へのソフトウェアパッケージングについて説明します。また、パッケージ化するソースコードを準備する方法も説明します。最後に、このガイドでは、選択した高度なパッケージ化シナリオについて説明しています。

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

目次目次

第第1章章はじめにはじめに1.1. ドキュメント規則1.2. 前提条件

第第2章章 RPM を使用したパッケージソフトウェアの理由を使用したパッケージソフトウェアの理由

第第3章章初めての初めての RPM パッケージパッケージ

第第4章章パッケージ化を行うためのソフトウェアの準備パッケージ化を行うためのソフトウェアの準備4.1. ソースコードとは?4.2. プログラムができる仕組み4.3. ソースからのソフトウェア構築4.4. ソフトウェアへのパッチの適用4.5. 任意のアーティファクトのインストール4.6. パッケージ化を行うためのソースコードの準備4.7. ソースコードの TARBALL への配置

第第5章章ソフトウェアの更新ソフトウェアの更新5.1. RPM パッケージ5.2. RPM の構築5.3. RPM のサニティーの確認

第第6章章高度なトピック高度なトピック6.1. パッケージの署名6.2. マクロの詳細6.3. カスタムマクロ6.4. EPOCH、SCRIPTLETS、TRIGGERS6.5. RPM 条件

付録付録A RHEL 7 のの RPM の新機能の新機能

付録付録B リファレンスリファレンス

333

5

6

8899

12141616

1919

3941

464649535457

60

61

目次目次

1

Red Hat Enterprise Linux 7 RPM パッケージングガイドパッケージングガイド

2

第1章はじめにRPM パッケージングガイドのドキュメント:

ソースコードのソースコードの RPM へのパッケージ化の準備方法。へのパッケージ化の準備方法。

これは、ソフトウェア開発経験のないユーザー向けです。4章パッケージ化を行うためのソフトウェアの準備を参照してください。

RPM にソースコードをパッケージ化する方法。にソースコードをパッケージ化する方法。

これは、ソフトウェアを RPM にパッケージ化する必要があるソフトウェア開発者を対象にしています。5章ソフトウェアの更新を参照してください。

高度なパッケージ化シナリオ。高度なパッケージ化シナリオ。

これは、高度な RPM パッケージ化シナリオに対応する RPM パッケージャーの参照資料です。6章高度なトピックを参照してください。

1.1. ドキュメント規則

このドキュメントでは、以下の慣例を使用しています。

コマンドの出力と、ソースコードを含むテキストファイルの内容はブロックに置かれます。

興味のあるトピックや語彙単語は、太字太字またはイタリックイタリックのいずれかで、それぞれの文書やWeb に対する URL として参照されます。

コードで見つかったユーティリティー、コマンド、およびこれら名は通常、monospace フォントで書かれています。

1.2. 前提条件

このチュートリアルをたどるには、以下のパッケージをインストールする必要があります。

注記注記

$ tree ~/rpmbuild//home/user/rpmbuild/|-- BUILD|-- RPMS

[command output trimmed]

Name: belloVersion:Release: 1%{?dist}Summary:

[file contents trimmed]

#!/usr/bin/env python

print("Hello World")

第第1章章はじめにはじめに

3

注記注記

これらの一部のパッケージは、RHEL にデフォルトでインストールされています。これらは、本ガイドで使用されているツールを明示的に指定するために明示的に一覧表示されています。

$ yum install gcc rpm-build rpm-devel rpmlint make python bash coreutils diffutils patch rpmdevtools


4

https://www.redhat.com/en/technologies/linux-platforms

第2章 RPM を使用したパッケージソフトウェアの理由RPM Package Manager (RPM) は、Red Hat Enterprise Linux、CentOS、および Fedora で実行できるパッケージ管理システムです。RPM を使用すると、Red Hat Enterprise Linux、CentOS、およびFedora 用に作成したソフトウェアの配布、管理、および更新が容易になります。多くのソフトウェアベンダーは、従来のアーカイブファイル (tarball など) でソフトウェアを配布します。ただし、RPMパッケージにソフトウェアをパッケージ化すると、いくつかの利点があります。これらの利点は以下のとおりです。

RPM を使用すると、以下が可能になります。

パッケージのインストール、再インストール、削除、アップグレード、および検証パッケージのインストール、再インストール、削除、アップグレード、および検証

ユーザーは、標準のパッケージ管理ツール (Yum や PackageKit など) を使用して、RPM パッケージのインストール、再インストール、削除、アップグレード、および検証を行うことができます。

インストール済みのパッケージのデータベースを使用した、パッケージのクエリーと検証インストール済みのパッケージのデータベースを使用した、パッケージのクエリーと検証

RPM はインストールしたパッケージとそのファイルのデータベースを維持するので、ユーザーは、システムのパッケージを簡単にクエリーし、検証することができます。

メタデータを使用して、パッケージ、それらのインストール手順などを記述します。メタデータを使用して、パッケージ、それらのインストール手順などを記述します。

各 RPM パッケージには、パッケージのコンポーネント、バージョン、リリース、サイズ、プロジェクト URL、インストール手順などを記述するメタデータが含まれています。

ソースパッケージとバイナリーパッケージへの元のソフトウェアソースのパッケージ化ソースパッケージとバイナリーパッケージへの元のソフトウェアソースのパッケージ化

RPM を使用すると、元のソフトウェアのソースを取得して、ユーザーのためにソースパッケージやバイナリーパッケージにパッケージ化することができます。ソースパッケージでは、使用しているパッチと、完全なビルド命令とともに、元のソースを使用できます。この設計により、新しいバージョンのソフトウェアがリリースされると、パッケージのメンテナンスが簡単になります。

Yum リポジトリーへのパッケージの追加リポジトリーへのパッケージの追加

Yum リポジトリーにパッケージを追加すると、クライアントがソフトウェアを見つけ、デプロイできるようになります。

パッケージへのデジタル署名パッケージへのデジタル署名

GPG 署名鍵を使用すると、パッケージにデジタル署名し、ユーザーがパッケージの信頼性を検証できるようになります。

第第2章章 RPM を使用したパッケージソフトウェアの理由を使用したパッケージソフトウェアの理由

5

第3章初めての RPM パッケージRPM パッケージの作成は複雑になる可能性があります。以下では、複数のことをスキップし、簡素化した完全で利用できる RPM Spec ファイルです。

このファイルを hello-world.spec として保存します。

ここで、以下のコマンドを使用します。

コマンド rpmdev-setuptree は、複数の作業ディレクトリーを作成します。これらのディレクトリーは$HOME に永続的に格納されているため、このコマンドを再び使用する必要はありません。

コマンド rpmbuild は、実際の rpm パッケージを作成します。このコマンドの出力は、以下のようになります。

Name: hello-worldVersion: 1Release: 1Summary: Most simple RPM packageLicense: FIXME

%descriptionThis is my first RPM package, which does nothing.

%prep# we have no source, so nothing here

%buildcat > hello-world.sh

/home/mirek/rpmbuild/RPMS/x86_64/hello-world-1-1.x86_64.rpm ファイルが、最初の RPM パッケージです。これはシステムにインストールしてテストできます。

第第3章章初めての初めての RPM パッケージパッケージ

7

第4章パッケージ化を行うためのソフトウェアの準備本章では、RPM Packager に必要な背景である、ソースコードとソフトウェア作成について説明します。

4.1. ソースコードとは?

ソースコードソースコードとは、人間が読むことのできる、コンピューターへの命令文で、計算タスクをコンピューターに伝えるものです。ソースコードは、プログラミング言語で書かれます。

このチュートリアルでは、3 つのバージョンの Hello World プログラムがあり、それぞれが異なるプログラミング言語で記述されています。このつの言語で書かれたプログラムはそれぞれパッケージ化され、RPM パッケージャーのつの主要なユースケースに対応します。

注記注記

プログラミングには、数千という言語が存在します。本書ではこれらの機能についてのみ説明しますが、概念的な概要については十分です。

bash で書かれた Hello World:

bello

Python で書かれた Hello World:

pello.py

C で書かれた Hello World:

cello.c

3 つのすべてのプログラムの目的は、コマンドラインで Hello World を出力することです。

注記注記

プログラムの方法を学ぶことは、ソフトウェアパッケージ作成者にとって必須ではありませんが、便利です。

#!/bin/bash

printf "Hello World\n"



#include

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


8

https://www.gnu.org/software/bash/https://www.python.org/

4.2. プログラムができる仕組み

人間が判読できるソースコードをマシンコードに変換する方法は数多くあります。マシンコードに変えるとはつまり、コンピューターがプログラムを実際に実行する命令です。ただし、すべての方法は以下の 3 つに絞ることができます。

1. プログラムがネイティブにコンパイルされる。

2. プログラムがマシンコードの解釈により、解釈される。

3. プログラムがバイトコンパイルによって解釈される。

4.2.1. ネイティブにコンパイルされたコード

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

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

4.2.2. 解釈されたコード

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

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

インタープリター言語は、バイトコンパイルバイトコンパイルまたは Raw インタープリターインタープリターのいずれかです。これら 2つは、パッケージ化作業のプログラムビルドプロセスにおいて異なります。

4.2.2.1. Raw インタープリタープログラムインタープリタープログラム

Raw インタープリター言語プログラムはコンパイルする必要はなく、インタープリターにより直接実行されます。

4.2.2.2. バイトコンパイルプログラムバイトコンパイルプログラム

バイトコンパイル言語は、バイトコードにコンパイルして、その言語の仮想マシンにより実行される必要があります。

注記注記

一部の言語では、raw インタープリターとバイトコンパイルを選ぶことができます。

4.3. ソースからのソフトウェア構築

本セクションでは、ソースコードからソフトウェアを構築する方法を説明します。

コンパイル言語で書かれたソフトウェアの場合、ソースコードはビルドビルドプロセスを経て、マシ

第第4章章パッケージ化を行うためのソフトウェアの準備パッケージ化を行うためのソフトウェアの準備

9


ンコードを生成します。このプロセスは、コンパイルコンパイルまたはトランスレートトランスレートとよばれ、さまざまな言語で異なります。その結果構築されるソフトウェアは実行実行または起動起動できるようになります。これにより、コンピューターがプログラマーで指定されたタスクを実行するようになります。

raw インタープリター言語で書かれたソフトウェアの場合、ソースコードは構築されず、直接実行されます。

バイトコンパイル型のインタープリター言語で書かれたソフトウェアの場合、ソースコードがバイトコードにコンパイルされ、その言語の仮想マシンによって実行されます。

4.3.1. ネイティブにコンパイルされたコード

この例では、C 言語で書かれた cello.c プログラムを実行可能ファイルに構築します。

cello.c

4.3.1.1. 手動による構築手動による構築

GNU コンパイラーコレクション (GCC) から C コンパイラを起動し、ソースコードをバイナリーにコンパイルします。

生成された出力バイナリー cello を実行します。

以上です。ソースコードからネイティブにコンパイルされたソフトウェアを構築して実行しました。

4.3.1.2. 自動ビルド自動ビルド

ソースコードの手動構築の代わりに、ビルドは自動化できます。これは、大規模なソフトウェアで使用される一般的な方法です。自動ビルドは、Makefile を作成してから、GNU make ユーティリティーを実行して行われます。

自動ビルドを設定するには、cello.c と同じディレクトリーに Makefile という名前のファイルを作成します。

Makefile

#include

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

gcc -g -o cello cello.c

$ ./celloHello World

cello: gcc -g -o cello cello.c

clean: rm cello


10

https://gcc.gnu.org/http://www.gnu.org/software/make/

ソフトウェアを構築するには、make を実行します。

ビルドがすでに存在しているため、make clean し、make を再び実行します。

ここでも、別のビルドを実行してもビルドは行われません。

最後に、プログラムを実行します。

これで、ビルドツールを使用した手動によるプログラムのコンパイルが完了しました。

4.3.2. 解釈されたコード

次の 2 つの例は、Python で書かれたプログラムのバイトコンパイルと、bash で書かれた、そのままのインタープリター処理プログラムのケースを示しています。

注記注記

以下の 2 つの例では、ファイルの一番上の #! 行は、シバンと呼ばれるもので、プログラミング言語ソースコードの一部ではありません。

シバンシバンにより、実行ファイルとしてテキストファイルを使用できるようになります。システムプログラムローダーは、シバンを含む行を解析して、バイナリーの実行ファイルへのパスを取得します。これは、プログラミング言語インタープリターとして使用されます。

4.3.2.1. バイトコンパイルコードバイトコンパイルコード

この例では、Python で書かれた pello.py プログラムをバイトコードにコンパイルし、Python 言語の仮想マシンで実行する方法を説明します。Python のソースコードは、そのまま解釈することも可能ですが、バイトコンパイルバージョンの方が高速です。したがって、RPM パッケージャーは、エンドユーザーが配布するバージョンにはバイトコンパイルのパッケージ化を推奨しています。

pello.py

$ makemake: 'cello' is up to date.

$ make cleanrm cello

$ makegcc -g -o cello cello.c

$ makemake: 'cello' is up to date.

$ ./celloHello World




11

https://www.python.org/https://www.gnu.org/software/bash/

プログラムのバイトコンパイル手順は、言語によって異なります。これは、言語、その言語の仮想マシン、その言語で使用するツールおよびプロセスによって異なります。

注記注記

Python はよくバイトコンパイルされますが、ここでは説明しません。以下の手順は、コミュニティーの標準に準拠するのではなく、簡潔さを重視しています。実際の Python ガイドラインは「Software Packaging and Distribution」を参照してください。

pello.py のバイトコンパイル:

pello.pyc のバイトコードを実行します。

4.3.2.2. そのままインタープリター処理されたコードそのままインタープリター処理されたコード

この例では、bash シェルの組み込み言語で書かれた bello プログラムをそのままインタープリター処理する方法を示しています。

bello

bash などのシェルスクリプト言語で書かれたプログラムはそのまま解釈されます。そのため、ソースコードのファイルを実行可能にして、実行することのみが必要です。

4.4. ソフトウェアへのパッチの適用

パッチパッチとは、その他のソースコードを更新するソースコードです。これは、2 つのバージョンのテキストの差を示すため、diff としてフォーマットされます。diff は、diff ユーティリティーを使用して作成されます。これは、パッチユーティリティーを使用してソースコードに適用されます。

注記注記

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

以下の例では、diff を使用して元のソースコードからパッチを作成し、パッチパッチ使用して適用します。後

$ python -m compileall pello.py

$ file pello.pycpello.pyc: python 2.7 byte-compiled

$ python pello.pycHello World

#!/bin/bash

printf "Hello World\n"

$ chmod +x bello$ ./belloHello World


12

https://www.python.org/https://docs.python.org/2/library/distribution.htmlhttps://www.gnu.org/software/bash/http://savannah.gnu.org/projects/patch/https://git-scm.com/

以下の例では、diff を使用して元のソースコードからパッチを作成し、パッチパッチ使用して適用します。後半のセクションで RPM を作成するときにパッチを適用します。「SPEC ファイルでの作業」を参照してください。

RPM パッケージングにパッチが関連する仕組みパッケージングでは、元のソースコードを単に変更するのではなく、コードを維持し、それにパッチを使用します。

cello.c のパッチを作成する方法:

1. 元のソースコードを保持します。

これは、元のソースコードファイルを保持する一般的な方法です。

2. cello.c を変更します。

3. diff ユーティリティーを使用してパッチを生成します。

注記注記

diff ユーティリティーには、いくつかの一般的な引数を使用します。詳細は、man ページの diff を参照してください。

- で始まる行は、元のソースコードから削除され、+ で始まる行に置き換えられます。

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

5. 元の cello.c を復元します。

RPM を構築するときは変更後のファイルではなく、元のファイルが使用されるため、元の

$ cp cello.c cello.c.orig

#include

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

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

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

$ cp cello.c.orig cello.c


13

RPM を構築するときは変更後のファイルではなく、元のファイルが使用されるため、元の cello.c を保持します。詳細は「SPEC ファイルでの作業」を参照してください。

cello-output-first-patch.patch を使用して cello.c にパッチを適用するには、パッチファイルを patchコマンドにリダイレクトします。

cello.c の内容がパッチを反映しています。

パッチが適用された cello.c を構築して実行します。

パッチを作成し、プログラムに適用して、パッチが適用されたプログラムを構築し、実行しました。

4.5. 任意のアーティファクトのインストール

Linux およびその他の Unix と同様のシステムの大きな利点は、ファイルシステム階層標準 (FHS) です。これは、ファイルが置かれるディレクトリーを指定します。RPM パッケージからインストールしたファイルは、FHS に従って配置されル必要があります。たとえば、実行ファイルは、システム$PATH 変数のディレクトリーに置く必要があります。

本ガイドのコンテキストでは、任意アーティファクト任意アーティファクトは RPM からシステムにインストールされたものを意味します。RPM およびシステムの場合は、スクリプト、パッケージのソースコードからコンパイルしたバイナリー、事前にコンパイルしたバイナリー、またはその他のファイルを意味します。

システムに任意アーティファクト任意アーティファクトを配置する一般的な方法を説明します。これには、install コマンドを使用し、make install コマンドを使用します。

4.5.1. install コマンドの使用

GNU make などのビルド自動化ツールを使用することが最適ではない場合もあります。たとえば、パッケージ化したプログラムがシンプルで、追加のオーバーヘッドが不要な場合がこれに当たります。これらのケースでは、パッケージャーは install コマンドを使用するのが一般的です (coreutils)。このコマンドは、指定のパーミッションセットで、ファイルシステム内の指定したディレクトリーにアーティファクトを配置します。

$ patch < cello-output-first-patch.patchpatching file cello.c

$ cat cello.c#include

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

$ make cleanrm cello


$ ./celloHello World from my very first patch!


14

http://www.gnu.org/software/make/http://www.gnu.org/software/coreutils/coreutils.html

以下の例は、インストール方法に対する任意アーティファクトとして以前に作成した bello を使用します。このコマンドには sudo パーミッションが必要になります。または sudo 部分を除いて root で実行する必要があります。

以下の例では、install では、bello ファイルが、実行可能なスクリプトに一般的なパーミッションを持つ /usr/bin に配置されます。

bello は、$PATH 変数に一覧表示されているディレクトリーにあります。フルパスを指定せずに、任意のディレクトリーから bello を実行できます。

4.5.2. make install コマンドの使用

システムに構築したソフトウェアをインストールする最も一般的な自動的な手段は、make install コマンドを実行することです。Makefile においてシステムに任意のアーティファクトをインストールする方法を指定する必要があります。

注記注記

通常、Makefile は、パッケージ管理者ではなく、開発者が作成するものです。

Makefile に install セクションを追加します。

Makefile

$(DESTDIR) 変数は GNU make 組み込みで、一般的には、root ディレクトリーとは異なるディレクトリーへのインストールを指定するために使用されます。

これで、Makefile を使用してソフトウェアを構築するだけでなく、ターゲットシステムへのインストールも可能になります。

cello.c プログラムを構築してインストールします。

$ sudo install -m 0755 bello /usr/bin/bello

$ cd ~

$ belloHello World

cello: gcc -g -o cello cello.c

clean: rm cello

install: mkdir -p $(DESTDIR)/usr/bin install -m 0755 cello $(DESTDIR)/usr/bin/cello



15

http://www.sudo.ws/https://www.gnu.org/software/make/manual/html_node/DESTDIR.htmlhttp://www.gnu.org/software/make/

cello は、$PATH 変数に一覧表示されているディレクトリーにあります。そのため、完全パスを指定せずに、任意のディレクトリーから cello を実行できます。

構築アーティファクトをシステム上の選択した場所にインストールしました。

4.6. パッケージ化を行うためのソースコードの準備

注記注記

このセクションで作成したコードは、こちらにあります。

開発者は、ソースコードの圧縮アーカイブとしてソフトウェアを配布するため、パッケージの作成に使用されます。このセクションでは、このような圧縮アーカイブを作成します。

注記注記

ソースコードアーカイブの作成は通常、開発者ではなく、RPM パッケージャーが行います。パッケージャーは、準備の整ったソースコードアーカイブと連携します。

ソフトウェアは、ソフトウェアライセンスとともに配布する必要があります。この例では、GPLv3 ライセンスを使用します。ライセンステキストは、サンプルプログラムごとに LICENSE ファイルに入ります。RPM パッケージャーは、パッケージ化を行う際にライセンスファイルを扱う必要があります。

以下の例で使用するには、LICENSE ファイルを作成します。

4.7. ソースコードの TARBALL への配置

以下の例では、これらつの Hello World プログラムを gzip 圧縮の tarball に追加します。多くのソフトウェアは、配布用に後でパッケージ化される方法でリリースされます。

$ sudo make installinstall -m 0755 cello /usr/bin/cello

$ cd ~

$ celloHello World

$ cat /tmp/LICENSEThis program is free software: you can redistribute it and/or modifyit under the terms of the GNU General Public License as published bythe 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 ofMERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See theGNU General Public License for more details.

You should have received a copy of the GNU General Public Licensealong with this program. If not, see .


16

https://github.com/redhat-developer/rpm-packaging-guide/tree/master/example-codehttps://www.gnu.org/licenses/quick-guide-gplv3.htmlhttps://www.gnu.org/software/gzip/

4.7.1. bello

bello プロジェクトは、bash で Hello World を実装しています。この実装には bello シェルスクリプトのみが含まれるため、生成される tar.gz アーカイブには LICENSE ファイルとは別のファイルのみが含まれます。このプログラムのバージョンが 0.1 であることを前提としています。

配布用に bello プロジェクトを準備します。

1. ファイルを単一のディレクトリーに配置します。

2. ディストリビューション用のアーカイブを作成し、~/rpmbuild/SOURCES/ に移動します。

4.7.2. pello

pello プロジェクトは、 Python に Hello World を実装します。この実装には pello.py プログラムのみが含まれるため、生成された tar.gz アーカイブには LICENSE ファイルとは異なる単一のファイルのみが含まれます。このプログラムのバージョンは 0.1.1 であることを前提とします。

pello プロジェクトを配布するために準備します。



$ mkdir /tmp/bello-0.1

$ mv ~/bello /tmp/bello-0.1/

$ cp /tmp/LICENSE /tmp/bello-0.1/

$ cd /tmp/

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

$ mv /tmp/bello-0.1.tar.gz ~/rpmbuild/SOURCES/

$ mkdir /tmp/pello-0.1.1

$ mv ~/pello.py /tmp/pello-0.1.1/

$ cp /tmp/LICENSE /tmp/pello-0.1.1/

$ cd /tmp/

$ tar -cvzf pello-0.1.1.tar.gz pello-0.1.1pello-0.1.1/pello-0.1.1/LICENSEpello-0.1.1/pello.py

$ mv /tmp/pello-0.1.1.tar.gz ~/rpmbuild/SOURCES/


17


4.7.3. cello

cello プロジェクトは、C で Hello World を実装しています。この実装には cello.c および Makefileファイルのみが含まれるため、生成される tar.gz アーカイブには LICENSE ファイルとは別の 2 つのファイルのみが含まれます。このプログラムのバージョンは 1.0 であることを前提としています。

パッチパッチファイルは、プログラムとともにアーカイブで配布されないことに注意してください。RPMPackager は、RPM を構築する際にパッチを適用します。このパッチは、.tar.gz とともに、~/rpmbuild/SOURCES/ ディレクトリーに配置されます。

cello プロジェクトを配布できるように準備します。



3. パッチを追加します。

これで、ソースコードが RPM にパッケージ化できるようになりました。

$ mkdir /tmp/cello-1.0

$ mv ~/cello.c /tmp/cello-1.0/

$ mv ~/Makefile /tmp/cello-1.0/

$ cp /tmp/LICENSE /tmp/cello-1.0/

$ cd /tmp/

$ tar -cvzf cello-1.0.tar.gz cello-1.0cello-1.0/cello-1.0/Makefilecello-1.0/cello.ccello-1.0/LICENSE

$ mv /tmp/cello-1.0.tar.gz ~/rpmbuild/SOURCES/

$ mv ~/cello-output-first-patch.patch ~/rpmbuild/SOURCES/


18

第5章ソフトウェアの更新このチュートリアルでは、Linux ディストリビューションの Red Hat Linux ファミリー (主に Red HatEnterprise Linux (RHEL)) の RPM のパッケージ化について説明します。

RHEL はターゲット環境ですが、本ガイドはほとんどの RPM ベースのディストリビューションに対応しています。ただし、前提条件のインストール項目、ガイドライン、マクロなど、ディストリビューション固有の機能については、調整が必要です。

このチュートリアルでは、いかなるオペレーティングシステム (Linux) のソフトウェアのパッケージ化に関する予備知識もないことを前提としています。

5.1. RPM パッケージ

このセクションでは、RPM パッケージ形式の基本を説明します。詳細は 6章高度なトピックを参照してください。

5.1.1. RPM とは

RPM パッケージは、システムに必要とされる他のファイルと情報を含むファイルです。特に、RPMパッケージは、ファイルを含む cpio アーカイブ、パッケージに関するメタデータを含む RPM ヘッダーで構成されます。rpm パッケージマネージャーはこのメタデータを使用して依存関係、ファイルのインストール先、およびその他の情報を決定します。

RPM パッケージには、以下の 2 つのタイプがあります。

ソース RPM (SRPM)

バイナリー RPM

SRPM およびバイナリー RPM も、同じファイル形式とツールを使用しますが、コンテンツが異なるため、目的が異なります。SRPM には、ソースコードと (オプションでパッチ) SPEC ファイルが含まれます。これには、ソースコードをバイナリー RPM にビルドする方法が書かれています。バイナリー RPMには、ソースおよびパッチから構築されたバイナリーが含まれます。

5.1.2. RPM パッケージ化ツール

「前提条件」にインストールされている rpmdevtools パッケージは、RPM をパッケージ化するためのいくつかのユーティリティーを提供します。これらのユーティリティーを一覧表示するには、以下のコマンドを実行します。

上記のユーティリティーの詳細は、各のマニュアルページまたはヘルプダイアログを参照してください。

5.1.3. RPM パッケージングワークスペース

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

$ rpm -ql rpmdevtools | grep bin

$ rpmdev-setuptree

$ tree ~/rpmbuild/

第第5章章ソフトウェアの更新ソフトウェアの更新

19

https://www.redhat.com/en/technologies/linux-platforms

作成されたディレクトリーは、以下の目的で使用します。

ディレクトリー目的

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

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

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

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

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

5.1.4. SPEC ファイルとは?

SPEC ファイルは、RPM を実際に構築するために rpmbuild ユーティリティーが使用する「レシピ」として考えることができます。これは、一連のセクションで命令を定義することで、ビルドシステムに命令しま本クションでは、Preamble と Body 部分で定義されます。Preamble には、Body に使用されている一連のメタデータ項目が含まれています。Body には、命令の主要部分が含まれています。

5.1.4.1. Preamble 項目項目

以下の表では、RPM SPEC ファイルの Preamble セクションで使用される項目を示しています。

SPEC ディレクティブ定義

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

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

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

Summary パッケージの 1 行の概要

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

5 directories, 0 files


20

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

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

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

Patch0 必要に応じて、ソースコードに適用する最初のパッチの名前。必要に応じて、より PatchX ディレクティブを追加できます。この X の値はたとえば、Patch1、Patch2、Patch3 など、毎回増分します。

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

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

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

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

Name、Version、および Release のディレクティブは、RPM パッケージのファイル名から成ります。RPM パッケージの担当者やシステム管理者は、これら 3 つのディレクティブを N-V-R、NVR と呼びます。これは、RPM パッケージのファイル名に NAME-VERSION-RELEASE 形式が含まれるためです。

特定のパッケージに対して rpm を使用してクエリーを実行し、NAME-VERSION-RELEASE の例を取得できます。

ここでは、python が Package Name で、2.7.5 がバージョンで、34.el7 がリリースです。最後のマーカーの x86_64 は、アーキテクチャーを意味しています。NVR とは異なり、アーキテクチャーのマーカーは RPM パッケージャーで直接管理されていませんが、rpmbuild ビルド環境で定義されます。ただし、これはアーキテクチャーに依存しない noarch パッケージです。

5.1.4.2. Body 項目項目

$ rpm -q pythonpython-2.7.5-34.el7.x86_64


21

以下の表では、RPM SPEC ファイルの Body セクションで使用される項目を取り上げます。

SPEC ディレクティブ

定義

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

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

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

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

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

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

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

5.1.4.3. 高度な項目高度な項目

SPEC ファイルには、高度な項目を含めることもできます。たとえば、SPEC ファイルにはスクリプトスクリプトレットレットとトリガートリガーを含めることができます。これは、ビルドプロセスではなく、エンドユーザーのシステムのインストールプロセスの際のさまざまな地点で有効になります。

高度なトピックについては、「Scriptlets と Triggers」を参照してください。

5.1.5. BuildRoots

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

「buildroot」のファイルは、後で dhcpd アーカイブに配置され、RPM の主要部分になります。RPMがエンドユーザーのシステムにインストールされている場合、これらのファイルは root ディレクトリーに抽出され、階層が正しく保持されます。

注記注記


22

注記注記

Red Hat Enterprise Linux 6 リリース以降では、rpmbuild プログラムには独自のデフォルトが設定されています。このデフォルト値を上書きすると、問題が発生することがあります。そのため、Red Hat では、このマクロの値を自身で定義しないことをすすめています。%{buildroot} マクロは rpmbuild ディレクトリーのデフォルトで使用できます。

5.1.6. RPM マクロ

rpm マクロは、特定の組み込み機能が使用されている場合に、ステートメントのオプションの評価に基づいて、条件付きで割り当てられる直接的なテキスト置換です。つまり、RPM に、ユーザーが行う必要のなりテキスト置換を行わせることができます。

これは、たとえば、SPEC ファイルでパッケージ化されたソフトウェア Version を複数回参照する場合などに便利です。Version は 1 度のみ (%{version} マクロで) 定義することができます。次に、SPECファイル全体で %{version} を使用します。すべては、以前に定義した Version に自動的に置き換えられます。

注記注記

見たことのないマクロが表示されている場合は、以下のように評価できます。

以下に例を示します。

一般的なマクロは %{?dist} で、「ディストリビューションタグ」に通知されます。これは、ビルドに使用されるディストリビューションを示します。

以下に例を示します。

マクロの詳細は、「マクロの詳細」を参照してください。

5.1.7. SPEC ファイルでの作業

RPM へのソフトウェアパッケージ化で最も大がかりな作業は、SPEC ファイルを編集することです。このセクションでは、仕様ファイルを作成し、変更する方法を説明します。

新しいソフトウェアをパッケージ化するには、新しい SPEC ファイルを作成する必要があります。手動で記述するのではなく、rpmdev-newspec ユーティリティーを使用します。このユーティリティーは、実装していない SPEC ファイルを作成し、必要なディレクティブとフィールドを入力します。

このチュートリアルでは、4章パッケージ化を行うためのソフトウェアの準備で作成した「Hello

$ rpm --eval %{_MACRO}

$ rpm --eval %{_bindir}/usr/bin

$ rpm --eval %{_libexecdir}/usr/libexec

# On a RHEL 7.x machine$ rpm --eval %{?dist}.el7


23

http://rpm.org/user_doc/macros.html

このチュートリアルでは、4章パッケージ化を行うためのソフトウェアの準備で作成した「HelloWorld!」プログラムの実装例を使用します。

bello-0.1.tar.gz

pello-0.1.1.tar.gz

cello-1.0.tar.gz

cello-output-first-patch.patch

~/rpmbuild/SOURCES に配置します。

各 3 つのプログラムに SPEC ファイルを作成します。

注記注記

プログラマーに焦点を合わせたテキストエディターの中には、独自の SPEC テンプレートで新しい .spec ファイルを事前に準備しているものもあります。rpmdev-newspec では、エディターに依存しない方法を利用できます。

~/rpmbuild/specs/ ディレクトリーには、bello.spec、cello.spec、および pello.spec という名前の 3つの SPEC ファイルが含まれています。

ファイルを調べます。そのディレクティブは、「SPEC ファイルとは?」セクションで説明されているディレクティブを表します。以下のセクションでは、これらの SPEC ファイルを作成します。

注記注記

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

以下に示す 3 つの例を見てみましょう。それぞれの手順が完全に説明されるため、パッケージのニーズに一致する場合は特定のファイルに移動できます。別のソフトウェアのパッケージ化を完全に調べる場合は、すべてお読みください。

ソフトウェア名

例の説明

$ cd ~/rpmbuild/SPECS

$ rpmdev-newspec bellobello.spec created; type minimal, rpm version >= 4.11.

$ rpmdev-newspec cellocello.spec created; type minimal, rpm version >= 4.11.

$ rpmdev-newspec pellopello.spec created; type minimal, rpm version >= 4.11.


24

https://github.com/redhat-developer/rpm-packaging-guide/raw/master/example-code/bello-0.1.tar.gzhttps://github.com/redhat-developer/rpm-packaging-guide/raw/master/example-code/pello-0.1.1.tar.gzhttps://github.com/redhat-developer/rpm-packaging-guide/raw/master/example-code/cello-1.0.tar.gzhttps://raw.githubusercontent.com/redhat-developer/rpm-packaging-guide/master/example-code/cello-output-first-patch.patch

bello raw インタープリタープログラミング言語で書かれたプログラム。ソースコードを構築する必要はなく、インストールのみが必要である場合を示しています。事前にコンパイル済みのバイナリーをパッケージ化する必要がある場合、バイナリーは単なるファイルであるため、この方法を使用することもできます。

pello バイトコンパイルインタプリタ－プログラム言語で書かれたプログラム。これは、ソースコードのバイトコンパイルと、生成される事前処理ファイルのバイトコードのインストールを示しています。

cello ネイティブコンパイル言語で書かれたプログラム。これは、ソースコードをマシンコードにコンパイルし、生成される実行ファイルをインストールする一般的なプロセスを示しています。

5.1.7.1. bello

最初の SPEC ファイルは、4章パッケージ化を行うためのソフトウェアの準備の bello bash シェルスクリプト用です。

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

1. bello ソースコードを ~/rpmbuild/SOURCES/ に配置します。「SPEC ファイルでの作業」を参照してください。

2. 空の SPEC ファイル ~/rpmbuild/SPECS/bello.spec を作成しました。このファイルには、以下のコンテンツが含まれます。

Name: belloVersion:Release: 1%{?dist}Summary:

License:URL:Source0:

BuildRequires:Requires:

%description

%prep%setup -q

%build%configuremake %{?_smp_mflags}

%installrm -rf $RPM_BUILD_ROOT%make_install

%files%doc


25

次に、bello RPM を作成するために ~/rpmbuild/specs/bello.spec を変更します。

1. Name、Version、Release、および Summary ディレクティブを入力します。

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

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

Release は、1%{?dist} に自動的に設定されます。最初は 1 となります。パスを含めるなど、アップストリームのリリースの Version を変更せずにパッケージを更新する場合は初期値を増加させます。新しいアップストリームリリースが発生すると、Release が 1 にリセットされます (たとえば bello バージョン 0.2 がリリースされる場合)。disttag マクロは、「RPM マクロ」で説明しています。

Summary は 1 行の短い説明です。編集後に、SPEC ファイルの最初のセクションを再アセンブルする必要があります。

2. License、URL、および Source0 ディレクティブを入力します。

License フィールドは、アップストリームリリースのソースコードに関連するソフトウェアライセンスです。+ たとえば、GPLv3+ を使用します。

URL フィールドは、アップストリームのソフトウェアページへの URL を指定します。たとえば、https://example.com/bello を使用します。ただし、一貫性のために %{name} マクロを使用し、代わりに https://example.com/%{name} を使用します。

Source0 フィールドは、アップストリームのソフトウェアソースコードへの URL を指定します。これは、パッケージ化しているバージョンのソフトウェアに直接リンクする必要があります。この例では、https://example.com/bello/releases/bello-0.1.tar.gz を使用できます。代わりに %{name} マクロを使用します。また、%{version} マクロを使用してバージョンにおける変更を行います。生成されるエントリーは、https://example.com/%{name}/releases/%{name}-%{version}.tar.gz です。編集後に、SPEC ファイルの最初のセクションを再アセンブルする必要があります。

Name: belloVersion: 0.1Release: 1%{?dist}Summary: Hello World example implemented in bash script

License: GPLv3+URL: https://example.com/%{name}Source0: https://example.com/%{name}/release/%{name}-%{version}.tar.gz

+ .BuildRequires ディレクティブおよび Requires ディレクティブに BuildArch ディレクティブを追加

%changelog* Tue May 31 2016 Adam Miller -



26

https://example.com/bellohttps://example.com/%{name}https://example.com/bello/releases/bello-0.1.tar.gzhttps://example.com/%{name}/releases/%{name}-%{version}.tar.gz

+ .BuildRequires ディレクティブおよび Requires ディレクティブに BuildArch ディレクティブを追加します。

BuildRequires は、パッケージのビルドタイム依存関係を指定します。bello にはビルド手順がありません。これは、bash が raw インタープリタープログラミング言語で、ファイルはシステム上のその場所に単純にインストールされるためです。このディレクティブを削除します。

+ * Requires は、パッケージのランタイム依存関係を指定します。bello スクリプトを実行するには、bash シェル環境のみが必要なため、このディレクティブで bash を指定します。

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

+ 編集後に、SPEC ファイルの最初のセクションを再アセンブルします。

+

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

%description は、ソフトウェアの完全な説明で Summary よりも長く、複数の段落が含まれています。この例では、簡単な説明のみを使用しています。

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

%build セクションでは、パッケージ化するソフトウェアを実際に構築する方法を指定します。ただし、bash はビルドする必要がないため、テンプレートが提供するものを削除して、このセクションは空白のままにする必要があります。

%install セクションには、ソフトウェアを構築してから BUILDROOT ディレクトリーにインストールする方法に関する rpmbuild の説明が記載されています。このディレクトリーは空の chroot ベースディレクトリーで、エンドユーザーの root ディレクトリーに似ています。ここでは、インストールしたファイルを格納するディレクトリーを作成する必要があります。

bello のインストールには、インストール先のディレクトリーを作成し、そこに実行可能な



Requires: bash

BuildArch: noarch


27

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

%install セクションは、編集後に以下のようになります。

%files セクションは、この RPM によるファイルのリストと、エンドユーザーシステム上のファイルの完全なパス場所を指定します。そのため、インストールしている bello ファイルのリストは /usr/bin/bello、または RPM Macros、%{_bindir}/%{name} です。このセクションでは、組み込みのマクロを使用して、さまざまなファイルの役割を示すことができます。これは、rpm コマンドを使用したパッケージファイルマニフェストのメタデータの照会に役立ちます。たとえば、LICENSE ファイルがソフトウェアライセンスファイルであることを示すには、%licnese マクロを使用します。

編集した後に、%files セクションは以下のようになります。

2. 最後のセクションの %changelog は、パッケージの各 Version-Release に対する日付入りのエントリーの一覧です。これらは、ソフトウェアの変更ではなく、パッケージの変更を記録します。パッケージ変更の例: パッチの追加、%build のビルド手順の変更。最初の行は、以下の形式に従います。

* Day-of-Week Month Day Year Name Surname - Version-Release

実際の変更エントリーには、以下の形式に従います。

各変更エントリーには、変更ごとに複数の項目を含めることができます。

各項目は新しい行で始まります。

各項目は - 文字で始まります。

日付エントリーの例:

bello 用の SPEC ファイル全体を作成できるようになりました。bello の完全な SPEC ファイルは以下のようになるようになりました。

%install

mkdir -p %{buildroot}/%{_bindir}

install -m 0755 %{name} %{buildroot}/%{_bindir}/%{name}

%files%license LICENSE%{_bindir}/%{name}

%changelog* Tue May 31 2016 Adam Miller - 0.1-1- First bello package- Example second item in the changelog for version-release 0.1-1



28

次のセクションでは RPM を構築する方法について説明します。

5.1.7.2. pello

次の SPEC ファイルは、ダウンロードした Python プログラミング言語 (または、4章パッケージ化を行うためのソフトウェアの準備セクションにシミュレートしたアップストリームリリースを作成したもの) で記述され、ソースコードを ~/rpmbuild/SOURCES/ に置きます。~/rpmbuild/specs/pello.specファイルを開いてから、一部のフィールドで入力を開始します。

これを始める前に、バイトコンパイル型のインタープリターソフトウェアについて特殊な処理を行うことがあります。このプログラムをバイトコンパイルすることから、生成されるファイルにはエントリーが含まれなくなるため、シバンは適用されなくなりました。実行ファイルを読み出すバイトコンパイルタイプ以外のシェルスクリプトや、「エントリーポイント」としてプログラムの実行にバイトコンパイルされない Python コードを少々利用することが一般的です。これは、簡単な例と思われるかもしれませんが、数千という行のコードのある大規模なソフトウェアプロジェクトの場合、事前にコンパイルしたコードのパフォーマンスの増大は大きなものとなります。

注記注記

License: GPLv3+URL: https://www.example.com/%{name}Source0: https://www.example.com/%{name}/releases/%{name}-%{version}.tar.gz

Requires: bash

BuildArch: noarch

%descriptionThe long-tail description for our Hello World Example implemented inbash 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 - 0.1-1- First bello package- Example second item in the changelog for version-release 0.1-1


29

https://www.python.org/https://www.python.org/

注記注記

バイトコンパイルしたコードを呼び出すスクリプトの作成や、ソフトウェアへのバイトコンパイルのエントリーを利用することは、多くのアップストリームソフトウェア開発者がそのソフトウェアをリリースする前によく行っていることです。しかし、これが常に当てはまるわけではなく、これは前述の状況において行うことを支援する意味で行われます。Python コードの通常リリースや、配布の詳細は、『ソフトウェア・パッケージと配布』のドキュメントを参照してください。

ソフトウェアへのエントリーポイントとなる、バイトコンパイルコードを呼び出す小さなシェルスクリプトを作成します。これは、SPEC ファイル内でアクションを実行する方法を実証するために、SPECファイルの一部として実行します。これについては、後で %install セクションで説明します。

~/rpmbuild/specs/pello.spec ファイルを開いてから、一部のフィールドで入力を開始します。

以下は、rpmdev -newspec から与えた出力テンプレートです。

最初の例と同様に、rpmdev -newspec がファイルの一番上部でともにグループ化した最初のセットのディレクティブで始めましょう (Name、Version、Release、Summary)。Name は既に指定されています。これは、rpmdev -newspec のコマンドラインへの情報を提供しているためです。

pello ソースコードの「アップストリームの」リリースバージョンと一致するように Version を設定します (この場合では 0.1.1) です。これは、ダウンロードしたコード例 (または 4章パッケージ化を行うためのソフトウェアの準備セクションで作成した例) で設定されています。

Name: pelloVersion:Release: 1%{?dist}Summary:

License:URL:Source0:

BuildRequires:Requires:

%description

%prep%setup -q

%build%configuremake %{?_smp_mflags}

%installrm -rf $RPM_BUILD_ROOT%make_install

%files%doc

%changelog* Tue May 31 2016 Adam Miller -


30

https://www.python.org/https://docs.python.org/2/library/distribution.html

Release は既に 1%{?dist} に設定されます。初期に 1 の数値は、問題を修正するために新しいパッケージを含めるなど、理由に関係なく、パッケージが更新されるたびに増分される必要がありますが、新しいアップストリームリリース Version 含まれません。新しいアップストリームリリース行われると(例: pello バージョン 0.1.2 がリリースされた場合など)、Release 番号は 1 にリセットされるはずです。%{?dist} の disttag は、「RPM マクロ」の以前のセクションの説明と似ています。

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

編集した後に、SPEC ファイルの最初のセクションは以下のようになります。

次に、rpmdev-newspec が SPEC ファイルでともにグループ化した次のセットのディレクティブに移ります (License、URL、Source0)。

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

URL フィールドは、ソースコードダウンロードリンクではなく、アップストリームのソフトウェアWeb サイトです。しかし、特定のソフトウェアに関する情報を見つけることができる実際のプロジェクト、製品、または企業 web サイトなどになります。この例では使用しているため、https://example.com/pelloとします。ただし、一貫性を確立するためにも %{name} の RPM マクロ変数を使用します。

Source0 フィールドは、アップストリームのソフトウェアのソースコードをダウンロードできる場所です。この URL は、この RPM パッケージをパッケージ化している特定のバージョンのソースコードリリースに直接リンクする必要があります。再度、これが例なので、例の値: https://example.com/pello/releases/pello-0.1.1.tar.gz を使用します。

この URL の例には、将来変更される可能性がある値のハードコードがあり、リリースバージョン 0.1.1などが変更される可能性もあることに注意してください。これは、SPEC ファイルの 1 つのフィールドを更新して再利用できるようにするだけで単純化できます。以前に一覧表示したハードコードサンプル文字列ではなく、https://example.com/%{name}/releases/%{name}-%{version}.tar.gz の値を使用します。

編集後、仕様ファイルの上部は以下のようになります。

次に、BuildRequires および Requires があり、それぞれはパッケージで必要とされるものを定義します。ただし、BuildRequires は、ビルドビルド時にパッケージによって必要となるものを rpmbuild に通知します。また、Requires は、ランランタイム時にパッケージに必要となるものです。

この例では、バイトコンパイルのビルドプロセスを実行するために python パッケージが必要になります。また、ランタイム時にバイトコンパイルコードを実行するには python パッケージも必要となりま

Name: pelloVersion: 0.1.1Release: 1%{?dist}Summary: Hello World example implemented in Python




31

https://example.com/pellohttps://example.com/pello/releases/pello-0.1.1.tar.gzhttps://example.com/%{name}/releases/%{name}-%{version}.tar.gz

す。したがって、Requires ディレクティブを使用して、必須として python を定義する必要があります。ここでは、小規模なエントリーポイントスクリプトを実行するために、bash パッケージも必要になります。

これはネイティブにコンパイルされた拡張機能がない、インタープリタープログラミング言語で書かれたソフトウェアであるため、ここでは何かを追加しなければなりません。それは、noarch に設定された BuildArch エントリーで、このパッケージが構築されているプロセッサーアーキテクチャーにバインドされないようにする必要がないことを RPM に命令するためです。

編集後、仕様ファイルの上部は以下のようになります。

以下のディレクティブは、マルチライン、マルチインストラクション、または実行するスクリプト処理タスクを定義することができるため、セクションの見出しと考えることができます。前の項目で行ったように、順を追って説明します。

%description は、Summary ディレクティブにあるものよりも、パッケージ化されているソフトウェアの完全な説明になります。この例では、大量のコンテンツを含めることはできません。しかし、このセクションは、必要であれば完全なパラグラフまたは複数のパラグラフになります。

%prep セクションは、ビルド用のビルド環境またはワークスペースを準備準備する場所です。多くの場合は、ソースコードの圧縮アーカイブの展開、パッチの適用、および SPEC の後の部分で必要とされるソースコードで提供される情報の解析です。ここでは、与えられたマクロ %setup -q を使用します。

%build セクションは、パッケージ化しているソフトウェアを実際に構築する方法をシステムに指示します。ここでは、ソフトウェアのバイトコンパイルを実行します。4章パッケージ化を行うためのソフトウェアの準備セクションを読んだ場合は、この例は見覚えがあるはずです。

SPEC ファイルの %build セクションは、以下のようになります。

%install セクションでは、以前にビルドしたソフトウェアを BUILDROOT にインストールする方法を rpmbuild 指示しています。これは、空の chroot ベースディレクトリーで効果的です。また、特定の場所にあるソフトウェアをインストールするのに必要となるパスまたはディレクトリー階層を構築する必要があります。ただし、RPM マクロは、パスをハードコードしなくてもこのタスクを実現するのに役立ちます。

以前、バイトコンパイルを行う際は、そのタスクを達成するためにシンプルなラッパースクリプトを作成する必要があり、シバンの行が含まれるファイルのコンテキストが失われることについて話しまし



BuildRequires: pythonRequires: pythonRequires: bash

BuildArch: noarch

%build

python -m compileall pello.py


32

た。これを実行する方法は複数あります。個別のスクリプトを作成し、それを個別の SourceX ディレクティブとして使用する方法や、SPEC ファイルでファイルのインラインを作成するなど、この例で示すオプションを利用できます。このような例のオプションを示す理由は、SPEC ファイル自体がスクリプト可能であることを示すためです。ここのドキュメントを使用して、Python バイトコンパイルコードを実行する、小規模の「ラッパースクリプト」を作成します。実際にバイトコンパイルファイルを、アクセス可能なシステム上のライブラリーディレクトリーにインストールする必要があります。

注記注記

以下では、ライブラリーパスをハードコーディングしていることがわかります。このようなことが不要な方法もいくつかあります。その多くは 6章高度なトピックで説明されています。「マクロの詳細」セクションでは、パッケージ化されているソフトウェアが書かれたプログラミング言語に固有のものです。この例では、複数のトピックを同時に説明しないように、分かりやすくするためのパスをハードコードしています。

%install セクションは、編集後に以下のようになります。

%files セクションは、この RPM が提供するファイルの一覧と、RPM がインストールされているシステムでこれらが配置される場所を示しています。これは %{buildroot} と相対的ではなく、インストール後にエンドシステムに存在することが見込まれるため、ファイルのフルパスであることに注意してください。そのため、インストールしている pello ファイルのリストは %{_bindir}/pello になります。また、%dir リストも提供して、作成したライブラリーディレクトリーと同様に、その中に配置したすべてのファイルを、このパッケージが「所有」することを定義します。

また、このセクション内では、ファイルでコンテキストを提供するためにビルドインマクロが必要になる場合があります。これは、生成されるパッケージについて rpm でシステムに問い合わせる必要のあるシステム管理者とエンドユーザーに便利です。ここで使用するビルトインマクロは %license です。これは、パッケージがマニフェストメタデータ内のソフトウェアライセンスファイルであることを rpmbuild に指示します。

%files セクションは編集後、以下のようになります。

最後のセクションの %changelog は、パッケージの特定の Version-Release と関連する、日付付きのエントリーの一覧です。これは、リリースからリリースへのソフトウェアでの変更内容のログではなく、パッケージ変更についてです。たとえば、パッケージに含まれるソフトウェアにパッチが必要な場

%install

mkdir

red hat enterprise linux 7 rpm パッケージングガ …...bash で書かれた hello world:...

Documents