Packaging/ReviewGuidelines/ja

パッケージレビューガイドライン

これはパッケージレビューのためのガイドラインです。できるだけ包括的に分かり易いようこのレビューガイドラインを作成しようとはしていますが、完璧なチェックリストを作成することは不可能だということに注意してください。レビューアと貢献者(パッケージャ)は、何らかの内容が不明確で疑わしいときは必ずfedora-packaging メーリングリストへ質問して、最も良い判断を行うべきです。

Author: Tom 'spot' Callaway
Revision: 0.30
Initial Draft: Monday Jun 27, 2005
Last Revised: Thursday, Jul 8, 2010

パッケージレビュープロセス

貢献者とレビューアはパッケージレビュープロセスに従います。

レビュー時にチェックすること

レビューにはとってもとっても多くのチェック項目があります。このチェックリストは、新人レビューアが探す範囲のカテゴリを明確にして彼らを支援するために提供されていますが、この内容を満たせば完璧という意味ではありません。レビューアはパッケージのレビュー時に自分たちで優れた判断を行うべきです。チェックリストの各項目は2つのカテゴリ SHOULD と MUST に分類されます。

MUST 項目
MUST に該当する項目はパッケージャ(又はレビューア)が 行わなければならない ことです。あるパッケージが MUST 項目を満たしていない場合、それは blocker と見なされます。blocker のパッケージがレビューで承認されることはありません。そういった項目は承認プロセスの前に修正されなければなりません。

• MUST: 全てのパッケージに rpmlint を実行しなければなりません。そして、その出力をレビューで提示します。
  

• MUST: パッケージはパッケージネーミングガイドラインに従って名前を付けなければなりません。
  

• MUST: spec ファイルの名前はベースパッケージの %{name} と同じでなければなりません。特別な免除がない限り %{name}.spec のフォーマットになります。
  

• MUST: パッケージはパッケージングガイドラインに準拠しなければなりません。
  

• MUST: パッケージは Fedora が承認したライセンスでライセンスガイドラインに準拠しなければなりません。
  

• MUST: spec ファイルのライセンスフィールドは実際のライセンスと一致しなければなりません。
  

• MUST: ソースパッケージ(のみ)が独自のライセンスファイルを持っている場合、そのパッケージのライセンスのテキストファイルを %doc に追加しなければなりません。
  

• MUST: spec ファイルはアメリカ英語で書かなければなりません。
  

• MUST: パッケージの spec ファイルは読み易いものでなければなりません。
  

• MUST: パッケージのビルドに使用するソースは spec ファイルの URL で提供されているアップストリームのソースと同じでなければなりません。レビューアはこの確認作業に md5sum を使用すべきです。もし、このパッケージで指定したアップストリームの URL が存在しないなら、このパッケージをどう扱うかについてソース URL ガイドラインを参照してください。
  

• MUST: パッケージは少なくとも1つの主要なアーキテクチャでコンパイルしてビルドに成功しなければなりません。
  

• MUST: パッケージをあるアーキテクチャでビルドしようとしてコンパイルに成功しないなら、そういったアーキテクチャは spec ファイルで ExcludeArch に設定すべきです。ExcludeArch に設定された各アーキテクチャは bugzilla に登録されなければなりません。登録したバグ ID は対応する ExcludeArch 行の隣にコメントとして記載すべきです。
  

• MUST: パッケージングガイドラインの例外事項に記載されているパッケージを除いて、ビルドをするための全ての依存関係は BuildRequires に定義されなければなりません。例外として記載されている BuildRequires を定義するかどうかは任意です。良識的に考えてください。
  

