RPM HOWTO: RPM パッケージの作成

6. RPM パッケージの作成

RPM パッケージの作成は全く簡単です、特に作成しようとしているソフトウェアを手に入れられるならなおさらです。

RPM を作成する基本的な課程は以下の通りです。

あなたのシステムに適合するように /etc/rpmrc を確実に設定します。
あなたのシステムで RPM を作成するためにソースコードを手に入れます。
正しく作成するために必要なソースへの変更をパッチにします
パッケージのための spec ファイルを作成します。
全ての物が正しい場所におかれている事を確認します。
RPM を用いてパッケージを作成します。

一般的な操作の下で、RPM はバイナリとソースパッケージを作成します。

6.1 rpmrc ファイル

現在、RPM の設定は /etc/rpmrc ファイルのみが有効です。例えば以下のようになります。 [訳注、デフォルトとして、/usr/lib/rpmrc というものがあり、個人の設定ファイルとして個人のホームディレクトリに .rpmrc を置くこともできます。]


require_vendor: 1
distribution: I roll my own!
require_distribution: 1
topdir: /usr/src/me
vendor: Mickiesoft
packager:  Mickeysoft Packaging Account <packages@mickiesoft.com>

optflags: i386 -O2 -m486 -fno-strength-reduce
optflags: alpha -O2
optflags: sparc -O2

signature: pgp
pgp_name: Mickeysoft Packaging Account
pgp_path: /home/packages/.pgp

tmppath: /usr/tmp

require_vendor の行は /etc/rpmrc もしくは spec ファイルのヘッダから vendor の行を探そうとします。これを無効にするには、ナンバーを 0 に変えて下さい。require_distribution と require_group の行も同様です。

