パッケージの説明を簡単に一行で書きます。 タイトルのように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に設定されます。

rpmver というパッケージに含まれている rpmver というコマンドで、バージョンやリリース番号の比較ができます。

$ rpmver -v 1-a 1-1
RPM version 1-a is lesser than version 1-1.

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

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

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

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

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

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

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

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

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

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 は同じ意味です)

Souce数字 で指定したファイルは %{SOURCE数字} というマクロとして Section 5.2, “スクリプト部”の %prep や %install などの部分で利用できます。 %{ } の中の SOURCE は全て大文字にしてください。%{Source数字} のように小文字を利用することはできません。

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

Section 7.1, “環境変数”で説明した、 仮想インストールのためのディレクトリ名を書きます。 Buildrootの設定を行わなければ、RPM_BUILD_ROOTはnullです。

例では、%{_tmppath}, %{name}, %{version}というマクロを利用して、 Buildrootが定義されています。%{_tmppath}は/usr/lib/rpm/macrosで定義されており、 /var/tmpを指します。%{name}はパッケージの名前を、%{version}はパッケージのバージョンを示すマクロです。

直接ディレクトリ名を書くのではなく、マクロを利用することを推奨します。 例の場合の Buildroot は/var/tmp/hoge-1.1-rootというディレクトリを指すことになります。

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

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

一行目の最初に * を書き、日付と変更を加えた人の名前を書きます。 二行目以降に - を書き、更新内容を書きます。 今日の日付は date コマンド で LANG=C date +'%a %b %d %Y' とすると確認できます。 12月1日のように日の部分が一桁の場合は 0 をつけ 01 のようにします。

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に書くように心がけましょう。

筆者はbuildした時に出力されるメッセージの

Requires: /bin/sh libICE.so.6 libORBit-2.so.0

といった部分を、(bash の for文 を利用して)slocate と rpm -qf で処理してパッケージ名を調べています。

$ for i in libICE.so.6 libORBit-2.so.0 ;
 do slocate $i |xargs rpm -qf ;
done | sort -u

Requires には、従来の Requires: だけではなく Requires(pre): などのように ( ) をつけて厳密に指定することもできるようになりました。

バージョン、リリース等を演算子を用いて指定することや、複数のパッケージをまとめて指定、複数行に分けて書くなど、書式は Requires: と同じです。

( ) の中にはTable 5.1, “Requires の ( ) の中で利用できるもの”にあるものが入ります。 ( ) の中に入る項目は Section 5.2, “スクリプト部” のタグ等に対応しています。どの部分で必要になるかを書きます。

Requires( ): のように ( ) の中に何も書かなかった場合は、Requires: として扱われます。

( ) の中は、Requires(pre,preun,post,postun): のように , を用いることで複数を同時に指定できます。

Requires(pre): などを指定した場合には、PreReq: の時と同様に、インストール、アンインストールされる順番が保証されます。 指定されたパッケージは先にインストールされ、後にアンインストールされます。

prereq は pre,preun,post,postun などよりも曖昧な書き方ですが、PreReq で書かれていたものを Requires に機械的に置き換える場合には利用できると思います。

rpmlib については、通常、build 時に自動的に追加されるものなので、特別な機能を利用するのでなければ、記述する必要はありません。

interp も、自動的に追加されますが、特別な shell などを利用する場合には記述しておいた方がよいでしょう。

rpm 4.0. から 4.0.[12] の間の変更で、PreReq: の代わりに Requires(prereq): 等を用いるようになりました。 PreReq: もまだ利用できますが legacy という扱いなので、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 で必要になるコマンドやパッケージを指定します。

Requires( ): と同じように、BuildRequires も ( ) をつけて詳細な指定をすることができます。

( ) の中にはTable 5.2, “BuildRequires の ( ) の中で利用できるもの”にあるものが入ります。 ( ) の中に入る項目は Section 5.2, “スクリプト部” のタグ等に対応しています。どの部分で必要になるかを書きます。

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

BuildRequiresと同様、BuildPrereq(prep) のように prep,build,install,clean を指定できます。

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

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

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

BuildConflicts: huga

このタグを使うと、 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パッケージが作成できて、 いろいろなアーキテクチャ上で共用できます。

specファイルや src.rpmパッケージから、パッケージを生成 できる アーキテクチャーを指定します。 たとえば、ExclusiveArch: i386 とすると、i386 以外の ppc,i486,i586,i686,x86_64 といったアーキテクチャーではバイナリパッケージを生成できなくなります。

specファイルや src.rpmパッケージから、パッケージを生成 できない アーキテクチャーを指定します。 たとえば、ExcludeArch: ppc とすると、ppc ではバイナリパッケージを生成できなくなります。ppc 以外の i386,i486,i586,i686,x86_64 といったアーキテクチャーではバイナリパッケージを生成できます。