• MUST: spec ファイルはロケールを適切に扱わなければなりません。これは %find_lang マクロを使用するこで行われます。%{_datadir}/locale/* を使用することは厳密に言えば禁止されています。
  

• MUST: 動的リンカのデフォルトパスに共有ライブラリ(ただのシンボリックリンクではない)を含む全てのバイナリ RPM パッケージ(又はサブパッケージ)は %post や %postun で ldconfig を実行しなければなりません。
  

• MUST: パッケージはシステムライブラリのコピーを含めてはいけません。
  

• MUST: パッケージを再配置可能であるように設計するなら、パッケージャはレビュー時にその要件、つまりその特別なパッケージの再配置を正当化する理由をはっきりと説明しなければなりません。この説明を行わずに /usr のパスを使用することは blocker と見なされます。
  

• MUST: パッケージは作成するディレクトリを全て所有しなければなりません。もしあなたのパッケージが使用するディレクトリを作成しないなら、そのディレクトリを作成するパッケージに依存すべきです。
  

• MUST: Fedora パッケージは spec ファイルの %files セクションにリストされているファイルを1回以上リストしてはいけません(有名な例外: 特殊な状況でのライセンステキスト)。
  

• MUST: ファイルのパーミッションは適切にセットされなければなりません。例えば、実行プログラムは実行権限をセットします。全ての %files セクションは %defattr(...) 行を含めなればなりません。
  

• MUST: パッケージは一貫性を持ってマクロを使用しなければなりません。
  

• MUST: パッケージはコード、又は許容されるコンテンツを含まなければなりません。
  

• MUST: 大きなドキュメントファイルは -doc サブパッケージに分割されなければなりません(大きいの定義はパッケージャの判断に一任されますが、サイズに対しての制限はありません。大きいはサイズか分量のどちらか一方でも構いません)。
  

• MUST: あるパッケージが %doc にドキュメントを含んでいるなら、アプリケーションの実行に影響を与えてはいけません。要約すると、ドキュメントが %doc にあるなら、そのプログラムはそこにドキュメントがなかったとしても正常に実行されなければなりません。
  

• MUST: ヘッダファイルは -devel パッケージに含めなければなりません。
  

• MUST: 静的ライブラリは -static パッケージに含めなければなりません。
  

• MUST: あるパッケージがバージョン指定のある共有ライブラリ(例 libfoo.so.1.1)を含むなら、.so(バージョン指定がない)のライブラリファイルを -devel パッケージに含めなければなりません。
  

• MUST: 大半のケースでは -devel パッケージは Requires: %{name} = %{version}-%{release} のようにフルバージョンの依存関係を使用してベースパッケージを要求しなければなりません。
  

• MUST: パッケージは libtool のアーカイブ .la ファイルを含めてはいけません。.la ファイルはビルド時に spec ファイルで削除されなければなりません。
  

• MUST: GUI アプリケーションを含むパッケージは %{name}.desktop ファイルを含めなければなりません。そして %{name}.desktop ファイルは %install セクションの desktop-file-install で適切にインストールされなければなりません。あなたの GUI アプリケーションが .desktop ファイルを必要ないと思うなら、その理由をコメントで spec ファイルに記載しなければなりません。
  

• MUST: パッケージは他のパッケージが既に所有しているファイルを所有してはいけません。基本原則として最初にインストールされるパッケージが、他のパッケージがそのファイルの存在に依存する可能性があるファイルを所有すべきです。例えば、これは filesystem 又は man パッケージによって所有されるファイルであっても所有権を共有するようなパッケージは Fedora にはないということです。もし他のパッケージが所有しているファイルを所有するための適切な理由があるなら、パッケージレビューのときに連絡してください。
  

• MUST: rpm パッケージの全てのファイル名は UTF-8 でエンコードされなければなりません。
  

---

SHOULD 項目:
SHOULD に該当する項目はパッケージャ(又はレビューア)が 行うべき ことですが、義務付けられているわけではありません。

• SHOULD: ソースパッケージがアップストリームに由来する独立したライセンスファイルを持っていないなら、パッケージャはアップストリームへライセンスファイルを含めるように尋ねるべきです。
  

• SHOULD: spec ファイルの要約やパッケージ説明のセクションは、可能なら非英語圏のために翻訳された内容を含めるべきです。
  

• SHOULD: レビューアは mock でパッケージをビルドするテストをすべきです。
  

• SHOULD: パッケージャは全てのサポートされたアーキテクチャでバイナリ RPMS をコンパイルしてビルドすべきです。
  

• SHOULD: レビューアは記載されているパッケージ機能をテストすべきです。例えば、実行するとセグメンテーションフォールトしてはいけません。
  

• SHOULD: スクリプトレットを使用するなら分かり易いものでなければなりません。曖昧な場合、レビューアに分かり易いものに決定することが一任されます。
  

• SHOULD: 通常 devel 以外のサブパッケージは完全にバージョン指定でベースパッケージに依存すべきです。
  

• SHOULD: pkgconfig(.pc) ファイルをどのパッケージに含めるかは、その使用方法に依存します。pkgconfig ファイルは、ほとんど開発の目的のために使用されるので、-devel パッケージに含められます。分かり易い例外としては、メインパッケージそのものがユーザ向けのランタイムをインストールしない開発向けのツールがあります。例えば、gcc や gdb になります。
  

• SHOULD: パッケージが /etc, /bin, /sbin, /usr/bin 又は /usr/sbin 以外でファイルの依存関係を持つなら、ファイルそのものではなく、そのファイルを提供するパッケージに依存関係があるものと見なしてください。
  

• SHOULD: パッケージの全てのバイナリ/スクリプトのために man ページを作成すべきです。もし man ページがないなら、アップストリームで man ページを追加するように働きかけてください。