]> Jun Nishii Akahoshi Yasumichi Kazutaka HARADA Takuya Kobayashi この文書は、Vine Linux上で動くアプリケーションをRPMパッケージ化する方法を解説しています。 初めてRPMパッケージを作成する方を主な対象としておりますが、他のドキュメントでは分かりにくいあるいは触れられていない点に注意して説明していますので経験者にも参考になる点があります。 なお、RPMパッケージのインストール方法やシェルスクリプト、基本的なコマンドの使い方は省略しております。 RPM Package Manager RPM アプリケーションの安全なインストール、更新、削除などを目的とした強力なパッケージ管理システムです。 バイナリパッケージ 展開すれば、そのまま実行可能な状態でアプリケーションに必要な全てのファイルがアーカイブされています。 バイナリパッケージのファイル名は、name-version-release.arch.rpmという形式です。 ソースパッケージ SRPM バイナリパッケージの作成に必要なソースやパッチ、SPECファイルがアーカイブされています。 ソースパッケージのファイル名は、name-version-release.src.rpmという形式です。 rpm -ivh hoge.src.rpm でで解説するディレクトリに展開されます。 SPECファイル SPEC ソースからパッケージを作成するための手順やパッケージの情報を記述するファイル。 SPECファイルのファイル名は、name.specという形式です。 この文書では主にSPECファイルの書き方を説明します。 パッチファイル パッチ オリジナルのソースに修正を加えるため、差分情報を記述したファイル。 ファイル名は、name.patchという形式です。 では、VinePlus向けパッケージを作成するにあたって設定すべきことを説明します。 RPMパッケージ(以下、パッケージ)作成環境の設定ファイルは、ユーザのホームディレクトリ(以下、~/)にある .rpmmacros です。 Vine Linuxをインストールしたままの状態であれば、下記の様になっています。 %_topdir ${HOME}/rpm # gpg signing # %_signature gpg # %_gpg_name Your Name <your mail address> 既に削除してしまった場合は、/etc/skel/.rpmmacrosから~/にコピーします。 また、内容を変更している場合は、次節以降を参考に必要な設定が漏れていないか確認してください。 パッケージ作成をroot権限で行うとシステムを破壊する場合があります。必ず、一般ユーザ権限で行ってください。 そのため設定ファイルは、あなたが通常使用している一般ユーザのホームディレクトリに用意してください。 パッケージ作成に必要なディレクトリは、~/.rpmmacrosの%_topdirで設定されたディレクトリに以下の名前で配置します。 ディレクトリ名 使用目的 BUILD パッケージ作成時にソースの展開や make を実行するための作業用ディレクトリです。 RPMS/arch 作成されたバイナリパッケージ(*.rpm)が格納されます。対象となる architecture によって arch の部分が、i386・ppc などになります。なお、architecture に依存しないパッケージは、RPMS/noarch に格納されます。 SRPMS 作成されたソースパッケージ(*.srpm)が格納されます。 SPECS パッケージ作成の指示書であるSPECファイル(*.spec)を格納します。 SOURCES パッケージ化するアプリケーションのソースやパッチを格納します。 Vine Linuxをインストールしたままの状態であれば、%_topdirが${HOME}/rpmに設定されており、上記のディレクトリも~/rpmの中に用意されています。 以下、で説明したディレクトリを単にBUILDとか、SOURCESと呼びます。 もし必要なディレクトリが無い、または削除してしまった場合は、端末上でmkrpmdirコマンドを実行してください。 $ mkrpmdir ~ このコマンドにより~/rpm配下に必要なディレクトリを作成できます。 もし、mkrpmdirコマンドが見つからない場合は、vutilsパッケージをインストールしてください。 VineSeed および VinePlus では、原則として GnuPG による署名を行っていただきます。(GnuPG 鍵の作成方法は web などを参照してください。 ) ~/.rpmmacrosに以下の記述があるか確認して下さい。 # gpg signing # %_signature gpg # %_gpg_name Your Name <your mail address> 行頭の # は、コメントを表しますので以下のように修正します。 # gpg signing %_signature gpg %_gpg_name Your Name <your mail address> 署名に GnuPG を使用する宣言 使用する GnuPG 鍵の宣言 使用する GnuPG 鍵に合わせて、Your Nameはあなたの名前(ローマ字表記)、your mail addressはあなたのメールアドレスに変更して下さい。 なお、パッケージ作成時には署名のためのオプションを与える必要がありますが、ファイル ~/.popt に以下の記述を追加しておくとオプションを省略可能になります。 rpmbuild alias --ba -ba --sign rpmbuild alias --bb -bb --sign rpmbuild alias --bs -bs --sign rpmbuild alias --ta -ta --sign rpmbuild alias --rebuild --rebuild --sign では、共通的に必要となる事項を中心にパッケージ作成の基本的な流れを説明します。 この章から、実際にパッケージ作成の手順を説明していきます。 次節以降の準備のためにパッケージ化しようとしているアプリケーションの情報を確認します。 最初にパッケージ化するアプリケーションが、既にVinePlus(VineSeed)向けに用意されていないか確認します。 # apt-get update $ apt-cache search name パッケージが存在していても不具合がある場合やバージョンアップする場合には、パッケージを修正する必要があります。 この様な場合には、apt-get source nameなどとして既存のSPECファイルを取得し、修正するようにしてください。 パッケージが存在しないかバージョンアップする場合は、ダウンロードしたソースをSOURCESに保存してください。 また、以下の情報についても配布元のサイトやソースに含まれる README などのファイルを見て確認してください。 ビルド・インストールの方法 ビルド・実行に必要なライブラリやアプリケーションとそのバージョン 実行時に参照される設定ファイル アプリケーションのビルド・実行に必要なライブラリやアプリケーションがあれば、それらのパッケージがインストールされているか確認してください。 特にライブラリでは、ビルドにのみ必要なファイルがサブパッケージ(通常はname-devel)として用意されている場合があり、注意が必要です。 また、複数のメジャーバージョンを共存させるためにパッケージ名にメジャーバージョンが追加されている場合があります。 パッケージによっては、名前の一部が省略されている場合もあります。 パッケージのビルドには、gtk2-develパッケージがインストールされている必要があります。 (この例では、gtk+ の + が省略されている上、gtk+-1.xと共存するためにパッケージ名にメジャーバージョンである 2 が追加されています。) なお、必要なライブラリ等のパッケージが用意されていない場合は、先にパッケージ化してください。 以下の様な場合には、パッチを用意します。 必要なライブラリが全てインストールされているにも関わらずビルドに失敗する 実行時の不具合がある アプリケーションのインストール先を変更できる仕組みになっていない 設定ファイルをVine Linux向けにカスタマイズしたい ビルドや実行に関する不具合は、既に配布元でも承知して公式のパッチが用意されている場合もあります。 その場合は、公式のパッチをダウンロードしてSOURCESに保存します。 アプリケーションのソースを展開 展開されたディレクトリをコピー $ cp -R srcdir srcdir.org コピー元のディレクトリ(srcdir)以下のファイルに必要な修正を加える パッチを作成する $ diff -uNr srcdir.org/ srcdir/ > patchname.patch patchname.patchをSOURCESに保存 いよいよ、パッケージ作成の肝となるSPECファイルの記述について説明します。 SPECファイルの内容は、以下の主要部分に分類できます。 パッケージ情報 パッケージの作成やインストール等の手順(スクリプト部) インストールされるファイルの一覧 パッケージの変更履歴 SPECファイルの文字コードはUTF-8にしてください。 SPECファイルの冒頭にパッケージのバージョンなど頻繁に使用されるものをマクロとして定義しておくと後々の修正が楽になります。 %define macro literalようにするとパッケージ作成時に%{macro}と書かれた部分をliteralに置換して処理します。 も参照して下さい。 rpmコマンドでパッケージに関する問い合わせを実行した場合に表示される情報やパッケージの依存情報などを記述します。 以下にパッケージ情報の記述例を示します。(#を記述すると#から行末までがコメントとして扱われます。) &ex-pkginfo;&ex-pkginfo; 基本情報から依存情報の部分は、1行につき1つの情報を記述する構成となっています。 各行は「Summary:」のようにタグとそれに続くコロンで始まり、さらにタグに対応する情報が続く形式になっています。 の情報は、rpm -qiなどでパッケージに関して問い合わせを行った場合に表示されます。 タグ内容 Summary パッケージの簡単な説明を英語で記述します。 Summary(ja) Summaryを日本語で翻訳します。 Name パッケージの名前です。定義以降、%{name}というマクロで参照できます。 Version パッケージのバージョンです。定義以降、%{version}というマクロで参照できます。 Release 冒頭の数字は同じバージョンで何回目のリリースになるかを意味します。%{?_dist_release}は、vl5の様に対象となるVine Linuxのバージョンに置き換えられます。定義以降、%{release}というマクロで参照できます。 License アプリケーションのライセンス Group アプリケーションの種類。を参照して下さい。 Packager パッケージメンテナ。BTS.VineLinux.Orgへのログインユーザ名を使用してください。複数のメンテナがいる場合、カンマで区切ります。 Distribution VinePlusやVineSeedのパッケージは、Vine Linuxを指定します。 Vendor 作成したrpmパッケージに関する責任を負うVendor名です。VinePlusやVineSeedのパッケージは、Project Vineを指定します。 Url アプリケーションの情報を提供しているURL タグ内容 Source パッケージ化するアプリケーションのソースファイル名。ソースの入手先を明示するためにURL形式で記述することも可能。 Patch で用意したパッチファイルを指定します。 書式はSourceと同じです。 BuildRoot 仮想インストールのためのディレクトリ名を書きます。直接ディレクトリ名を書くのではなく、例のようにマクロを利用してください。 複数のソースファイルやパッチがあるときはSource0、Source1、...やPatch0、Patch1、...というふうに番号をふって列挙します。(Source0は、Sourceと省略できます。) Souce数字 で指定したファイルは %{SOURCE数字} というマクロとして の %prep や %install などの部分で利用できます。 パッケージの依存情報など他のパッケージとの関係を示すには、のようなタグを使用します。 タグ内容 Requires 作成しているrpmパッケージが動作するのに必要なパッケージ名 BuildRequires パッケージの作成時に必要となるパッケージ名 Conflicts 共存できないパッケージ名 Provides 作成するパッケージが他のパッケージの代替となる場合、そのパッケージ名を記述 Obsoletes パッケージをインストールする際にアンインストールしたいパッケージ名 BuildConflicts パッケージ作成時にはインストールしておけないパッケージ名 <, >, =, >=, <=といった演算子を使うとパッケージのバージョン、リリース番号を限定することもできます。 Requires: ghostscript = 5.10 BuildRequires: gtk2-devel >= 2.16.0 演算子の両側にスペースやタブを入れない場合、パッケージ名からバージョンまでが一つのパッケージ名として認識されてしまいます 例えば、BuildRequires: gtk2-devel>=2.16.0とすると「gtk2-devel>=2.16.0」というパッケージ名だと認識してしまいます。 複数のパッケージが関係する場合は、カンマ(,)やスペースで区切って列挙したり、複数行に分けて記述できます。複数行に分ける場合は、各行にタグが必要です。 パッケージがいくつかのグループに分類できる場合には、複数行に書いた方がわかりやすくなります。 Requires: ghostscript >= 5.10, ghostscript-fonts, VFlib = 2.24, tetex, tetex-extra Requires: ghostscript >= 5.10, ghostscript-fonts, VFlib = 2.24 Requires: tetex, tetex-extra Summaryよりも詳しいパッケージの解説を%descriptionの次の行から、英語で記述します。 Summaryタグの場合と違い、複数行にわたる解説を書くことができます。 なお、日本語による翻訳を追加する場合は、%description -l jaとして、同様に記述できます。 スクリプト部では、パッケージの作成やインストール等の手順を記述します。 &ex-script; スクリプト部は、で示すセクションに分かれます。 各セクションは、独立したbashスクリプトとして実行できるように記述します。 各セクション名が現れた時に #!/bin/sh -eが起動され(Vine Linuxでは/bin/shは/bin/bashにsym.linkされてる)、 各環境変数(RPM_SOURCE_DIRやRPM_PACKAGE_NAMEなど)が定義された後、 次のセクション名が出てくるまで、記述されているスクリプトが実行されます。 環境変数の詳細については、を参照してください。 セクション名概要詳細説明 %prep ソースをビルドする前に実施する準備事項 %build ソースのビルド手順 %install ソースからのインストール手順 %check ビルドされたバイナリが正常に動作するか検証する手順 %clean パッケージ作成後の後始末 その他 パッケージのインストール等の前後に実行する手順 以下、各セクションの詳細を解説します。 ソースをビルドする前に実施する準備事項をシェルスクリプトで記述します。 以下で説明する%setup,%patchなどのマクロを用いて、ソースの展開やパッチの適用などを行います。 なお、このセクションの最初でrm -rf ${RPM_BUILD_ROOT}として、 ${RPM_BUILD_ROOT}(のBuildRootで指定したディレクトリ) を掃除することが多いです。ただし、このときには、 BuildRootの設定には十分気をつけて下さい（何故かわかりますね？） %setup tarでアーカイブされ、 gzipまたはbzip2圧縮されたソースを展開します。 %setupとオプションなしで書くと、以下が順に行われます。 で指定したディレクトリBUILDにcdする。 指定ディレクトリ(-nで指定できる。デフォルトのディレクトリ名は、 ${RPM_PACKAGE_NAME}-${RPM_PACKAGE_VERSION}、後述) がカレント・ディレクトリ(BUILD)に存在すれば消去する。 Sourceで指定したソースのアーカイブを展開する。 指定ディレクトリ(2の指定ディレクトリ名と同じ)にcdする。 %setupの動作を制御する必要がある場合は、を参照してください。 %patch %setupで展開したソースにパッチをあてるためのマクロとしてはたらきます。 オプションなしで%patchと書くと、 patch -p0 -s < ${RPM_SOURCE_DIR}/<Patchで指定したファイル> が起動されます。 のように書くと、 patch -p1 -s < ${RPM_SOURCE_DIR}/<Patchで指定したファイル> と同じことをします。 パッチファイルが複数ある場合、Patch0, Patch1,...に対して、 %patch0 -p1 %patch1 -p1 と実行することも出来ます。%patchには-b <name> (バックアップ・ファイルの拡張子指定、デフォルトは.orig)などのオプ ションがあります。 ソースをmakeするスクリプトの開始であることを示し、また、 %setupで指定したディレクトリにcdするマクロとしてはたらきます。 以下には、makeを行うときの手順をスクリプトとして書きます。 ここでの処理で必要となるパッケージ等は、BuildRequires(build): で指定します。 autoconf化されたソースなどmakeの前に $ configure --prefix=/usr などとしてインストールするディレクトリなどを制御できるソースがあります。 configureスクリプトが用意されている場合には、%configureマクロを利用すると便利です。 %configureマクロは、/usr/lib/rpm/macrosで次のように定義されており、 Vine Linux推奨のコンパイルフラグやインストールディレクトリを設定できます。 %configure \ CFLAGS="${CFLAGS:-%optflags}" ; export CFLAGS ; \ CXXFLAGS="${CXXFLAGS:-%optflags}" ; export CXXFLAGS ; \ FFLAGS="${FFLAGS:-%optflags}" ; export FFLAGS ; \ ./configure --host=%{_host} --build=%{_build} \\\ --target=%{_target_platform} \\\ --program-prefix=%{?_program_prefix} \\\ --prefix=%{_prefix} \\\ --exec-prefix=%{_exec_prefix} \\\ --bindir=%{_bindir} \\\ --sbindir=%{_sbindir} \\\ --sysconfdir=%{_sysconfdir} \\\ --datadir=%{_datadir} \\\ --includedir=%{_includedir} \\\ --libdir=%{_libdir} \\\ --libexecdir=%{_libexecdir} \\\ --localstatedir=%{_localstatedir} \\\ --sharedstatedir=%{_sharedstatedir} \\\ --mandir=%{_mandir} \\\ --infodir=%{_infodir} ここで定義されていないオプション、例えば--disable-scrollkeeperというようなオプションが必要な場合には %configure --disable-scroolkeeperのように追加でオプションを指定できます。 ファイルをinstallするスクリプトの開始であることを示し、また、 %setupで指定したディレクトリにcdするマクロとしてはたらきます。 以下には、installを行うときの手順を示します。 データ定義部のBuildRootで設定したディレクトリ(${RPM_BUILD_ROOT}) の下に全てのファイルがインストールされるように、工夫しましょう。 Makefileが短いときには、修正してpatchをつくるかわりに、ここに、 cp, installコマンド等を用いたinstallスクリプトを書くのも一手です。 %setup のところと同じように、マクロ %{SOURCE数字} を使って Source: で指定したファイルを直接インストールすることもできます。 %{__install} -m 644 %{SOURCE2} %{buildroot}/where/there/ なお、rpm-3.0.5以降では、インストールされたバイナリは rpmパッケージにする段階で自動的にstripされますので、 %installでbinaryのstripを行う必要はありません。 ここでの処理で必要となるパッケージ等は、 BuildRequires(install): で指定します。 ビルドされたバイナリが正常に動作することを check するスクリプトの開始であることを示します。 %setupで指定したディレクトリにcdするマクロとしてはたらきます。 以下には、make test や make check などを実行するときの手順を示します。 GNOME などが利用する desktopファイルの書式チェックなどを行うこともできます。 を参照してください。 rpm-4.2以降で実装された機能です。 ここでの処理で必要となるパッケージ等は、 BuildRequires(install): で指定します。 rpmを作ったあとの後始末を記述します。 ここでの処理で必要となるパッケージ等は、 BuildRequires(clean): で指定します。 %filesはじまる部分で、RPMパッケージに収録するファイル名を列挙します。 &ex-files; このとき以下に注意してください。 ここに書くファイル名は重複してはいけません。 列挙されたファイルは、%docで指定するものを除いて、 %installまでのスクリプトの実行によって、 記述した通りの場所(${RPM_BUILD_ROOT}を''/''とみなす) にinstallされるものでないといけません。 列挙されたファイルがおかしな userID/groupID を持っていると、 rpmパッケージが正常にbuildできないことがあります。 ファイルを含まないバーチャルパッケージRequires で他のパッケージをまとめてインストールしたり、%post, %preun, %postun などで何らかのコマンド処理を行うようなパッケージ。task-gnome や task-tetex などのように task- という名前が使われます。を作る場合でも、%files という行だけは必要になります。%files という行を省略してしまうと、rpmbuild コマンドで処理しても src.rpm しか作れません。 rpmbuildコマンドは、SPECファイルに基づいてRPMパッケージを作るときに、 で設定した一連のスクリプトを実行した後、 ${RPM_BUILD_ROOT}をとみなして%files以下で指定されたファイルを回収し、 それを指定位置にinstallするようなRPMパッケージをつくります。 %docというマクロを用います。のように、%doc READMEとすると、 %setupで指定したホームディレクトリ下のREADMEが、 ${RPM_BUILD_ROOT}/usr/doc/hoge-1.1-2/にcpされたのち、 rpmパッケージに回収されます。つまり%docは、 ドキュメントファイルのインストールとパッケージングのためのファイル指定を同時に行うマクロとしてはたらきます。 以下のように、ディレクトリごと指定もできます。 %doc doc/ その絶対パスで指定します。 個別ファイルはそのまま指定。(/usr/bin/hoge.bin など) あるディレクトリ以下の全てのファイルをrpmパッケージにいれたいときには、 そのディレクトリ名を書きます。(タグなし、/usr/hoge/ など)。 アンインストール時には、そのディレクトリごとなくなります。 ワイルドカードも使えます。(/usr/hoge/* など) rpm-3.0.5以降では、man ファイルや info ファイルは自動的にgzipで圧縮されます。 %filesにmanやinfoのファイル名を書くときには拡張子.gzをつけるのを忘れないようにしましょう。 %dir <dir name> 指定したディレクトリだけをパッケージに含める。 ``/usr/hoge/'' = ``%dir /usr/hoge/'' + ``/usr/hoge/*'' ってかんじです。 %config <file name> configファイルであることを示す。 ファイルが書き換えられていた場合、 アンインストール時には .rpmsaveをつけた名前で保存されます。 アップグレード時には新しいファイルと置き換えられ、 元のファイルは .rpmsaveをつけた名前で保存されます。 ファイルが変更されていた場合、 アップグレード時に新しいファイルに置き換えずにもとのファイルをそのまま使う場合には、 %config(noreplace) を指定します。 %config(noreplace) <file name> この場合新しいパッケージに入っている設定ファイルは、 .rpmnew をつけた名前で保存されます。 また、アップグレードではなく、同じバージョンをインストールし直した時には、 .rpmorig をつけた名前で保存されます。 存在しなくても問題ないファイルの場合は、 %config(missingok) を指定します。 %config(missingok) <file name> これは、rpmコマンドの -V オプションでチェックした時に、 ファイルが無くてもエラーにならないようにするためのものです。 %attr(<mode>,<owner>,<group>[, dirmode]) <file name> %filesに列挙するファイルのパーミッションやuser ID、group IDを設定する。 例えば、 %attr(755,root,root) /usr/lib/hoge とする。一部の属性を省略(書き換えない)したいときには - を使って、 %attr(755,-,root) /usr/lib/hoge とする。 %attr(755,root,root) のように( )の中には 3つしか書かないことが多いですが、 %attr(755,root,root,755) のように 4つ書くこともできます。 4つ目の数字(dirmode)は、 ディレクトリとサブディレクトリのパーミッションになります。 %defattr(<mode>,<owner>,<group>[, dirmode]) それ以降の行に書かれた属性のデフォルト値を設定する。 %attr が出てきた行を除いて、それ以降に書かれたものに共通になります。 %defattr も %attr も何度でも使えます。 次の例だと、/usr/bin/hoge と /usr/lib/hoge は一つ目の %defattr の 755 になり、 /usr/share/locale/ja 以降は二つ目の %defattr の 644 になります。 %defattr(755,-,-) /usr/bin/hoge /usr/lib/hoge %defattr(644,-,-) /usr/share/locale/ja /usr/share/locale/lv %attrと同様、4つ目の数字は、 ディレクトリとサブディレクトリのパーミッションになります。 %verify( ) <file name> %filesに列挙するファイルについて、rpm -V でパッケージを検証する時に、検証する項目を指定する。 ( ) の中にはにあるものが入ります。 複数指定する場合には、, もしくは スペース で区切ります。 項目内容sizeサイズmodeパーミッションとファイルの種類md5md5 値rdevデバイスファイルのモードビットなどlinkリンク先userファイルの所有者 usergroupファイルのグループ groupmtimeファイルの更新時刻 mtime(modification time) not とすると検証しない項目だけを指定できます。 書き換えることが前提となる設定ファイルなので、ファイルサイズ と md5値 と 更新時刻 は検証する必要がないといった場合には、 %verify(not size,md5,mtime) /etc/hoge.conf のように指定します。 %defverify( ) それ以降の行に書かれたファイルについて検証する項目を設定します。 %verify と %defverify は、%attr と %defattr と同じような関係です。 %config %attr %verify などは、次のようにスペースを入れることで一つのファイルに複数指定できます。 %config %verify(not size,md5,mtime) /etc/hoge.conf この%filesの指定は少々面倒なとこかもしれません。 新しくパッケージをつくる場合などは、%install までのスクリプト部を書いたところで、%files以下は何も書かないまま、一度、そのSPECファイルから rpm をbuildしてみるとよいかもしれません。(rpm -bi hoge.spec これについては次節)。 そのあとで、${RPM_BUILD_ROOT}以下にinstallされてるファイルを、find コマンドで見てみて%filesの指定をします。 %filesで書かれていないファイルがある場合には、build 時に パッケージに未収録のファイルを検査中: /usr/lib/rpm/check-files /var/tmp/hoge-1.1-root 警告: パッケージに未収録のインストール済みファイルが見つかりました: と未収録のファイルの名前などが表示されます。 この部分を利用して %files の部分を作成するのもよいでしょう。 ソースのバージョンアップなどで、作成されるファイルが増減したり、ディレクトリが変わったりする場合があります。未収録のファイルがあっても、build が途中で終了せず、パッケージを作成できてしまう場合があるので、build 時のメッセージは必ず確認してください。 %changelog以下にパッケージの更新履歴を英語で記述します。最新の更新情報が上にくるように書きます。 &ex-changelog; 一行目の最初に * を書き、日付と変更を加えた人の名前を書きます。 二行目以降に - を書き、更新内容を書きます。 今日の日付は date コマンド で LANG=C date +'%a %b %d %Y' とすると確認できます。 12月1日のように日の部分が一桁の場合は 0 をつけ 01 のようにします。 Vine Linux でのパッケージングルールでは 一行目に日付、パッケージャーの名前、メールアドレス、パッケージのバージョン,、リリース番号を書くことになっています。 * 曜日 月 日 西暦年 パッケージャーの名前 <メールアドレス> バージョン-リリース番号 - 更新内容 更新内容の部分でもマクロは展開され %{name} は hoge になります。 マクロを展開せずにそのまま %{name} と書きたい場合は %%{name} のように % を二つ続けて書いて下さい。 日本語を使うことも可能になっていますが、Summary や description のように環境変数に応じて日本語や英語のどちらかを表示するという仕組みは無いので、 英語だけで書くほうがよいでしょう。 RPMパッケージを作成するには、次のコマンドを実行します。 $ rpmbuild -ba --sign hoge.spec 特に問題がなければ、バイナリパッケージとソースパッケージの両方が作成されます。 どちらか一方のみを作成する場合は、オプション-ba(build all)の代わりに -bb(build binary)あるいは-bs(build source)を使用します。 なお、オプション--signは、パッケージに署名することを意味します。で~/.poptの設定をした場合は、省略可能です。 署名オプションが有効になっていれば、次の様なプロンプトが表示されるのでGnuPG鍵のパスフレーズを入力して下さい。 パスフレーズの入力: Vine Linux 3.0以降で採用されているrpm-4.xではパッケージのビルドはrpmbuildコマンドを利用するようになりました。過去との互換性のためVine Linuxでは、rpmコマンドも利用できるようになっていますが、将来的に廃止の予定であるため今後はrpmbuildコマンドをお使いください。 パッケージを作成せずに段階的にスクリプト部を検証する場合は、のオプションを使用します。 この際、オプション--short-circuitを併用すると一つ前の段階の動作結果を利用できます。 オプション実行内容 -bp %prepセクションの実行(build prep) -bc %prep、%buildセクションの実行(build compile) -bi %prep,%build,%install,%checkセクションの実行(build install) 次のように | (パイプ) と tee コマンドを利用して、ビルド中のメッセージをファイルに残しておくと、エラーの確認や、%files の確認、Requires の確認といった作業がやりやすくなります。 $ rpmbuild -ba hoge.spec 2>&12>&1 はエラーメッセージ(2:標準エラー出力の内容)を (tee コマンドに渡すために) 標準出力(1) にリダイレクトする(2に流れるメッセージを 1と合流させる)というものです。これで、tee で指定したファイル hoge-build.log に、標準出力のメッセージと一緒にエラーメッセージも書き込まれるようになります。 |tee hoge-build.log 他に、 tar.gz 形式のソースの中に含まれている SPEC ファイルを用いて build するときには、 -b のかわりに -t を用いて、 $ rpmbuild -ta hoge.tar.gz などとします。 SPEC ファイルのエンコーディング等を確認する。 $ rpm -qpi hoge.rpm で文字化けしないかどうか、また、バージョンなど、記述した内容にミスが無いか確認する。 $ LANG=C rpm -qpi hoge.rpm として英語による出力も確認する。 Changelog の記述を確認する。 $ rpm -qp --changelog hoge.rpm | head などで、追記した部分を確認する。 依存関係(Requires)を確認する。 $ rpm -qpR hoge.rpm パッケージがシェルスクリプトのファイルなどを含んでいる場合、その中で利用されるコマンド(もしくはパッケージ)が Requires: で指定されているかを確かめる必要もあります。これは、実際にシェルスクリプトを実行するなどして確かめる必要があります。 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 build 時の依存関係(BuildRequires)を確認する。 できあがった src.rpm を、BuildRequires で指定していない devel などのパッケージをアンインストールした状態で rebuild してみる。 *-devel というパッケージをアンインストールするのに、筆者は(bash で)次のようなコマンド(for文)を利用しています。sed や awk で処理してる部分はもう少し上手なやり方があるかもしれません。 for i in `rpm -qa --last | grep devel | sed s/devel-/"devel "/ | awk '{print $1}'` ; do echo $i ; rpm -q $i && rpm -e $i ; rpm -q $i && apt-get remove $i ; done ローカルに apt のリポジトリを作成しておくと、apt-get install や apt-get build-dep で、依存関係のチェック等が行えて便利です。 では、を一通り理解した方向けにより高度なパッケージ作成に必要な情報を提供します。 スクリプト部の各タグからはじまる部分は、先にも述べた通り独立したbash scriptとして働くので、 その範囲内で、 TEXMF="/usr/share/texmf" と変数を定義して用いることができます。 定義した変数は ${ } で囲んで ${TEXMF} のようにすると利用できます。 $TEXMF のように { } を省略することもできます。 /usr/share というディレクトリは標準で %{_datadir} というマクロが定義されているので TEXMF="%{_datadir}/texmf" とすることができます。 マクロについては、次節以降で説明します。 また、以下の変数は各タグ毎に環境変数として定義されます。 RPM_SOURCE_DIR ディレクトリSOURCESを表す。参照。 デフォルトは、 RPM_SOURCE_DIR="/usr/src/redhat/SOURCES" RPM_BUILD_DIR ディレクトリBUILDを表す。参照。 デフォルトは、 RPM_BUILD_DIR="/usr/src/redhat/BUILD" RPM_DOC_DIR %docで指定されたドキュメントファイルをインストールするためのディレクトリを表す。 rpmrcファイルの、defaultdocdirで指定する。デフォルトは、 RPM_DOC_DIR="/usr/doc" RPM_OPT_FLAGS コンパイル時にコンパイラにわたすデフォルトのオプション指定を表す。 rpmrcファイルの、optflagsで指定する。 アーキテクチャ毎に指定ができる。 例えば、%buildにおいて以下のように使う make CFLAGS=${RPM_OPT_FLAGS} デフォルトはarchitectureがi386のときには、 RPM_OPT_FLAGS="-O2 -m486 -fno-strength-reduce" RPM_ARCH_FLAGS buildを行なっているシステムのアーキテクチャを表す変数。 アーキテクチャがi386なら、 RPM_ARCH_FLAGS="i386" RPM_OS buildを行なっているシステムのOSをあらわす変数。Linuxなら、 RPM_OS="Linux" RPM_BUILD_ROOT BuildRootで設定された仮想インストールのためのディレクトリを表す。 (のBuildRootの項参照) RPM_PACKAGE_NAME Nameで設定されたパッケージ名を表す。 (のNameの項参照) RPM_PACKAGE_VERSION Versionで設定されたバージョン名を表す。 (のVersionの項参照) RPM_PACKAGE_RELEASE Releaseで設定されたリリース番号を表す。 (のReleaseの項参照) マクロは %define マクロの名前 内容 のように書くことで定義できます。 %{マクロの名前} のように書くことで利用できます。 {} を省略して %マクロの名前 と書くこともできますが、 {} をつけて利用したほうが、 に出てきた %prep や %build などといったタグと区別しやすくなります。 マクロは、%setupや%installなどのスクリプト部やファイル定義部など、 SPECファイル全体で使えるので、 うまく使うとバージョンアップに追随してSPECファイルを書くときに楽ができます。 %define で定義せずに使えるマクロとして %{name} , %{version} , %{release} があります。 にでてきた、Name Version Release の値が、 それぞれ %{name} , %{version} , %{release} の内容になります。 %define name hoge として name を定義し Name: %{name} のように利用しているSPECファイルを見かけることがありますが、 Name の値を参照するのが %{name} なので、本来とは逆の使い方になり問題を起こす場合があるかもしれません。 このような場合は %define pkg_name hoge , Name: %{pkg_name} のように %{name} とは違う名前のマクロを利用したほうがよいでしょう。 のSPECファイルの例のデータ定義部は、 %{name} と %{version} というマクロを利用して、以下のように書くことができます。 Name: hoge なので %{name} は hoge に、Version: 1.1 なので %{version} は 1.1 になります。 Name: hoge Version: 1.1 Release: 1 Source: %{name}-%{version}.tar.gz Patch: %{name}.patch SPECファイルの中(どこでもいいです)に %dump と書いておくと、 rpmbuild コマンドでパッケージを作る時に、 すべてのマクロが標準エラー出力に出力され、確認することができます。 マクロの定義を取り消したいけれど、行を削除するのではなくコメントとして残しておきたいという場合には、 %define に % をつけて、%%define にし、さらに # をつけます。 %define hoge hige を # %%define hoge hige のようにします。 # %define hoge hige ではだめです。 # 以降はコメントになるという処理よりも、マクロの %define の方が先に処理されるので、 %define hoge hige が解釈されてしまいます。 よく利用されるコマンドやディレクトリなどにはあらかじめマクロが定義されています。 自分で定義した変数と同様にSPECファイル全体で使えます。 標準で定義されているマクロは /usr/lib/rpm/macros に書かれています。 ユーザー毎のマクロを記述するファイルは~/.rpmmacrosです。 ~/.rpmmacros に書く場合には %マクロの名前 内容 とします。 で出てきた %_topdir などもマクロです。 ユーザー毎のマクロと、標準で定義されているマクロをあわせたものは、 rpmコマンドの --showrcオプションで確認できます。 $ rpm --showrc また、それぞれのマクロがどんなものかは、 $ rpm --eval "%{マクロ}" のようにすると確認できます。 標準で定義されているマクロについてはなるべく利用してください。 SPECファイルのメンテナンスしやすさの向上につながります。 たとえば、%{configure} や %{makeinstall} といったマクロを利用することで、 %build や %install の部分を簡潔に書くことができる場合があります。 %build %{configure} %{__make} %install %{makeinstall} $ rpm --eval "%{configure}" などとやってそれぞれのマクロがどんなものか確認して下さい。 rpm 4.x および Vine Linux 4.1 で定義されているマクロを使うと のSPECファイルは次のようになります。 &ex-usemacro; Requires には、従来の Requires: だけではなく Requires(pre): などのように ( ) をつけて厳密に指定することもできるようになりました。 ( ) の中にはにあるものが入ります。 ( ) の中に入る項目は のタグ等に対応しています。どの部分で必要になるかを書きます。 Requires( ): のように ( ) の中に何も書かなかった場合は、Requires: として扱われます。 ( ) の中は、Requires(pre,preun,post,postun): のように , を用いることで複数を同時に指定できます。 項目対応するタグ等pre%pre で必要になるものpreun%preun で必要になるものpost%post で必要になるものpostun%postun で必要になるものprereqインストール時に必要になるものverify%verifyscript で必要になるものinterpスクリプト部を解釈(interpret)するために必要になるものrpmlibrpmのデータベース等を扱うために必要なもの Requires(pre): などを指定した場合には、インストール、アンインストールされる順番が保証されます。 指定されたパッケージは先にインストールされ、後にアンインストールされます。 prereq は pre,preun,post,postun などよりも曖昧な書き方ですが、以前 PreReq で書かれていたものを Requires に機械的に置き換える場合には利用できると思います。 rpmlib については、通常、build 時に自動的に追加されるものなので、特別な機能を利用するのでなければ、記述する必要はありません。 interp も、自動的に追加されますが、特別な shell などを利用する場合には記述しておいた方がよいでしょう。 日本語化された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 という仮想パッケージを要求するものが多いです。 コンパイラなどのパッケージや、 ヘッダーファイルやライブラリなどを含んだ 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 も ( ) をつけて詳細な指定をすることができます。 ( ) の中にはにあるものが入ります。 ( ) の中に入る項目は のタグ等に対応しています。どの部分で必要になるかを書きます。 項目対応するタグ等prep%prep,%setup で必要になるものbuild%build で必要になるものinstall%install,%check で必要になるものclean%clean で必要になるもの 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 よりも先に作成する必要があるということを示しておきます。 hoge-1.1.tar.gzを展開したときに、hoge-1.1/というディレクトリができるなら、 オプションをつけなくても以上の作業が行われますが、例えば、 hoge/というディレクトリができるなら、このディレクトリの下にcdできるように、 %setup -n hoge または、 %setup -n ${RPM_PACKAGE_NAME} と指定します。 複数のソースがあるときには以下に述べるオプション-aや-bを使います。 例えばSource、Source1、Source2の3つがあるときには、 %setup -a 1 -a 2 -n hoge などとします。(以下のオプションの指定参照。) この%setupにはさまざまなオプションがありますが、 代表的なものを以下に示します。 -n <ディレクトリ名> %setupを実行した後(もしくは前)にcdするディレクトリ名(name)を指定する。 このオプションを省略したときの、デフォルトのディレクトリ名は、 ${RPM_PACKAGE_NAME}-${RPM_PACKAGE_VERSION}。 -c 指定ディレクトリ(上の-nオプションで指定したディレクトリ) を作成し(create)、そこにcdした後にソースの展開をします。 -a <#> Source0を展開した後、 指定ディレクトリ(上と同じ)にcdした(after)、 #番目のソース(Source#)の展開をします。 %setup -a 2 -a 3 と複数-aオプションが指定された時には、 Source0 が展開された後、指定ディレクトリに cd し、 Source2、Source3を展開します。 (Source0の展開は最初の一回だけです。) -b <#> Source0を展開した後、 指定ディレクトリ(上と同じ)にcdする前に(before)、 #番目に指定されてるソース(Source#)の展開をします。 -D 先に述べたように、%setupは、まず、指定ディレクトリ(上と同じ)が、 ディレクトリBUILDの下にあるかどうかをチェックして、もし存在していたら、 それを削除してから、ソースの展開などの作業を行います。 %setupを複数回呼びたい場合、 2回目に%setupを呼んだ時に最初の%setupで展開したディレクトリを削除されては困ります。 この-Dオプションは、このような削除を行わないようにします。(あまり使いません) -T ソースの展開を行いません。先に述べたように、 オプション指定を -a 2 や -b 2 とすると、 Source0とSource2で指定したものが展開されます。 Source2だけを展開したいときには、このオプションを使って、 %setup -T -a 2 とします。また、 %setup -T -c hoge とすると、パッケージの展開は行わず、ディレクトリhogeを作って、 そこにcdします。 -q ソースの展開のとき、展開中の情報を表示しません。 たとえば tar での展開の時に、-q 無しだと tar xvvf、-q 有りだと tar xf のように変わります。 次のように tar.gz ではないファイルが Source0 となる場合があります。 Source0: hoge-%{version}.lzh tar.gz ではないので、%setup では展開できません。 このような場合には、まず %setup の -Tオプション を利用して作業ディレクトリに移動します。 %setup のあとには、bash script を書いて作業を行うことができるので、 通常のコマンドで Source0 のファイルを展開します。 %setup -T hoge-%{version} lha x %{SOURCE0} 次のように tar.gz などでは無いファイルが Source2 としてあるということがあります。 Source0: hoge-%{version}.tar.gz Source1: hoge-additional-%{version}.tar.gz Source2: how-to-use-hoge.txt こういった場合には、Source0 と Source1 を %setup で展開したあとで、installコマンドなどで、Source2 に対応するマクロ %{SOURCE2} を処理します。 %setup で展開するのと同じ処理をしたければ、 %setup -q -a 1 %{__install} -m 644 %{SOURCE2} . のようにします。 %setup で Source0 を展開してできたディレクトリ BUILD/hoge-%version/ に移動しているので、installコマンド で . (カレントディレクトリcurrent directory, 現在のディレクトリ) を指定すると . は BUILD/hoge-%version/ となっているので、BUILD/hoge-%version/に Source2 が install されます。 他のファイルと同じように BUILD/hoge-%version/ にあるので %doc として指定するのもそのままできます。 %files %doc how-to-use-hoge.txt %{SOURCE2} といったマクロは %doc のところでは使えないので、%doc %{SOURCE2} とすることはできません。 lha や unzip など、特別なコマンドが必要になる場合は、 BuildRequires(prep): で指定します。 スクリプト部に入れることができるセクションは、で説明したほかにもいろいろあります。 セクション名概要詳細説明 %pre RPMパッケージをインストールするときパッケージの展開前に行うことを書く %post RPMパッケージをインストールするときパッケージの展開後に行うことを書く %preun RPMパッケージをアンインストールするとき展開ファイルの削除前に行うことを書く %postun RPMパッケージをアンインストールするとき各ファイルを削除した後に行うことを書く さらに、他のパッケージがインストールされた時に起動するスクリプトも記述できます。 セクション名概要詳細説明 %triggerin あるパッケージがインストールされていた、もしくは、された時に起動するスクリプト %triggerun あるパッケージの削除前に起動するスクリプト 参照 %triggerpostun あるパッケージの削除後に起動するスクリプト 参照 パッケージが正しくインストールされているかを検証するには、rpm コマンドで -V オプションを用いますが、-V オプションでできることを増やすためのセクションもあります。 セクション名概要詳細説明 %verifyscript RPMパッケージを検証するとき(rpm -Vを実行した時)に追加して起動するスクリプト この章で説明するセクションは、SPECファイルからRPMパッケージを作るときには、実行されることはありません。 %pre %post %preun %postun %triggerin %triggerun %triggerpostun といったセクションを使うのは、ちょっと注意が必要です。 詳しくは、を参照してください。 RPMパッケージをインストールするとき、パッケージの展開前に行うことを書く。 -pオプションについては%postの場合（以下）参照。 ここでの処理で必要となるパッケージ等は、Requires(pre): で指定します。 RPMパッケージをインストールするとき、パッケージの展開後に行うことを書く。 ここでの処理で必要となるパッケージ等は、Requires(post): で指定します。 %post if [ "$1" = 0 ] ; then %{_syssbindir}/install-info %{_infodir}/hoge.info.gz %{_infodir}/dir fi として、info のメニューエントリに infoファイルを追加します。 if [ $1 = 0 ]; then と fi の行は、 アップグレード時には実行せず、インストール時だけに実行させるための記述です。 も参照してください。 %{_syssbindir}/install-info というコマンドが必要になるので、 Requires(post): %{_syssbindir}/install-info とします。 info ファイルは、アンインストール時にも処理が必要になります。 も参照してください。 %post %{_syssbindir}/ldconfig とすると、ldconfigが実行される。また、代わりに %post -p %{_syssbindir}/ldconfig と、-pオプションを用いて書くと、 シェルを起動すること無く直接コマンドが実行される。 またこのコマンドはrpmパッケージのインストール時に必要なコマンドとして、 Requires(interp): %{_syssbindir}/install-info として登録される。 正確にいうと、タグに -pオプションをつけた場合は、 /bin/sh ではなく別のプログラムでスクリプト部分を解釈(interpret)させるということになります。 この場合には Requires(interp) として登録されます。(%postなので Requires(post) としても登録されます。) %post -p %{_syssbindir}/ldconfig # update ld.so.cache %files この場合は %post と %files の間の2行が、スクリプト部分になります。 一行目に # update ld.so.cache と書いてあります。 bash であれば、# で始まる行は コメントと解釈され無視されますが、 このスクリプト部分を読み、実行するのは /bin/sh ではなく %{_syssbindir}/ldconfig です。 ldconfig には # 以降をコメントとして無視するというルールは無いので、 そのまま実行しようとしてエラーになります。 エラーを起こさないようにするには %post -p %{_syssbindir}/ldconfig %files とするか、 %post %{_syssbindir}/ldconfig # update ld.so.cache %files とします。 一つ目の例では、%{_syssbindir}/ldconfig がスクリプト部分を実行するために起動し(、起動した時点で ld.so.cache が更新されますが)、スクリプト部分については何も書かれていないので何もせずに終了します。 二つ目の例では、/bin/sh が起動し、スクリプト部分を解釈し %{_syssbindir}/ldconfig を実行、# 以下はコメントなので無視します。 RPMパッケージをアンインストールするとき、展開ファイルの削除前に行うことを書く。 ここでの処理で必要となるパッケージ等は、Requires(preun): で指定します。 -pオプションについては%postの場合と同様です。Requires(interp): と Requires(preun): に登録されます。 %preun if [ $1 = 0 ]; then %{_syssbindir}/install-info --delete %{_infodir}/hoge.info.gz %{_infodir}/dir fi として、info のメニューエントリから削除します。 if [ $1 = 0 ]; then と fi の行は、 アップグレード時には実行せず、アンインストール時だけに実行させるための記述です。 も参照してください。 RPMパッケージをアンインストールするとき、各ファイルを削除した後に行うことを書く。 ここでの処理で必要となるパッケージ等は、Requires(postun): で指定します。 -pオプションについては%postの場合と同様です。Requires(interp): と Requires(postun): に登録されます。 あるパッケージがインストールされていた、もしくは、された時に起動するスクリプトを書く。 %triggerin -- hoge echo "hoge is installed" と書いておくと、パッケージhogeをインストールしたときに、 上記メッセージが表示されます。以下のように、バージョン指定もできます。 %triggerin -- hoge > 3.0 echo "hoge is installed" 同様にして、あるパッケージの削除前に実行される%triggerun、 あるパッケージの削除後に実行される%triggerpostunがあります。このセクションについては、 /usr/share/doc/rpm-<version>/triggers に詳しい説明があります。 RPMパッケージを検証するとき(rpm -Vを実行した時)に、追加して実行することを書く。 ここでの処理で必要となるパッケージ等は、Requires(verify): で指定します。 -pオプションについては%postの場合と同様です。Requires(interp): と Requires(verify): に登録されます。 このスクリプトの実行結果は、成功した場合には何も表示されず、エラーが発生したときにエラーメッセージのみが標準出力に出力されます。rpm -Vvv などのようにした場合には、標準出力への出力も確認できます。 たとえば、%pre で %{_sbindir}/useradd hoge などとしてユーザーを登録した場合には、 %verifyscript %{_bindir}/id hoge としておくと、hoge というユーザーが存在しているかどうかを確認することができます。 この場合、/usr/bin/id というコマンドは coreutils というパッケージに含まれているので、 Requires(verify): %{_bindir}/id あるいは、Requires(verify): coreutils とします。 インストールされるファイル全体の容量が大きくなる場合、アプリケーションの実行時に必要なファイルのみを本体に収録し、他のファイルをサブパッケージ化することがあります。 たとえば、muleのRPMパッケージをつくるときに、本体のRPMパッケージがelcを含んでいれば、 そのソースであるelファイルはなくてもmuleの実行には問題ないですから、 mule.rpm と mule-el.rpm みたいにわけたほうがよいかもしれません。 また、ライブラリや開発用ヘッダファイルもソースに含まれるアプリケーションをパッケージ化する時は、 アプリ本体の hoge.rpm と、開発者用に hoge.h を入れたhoge-devel.rpmにわけたいこともあるでしょう。 ドキュメントが大きいと、hoge-docs.rpmも別に作りたいこともあるでしょう。 こういうときには、ちょっとSPECファイルを変更するだけで、 サブパッケージの作成をすることができます。 具体的には、 サブパッケージ(ここでは、hogeのサブパッケージhoge-docsとする)のための、 データ定義部(%package docsではじまり、GroupやSummary、%description docsなどを書く部分)と、 そのサブパッケージにいれるファイルを列挙した%files docs から始まるファイルリストを付け加えます。 具体例は、RPM-BUILD-HOWTOにもありますので、興味のある人はそちらを参照してください。 には、よく使われるサブパッケージ名を記載しています。サブパッケージ作成時の参考としてください。 サブパッケージ名収録内容 devel メインパッケージのライブラリを使うプログラムをコンパイルする際に必要なヘッダファイル (*.h) libs ランタイムライブラリ *.so.*。本体パッケージのサイズがある程度大きくなった場合などの理由がある場合、本体にはバイナリや設定ファイルを、ライブラリを -libs サブパッケージに分けて収録することがあります。 static static ライブラリ (*.a)。明確な理由により static ライブラリを必要とする場合にサブパッケージ化する。それ以外の場合は、パッケージ対象から除外してください。 tools, utils 本体のパッケージが主にライブラリを収録している場合、ツールなどのバイナリやスクリプト群をサブパッケージ化する場合があります doc, docs 付属ドキュメント類などを独立したサブパッケージに分けたもの demos, example サンプルスクリプトやサンプルコード類をサブパッケージに分けたもの GNOME,KDE,Xfce のメニューに追加するためには、ディレクトリ/usr/share/applicationsに アプリケーションの名前.desktop というファイル(以降 desktopファイルと呼びます)をインストールする必要があります。 desktopファイルを取り扱う desktop-file-installコマンド、desktop-file-validateコマンド、update-desktop-databaseコマンドは、desktop-file-utilsというパッケージに含まれています。 desktopファイルの扱いは次のような手順になります。 %installタグの部分で次のようにして desktopファイルを%{buildroot}/%{_datadir}/applicationsにインストールしておきます。 %install %{__mkdir_p} %{buildroot}/%{_datadir}/applications %{_bindir}/desktop-file-install --dir=%{buildroot}/%{_datadir}/applications hoge.desktop %checkタグの部分で次のようにして desktopファイルが書式にしたがって正しく書かれているかをチェックします。 %check %{_bindir}/desktop-file-validate %{buildroot}/%{_datadir}/applications/hoge.desktop ソースから make する、make install するなどの部分ではこのチェックが行われないことも多いので、%checkタグの部分でチェックを行うようにしておきます。 desktop-file-validateコマンドは複数のファイルをまとめて処理できないので、*.desktop のようにはできません。desktopファイルの数だけ、コマンドを書いてください。もちろん、for文などを使ってもかまいません。 %postタグや%postunタグの部分で %post if [ -x %{_bindir}/update-desktop-database ] ; then %{_bindir}/update-desktop-database %{_datadir}/applications fi %postun if [ -x %{_bindir}/update-desktop-database ] ; then %{_bindir}/update-desktop-database %{_datadir}/applications fi のように処理します。 update-desktop-database コマンドがインストールされていなければ実行しない、という形にすることで、twm や icewm や WindowMaker など、GNOME等のメニューとは直接関係ないウィンドウマネージャを使用しているときに、deskto-file-utils に依存せずにすむようになります。 他のファイルと同じように %filesの部分に入れておきます。 %files %{_datadir}/applications/hoge.desktop BuildRequires で desktop-file-utils を指定します。 BuildRequires(install,check): desktop-file-utils Emacsen には emacsen-common というパッケージがあり、 インストールされている Emacsen の FLAVOR の情報や、 FLAVOR ごとに、その FLAVOR で byte compile された Emacs Lisp パッケージのリストを管理するという仕組みがあります。 この仕組みを用いることで以下のようなことが可能となっています。 パッケージのインストール時に、すでにインストールされている Emacsen の FLAVOR ごとにそれぞれ byte compile して elc ファイルを作成する。 パッケージのアンインストール時に、すべての FLAVOR からパッケージの elc ファイルを削除する。 Emacsen の FLAVOR のインストール時、アンインストール時に、その FLAVOR で byte compile する、FLAVOR で byte compile した elc を削除する。 この仕組みを利用するために、Emacs Lisp のパッケージでは以下のようなことをしておきます。 %installタグの部分では byte compile していない el ファイルを %{_datadir}/emacs/site-lisp/%{name} 以下にインストールします。 Source2 や Source3 などに byte-compile と install を行うためのスクリプトAと、 byte-compile してできた elc ファイルを削除するためのスクリプトBを用意します。 インストールに使える Makefile 等がある場合は %installタグの部分で %{_datadir}/emacs/site-lisp/%{name} 以下に Makefile 等をインストールしておき、 スクリプトの中から利用できるようにします。 install 用のスクリプトAでは、 Emacsen の FLAVOR に応じて %{_datadir}/FLAVOR/site-list/%{name}/ 以下に bytecompile した elc ファイルをインストールするようにします。 uninstall 用のスクリプトBでは、 Emacsen の FLAVOR に応じてスクリプトAでインストールした elc ファイルを削除するようにしておきます。 %installタグの部分で次のようにして、スクリプトAとスクリプトBをインストールします。 %_installemacsenscript %{name} %{SOURCE2} %_removeemacsenscript %{name} %{SOURCE3} スクリプトA,B はそれぞれ /usr/lib/emacsen-common/packages/install/ , /usr/lib/emacsen-common/packages/remove/ に、 %{name} という名前でインストールされます。 これによって、スクリプトA,B は、Emacs の FLAVOR がインストール、アンインストールされた時に実行されるようになります。 %files の部分でそれぞれのスクリプトを記述しておきます。 %{_libdir}/emacsen-common/packages/install/%{name} %{_libdir}/emacsen-common/packages/remove/%{name} %postタグの部分は次のように記述しておきます。 if [ "$1" = 数字 ]; then ; fi は、インストール時、アップグレード時、アンインストール時、それぞれで違う動作をさせるためのものです。を参照してください。 %post # # bytecompile and install # if [ "$1" = 2 ]; then %_emacsenPackageRemove %{name} fi %_addemacsenlist %{name} %_emacsenPackageInstall %{name} %preun if [ "$1" = 0 ]; then %_emacsenPackageRemove %{name} %_removeemacsenlist %{name} fi %_emacsenPackageInstall と %_emacsenPackageRemove は スクリプトA,B を実行するためのマクロです。 %_addemacsenlist と %_removeemacsenlist は、インストール済み Emacs Lisp パッケージのリストにパッケージを登録する、削除するというマクロです。 %_installemacsenscript, %_removeemacsenscript, %_emacsenPackageRemove, %_addemacsenlist, %_removeemacsenlist の行の次の行は、空行にしておかないとエラーとなるようです。 alternatives については update-alternatives による標準コマンドの切り替え にまとめられています。 alternatives に登録する場合には %post と %preun で次のようにします。 %post if [ "$1" = "1" ]; then %{_syssbindir}/update-alternatives --install リンク名 総称名 選択候補 優先度 fi %preun if [ "$1" = "0" ]; then %{_syssbindir}/update-alternatives --remove 総称名 選択候補 fi Provides と Requires を指定します。 Provides: 総称名 リンク名 Requires: update-alternatives Requires(post,preun): %{_syssbindir}/update-alternatives とします。 Provides の リンク名 については、無くても問題はありませんが、%files には書かれないファイルなので、Provides に書いておいたほうがよいと思います。 %post での登録と %preun での削除は、インストール時とアンインストール時だけに必要で、アップグレード時に実行してしまうと問題があるので、"$1" が 1 の場合(インストール時)と 0 の場合(アンインストール時)だけ処理するように if 文 にしておきます。 %post での処理を、パッケージのアップグレード時にも行ってしまうと、パッケージのインストール後にユーザが優先度を変更していた場合、それを無視してパッケージ側で優先度を勝手に変更してしまうことになります。 新規パッケージではなく、既存のパッケージの %post,%preun に update-alternatives の処理を追加する場合には、次のようにするとよいかもしれません。 %post if [ "$1" = "1" ]; then if [ "`%{_sysbindir/update-alternatives --list '総称名' | grep -c 'リンク名'`" = "0" ]; then %{_syssbindir}/update-alternatives --install リンク名 総称名 選択候補 優先度 fi fi %preun if [ "$1" = "0" ]; then %{_syssbindir}/update-alternatives --remove 総称名 選択候補 fi %triggerin と %triggerpreun と %preun を用いることで、他のパッケージが持っているファイルを alternatives で登録するようなパッケージを作ることもできます。 Provides: 総称名 リンク名 Requires: update-alternatives Requires(preun,triggerin,triggerpreun): %{_syssbindir}/update-alternatives %preun if [ "$1" = "0" ]; then %{_syssbindir}/update-alternatives --remove-all 総称名 fi %triggerin -- 対象となるパッケージ if [ "$1" = "1" ]; then echo triggerin scriptlet by %{name} start %{_syssbindir}/update-alternatives --install リンク名 総称名 選択候補 優先度 echo triggerin scriptlet by %{name} end fi %triggerpreun -- 対象となるパッケージ if [ "$1" = "0" ]; then echo triggerpreun scriptlet by %{name} start %{_syssbindir}/update-alternatives --remove 総称名 選択候補 echo triggerin scriptlet by %{name} end fi GConf2を設定の保存に利用しているアプリケーションの場合、通常、make installの途中でデフォルトの設定値が記述されたファイルをGConf2に登録しようとします。 しかし、このタイミングでGConf2への登録を行うとRPMパッケージ化の際にエラーを吐きますし、RPMパッケージをインストールしてもGConf2には何も登録されません。 この様なアプリケーションをパッケージ化する場合は、以下のようにSPECファイルを記述してGConf2への登録のタイミングを制御する必要があります。 %installセクションのmake installの前後を以下のように記述します。 export GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL=1 make install unset GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL これでmake install時にGConf2への登録が省略されます。 %postセクションに以下の記述を追加します。 export GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source` gconftool-2 --makefile-install-rule %{_sysconfdir}/gconf/schemas/package.schemas > /dev/null packageの部分は、適切な名前(ワイルドカード使用可)に置き換えてください。 %preunセクションに以下の記述を追加します。 if [ $1 = 0 ]; then export GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source` gconftool-2 --makefile-uninstall-rule %{_sysconfdir}/gconf/schemas/package.schemas > /dev/null fi これは、削除される前の .schemas ファイルを利用しますので%postunセクションでは駄目です。 Vine Linuxでは従来、staticライブラリ(*.a)を-develサブパッケージに収録していました。しかし、以下の理由から今後は原則としてstaticライブラリをパッケージに収録しないこととします。 あるライブラリにバグ、セキュリティホールなどが発見された場合にそれをリンクしているパッケージを追跡することが難しい staticリンクした場合、ライブラリの問題でアプリケーション全体の再ビルドが必要となる ただし、明確な理由によりstaticライブラリを必要とする場合は、メインパッケージや -devel サブパッケージに収録するのではなく、-static サブパッケージを作成して収録してください。 従来、一部のパッケージで Libtool で使われる .la ファイル (ライブラリアーカイブ、擬似ライブラリ)がパッケージに収録されていました。しかし、以下の理由から今後は原則としてパッケージには収録しないこととします。 Linux などの場合では .la ファイルを使わずとも .so に情報が内包されているため、.la ファイルは必要ではない 間違った情報がはいっていることもあり、それが原因で問題がおこる場合がある .la があったりなかったりという状態が混在すると、ライブラリを見つけられない場合が発生する 間違えてもそれ(%postではったリンクなど)を%preunや%postunで削除してはいけない シンボリック・リンクを含む全てのファイルを%installまででインストールして、 %filesに加えるべきである。 これは特に重要です。よく、%post で、シンボリック・リンクをはって、 %preun でそのリンクを削除するようなSPECファイルがあります。 これを行うと、アップデート時に問題が生じることがあります。以前、 libcのパッケージでこういう記述が入ってるものがあって、 深刻な問題が生じたこともありました。 その理由は、rpm -U <new-rpm> としたときに、 rpm -e <old-rpm> rpm -i <new-rpm> ではなく、 rpm -i <new-rpm> rpm -e <old-rpm> とはたらくためです。 つまり、%post で、シンボリック・リンクをはって、 %preun でそれを削除するような rpm のバージョンアップをしようと、 rpm -U （アップデート）を実行すると 新しいパッケージのインストールが行なわれ、 %postでシンボリック・リンクがつくられる。 古いパッケージのアンインストールが行なわれる。 このとき、%preunでさっき新しいパッケージが作ったシンボリック・ リンクが削除される。 この仕様は、libcとかのアップグレードの途中でlibcとかがなくなってトラブルが生じるのを避けようとしたためのものと思われます。 実はこの問題は解決法があります。 %pre, %post, %preun, %postunのスクリプト実行時には、スクリプトに対して以下の引数が与えられます。 rpm -iでインストールを行うとき %pre, %postに対して$1=1 rpm -Uでアップデートを行うとき 新しいrpmのインストール時に、 %pre, %postに対して$1=2 古いrpmをアンインストール時に、 %preun, %postunに対して$1=1 rpm -eでアンインストールを行うとき %preun, %postunに対して$1=0 すなわち、はじめてインストールするときには、引数として1がわたされ、 rpm -eでアンインストールするときには0がわたされるわけです。 これを利用すると、 %post if [ $1 = 1]; then echo ``First installation!'' fi %preun if [ $1 = 0]; then echo ``Good bye!'' fi とかできるわけです。 （それでも%postなどでシンボリック・リンクをはったりすると、 出どころ不明のファイルが増えることになります。その他トラブルをさけるため、 できるだけファイルは%filesに加えるようにし、 %postなどに書くスクリプトはできるだけ少なくしましょう) Epoch については説明しませんが、 パッケージのバージョン管理に混乱を引き起こす場合があるので、 絶対に必要という場合以外は利用しないでください。 なお、Serial は rpm 4.4 で obsolete となっています。 サブパッケージの作り方を覚えると、やたら沢山のサブパッケージをつくる人がいるが、 アップグレード時のメンテ(rpm -UやSPECの書き直し)が面倒になるばかりか、 どれがなんだか分からなくなったりする。分割は必要最小限に。 %configを多くすると、%filesが非常にわかりづらくなることがあり、 version up等の時にこの部分のメンテに労力がかかるようになりよくない。 デフォルトのままで出来るだけ多くの人が利用できるようなconfigファイルを用意し、 ユーザの%configの設定は必要最小限ですむように心掛けると、 多くの人が利用しやすいものができ、多くの場合に%fileの記述もすっきりする。 configファイルの設定やMakefileなどを変えたりするために頑張ってpatchをいろいろつくるよりも、 別にファイルを用意してSourceに加えておき、%installあたりで %{__cp} ${RPM_SOURCE_DIR}/hoge.conf . とかしてしまったほうが、すっきりすることが多い。srpmをばらしても、 そのファイルがすぐ出てきてわかりやすく、 アップデートのためにSPEC修正するときも楽だったりする。 SPECファイルはソースのアップデートに対応して修正をしたり、 第三者が見て必要に応じて書き直したりすることがある。 凝っていろいろな設定をしたりする複雑なものを書くより、 ポータビリティを重視して簡潔に書いた方が後のメンテのためには吉。また、 違った環境でbuildができなくなるようなことが無いよう、 SPECファイル中のスクリプトで、特殊なコマンドを呼ぶようなことは避け、 一般的なコマンド使用にとどめるべき。 Group説明例 Applications/Accessories ちょっとした小物や単機能のシンプルなアプリケーション 電卓、辞書 Applications/Administration システムやデスクトップの設定、管理の為のアプリケーション(動作に root 権限が必要) synaptic、gnome-system-tools Applications/Archiving ファイルの圧縮や解凍、書庫(アーカイブ)の作成に使用するアプリケーション bzip2, cpio, file-roller Applications/Development アプリケーションの開発に使用するアプリケーション xxgdb、IDE Applications/Documentation ドキュメントのみのパッケージ Vine-manual、JF Applications/Editors テキストエディタ GEdit、Emacs、Vi Applications/Editors/Emacs Emacs 及び Emacs 用のアプリケーション Applications/Edutainment 教育あるいは科学に関連したアプリケーション gnuplot、dia Applications/Games ゲーム Applications/Graphics 画像を扱うアプリケーション GIMP、Inkscape Applications/Internet インターネットを利用するアプリケーション firefox、Sylpheed、gFTP Applications/Multimedia 動画や音楽を扱うアプリケーション Totem、BMP 、XMMS Applications/Other Applications の他のどの Group にも割り当てられないもの Applications/Productivity ワープロや表計算、PIM等のアプリケーション abiword、Gnumeric Applications/Publishing 印刷やフォントに関連したアプリケーション ghostscript, tetex Applications/Services ウェブサーバーやメールサーバー及び各種デーモン(Daemon) Apache、Postfix Applications/System システムを設定したり監視したりするアプリケーション(ユーザー権限で動作可能) gnome-system-monitor、mtools Applications/Text テキストの処理に使用するアプリケーション less, nkf, namazu Development/Libraries 開発に必要なヘッダファイル等を含むパッケージ *-devel Development/Languages 開発に使用する各種言語用のパッケージ perl、php、ruby Development/Tools 開発に必要な各種 Tool を含むパッケージ automake、gettext System Environment/Base システムの動作に必要な最小構成のパッケージ(インストーラでいうところの最小構成に該当) System Environment/Daemons システムの動作で必要なサービス及びデーモン dbus、hal System Enviroment/Kernel カーネル System Environment/Libraries システムの動作に必要な各種ライブラリ gtk2、libpng System Environment/Shells 各種シェル User Interface/Desktops デスクトップ環境やウィンドウマネージャのアプリケーション KDE、Xfce 、Fluxbox User Interface/X XOrgと、それに付属するパッケージApplications/Accessories Vine Linux で使用できるGroup一覧は、/usr/share/doc/rpm-*/GROUPS_for_vine.txt に記述されています。 それぞれの Group の簡単な説明は、/usr/share/doc/rpm-*/GROUPS-DESC_for_vine.txt に記述されています。 パッケージ作成に必要なディレクトリを変更したいときには、~/.rpmmacrosの設定を変更します。 パッケージ作成に必要なディレクトリを全て/home/user/VinePlus以下に格納する場合は、以下のように変更します。 %_topdir /home/user/VinePlus また、以下のマクロを設定することで個別に設定することもできます。 マクロ名 使用目的 既定値 %_builddir ソースの展開・ビルド用 %_topdir/BUILD %_rpmdir バイナリパッケージ格納用 %_topdir/RPMS %_srcrpmdir ソースパッケージ格納用 %_topdir/SRPMS %_specdir SPECファイル格納用 %_topdir/SPECS %_sourcedir アプリケーションのソース・パッチ格納用 %_topdir/SOURCES ここで説明したマクロを設定した場合は、設定に合わせて書き込み可能なディレクトリを作成する必要があります。 特に%_rpmdirを設定したとき(%_topdirの変更による位置の変化も含む)には、設定したディレクトリの中に i386・noarch などのarchitecture 毎のディクレトリも忘れずに作成してください。 Prefix このタグを使うと、 rpmパッケージをインストールする時にインストールディレクトリをコントロールできます。 例えば、 Prefix: /usr としていて、ファイル定義部で %files /usr/bin/fuga と定義してたとしましょう。このパッケージをインストールする時に、 --prefix /usr/local とオプション指定すると、 fugaは/usr/local/bin/fuga.binにインストールされます。 BuildArch 書いたSPECファイルを使って生成されるrpmパッケージのアーキテクチャを指定できます。 例えば、elファイルとかシェルスクリプトとかばかりを含むrpmパッケージを作るときには、 i386やalphaなどのアーキテクチャに依存しないnoarchであることを、 BuildArch: noarch というふうに明示します。 このような指定をしておくとnoarch.rpmという拡張子のつくrpmパッケージが作成できて、 いろいろなアーキテクチャ上で共用できます。 ExclusiveArch SPECファイルや src.rpmパッケージから、パッケージを生成 できる アーキテクチャーを指定します。 たとえば、ExclusiveArch: i386 とすると、i386 以外の ppc,i486,i586,i686,x86_64 といったアーキテクチャーではバイナリパッケージを生成できなくなります。 ExcludeArch SPECファイルや src.rpmパッケージから、パッケージを生成 できない アーキテクチャーを指定します。 たとえば、ExcludeArch: ppc とすると、ppc ではバイナリパッケージを生成できなくなります。ppc 以外の i386,i486,i586,i686,x86_64 といったアーキテクチャーではバイナリパッケージを生成できます。 2009/7/4 「環境設定」、「基本的な流れ」、「より高度なパッケージ作成のための情報」の３部構成に変更 「ライブラリのパッケージングポリシー」を追加 2009/6/26 「rpm関連ファイルの説明」を「用語の解説」に修正 「rpmパッケージをつくるための準備」を「パッケージ作成毎の準備」に変更 2009/6/25 「はじめに」を「文書の概要」と「さらに深く知りたい方へ」に分割 「環境設定」を「rpmパッケージをつくるための準備」から分割 「更新記録」を付録に変更 2007/10/3 Appendix B で desktop file に関して修正 2007/9/10 Appendix B で desktop-file-install を使うよう修正 2007/7/21 Appendix B に desktop-file-validate について追記 2007/6/26 Copyright と Serial について追記 2007/6/25 %prep での %{SOURCE数字} の利用例を記載 %post での install-info の例で、install時にのみ処理を行うように if文 を追加 %files と Requires の探し方のヒントを記載 ExclusiveArch と ExcludeArch の説明を記載 Appendix B にalternatives を利用するパッケージについて追加 2007/5/23 Requires( ),BuildRequires( ) の説明を追加 Prereq の代わりに Requires(pre,post) 等の使用を推奨 %verifyscript について記載 %verify について記載 パッケージ作成後に確認することを記載 リンクの修正 2006/12/8 Epoch の使用について記載 install-info --delete の記述を修正 Group 一覧、説明 の typo を修正 2006/11/17 Group 一覧、説明を rpm-4.4.2-0vl16 にあわせて修正 2006/11/8 License の説明を修正 %check の説明を追記 rpmbuild -bi で %check も実行されることを記述 Vine Linux 4.x での Group 一覧、説明を修正 Appendix B にGNOMEのメニューについて追加 2006/11/3 Vine Linux 4.x での Group 一覧、説明を追加 BuildRequires と BuildConflictsの説明を追加 Requires と Prereq、BuildRequires と BuildPrereq の説明を修正、それぞれの違いを追記 %config に noreplace,missingok の説明を追加 マクロの説明を追加 spec の例を修正、マクロを使用した spec の例を追加 %check の説明を追加 %post,%postun に info ファイルの例を追加 タグの -p の説明を追加 Appendix B パッケージ固有の作法等についてを作成 2006/10/26 全体を見直し 2004/9/19 rpmbuildを推奨する様、追加。 2004/6/30 tex形式から、DocBook SGML形式に変更。 2000/10/30 細かい修正をすこし rpm-3.0.5 以降で binary が strip されることと、man/info がgzされることを記述 Prereq の説明追加 rpm -bp の説明追加 2000/3/7 minor なタイポや記述の修正 %setup の記述修正(-a,-b)および追加(-q) .rpmmacros の説明に .rpmrc の場合も併記 1999/9/3 .rpmmacros の記述追加(rpm-3.0.x 対応) BuildPrereq に関する記述を追加 1999/2/16 Summary(ja), %description -l ja, %changelog に関する記述を追加 その他細かい修正 rpmパッケージの作り方についてさらに知りたい人は、 RPM-BUILD-HOWTO (古高さん、石岡さん著、JFにあります)や Maximum-RPM(英語です。)を読みましょう。 どちらも、書かれてからだいぶ時間が経っていますが、参考になると思います。 RPM-BUILD-HOWTO は JF というパッケージがインストールされていれば、 /usr/share/doc/JF/archive/RPM-BUILD-HOWTO.txt.gz にあります。 また、rpm付属のドキュメントが /usr/share/doc/rpm-version/ 以下にあります。(英語です。) 細かなことについて知りたい場合は、apt-get source rpm , rpm -bp rpm.spec などとして、rpm 自体のソースを読むのもよいでしょう。 Vine Linux では パッケージングに関する指針 というドキュメントもあります。Vine Seed や Vine Plus のパッケージを作成する場合にはこの指針に従ってください。