openSUSE:Factory レビュー

移動先: 案内, 検索
Factory での開発作業


openSUSE レビューチームによるレビュー

openSUSE プロジェクトでは、主にパッケージが Portal:パッケージング に記述されているルールに従い、 openSUSE レビューチーム が作成した概要ガイドラインに従っていることを望んでいます。

一般的なレビュー

まずは適用すべきいくつかのプロセス面の条件があります:

  • パッケージがサポート対象のアーキテクチャ (現時点では x86, x86_64) すべてで構築されているかどうか？こちらは自動的にチェックすることができます。
  • パッケージの送信元が、対応する devel プロジェクトからのものであるかどうか？こちらも自動的にチェックすることができます。

.changes ファイルに対するレビュー

  • それぞれの送信に対して、対応する .changes ファイルの項目が存在していなければなりません。
  • 更新を目的とした送信の場合、 .changes ファイルには 1 つ以上のバグ報告、もしくは fate 項目が記されていなければなりません。
  • 新しいバージョンの公開を目的とした送信の場合、新しいバージョンで追加もしくは変更された内容を正しく記述していなければなりません。
  • .changes ファイルは時系列に並んでいなければなりません。
  • .changes ファイルの古い項目に対して変更を加える際は、バグの番号や記述ミスを修正する目的に限るべきです。一般的に、古い項目を削除したり本質的な部分を変更したりすべきではありません。
  • .changes ファイルのヘッダ書式は、厳密に守られていなければなりません。これにはたとえば、ユーザや日時の書式、および '----' の区切り文字列などがあります。
  • .changes ファイルに新しい項目を作成する際、その記述方式は以前の項目から大きく逸脱すべきではありません。
  • パッケージャがソースコードに対するパッチを追加した場合、一般に .changes 内でそのパッチに対する参照と説明を記述する必要があります。また、パッチを削除した場合も、 .changes 内で説明する必要があります (たとえばパッチがアップストリーム (提供元) 側に取り込まれたなど) 。
A Good Example
XXX

spec ファイルのレビュー

  • 一般的にはパッケージをすべてのアーキテクチャに対して構築すべきですが、特定のアーキテクチャ以外では意味のないパッケージになってしまうなど、何らかの理由で ExclusiveArch タグを使用している場合は、 spec ファイル内でその理由を説明すべきです。
  • openSUSE:パッケージング修正ガイドライン など、パッケージングに対する標準的な作法すべてに準拠すべきです。たとえば:
    • ソースコードに対してパッチを適用する場合、警告を減らすか完全に解消すべきです。
  • ライセンスヘッダを正しく設定しなければなりません。
  • spec ファイルの冒頭に、基本的なタグ (例えば Name:, Version:, Release:, URL: など) が存在していなければなりません。
  • 利用しているバージョンが正当なものであり、以前のバージョンからアップグレード可能なものでなければなりません。
  • spec ファイル内で以前は用いられていたものの、現在となっては記述すべきでないものを含むべきではありません。たとえば:
    • AutoReqProv: on, # norootforbuild, # usedforbuild, %clean セクションなど
  • spec ファイル内に置き換えておくべきものが残っていてはなりません。たとえば、下記をそれぞれ置き換えます:
    • %{?jobs:-j%jobs} -> %{?_smp_mflags}
    • %fdupes %buildroot -> %fdupes %buildroot/%_prefix (これを置き換えておかないと、構築時にトップレベルディレクトリとパーティションとの間でハードリンクが作成されることになり、インストールが失敗することになってしまいます)
  • 適切に OBSOLETES を設定しなければなりません (詳しくは openSUSE:パッケージの依存関係 をお読みください) 。
  • 適切な パッケージ名 を指定しなければなりません。共有ライブラリの場合は、 共有ライブラリパッケージングポリシー にも命名ルールがあります (たとえばコロン (:) を含まないようにするなど) 。

受け入れか拒否か

上記までのルールのいずれかに違反した場合は、例外なくパッケージを拒否すべきなのでしょうか？多くの場合、そうではありません。一般的には、違反をどのように処理すべきか常識から判断するべきですし、場合によってはチーム内に異なる観点を持つ人がいて、異なる判断をする場合もあります。つまり、当面の間はこのルールを改良し続ける必要があることになります (もちろんこれには時間と手間がかかります) 。

違反が見つかった場合の対応方法:

  • 単純に拒否します (もちろんこれだけでは、送信者が残酷な仕打ちと感じるかもしれません)
  • 場合によっては、独自のブランチを作成し、違反を解決するよう修正して、再送信してもかまいません (もともとの送信は廃止するものとします)
  • 送信者にメッセージを送信して、違反を解消してもらうようにお願いします (対話は常に必要なものであり、パッケージ作成者にとっても適切な手段です) 。常に拒否した理由とこの項目を説明するものとし、どう直すべきかを指摘し、再送信するようにお願いしてください。

