The wikis are now using the new authentication system.
If you did not migrate your account yet, visit https://idp-portal-info.suse.com/

openSUSE:Factory でやるべきこととやるべきではないこと

移動先: 案内, 検索


メンテナがやるべきこと、そしてやるべきではないことについて、いくつかの一般的なヒントを示しています。


メンテナがやるべきこと

他の人がパッケージを利用していることを心に留めておくこと

これは最も重要なルールです。パッケージに対して実施した作業は、次に誰かが作業を行なうことを考慮して、できるだけわかりやすいものにしておく必要があります。

たとえば、わかりやすい説明を .changes ファイルと .spec ファイルに書いておくだけでなく、関連するリソース (修正であれば 修正タグ) などへのリンクも示しておくとよいでしょう。

それ以外にも、わかりにくい修正は避けるべきです。

送信要求に対して、速やかかつ友好的に処理すること

よいメンテナは、貢献者の意欲をよりよく刺激します。これを実現するには、送信要求に対してできる限り速やかに、かつ友好的に応答するのがよいでしょう。何も応答が無く何日も待たされてしまうのは、意欲を減退させてしまうことでしょう。また、要求を拒否する場合も、要求のどこに問題があるのかをきちんと説明し、無遠慮な回答は避けましょう。 Build Service の レビュー機能 をお使いになるとよいでしょう。

changes ファイルには各々の変更をきちんと記載すること

Factory に対して修正や更新を送信する場合は、必ずすべての変更点を .changes 内に記述しなければなりません。新しく .changes の項目を追加する場合は、 osc vc コマンドを利用すると、必要なひな形を自動で作成することができます。

.changes 内に変更点を記述する場合は、単に変更した内容だけを記述するのではなく、なぜ変更が必要だったのかを説明しておく必要があります。たとえば "Add pkgconfig(coolstuff) BuildRequires" ("BuildRequires に pkgconfig(coolstuff) を追加") だけでなく、 "Add pkgconfig($coolstuff) BuildRequires to enable $cool feature" ("$cool という機能に対応するため、 BuildRequires に pkgconfig(coolstuff) を追加") という形で記述し、わかりやすくしておくことが求められます。

なお、 バグ報告機能要求 から発生した修正の場合は、 "Fix bnc#12345" や "Close fate#12345" などのように記載して、バグや機能への参照を忘れずに記入しましょう。

%{optflags} を使用すること

%{optflags} (または $RPM_OPT_FLAGS) が C/C++ コンパイラの CFLAGS/CXXFLAGS に渡されていることを確認してください。 %configure を使用してもかまいませんが、ソフトウエア側の仕組みによっては make 実行前に export CFLAGS="%{optflags}" を実行しないと、最適化が行なわれない場合があります。修正に対しても同様です。

rpmlint の警告メッセージをよく読むこと

構築が完了すると、 rpmlint が構築済みのパッケージを調査して、一般的なパッケージングエラーを警告します。作成されたレポートは、 RPMLINT report: としてビルドログの末尾に出力されます。これらの警告に対応すると、一般的にはパッケージを改善することにつながるようになっています。

FHS に従うこと

パッケージ内のファイルは、適切な場所に配置してください。特に ファイルシステム階層標準 に示された項目には、できるだけ従うようにしてください。一般的には、この作業はアップストリーム (提供元) プロジェクトが行なうもので、 %make_install (または make install) することで適切なディレクトリに配置されます。

一貫性のあるパッケージングスタイルを貫くこと

.spec ファイルの記述では、様々な方法で同じ結果を得ることができますが、貢献者の負担を減らすため、特定のパッケージングスタイルを貫くとよいでしょう。

たとえば spec クリーナツール (openSUSE:Tools 内にあります) では、 .spec ファイルをよみやすく整形することができます。具体的には、 複数を同じ行に記入することのできる BuildRequires について、 1 行に 1 つずつ記述するように修正して差分がわかりやすくなるようにすることができます。

関連するドキュメンテーションをよく読むこと

パッケージを作成する際には、 パッケージングガイドライン をお読みください。

メンテナがやるべきではないこと

同梱ライブラリを含めてしまうこと

可能な限り、同梱されるライブラリではなく、システムが提供するライブラリを使用しましょう。システムが提供するライブラリを使用して問題が発生する場合は、アップストリーム (提供元) にバグを報告して、修正を作成しましょう。共有ライブラリはどのソフトウエアからも使用されるべきもので、独自のバージョンを使用すべきではありません。

まだ受け入れていない送信要求があるにもかかわらず、勝手に変更してしまうこと

パッケージを更新したり修正したりする場合は、まず送信要求が届いていないかどうかを確認しましょう。既に更新や修正の作業をしてくれている人がいるかもしれませんし、その人を無視して自分で更新や修正を行なってしまうと、その人の苦労を台無しにしてしまうことにもなります。

修正を自分だけのものにしてしまうこと

ソフトウエアに対して何らかの修正を行なった場合は、その修正を自分のリポジトリ内だけで完結させず、アップストリーム (提供元) のバグトラッカーなどに登録し、その旨を伝えるとよいでしょう。これにより、アップストリームが新しいバージョンを公開する際にその修正を取り込んでくれるかもしれませんので、 openSUSE 以外の利用者に対しても修正の効用を反映することができます。