2. spec ファイルのタグ

2.1. Version、Release

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 の付け方

例: 3.0pre2 の場合

Version: 3.0
Release: 0.2.1m

0 の次の数が pre の version、次が rebuild 回数となる。

0 . 自然数 . 自然数 m
であり、複数の自然数が [ . ] で区切られたものとみなされる。 よって、桁が増えてもそのまま 0.2.9m, 0.2.10m, 0.2.11m と続けていって構わない。

例: CVS 等 日付がはいる場合

Release: 0.20001201.1m

0. に続けて 日付、rebuild 回数となる。 つまり pre 等と同じく

0 . 自然数 . 自然数 m
であるから、pre20001201 と結局は同じことである。

又、version に pre を廃止した経緯は、

2.0pre2 > 2.0
になってしまう為の対策である。

2.2. Provides

Provides: foobar = 3.1-2m
というように、Provides タグでヴァージョンやリリース番号まで指定できる。 古いパケジとの互換性などに使えるかもしれない。

2.3. Source、Patch

メインとなる 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で囲んではいけない。

2.4. Distribution

Distribution は指定しないこと。

2.5. Packager、Vendor

Packager および Vendor は付けないこと。 %changelog に名前とメールアドレスを書く。

2.6. URL

アプリケーションを公開しているプライマリ web page、 あるいはプライマリ ftp の URI を必ずつける。 ないのであれば、便宜的に「http://www.momonga-linux.org//」とする。 最新版を追おうとしたときに、最初に import した人しか 場所がわからないというのは困るからである。 なお、URL タグではホスト名やディレクトリ名の末尾の「/」は必ずつけ、不要な「index.html」などはつけないこと。 これは、URL タグを整理してMomonga Antennaで捕捉する際に、事実上同じホストを指示している複数のパッケージについて複数回更新時刻をチェックすることのないよう、表記を統一することが望ましいからである。

2.7. Requires、PreReq、BuildRequires、BuildPreReq

full path はなるべく使わない。 パッケージ名を用いること。

Requires、PreReq、Conflicts、Obsoletesは、 特定の(サブ)パッケージに関する属性なので、 (それぞれのサブ)パッケージの%descriptionの直前に書くのが好ましい。 一方、BuildRequires、BuildPreReq、BuildConflictsは、 specファイルに関する属性なので、 Source等の直後に書くのが好ましい。

2.8. BuildConflicts

できれば使わない。 TO.Zoo なパケジなどでは適宜使用。

2.9. Group

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 などを使った場合の結果が まとまりないものになるのを防ぐためである。

2.10. BuildRoot

BuildRoot は

BuildRoot: %{_tmppath}/%{name}-%{version}-root
と指定する。

2.11. Prefix

これは %_prefix の定義ではないので注意。 [2] そのパケジが再配置可能な場合 [3] にのみ、そのパスのうちの 置換できる部分を指定するタグである。例えば、標準では /usr/bin や /usr/lib にインストールされるのを /usr/local/bin と /usr/local/lib 等にしても大丈夫な (再コンパイルの必要のない) パケジであれば、 Prefix: /usr とすることができる。この場合ユーザはインストール時に rpm --relocate /usr=/usr/ocal とする選択肢を得ることになる。

しかし、試してみたところ、 --relocate を付けて -U したときに既存のファイルが消されなかったり、 その後に -U するときにも毎回 --relocate する必要があるなど、 非常に使いにくいようだ。

2.12. License、Copyright

Copyright タグはなるべく用いない。なぜなら作られたパッケージの情報を引 き出すと、「License:」のように表示されてしまい、本来の意味がなくなってしま うからである。 特に記したいときは 「#」でコメントにして表記すること.

例:

# Copyright: UCL
License: BSD
    

現在策定中であるが、License タグも利用可能なものを限定することになる。 日誌に出たあと Momonga-members:00056 以下の スレッドになっている。基本となるのは www.gnu.org/licenses であるので、現状ではここをよく見ておくこと。

2.13. %setup、%build

%setup では -q を付けて、source の展開を表示しないようにする。 %build 中の tar 展開なども同様に v は付けない。

これは remote での rebuild を考慮してのことである。

3.21.「%setup のオプション」も参照されたい。

2.14. %patch

-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 を書いても普通のパッチと同じように扱える。

2.15. %install

インストールされるファイルのパーミッションに注意すること。とくに、CVS から チェックアウトしたファイルをそのままコピーするような場合、import 時の パーミッションが保持されているとは限らないので、必ず明示的にパーミッションを 指定する。cp コマンドと chmod コマンドを併用してもよいが、install コマンドの -m perm オプションを使うのが便利である。

2.16. %changelog

変更があった場合、変更点を明記する。 ささいな変更でも 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ファイルの最後に書くのが好ましい。

2.17. %defattr

%files には、特に断わりのない場合には必ず

%defattr(-,root,root)
を付けること。

2.18. %clean

%clean
rm -rf %{buildroot}
    

を追加し、掃除すること。



[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 以下に収まっていないといけないらしい