パッケージの説明を簡単に一行で書きます。 タイトルのようにspecファイルの一行目に書くことが多いです。 英語で簡潔に書きましょう。Summaryは、国際化機能をもっており、 Summary(ja)のように、日本語のサマリーを書いておくと、 環境変数 LANGUAGE が ja な時には、日本語のほうが表示されます。 ただし、Summary(ja)を用意したときにも、英語のSummaryは必ず用意してください。 また、日本語がspecファイルの始めの方にあると、 rpmコマンドがエラーを出すことがあるので、 Summary(ja)はデータ定義部の下のほうに書くほうがいいようです。 また、日本語メッセージは必ず EUC で入れてください。

つくるrpmパッケージの名前です。 環境変数RPM_PACKAGE_NAMEに設定されます。

ソースのバージョン名を入れます。 環境変数RPM_PACKAGE_VERSIONに設定されます。

同じソースからつくるrpmパッケージのリリース番号です。 環境変数RPM_PACKAGE_RELEASEに設定されます。

rpmパッケージをつくるソース名です。 Section 4.1, “環境設定”で設定したSOURCESのディレクトリに置いておきましょう。 ソースの入手先を明示するために、

Source: ftp://ftp.hogehoge.org/hoge-1.1.tar.gz

と書いておくと便利です。自分でつくったソースならば、 サンプルのようにファイル名のみを書いておきます。

複数のソースファイルがあるときには、

Source0: ftp://ftp.hogehoge.org/hoge-1.1.tar.gz
Source1: ftp://ftp.hogehoge.org/hoge-devel.tar.gz

というふうに番号をふって列挙します。(Source0 と Source は同じ意味です)

上で設定したソースにあてる、パッチファイルです。書式はSourceと同じです。 このパッチファイルもディレクトリSOUCESに置いておきましょう。 複数あるときにも、Sourceと同様に番号をふって列挙できます。

作成するrpmパッケージのライセンスを書きます。 もとのソースの COPYING などのファイルを参照し、 できるだけ簡潔に書きましょう。

rpm 4.1 以降では Copyright ではなく License を使うようになりました。 Copyright を使っている場合は License に書き変えましょう。

作るパッケージのグループ名を書きます。 このグループ名は、 rpmコマンドの-g,--groupオプションで利用したり、 Synapticで分類に用いることができます。 Appendix A, Vine Linux で使用できるGroup一覧にGroup一覧を示します。 自分で作ったパッケージのグループ名をとりあえず Local にしておくなどグループ名はこの一覧に無いものでも自由に付けられますが、 分類ということを考え適切なグループ名を選択しておきましょう。

rpmパッケージを作ってるあなたの名前です。Email addressを入れておくと、 思わぬとこからバグ報告とかもらえて嬉しいこともあります。

Section 7.1, “環境変数”で説明した、 仮想インストールのためのディレクトリ名を書きます。 Buildrootの設定を行わなければ、RPM_BUILD_ROOTはnullです。 例では、%{_tmppath}, %{name}というマクロを利用して、 Buildrootが定義されています。%{_tmppath}は/usr/lib/rpm/macrosで定義されており、 /var/tmpを指します。%{name}は、パッケージの名前を示すマクロです。 よって例の場合はBuildroot は /var/tmp/hoge-rootというディレクトリを指すことになります。 マクロを使わずに直接このディレクトリ名を書いても構いません。

このタグの下に、rpmパッケージの解説を書きます。 rpm -qip <rpm-name>で出てくる説明です。 このタグも国際化機能をもってます。日本語メッセージを表示させたいときには、 %description -l ja を用います。ただし、日本語メッセージを用意したときにも、 必ず英語メッセージは書いておきましょう。 %description は、 specファイルの一番下(ファイルリスト部の下)に持って来ることもできます。

ここには、更新のログを書いておきます。最新の更新情報が上にくるように書きます。 必須ではありませんが、バージョンアップの履歴や設定変更などといった更新情報は、 トラブル解決の重要なヒントにもなりますので書いておきましょう。

%changelogは、specファイルの一番下(ファイルリスト部の下)に持って来ることもできます。

一行目の最初に * を書き、日付と変更を加えた人の名前を書きます。 二行目以降に - を書き、更新内容を書きます。 今日の日付は date コマンド で LANG=C date +'%a %b %d %Y' とすると確認できます。

