2. spec ファイルのタグ

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]

又、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で囲んではいけない。

Distribution は指定しないこと。

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

アプリケーションを公開しているプライマリ 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等の直後に書くのが好ましい。

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

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

BuildRoot は

BuildRoot: %{_tmppath}/%{name}-%{version}-root

と指定する。

これは %_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ファイルの最後に書くのが好ましい。

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

%defattr(-,root,root)

を付けること。

%clean
rm -rf %{buildroot}
    

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