次の行は distribution 行です。ここか spec ファイルのヘッダ中に定義できます。vender 行も同様ですが、何でもよいです。(例、Joe's Software and Rock Music Emporium)

RPM はまた現在複数のアーキテクチャ上でパッケージを作成する事をサポートしています。rpmrc ファイルは作成時にアーキテクチャ固有のフラグが求められるようなパッケージを作成するのに必要な"optflag" 変数を持つ事ができます。

上記のマクロに付け加えて、さらにいくつかあります。

rpm --showrc

とすれば、どのようなタグが設定され、有効な全てのフラグは何かわかります。

6.2 spec ファイル

sepc ファイルについて述べて行きます。spec ファイルはパッケージを作成するために必要です。spec ファイルは作成の仕方の指示を含むソフトウェアの説明とインストールされる全てのバイナリファイルのリストです。

標準的な規則に従って spec ファイルの名前を付けたほうがよいでしょう。それは、パッケージ名-ダッシュ-バージョン番号-ダッシュ-リリース番号- ドット-spec とすべきです。

ここに簡単な spec ファイルがあります。(vim-3.0-1.spec) [訳注、vim-3.0-1.spec とありますが、これはeject-1.4-3.spec でしょう。]


Summary: ejects ejectable media and controls auto ejection
Name: eject
Version: 1.4
Release: 3
Copyright: GPL
Group: Utilities/System
Source: sunsite.unc.edu:/pub/Linux/utils/disk-management/eject-1.4.tar.gz
Patch: eject-1.4-make.patch
Patch1: eject-1.4-jaz.patch
%description
This program allows the user to eject media that is autoejecting like
CD-ROMs, Jaz and Zip drives, and floppy drives on SPARC machines.

%prep
%setup
%patch -p1
%patch1 -p1

%build
make RPM_OPT_FLAGS="$RPM_OPT_FLAGS"

%install
install -s -m 755 -o 0 -g 0 eject /usr/bin/eject
install -m 644 -o 0 -g 0 eject.1 /usr/man/man1

%files
%doc README COPYING ChangeLog

/usr/bin/eject
/usr/man/man1/eject.1

6.3 ヘッダ

ヘッダは書き込む必要のあるいくつかの標準的なフィールドがあります。またいくつか注意があります。フィールドは以下のように書き込まなければなりません。

Summary: これは一行のパッケージの説明です。
Name: これは使おうとしている rpm ファイル名からの文字列でなければなりません。
Version: これは使おうとしている rpm ファイル名からのバージョン番号でなければなりません。
Release: これは同じバージョンのパッケージのためのリリース番号です。 (例えば、パッケージを作成しそれがわずかに壊れているのを発見し再度作成する必要があるならば、次のパッケージのリリース番号は2となります。)
Icon: これは他の高レベルなインストールツール(Red Hat の "glint"の様な)を用いる為のアイコン名です。それはgif ファイルで SOURCES ディレクトリに置かなければなりません。
Source: この行は元のソースファイルのホームロケーションを指します。再びソースファイルを手に入れたいとか新しいバージョンをチェックしたい時に使われます。注意：この行のファイル名とあなたのシステム上に持つファイル名は一致していなければなりません。(例えば、ソースファイルをダウンロードしその名前は変えてはいけません。) 一つ以上のソースファイルを明記したい時は以下のように書きます。
Source0: blah-0.tar.gz Source1: blah-1.tar.gz Source2: fooblah.tar.gz
これらのファイルは SOURCES ディレクトリに置きます。(ディレクトリ構造は後の節 "ソースディレクトリツリー" で扱います。)
・Patch: これは再びパッチをダウンロードする必要がある時にそれを見つける事のできる場所です。注意：あなたが自分で作成したパッチを作る時ファイル名は使う名前と一致しなければなりません。例えば以下のようです。
Patch0: blah-0.patch Patch1: blah-1.patch Patch2: fooblah.patch
これらのファイルは SOURCES ディレクトリに置きます。
Copyright: この行はパッケージがどのような著作権であるか表示します。 GPL、BSD、MIT、public domain、distributable、commercial の様なものを使うべきです。
BuildRoot: この行は新しいパッケージを作成、インストールするための "ルート" のディレクトリを明記します。あなたのマシーンにインストールする前にパッケージをテストするのを助けるために使う事ができます。 [訳注、ここに記述するだけでは、作成およびテストはできません。詳しくは、RPM-BUILD-HOWTO を読むと良いでしょう。]

Group: この行は高レベルなインストールプログラム(Red Hat の "glint" のような)に階層構造の中でこのプログラムがどこに属するのかを明示するためにつかわれます。現在のグループツリーは以下のようになっています。[訳注、日本向けに Extensions/Japanese というものあります。]


Applications
    Communications
    Editors
        Emacs
    Engineering
    Spreadsheets
    Databases
    Graphics
    Networking
    Mail
    Math
    News
    Publishing
        TeX
Base
    Kernel
Utilities
    Archiving
    Console
    File
    System
    Terminal
    Text
Daemons
Documentation
X11
    XFree86
        Servers
    Applications
        Graphics
        Networking
    Games
        Strategy
        Video
    Amusements
    Utilities
    Libraries
    Window Managers
Libraries
Networking
    Admin
    Daemons
    News
    Utilities
Development
    Debuggers
    Libraries
        Libc
    Languages
        Fortran
        Tcl
    Building
    Version Control
    Tools
Shells
Games

%description これは本当はヘッダの項目ではありません、しかしヘッダの中に記述されるべきです。パッケージと(もしくは)サブパッケージに一つの説明(description)のタグが必要です。これはパッケージの包括的な説明を与えるために使われるべき複数行のフィールドです。

6.4 Prep

これは、spec ファイル中の2番目のセクションです。作成用に準備するソースを得るために使われます。ここで、パッチの当てられたソースを得るために必要な事をし make するために必要な準備をします。

注意：各セクションはシェルスクリプトを実際に実行するための場所です。簡単に sh スクリプトを作成し、ソースを解凍しパッチを当てるために %prep タグの後にそれを置く事ができます。しかしながら、この中には上記の事を支援するためのマクロがあります。

それらの最初マクロのは、%setup マクロです。そのもっとも簡単な形は(コマンドラインのオプションなし)、単にソースを解凍しできたソースディレクトリの中に cd するだけです。以下のオプションがあります。

-n name は列挙された name に作成ディレクトリの名前をセットします。デフォルトは $NAME-VERSION です。他の可能性として $NAME、 ${NAME}${VERION}、メインの tar ファイルが用いているものです。 (これらの "$" 変数は spec ファイル中の本当の変数でない事に注意して下さい。これらは参考のためにここで使われたものです。実際には変数ではなくパッケージ中の本当の名前とバージョンを使う必要があります。)
-c は tar ファイルを解凍する前に名付けられたディレクトリを作りそこに cd します。
-b # はディレクトリに cd する前に Source# を解凍(untar)します。 (これは -c オプションと一緒に用いるのは意味がありません、しないで下さい。) これは複数のソースファイルがある時のみ役に立ちます。
-a # はディレクトリに cd した後に Source# を解凍(untar)します。
-T このオプションはソース解凍(untar)のデフォルト動作を無効にします。解凍(untar)されたメインのソースファイルを得るために -b 0 もしくは -a 0 を必要とします。2つめのソースがある時にこれを必要とします。
-D は解凍する前にディレクトリを消去しません。これは setup マクロが複数ある時のみ有用です。最初の setup マクロの後の setup マクロでのみ使うべきです。(決して最初の setup マクロで使わないで下さい。)

次に有益なマクロは %patch マクロです。このマクロはソースにパッチを当てる課程の自動化を助けます。いくつかのオプションがありそれは以下の通りです。

# はパッチファイルとして Patch# を利用します。
-p # patch(1) コマンドのための取り除くディレクトリの数を明記します。
-P デフォルトの動作では Patch (もしくは Patch0)を当てます。このフラグはデフォルトの動作を禁止するので解凍(untar)されたソースファイルを得るために 0 を必要とします。このオプションは最初のマクロと異なる大きい番号を求められる2番目(もしくはそれ以降)の %patch マクロで有用です。
本来の %patch # -p コマンドの代わりに %patch# も使えます。

以上で必要なマクロは全部です。これらを正しく記述した後に、sh スクリプトを用いて他のあらゆる必要なセットアップをする事もできます。%build マクロ(これは次節で説明します。)が sh を経由して実行されるまで何でも含められます。ここで行いたい事の形は上記の例を見て下さい。

このセクションにはマクロはありません。ソースを解凍(untar)し、パッチを当て、ディレクトリに cd したならここでは単にソフトウェアを作成するために必要なコマンドを記述して下さい。これは単に sh に渡す他のコマンドの集まりなので、どんな合法的な sh のコマンド(コメントを含む)でもここで実行できます。[訳注：これはシェルの組み込みコマンドの事だけをいっているのではありません。]これらのセクションの各々で作業ディレクトリはソースディレクトリの一番上にリセットされますのでそれを覚えておいて下さい。もし必要ならばサブディレクトリに cd して下さい。

6.6 Install

ここにもマクロはありません。基本的にここにインストールに必要なコマンドなら何でも置けます。作成したパッケージ中で make install が有効なら、ここに置きます。そうでないのなら、make install の為の makefile へのパッチを当て、make install をするか、sh コマンドによって手動でインストールする事もできます。現在の作業ディレクトリがソースディレクトリのトップレベルである事を考慮して下さい。

6.7 pre ,post インストール / アンインストールスクリプト (任意)

バイナリパッケージのインストール / アンインストールを行う前と後に実行するスクリプトをここに置く事ができます。シェアードライブラリを含むパッケージをインストールもしくはアンインストールした後に ldconfig を実行するような事をするためにこのタグがあります。以下に各々のスクリプトのためのマクロがあります。

%pre はインストールする前のスクリプトためのマクロです。
%post はインストールした後のスクリプトのためのマクロです。
%preun はアンインストールする前のスクリプトのためのマクロです。
%postun はアンインストールした後のスクリプトのためのマクロです。

6.8 Files

このセクションはバイナリパッケージのためのファイルの一覧を表示しなければなりません。RPM は make install の結果どのバイナリがインストールされたのか知る方法がないためです。これをする方法はありません! パッケージのインストール前と後に find を実行すればよいのではないかと疑問に思う人もいるかもしれません。マルチユーザーシステムにおいて、パッケージと関係のないファイルがパッケージを作成している課程の間に作られているかもしれないのでこれは受け入れられません。

同様に特別な事をするために有効なマクロがいくつかあります。以下に説明します。

%doc はバイナリをインストールする際にインストールしたいソースパッケージ中のドキュメントに印を付けるのに使われます。ドキュメントは /usr/doc/$NAME-$VERSION-$RELEASE にインストールされます。このマクロを使ってコマンドライン上で複数のドキュメントの一覧を列挙するか、各ドキュメントごとにマクロを使って別々に列挙することができます。
%config はパッケージ中の設定ファイルに印を付けるのに使われます。これは sendmail.cf、passwd などのようなものを含みます。もし後に設定ファイルを含むパッケージをアンインストールするならば、変更されていないファイルは削除され、変更されたファイルはもとファイル名に .rpmsave という拡張子を付加されたものに名前が変更されます。このマクロでも同時に複数のファイルの一覧を列挙できます。
%dir パッケージによって所有され含まれるファイル一覧中の単一のディレクトリに印を付けます。デフォルトでは、%dir マクロを使わずにディレクトリ名を表示したなら、そのディレクトリ中の全てがファイル一覧に含まれそして後にそのパッケージの一部としてインストールされます。
%files -f <filename> はソースの作成ディレクトリ中の任意のファイルをリストに加える事ができます。これはパッケージ自身のファイルリストを作成する事ができるパッケージがある場合に便利です。その時ここにそのファイルリストを含めます、そして特にファイルを一覧表示してはなりません。

ファイル一覧中の最大の注意点はディレクトリの一覧です。もし間違って /usr/bin を一覧に記してしまったら、バイナリパッケージはあなたのシステムの /usr/bin 中の全てのファイルを含んでしまいます。

6.9 作成

ソースディレクトリツリー

まず最初に必要な事は、きちんと設定された作成ディレクトリツリーです。これは /etc/rpmrc ファイルを用いて設定可能です。多くの人々は /usr/src を使うでしょう。

作成ソースディレクトリツリーを作るために以下のディレクトリを作る必要があるかもしれません。

BUILD は RPM により全ての作成が行われるディレクトリです。特に他の場所で作成のテストを行う必要はありませんが、ここは RPM が作成する用いるところです。
SOURCES はオリジナルのソース(tar)ファイルとパッチを置くディレクトリです。ここは、RPM がデフォルトで探すディレクトリです。
SPECS は全ての spec ファイルを置くディレクトリです。
RPMS は RPM が作成したバイナリ RPM パッケージを置くディレクトリです
SRPMS は全てのソース RPM パッケージを置くディレクトリです。

作成テスト

おそらく最初にしたいことは、RPM を用いずに作成するためのソースツリーを得ることでしょう。これをするために、ソースを解凍し、ディレクトリ名を $NAME.orig に変更して下さい。そしてもう一度ソースを解凍して下さい。そしてこのソースを作成に使用して下さい。ソースディレクトリに入り作成するための指示にしたがって下さい。もし何か編集をしなければならないなら、パッチが必要となります。一度それを作るためにソースディレクトリをきれいにします。./configure スクリプトにより生成されたファイルを確認し削除します。[訳注：要するに、いわゆる make 一発状態にすれば良いという事です。] そして、ソースディレクトリの親ディレクトリに cd します。以下のようにします。

diff -uNr dirname.orig dirname > ../SOURCES/dirname-linux.patch

これは、spec ファイルで使用可能なパッチを作成します。上記の"linux"は単に識別子であることに注意して下さい。なぜパッチを作成しなければならないかを説明するために "config" や "bugs" の様なより説明的なものを使ってもよいでしょう。間違ってバイナリを含めないように確認するために作成したパッチを使用する前に調べるのはよい考えです。

ファイルリストの生成

作成するためのソースを手にいれ、それをどうやって作成するかわかったならば、作成しインストールします。インストールの結果の出力から spec ファイルで用いるためのファイルリストを作成します。私たちは、たいてい全てのステップで並行して spec ファイルを作成しています。最初のファイルリストを作成して簡単な部分を書き込み、そして順を追って埋めていきます。

RPM を用いたパッケージの作成

spec ファイルを書き終えたなら、パッケージを作成する準備ができました。もっとも有効な方法は、以下のようなコマンドを使うことです。

rpm -ba foobar-1.0.spec

-b スイッチには以下のような有用なオプションがあります。

p は spec ファイルの prep セクションだけを実行します。
l は %files のリストをチェックします。
c は prep セクションを実行しコンパイルを行います。これはソースが完全に構築できるものかどうか不確実な時に役立ちます。ソースを構築しそれから RPM を使いはじめるまでは、ソースのみで作業し続けたいでしょうから、役に立たないと思われます。しかし一旦 RPM を使うのに慣れてしまえば、それを使う例が見つかるでしょう。 [訳注、%Build セクションの有効性を確認するぐらいでしょう。]
i は prep セクションを実行し、コンパイルインストールを行います。
b は prep セクションを実行し、コンパイルインストールを行い、バイナリパッケージのみを作成します。
a は全てを作成します。(ソースとバイナリのパッケージの両方)

-b スィッチには以下のようないくつかの変更子があります。

--short-circuit は指定された処理を飛ばします。(c と i でのみ使用できます。)
--clean はパッケージの作成が終った後に作成したディレクトリツリーを消去します。
--keep-temps は /tmp 以下に作られた全ての一時ファイルとスクリプトを保存します。実は -v オプションを用いることにより /tmp に作られたファイルを見ることができます。
--test は実際にはどの処理も実行はしませんが、keep-temp は行います。

6.10 テスト

いったん、ソース及びバイナリの rpm パッケージを作成したら、それをテストする必要があります。最も簡単で良い方法は、パッケージを作成したマシンと全く異なったマシン上でテストする事です。なぜなら、あなたのマシン上で何度も make install をしているので、きちんとインストールされるはずだからです。

テストのために rpm -u パッケージ名とすることもできます、[訳注：おそらくこれは typo で rpm -e でしょう。rpm -u は現在では動作しません。 ]しかしパッケージ作成の時に make install を実行しているので間違う事もあります。もしファイルリストに洩れがあると、アンインストールされません。その時にはバイナリパッケージを再インストールしてシステムを再び完全なものにします、しかし rpm パッケージはまだ完全ではありません。あなたは、 rpm -ba specファイル名をしただけだという事をしっかり心に止めておいてください。多くの人々はパッケージをインストールするのに rpm -i パッケージ名を行うだけです。バイナリがインストールされる時に必要な事を build セクションや install セクションで何もしていないことを確認してください。

6.11 新しく作成した RPM パッケージをどうすれば良いか。

いったん、あなたが RPM パッケージを作成したなら(すでに何か RPM 化したと仮定します)、あなたの作成したパッケージで他の人に貢献する事ができます(作成した RPM パッケージが自由に配布可能なものとします)。そうするために、ftp.redhat.com にアップロードしてください。 ftp://ftp.redhat.com

6.12 What Now?

新しい RPM パッケージですることとテストに関しては上記のセクションを見てください。私達は取得可能な全ての RPM パッケージを募集しています。そして、それらが素晴らしい RPM パッケージであることを望んでいます。作成したパッケージをよく時間をかけてテストしてください。そして、万人の利益のためにそれをアップロードするために時間をかけてください。同様に、自由に配布できるソフトウェアのみをアップロードするようにしてください。商用ソフトウェア及びシェアウェアはそれらの著作権がはっきりと自由に配布する事が許される事を言及してない限りアップロードすべきではありません。これには、Netscape ソフトウェア、ssh、pgp 等が含まれます。

次のページ前のページ目次へ

ソースディレクトリ ツリー

作成テスト

ファイルリストの生成

RPM を用いたパッケージの作成

[

ソースディレクトリツリー