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 Items:
Items marked as SHOULD are things that the package (or reviewer) SHOULD do, but is not required to do.

• SHOULD: If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it.
  
• SHOULD: The description and summary sections in the package spec file should contain translations for supported Non-English languages, if available.
  
• SHOULD: The reviewer should test that the package builds in mock.
  
• SHOULD: The package should compile and build into binary rpms on all supported architectures.
  
• SHOULD: The reviewer should test that the package functions as described. A package should not segfault instead of running, for example.
  
• SHOULD: If scriptlets are used, those scriptlets must be sane. This is vague, and left up to the reviewers judgement to determine sanity.
  
• SHOULD: Usually, subpackages other than devel should require the base package using a fully versioned dependency.
  
• SHOULD: The placement of pkgconfig(.pc) files depends on their usecase, and this is usually for development purposes, so should be placed in a -devel pkg. A reasonable exception is that the main pkg itself is a devel tool not installed in a user runtime, e.g. gcc or gdb.
  
• SHOULD: If the package has file dependencies outside of /etc, /bin, /sbin, /usr/bin, or /usr/sbin consider requiring the package which provides the file instead of the file itself.
  
• SHOULD: your package should contain man pages for binaries/scripts. If it doesn't, work with upstream to add them where they make sense.