Vine Linux でのパッケージングルールでは 一行目に日付、パッケージャーの名前、メールアドレス、パッケージのバージョンとリリース番号を書くことになっています。

* 曜日 月 日 西暦年 パッケージャーの名前 <メールアドレス> バージョン-リリース番号
- 更新内容

更新内容の部分でもマクロは展開され %{name} は hoge になります。 マクロを展開せずにそのまま %{name} と書きたい場合は %%{name} のように % を二つ続けて書いて下さい。

日本語を使うことも可能になっていますが、Summary や description のように環境変数に応じて日本語や英語のどちらかを表示するという仕組みは無いので、 英語だけで書くほうがよいでしょう。

作成しているrpmパッケージが動作するのに必要なパッケージ名を書きます。 例えば、

Requires: gs

として、動作にgsがインストールしていることが必要なことを示します。

<, >, =, >=, <=といった演算子を使って必要なバージョン、 リリース番号を示すことも出来ます。演算子の両側には必ずスペースを入れてください。 (入れないと一つの名前として認識されてしまいます)

Requires: ghostscript = 5.10

とするとghostscriptのバージョン5.10が必要なことを示し、

Requires: ghostscript >= 5.10

として5.10以上が必要なことを示します。必要なライブラリ名を書くこともできます。

Requiresしたいものが複数あるときには、

Requires: ghostscript >= 5.10, ghostscript-fonts, VFlib = 2.24

などのように、'','' や '' ''(スペース)で区切って並べます。

また、

Requires: ghostscript >= 5.10, ghostscript-fonts, VFlib = 2.24
Requires: tetex, tetex-extra

のように複数行で書くこともできます。 たくさんのパッケージが必要となる場合や、 それらのパッケージがいくつかのグループに分類できる場合には、 複数行に書いた方がわかりやすくなります。

rpmパッケージをbuildするときには、 そのパッケージに含まれるバイナリの実行に必要なライブラリ名も、 自動的にRequiresに加えられます(正確には必要なライブラリのsonameが加えられます)。 rpmパッケージをinstallするときに、必要なライブラリがシステム上にないと、 libhoge.so is neededとかいって、おこられますが、 libhoge.soがなんというパッケージに入ってるかわからずに困ることがよくあるので、 必要なパッケージ名をきちんとRequiresに書くように心がけましょう。

パッケージをインストールする順番が問題になる場合と、 パッケージのインストール、アンインストールの時に必要となるパッケージがある場合は、 次に説明する PreReq も利用してください。

Requiresと同様に必要とするパッケージ名を書きます。バージョンの指定もできます。 Requiresとの違いはインストールされる順番が保証されるということだけです。 Prereqで指定されたパッケージは先にインストールされます。

A というパッケージが Prereq: B として B というパッケージを要求した場合には、 B のパッケージが A のパッケージより先にインストールされているかチェックが行われるので、 rpm -ivh A B のように A と B を同時にインストールするように指定した場合にも B が A より先にインストールされるようになります。

パッケージのインストール時、 アンインストール時に必要となるパッケージは、 Prereq で指定してください。 Requiresと重複してもかまいません。

例えば、infoファイルをもったパッケージでは、 パッケージインストール時(%post)の infoファイルのインストールに install-info が必要となるので、Prereq で指定する必要があります。

パッケージの動作自体には直接必要なくても、 %pre,%post,%preun,%postun などで必要になるコマンドやパッケージは、Prereq で指定する必要があります。

Requiresと逆の意味を持ちます。すなわち、共存できないパッケージ名を指定できます。 バージョンやリリース番号指定もRequiresと同様にできます。 例えば以下のように指定します。

Conflicts: fugefuge >= 1.0, fugafuga = 1.2-1

パッケージが提供する機能を書きます。

日本語化されたgsであるgsjというパッケージがあるとします。 このパッケージはもともとのgsと同等の機能を持っています。 インストールしたいhoge-1.1-2.rpmがgsを必要(Requires)としてるとしましょう。 しかし、gsjがインストールされているためにgsはインストールされていません。 このとき、hoge.rpmをインストールしようとするとrpmコマンドは gsが無いためにエラー・メッセージを出します。

このようなトラブルをさけるためには、gsjを作るときに、

