release は「nm」とする。 n は 0 以上の整数、m はMomongaの m (小文字)の意。 これにより、全ての rpm は (name)-(ver)-nm となる。 細かい修正があった場合は n を増やす。nmn とはしない。
基本的に 1m を始点とし、修正ごとの増分は 1 とする。 なお、Release タグと changelog セクションの数字が一致していないことが 結構あるようなので、 (間違っているのが changelog の方であればそれほど問題ではないが) commit ごとに注意すること。
現在 release が k を含むものは、commit の機会に m に変更する。 ただし、単に release の k を m に変更するだけの修正は、無用な再ビルドを強要 してしまうので、Momonga Linux の最初のリリースまではこれを避ける。できるだけ、 何かのついでに修正すること。また、k を m に変更する際、version が上がらない のであれば、1m とせずに nk の n に 1 を加えるようにすること。1 にしてしまうと、 rpmでインストールする際に release が小さいほうが古いバージョンであると 判断されてしまうからである。
alpha, pre2, rc1 等は 0.n.nm を、 CVS tree から抜き出した場合は 0.YYYYMMDD.nm を特例として認める。 [1]
alpha 版および pre 版等における例外的な rel の付け方
Version: 3.0 Release: 0.2.1m
0 の次の数が pre の version、次が rebuild 回数となる。
0 . 自然数 . 自然数 mであり、複数の自然数が [ . ] で区切られたものとみなされる。 よって、桁が増えてもそのまま 0.2.9m, 0.2.10m, 0.2.11m と続けていって構わない。
Release: 0.20001201.1m
0. に続けて 日付、rebuild 回数となる。 つまり pre 等と同じく
0 . 自然数 . 自然数 mであるから、pre20001201 と結局は同じことである。
又、version に pre を廃止した経緯は、
2.0pre2 > 2.0になってしまう為の対策である。
Provides: foobar = 3.1-2mというように、Provides タグでヴァージョンやリリース番号まで指定できる。 古いパケジとの互換性などに使えるかもしれない。
メインとなる Source は NoSource で指定する。 ただし、新しい tar ball が置かれると、古い物が消されてしまうソースなどは、例外として NoSource にしない。 Source、Patch のどちらも、http および ftp 配布されているものは URI 表記すること。 それにより、巨大な tar ball が必要なパッケージを commit した時も、 tar ball を add しなくても 他の人に取って来てもらう or add してもらう事ができるようになるという利点がある。
なお、数 KBytes 以下のような小さなものまで NoSource で指定する必要はない。 全ての tar ball を収集する手間が増えるだけだからである。
ビルドツールの動作に支障をきたすので、いまのところ、 SourceやPatchタグを%ifで囲んではいけない。
アプリケーションを公開しているプライマリ web page、 あるいはプライマリ ftp の URI を必ずつける。 ないのであれば、便宜的に「http://www.momonga-linux.org//」とする。 最新版を追おうとしたときに、最初に import した人しか 場所がわからないというのは困るからである。 なお、URL タグではホスト名やディレクトリ名の末尾の「/」は必ずつけ、不要な「index.html」などはつけないこと。 これは、URL タグを整理してMomonga Antennaで捕捉する際に、事実上同じホストを指示している複数のパッケージについて複数回更新時刻をチェックすることのないよう、表記を統一することが望ましいからである。
full path はなるべく使わない。 パッケージ名を用いること。
Requires、PreReq、Conflicts、Obsoletesは、 特定の(サブ)パッケージに関する属性なので、 (それぞれのサブ)パッケージの%descriptionの直前に書くのが好ましい。 一方、BuildRequires、BuildPreReq、BuildConflictsは、 specファイルに関する属性なので、 Source等の直後に書くのが好ましい。
Group は
Amusements/Games Amusements/Graphics Applications/Archiving Applications/Communications Applications/Databases Applications/Editors Applications/Emulators Applications/Engineering Applications/File Applications/Internet Applications/Multimedia Applications/Productivity Applications/Publishing Applications/System Applications/Text Development/Debuggers Development/Languages Development/Libraries Development/System Development/Tools Documentation System Environment/Base System Environment/Daemons System Environment/Kernel System Environment/Libraries System Environment/Shells User Interface/Desktops User Interface/X User Interface/X Hardware Supportのどれかとする。
これ以外の Group を使っているパッケージは修正する。 これは install する際の package 選択時や、 rpm2html などを使った場合の結果が まとまりないものになるのを防ぐためである。
これは %_prefix の定義ではないので注意。 [2] そのパケジが再配置可能な場合 [3] にのみ、そのパスのうちの 置換できる部分を指定するタグである。例えば、標準では /usr/bin や /usr/lib にインストールされるのを /usr/local/bin と /usr/local/lib 等にしても大丈夫な (再コンパイルの必要のない) パケジであれば、 Prefix: /usr とすることができる。この場合ユーザはインストール時に rpm --relocate /usr=/usr/ocal とする選択肢を得ることになる。
しかし、試してみたところ、 --relocate を付けて -U したときに既存のファイルが消されなかったり、 その後に -U するときにも毎回 --relocate する必要があるなど、 非常に使いにくいようだ。
Copyright タグはなるべく用いない。なぜなら作られたパッケージの情報を引 き出すと、「License:」のように表示されてしまい、本来の意味がなくなってしま うからである。 特に記したいときは 「#」でコメントにして表記すること.
例:
# Copyright: UCL License: BSD
現在策定中であるが、License タグも利用可能なものを限定することになる。 日誌に出たあと Momonga-members:00056 以下の スレッドになっている。基本となるのは www.gnu.org/licenses であるので、現状ではここをよく見ておくこと。
%setup では -q を付けて、source の展開を表示しないようにする。 %build 中の tar 展開なども同様に v は付けない。
これは remote での rebuild を考慮してのことである。
3.21.「%setup のオプション」も参照されたい。
-b .hoge として suffix をつけるようにすること。
例:
%patch0 -p1 -b .typo
%patch の -p と -E は 本来の patch にそのまま渡すオプションだが、 -E を付けておくと、パッチで空になるファイルを消してくれるので、 パッチを当てつつファイルを消去しなければならないときに rm を別途使う必要がなくなる。 ただ、パッチで新規作成したファイルに対して foo.c.typo というような permission 0000 の ファイルができてしまうのはどうしようもないようだ。 自動削除されず邪魔になるような場合には chmod すること。
なお、%patch は gzip 等で圧縮されたパッチも 扱ってくれるし、NoPatch タグというものもあるので、Patch タグに .gz なファイルの URI を書いても普通のパッチと同じように扱える。
インストールされるファイルのパーミッションに注意すること。とくに、CVS から チェックアウトしたファイルをそのままコピーするような場合、import 時の パーミッションが保持されているとは限らないので、必ず明示的にパーミッションを 指定する。cp コマンドと chmod コマンドを併用してもよいが、install コマンドの -m perm オプションを使うのが便利である。
変更があった場合、変更点を明記する。 ささいな変更でも Release を上げる場合など、必ず変更点を明記すること。 また、version と release も合わせて明記すること。 特に、version と release の明記は、変更時点を知る手がかりになるので 必ず書くこと。
また、他の Distribution から RPM file を持ってきた場合は、 ここに取得先や元のパッケージの %changelog を記載すること。 記述内容は、spec file を参考にした、hogehoge という patch を利用した、 などのように詳細に書くこと。
例:
%ChangeLog * Sat Jun 24 2000 AYUHANA Tomonori <l@kondara.org> - (0.9.8-1k) - %%build section - RawHide (0.9.8-1) - hogehoge-buroro.patch - RawHide (0.9.8-1) - hogehoge-guhaguha.patch - Mandrake (0.9.8-1mdk2) - hogehoge-mumumu.patch - Kondara-devel.ja:12345
%changelogセクションは確実に長くなっていくので、 specファイルの最後に書くのが好ましい。
[1] rpm は、英数字以外の文字を区切り (時刻のコロンの様なもの) として扱い、区切られた各英数字列を比較する。比較の際は、まず 文字数を比較して、どちらかが長い場合は長い方が大きいと判断する。 このとき、先頭の '0' の列は無視している。また、文字数が 同一の場合は strcmp(3) を用いて大小を比較する。
であるから、0.n.nm というのは 0.n.n という小数に m が付いたものではない。 rpm 的には 0.1 < 0.010 なのである。 tools/ で make して得られる rpmvercmp で、 rpm がどういう判定をするかがわかるので、きちんと rpm 的に rel が「単純増加」していくように注意すること。
[2] %prefix は定義されるかも
[3] 全体が Prefix 以下に収まっていないといけないらしい