セキュリティレビュー

新しく setuid されたバイナリが追加されたような場合などは、まずセキュリティチームのレビューが必要です。この場合は、レビューのキュー内にセキュリティチーム (security-team) を追加して、レビューを依頼してください。キューへの追加は、現時点ではコマンドラインからのみ実施することができます。 

   osc review add -G security-team ID

一般的に、セキュリティのレビューは優先順位を最上位に置くものとし、指摘された問題があれば慎重に対応すべきです。

メンテナンスレビュー

メンテナンス更新を実施する場合は、通常のレビューに加えて patchinfo ファイルのレビューを追加で実施する必要があります:

  • patchinfo のデータとソース内の .changes ファイルとが正しく対応していることを確認します。
  • patchinfo 内に記述されているバグ番号や CVE 番号が、 .changes ファイル内に記載されているものと一致していることを確認します (ほぼ自動的に処理されます) 。
  • 修正は動作や ABI の点で、後方互換性がなければなりません。つまり、メンテナンス更新で設定やパッケージの動作が変わるようなことはあってはなりませんし、パッケージの機能などが他のパーツなどに分割されるようなことも、あってはなりません。また、共有ライブラリの変更の場合、製品全体に対して影響があるようなことも、あってはならないことに注意してください。
  • すべての送信には適切なパッケージ名 (foo.openSUSE_X.Y などの拡張パッケージ名) を付与しなければならないほか、 openSUSE_X.Y:Update に対するソースリンクも存在する必要があります。これはリリース番号を適切に動作させるために必要なものであるばかりか、新しいパッケージの場合でも必要です。
  • 少なくとも 1 つ以上の Bugzilla のバグ番号を記載する必要があります。 Bugzilla のエントリが存在することで、なぜ修正が必要になっているのかがより詳しく理解できるためです。

間違いなく拒否される例

間違いなく拒否されてしまうような例としては、たとえば下記のような場合があります:

  • そもそも構築が成功していない。
  • spec ファイルやソース、 .changes ファイルが無い。
  • .changes 内に新しい項目がない。
  • rpmlint が "エラー" を報告している。警告が大量に存在するような場合も、拒否の理由となります。
  • .changes 内の項目が酷く乱雑になっていたり、必要な情報が書かれていなかったりしている。
  • setuid ビットが設定されているなど、明らかなセキュリティ違反が見つかった場合。 rpmlint ではこれらを検出して報告しますが、手作業でも確認を実施して拒否することがあります。
  • ヘッダファイルなどが間違ったパッケージに収容されているなど、明らかなパッケージポリシー違反がある場合 (もちろんこれには多数の例外があります) 。
  • マクロの使用が不適切である。
  • 以前に修正された古い問題を再発させてしまうような場合。

ベストエフォート (最善努力)

openSUSE チームでは各レビューに対して最善の努力を尽くしますが、場合によっては間違いをしてしまうような場合もあります。特にセキュリティ面の問題など、致命的な問題を見逃す可能性もあることに注意してください。

なお、メンテナンス更新に対するレビューには、より厳しいルールを実施する必要があります。

また、パッケージを受け入れた後、パッケージを整理するためのバグ報告を後から作成する場合もあります。

削除 (delete) 要求のレビュー

削除要求に対しては、最小限の要件のみを確認します:

  • 削除に至った適切な理由が提示されていること、および公式の openSUSE メーリングリスト内で議論されていること (もちろんすべてがそうでなければならないというわけではありません) 。
    • アップストリーム (提供元) の開発が終了してしまった場合や、メンテナンス (セキュリティホールやバグの修正など) にかかる負荷が労力に見合わないものになってしまっているなど。
  • パッケージを改名するような場合 (つまり、異なる名前で同じパッケージに対する新しい送信が存在する場合):
    • 削除要求には改名後のほうの送信番号を含んでいるべきです。これにより、両方の送信を一括で処理します。

パッケージの種類別のガイドライン

共有 (shared) ライブラリと静的 (static) ライブラリ

Perl のパッケージ

Perl のパッケージは、自動化ツール _cpanspec_ で生成すべきです。これにより最大限の互換性を確保できるほか、レビューもほとんどの場合、そのままうまくいくようになります。このスクリプトについて、詳しくは *coolo* にお尋ねください。

http://en.opensuse.org/openSUSE:Packaging_Perl

Python のパッケージ

Ruby のパッケージ

Ruby のパッケージについては、自動化ツール _gem2rpm-opensuse_ を利用して生成すべきです。これにより最大限の互換性を確保できるほか、レビューもほとんどの場合、そのままうまくいくようになります。このスクリプトについて、詳しくは *darix* にお尋ねください。

「https://ja.opensuse.org/index.php?title=openSUSE:Factory_レビュー&oldid=6550」から取得