Provides: gs

と書いておくと、gsjはgsパッケージを提供することができます。

また、あるパッケージ A がpdfを読むツールをRequiresするときに、 xpdf と gs(pdf対応) のように複数の選択肢がある場合、 xpdf と gs の Providesに

Provides: pdf-reader

と仮想的なパッケージ名(仮想パッケージ virtual package)を書いておいて、 A で Requires: pdf-reader としておけば、パッケージ名を限定せずに、 なんらかのpdf-readerがインストールされてることを要求できます。 たとえば emacs lisp のパッケージでは emacs や xemacs ではなく emacsen という仮想パッケージを要求するものが多いです。

仮に、pLaTeX2eのrpmをインストールするときには、 古いTeXのパッケージであったptexはアンインストールしたいとしましょう。 こんなときには、pLaTeX2eのspecファイルには、

Obsoletes: ptex

と書いておくと、pLaTeX2eのインストール時にptexは消去されます。

パッケージの作成の時に必要になるパッケージを書きます。 例えば、

BuildRequires: zlib-devel

として、パッケージの作成に zlib-devel パッケージが必要なことを示します。

コンパイラなどのパッケージや、 ヘッダーファイルやライブラリなどを含んだ hoge-devel などのパッケージで不足するものがないか確認しましょう。

また、Source: で指定されたファイルが hoge.zip のように zip 形式の場合は、 ソースの展開に unzip のパッケージが、 同様に lzh 形式なら lha のパッケージが必要になります。

Vine Linux では build-essential という仮想パッケージがあり、 このパッケージをインストールすることでたくさんのパッケージがインストールされます。 参照 環境設定

パッケージの作成時には build-essential をインストールすることを前提としているので、 build-essential に含まれている make,gzip,bzip2,tar,patch,findutils,coreutils,file,libtool,automake,autoconf などは省略してかまいません。 gcc や gettext などは、ソースが C言語であることや、メッセージが国際化されていることなどを示す意味もあるので、必要であれば書いておいた方がいいかもしれません。

%prep,%setup,%build,%install で必要になるコマンドやパッケージを指定します。

BuildRequiresと同様にパッケージの作成の時に必要になるパッケージを書きます。 BuildRequiresとの違いは必要とするパッケージを作成する順番を決めるということです。

A というパッケージがパッケージ作成時に B と C の二つのパッケージを必要としているとします。 この場合 B と C をインストールすれば、A というパッケージを作成することができます。

このときに B と C のパッケージがなくて、それぞれ作る必要があったとします。 B と C がそれぞれ独立したものではなく、C のパッケージ作成時に B が必要で、 できあがった C は B の特定のバージョンを必要とするパッケージになるということがあります。 このような場合には BuildPrereq に B を BuildRequires に C を指定し、 B を C よりも先に作成する必要があるということを示しておきます。

BuildRequiresと逆の意味を持ちます。 パッケージ作成時にはインストールしておけないパッケージ名を指定できます。 例えば以下のように指定します。

BuildConflicts: huga

作成したrpmパッケージがなんらかのディストリビューションに含まれる時、 そのディストリビューション名を書きます。

作成したrpmパッケージに関する責任を負うVendor名です。 なんらかのプロジェクトでrpmパッケージを作ってる時には、 そのプロジェクト名を書きましょう

ソースの情報を提供しているURLを書きます。 例えば以下のように書きます。

URL: http://www.fugahogo.com/hogehoge.html

このタグを使うと、 rpmパッケージをインストールする時にインストールディレクトリをコントロールできます。 例えば、

Prefix: /usr

としていて、ファイル定義部で

%files
/usr/bin/fuga

と定義してたとしましょう。このパッケージをインストールする時に、 --prefix /usr/local とオプション指定すると、 fugaは/usr/local/bin/fuga.binにインストールされます。

書いたspecファイルを使って生成されるrpmパッケージのアーキテクチャを指定できます。 例えば、elファイルとかシェルスクリプトとかばかりを含むrpmパッケージを作るときには、 i386やalphaなどのアーキテクチャに依存しないnoarchであることを、

BuildArch: noarch

というふうに明示します。 このような指定をしておくとnoarch.rpmという拡張子のつくrpmパッケージが作成できて、 いろいろなアーキテクチャ上で共用できます。