Gentoo Linux デベロッパーポリシー

1. 一般的なガイドライン

これはいくつかの一般的なデベロッパーのガイドラインです：

• 変更点はいつもrepomanで確認してください。cvs commitの代わりにrepoman commit を使用してください。
• あるパッケージが現在のバージョンで壊れている場合、またはとても汚ないbuild/installプロセスを行なっている場合には、他のディストリビューションでどうしているかを見てください。
  • http://cvs.mandrakesoft.com/cgi-bin/cvsweb.cgi/SPECS/
  • http://www.debian.org/distrib/packages
• エンドユーザーは、完成してunmaskされたebuildパッケージを"普通に動作する"と考えます。インストールされたパッケージをいじることは、オプションであるべきです。したがって妥当なデフォルトのセッティングでインストールするべきです。
• オンラインドキュメントや多くのシニアデベロッパーによって記述・メンテナンスされているebuildを参照して参考にしてください。技術的な問題やポリシーについての質問は、シニアデベロッパーに自由に質問して構いません。
• commitは十分気をつけて行なってください。 commitが何千ものユーザーに悪影響を与える可能性があることを覚えておいてください。 もしcommitがそのツリーに破損を与えることになった場合、すぐに修正してください。

2. 特定のアプリケーションのガイドライン

Perl 

以下の条件の一つ以上を満たすときにのみ、新しいPerlモジュールをPortageに加えることになっています。：

• そのモジュールが依存関係を満たしている。
• そのモジュールがg-cpanで扱うことができない。
• そのモジュールが既存のebuildに機能を提供する。
• そのモジュールがツール、アプリケーション、その他の機能を提供する。(つまり、.PM以上のものを提供)

少なくともひとりのperl herdのメンバーがその追加を承認することを確認してください。

3. ebuild ポリシー

命名 ポリシー 

ebuild ファイル名は4つの部分から成り立っています。

pkg-ver{_suf{#}}{-r#}.ebuild

最初の pkg セクションはパッケージ名です。 それは英小文字、0-9の数字、ハイフン(-)しか含むべきではありません。 たとえば、util-linux、 sysklogd、 glibcです。 Portageツリーにはいくつかのこのルールに従っていないパッケージがあります。しかしあなたのパッケージはこれに従うべきです。

2つ目のセクションverはパッケージのバージョンです。通常はそのパッケージのメインのソースtarballと同じになります。一般的にバージョンは1.2や4.5.2のように2つか3つ(またはそれ以上)の数字がピリオドによって区切られています。また最後に一文字のアルファベットが持つことがあります。例：1.4b、2.6h。パッケージのバージョンはパッケージ名とハイフンで継がります。例：foo-1.0、bar-2.4.6。

3つ目のセクション{_suf{#}}はオプションで、以下のあらかじめ定義されたsuffixを持ちます。なお、このリストは古い→新しい順に並んでいます。

suffixの後には正の整数が続く場合があります。例：linux-2.4.0_pre10。同一のバージョン部分の場合には、suffixは以下のように並びます。(古い順です)_alpha < _beta < _pre < _rc < (suffixなし) < _p

後ろに数字が続く同一のsuffixの場合には、数字が大きい程最近のものになります。例：foo-1.0_alpha4はfoo-1.0_alpha3より新しいです。

4つ目のセクション({-r#})はGentoo Linux独自のリビジョンナンバーです。 このセクションはsuffixと同様にオプションです。 #部分は正数です。例：package-4.5.3-r3.

このリビジョンナンバーはオリジナルのソースtarballに依存せず、ユーザーに改良されたGentoo Linuxパッケージが存在することを知らせるために使用します。ebuildの初期リリースではリビジョンナンバーは付けません。例：package-4.5.3。これはPortage内部ではリビジョンナンバー0として扱われます。そして次のようにカウントアップします。 1.0 (初期バージョン)、1.0-r1、1.0-r2、…。

バージョンアップやリビジョンアップ 

パッケージのリビジョンナンバーは、ebuildにユーザーがアップグレードする必要のある修正を行なったときに、Gentoo Linuxデベロッパーによって増やされます。 よくある例としては、ebuildを修正したことによって、同じソースtarballを使用しているにもかかわらず、インストールされるファイルが以前と変わる場合です。 内部的な書式の変更などをebuildにした場合に、インストールされるファイルが変更ない場合には、リビジョンナンバーを増やす必要はありません。 同様に、一部のユーザーが影響を受けるコンパイルの問題でebuildを修正した場合には、リビジョンナンバーを増やす必要はありません。なぜなら、正常にインストールできている人が再度新しいリビジョンをインストールする価値がないからです。そして、その問題に直面した人はそのパッケージをインストールしていません(なぜならコンパイル失敗のため)。このような理由から新しいリビジョンで強制的にアップグレードする必要がないわけです。 また、少数のユーザーしか影響を受けない場合で、 そのパッケージが通常のコンパイル時間では終了しない場合などにも、 リビジョンアップは必須ではありません。 様々な状況で最良の判断をしてください。

新しいebuildはなんらかの理由により以前行なわれていた修正が欠落しないように、以前のバージョンのebuildを元にすべきです。ebuildの中の修正箇所には、何のために、なぜ必要かを、適当なコメントとして含めるべきです。もしその修正を詳しく知らないとき、またはその修正が必要か判断できない場合には、そのebuildをアップデートすべきではありません。

virtual機能 

Portageは"virtual"パッケージと呼ばれる概念を持っています。virtualパッケージを使用すると、特定のcategory/package名を他のものに結びつけることができます。

virtualパッケージを使い方の例を示します。foocronという新しいパッケージを作成したとしましょう。Gentoo Linuxではcronパッケージに依存する必要のあるパッケージは、virtual/cronパッケージに依存させています。こうすることでユーザーがいくつかのcronパッケージから好きなものを柔軟にインストールすることができます。作成したfoocron-1.0.ebuildをこのシステムに加えるためには、以下の行をebuildに加えてください。

PROVIDE="virtual/cron"

foocron-1.0がインストールされたとき、virtual/cronパッケージが登録されたことになります。これまでにcronパッケージをひとつもインストールしていなかった場合、これでvirtual/cronに依存している全パッケージがその依存関係を満たすことになります。 注意点がひとつあります。PROVIDEにはどんなタイプのパッケージでも指定することはできます。 つまりvirtual/で始まっている必要はないのです。 しかしながら、リネームされたパッケージを扱うためにPROVIDE機能を使用するのでなければ、virtual/カテゴリを使用するべきです。

Gentoo Linuxのvitual機能の実装にはもうひとつの特徴があります。 virtual/cronをPROVIDEするパッケージがインストールされていない場合、どのようなことが起こるのでしょうか？ Portageはどうやってvirtual/cron依存を満足させる"正しい"cronを選ぶのでしょうか？ Portageはこのようなときに、各virtualには何を割り当てるのかが書かれたvirtualsという名前のファイルを使用します。このファイルはprofileディレクトリ/etc/make.profileに保存されています。 virtualsファイルを見てください。次のようになっています。

virtual/lpr             net-print/cups
virtual/python          dev-lang/python
virtual/mta             net-mail/ssmtp

このファイルの1行目は、まだvirtual/lprが存在しない場合にvirtual/lprに依存しているパッケージをインストールすると、この依存関係を満足させるためにnet-print/cupsがインストールされることを示しています。 net-print/cupsはPROVIDE="virtual/lpr"の行を含んでいます。これにより、今後virtual/lprへの依存関係は満たされます。

以下の文はデベロッパー向けのガイドラインです。foocronパッケージを加えた場合、virtual/cronに依存するすべてのプログラムが動くことを保証しないといけません。 そして、virtual/cronに依存するfoobarosityというパッケージを加えた場合には、同様にfoobarosityがすべてのvirtual/cronをprovideするパッケージで十分に機能する必要があります。

新規にvirtualパッケージを作成する前に、内部のデベロッパーメーリングリストでそのvirtualについて議論してください。 開発者に新しいvirtualについての情報を流し続けることは、開発者が統一してそれを使用するために、不可欠なことです。

CVS ソースポリシー 

開発用のCVSツリーからebuildをbuildするには2つの方法があります。第一のそして伝統的な方法は、上流のCVSツリーからあなた自身がスナップショットtarballを作成し、私たちの公式distfileレポジトリにそれを置き、ebuildをそのスナップショットtarball用に記述する方法です。このタイプのCVS ebuildを以下では"スナップショットCVS ebuild"と呼びます。

CVSを利用してebuildを作成する他の方法として、"live"CVSを用いて作成するためにcvs.eclassを利用する方法があります。そのebuildは最新のCVSレポジトリから"fetch"した時にソースをダイナミックに取得します。そのため、できる限り最新のソースを利用することができます。このタイプのCVS ebuildを以下では"'live' ebuild"と呼びます。

以下の段落ではCVSを利用したebuildについてのポリシーを詳細に説明します。Portage ツリーにそのようなebuildを追加するためには厳密なルールがあるのを、注意する必要があります。

スナップショットCVS ebuildは"live"cvs.eclasscvs ebuildよりも格段に好まれます。

スナップショットCVS ebuildは、そのCVSスナップショットがよく知られたそのソフトウェアが適切に動くために必要なバグフィクスが含まれている場合、またはCVSバージョンが普通のリリースバージョンよりも単純に"良好に動く"場合に許可されます。

"live"cvs.eclass ebuildは一般的にデベロッパーの簡便さのためにだけ利用され、常に~[arch]キーワードでmaskされた状態にされているべきです。 上流のCVSツリーがいつでも変更されることがあるので、"live" cvs.eclassを使用して確実な保証をすることは不可能です。それがいつもmaskされているべきである理由です。

"live" CVS ebuildや"snapshot" CVS ebuildのどちらにしても、あなたはデベロッパーとしてそのebuildが正しく動くことに責任があります。しかしこれは"live" CVS ebuildに関しては当然ながら明確な理由で格段に難しいです。

ebuild(どんな種類でも)が正しく動かなかったりおかしいときには、修正するかPortageツリーから削除されるべきです。"live" ebuildの場合、ずっと~[arch]キーワードでmaskされたままかもしれません。(この特別な例外は以下で説明します)

どうしても必要だというユーザーがいるようなら、"live" CVS ebuildを追加しても良いでしょう。 他のユーザーが予期せずそれをmergeしてしまわないように、~[arch]キーワードを設定する必要があります。

この方法だと、それを要求した(開発者のような)ユーザーはインストールでき、それ以外のユーザは実際のmergeをしなくてすみます。もう一度確認すると、"live" cvs.eclassを要求するユーザーがいる場合にのみ適用されます。スナップショットebuildは、通常のリリースバージョンよりも安定して優れた機能を提供する目的の場合のみPortageツリーに加えられるべきです。

一般ユーザーが登録したebuild 

一般のユーザーが登録したebuildはやみくもに信じてはいけません。またいつも十分にテストをし、CVSへcommitする前に検査しなければなりません。 もし一般ユーザーが登録したebuildに問題があった場合、あなたに責任があります。 それをCVSにcommitすることは、あなたがすべてのGentoo Linux の開発標準にそのebuildが適合していると保証することになります。

ユーザーが登録したebuildに次のようなヘッダーが含まれていないことを確認してください。

# Ebuild updated by: me <[email protected]>

この情報はChagenLogに適切なChangeLog書式で記述されるべきです。いつもChangeLogにはebuildを登録したユーザーのクレジットを記述するようにしてください。この情報はChangeLogの最初に記述します。

また、新しいebuildをcommitするときには次の行が含まれていることを確認してください。

# $Header: $

rsyncされるユーザー提供ebuildファイルには、不正なヘッダー行が含まれているものがかなり多いです。

ebuildをアップグレードする場合には、すでに存在するebuildとの差分を取ることを推奨します。これをすることによって、以前修正されたバグが再び"新しい"ebuildに入ってしまうことを防ぐことの助けになります。ebuildの差分ではなくebuild自体がユーザーから提供された場合、何が変化したか(何が新しいebuildに入っているか、新しいebuildでfixされたもの削除されたもの)を見るためにdiffコマンドを使ってください。

一般的に、あなたがユーザー提供のebuildをきれいにしたいと思う場合は別にして、ebuildを標準のレベルに達するようにユーザーに変更してもらってください。 ユーザーが自分の間違いを元に正しいebuildの記述を学習し、将来的には正しいebuildをsubmitすることになるので、ユーザーに作業してもらうことは良いことです。 たとえ提供されたものが良いものでなくても、感謝してください。親切に丁寧にしてください。 そのebuildが使えなくても、ebuildを記述する技術がないことを侮辱せずにそのユーザーに言うことはできます。壊れたebuildをsubmitしたユーザーが、適切に励まされ支援を受け自分の能力を伸ばそうとするならば、将来的にはGentoo Linuxプロジェクトのスキルを持った優秀なメンバーになるかもしれないことを覚えておいてください。

4. 品質保証ポリシー

Portage リリースポリシー 

Portage管理者だけがmaskしたりunmaskedすることによって、新しいPortageをリリースする権限を持っています。他の誰も新しいPortageのリリースをする権限を持っていません。

このルールの唯一の例外は、Portaeg管理者が長期間の間不在でかつ重大なバグがPortageに存在した場合です。この緊急時には、シニアデベロッパーにその修正をテストし、それから新しいリリースをすることが許されます。

この"例外規定"を適用する前には、以下のことをもう一度確認してください。Portage管理者は本当に不在なのか。この修正は本当にすぐにPortageツリーに入れるようなとても重大なものなのか。修正したコードがすべて正常に動作することのテストを行なったのか。これは重要です。もしあなたの修正したPortageが壊れていた場合、特にそれがunmaskされた場合に、すべてのGentooユーザーにとって重大な問題となることを覚えておいてください。この"例外規定"を使用するのは、絶対的に必要な場合だけ、つまりこの例外規定を使用しない場合の影響が非常に大きい場合だけにしてください。

そしてその際は、その緊急の修正はオンラインでアクセス可能なすべてのデベロッパーの協力によって、新しいバージョンのテスト等が行われるべきです。"一人だけ"でするべきではありません。そして"緊急"バージョンのことを周知し、それが必要だった理由、Portage管理者を待つことをしなかった理由を説明するために、gentoo-coreメーリングリストに投稿しなくてはなりません。

Portage管理者は信頼できるな特別の人たちにPortage開発用cvsツリーにcommitをすることを許可します。 しかしながら、たとえあなたがこのメンバーの一人だとしても、この権限はPortageの新しいリリースを行なう権限ではありません。それはPortage管理者の仕事です。その人はPortageの新しいリリースの前に、変更に対してのレビューを行ない、妥当な品質保証テストをします。この仕事がPortage管理者によって行なわれ、このルールを破らないことを考慮に入れてください。この明確なポリシーが今後のPortage品質保証問題を防ぐ助けになることを期待します。

maskされたパッケージ 

/usr/portage/profiles/package.maskはユーザーによってmergeされるべきではないパッケージのリストと、その明確な理由が記述されています。 Package.maskは壊れているパッケージや、何か他のものを壊してしまうパッケージが、mergeされるのを防ぐためや、Portageツリーへ~ARCH KEYWORDSで入る前に通常以上にテストが必要な場合に使用されます。package.maskに追加する場合には、必ずmaskするebuildをcommitする前にpackage.maskをcommitします。 これはpackage.maskがアップデートされる前に、そのebuildをユーザーが使ってしまうことを防ぐことになります。

package.maskから取り除くときには最大限の注意が必要です。 package.maskの中にあるebuildには、その理由があることを覚えておいてください。 もしmaskを外す場合には、その前に必ずpackage.maskに書かれたデベロッパーに連絡してください。 加えて、そのmaskされたパッケージがコアパッケージのもの、またはコアパッケージに依存するもの、またはmaskを外すことが悪影響を与える可能性がある場合には、内部のデベロッパーメーリングリストで議論すべきです。

~ARCHキーワード 

~archは、Portageに加えられた新しいパッケージをテストするための目的で存 在します。これは他のディストリビューションの"unstable"や"testing"と同 等の意味ではありません。

Portageに入るどの新しいパッケージも、そのバージョンで動くと知られているアーキテクチャの~archでマークされるべきです。そのebuildをcommitするデベロッパーは、正常に動作することとそのキーワードが正確なことを確認しなければなりません。

~ARCHからARCHへの移動 

パッケージのバージョンが十分に安定していることがわかり、そのパッケージのGentooメンテナーが普通のGentooユーザーのマシンを壊してしまわないだろうと確信したときに、~ARCHからARCHへ移動することができます。 パッケージの安定度は、そのバージョンの導入以降一ヶ月間の未確認または未解決のバグレポートが目安になります。

そのパッケージのバージョンが安定しているか、または開発バーションなのでpackage.maskに書かれているべきか、または~archを残しておくべきかを考えるのはパッケージメンテナーの責任です。

また、そのようなバージョンの依存関係を満たすものがARCHにあることを確認する必要があります。

5. 変数

必須の変数 

Gentoo LinuxポリシーではKEYWORDS、LICENSE、SLOT変数がすべてのebuildに含まれている必要があります。 HOMEPAGE、 SRC_URI、 DESCRIPTIONもまた特別な状況を除いて含まれているべきです。またDEPEND、(もし必要ならば、RDEPEND)はパッケージが他のパッケージ又はランタイムにそれぞれ依存している場合には含まれているべきです。

DEPENDとRDEPEND 

DEPENDはビルド時に必須な特定パッケージの依存を定義します。 またRDEPENDは実行時に必須の特定パッケージの依存を定義します。 ebuildの実行時の依存がDEPENDで指定したものと異なる場合にのみ、 RDEPENDを明示的に指定する必要があります。 RDEPENDが指定されない場合には、RDEPENDは自動的にDEPENDの指定がセットされます。 RDEPENDをDEPENDへebuildの中でセットしないでください。

Code listing 5.1

# これはOK RDEPEND="${DEPEND} net-ftp/curl virtual/glibc" # こう設定してはいけない RDEPEND="${DEPEND}"

そしてまたバイナリ.tbz2パッケージをインストールする際には、RDEPEND依存だけが満足されていれば良いということも重要です。このことはRDEPEND依存に何を正しく選べばよいのかという助けになります。もしebuildのRDEPENDが定義されていないと、デフォルト値としてDEPENDの値がセットされます。

パッケージは依存を満足する最も古いバージョンに依存するべきです。libfoo-1.2.xで動く場合には、あなたがlibfoo-2.xをインストールしているだけという理由ででそれに依存しないようにしてください。

一般的に、パッケージは>=libfoo-1.2の代わりに=libfoo-1.2*に依存されているべきです。そうでなければ、libfoo-2.0が導入されたときにうまく動かない可能性があります。

virtual/fooをPROVIDEする複数の異なったパッケージが同一のインターフェースを提供している場合のみ、virtual/fooのようなvirtualパッケージへ依存することができます。例えばvirtual/jdk-1.3を考えてみます。いくつかのパッケージはibm-jdk-1.3では動かずに、一方ではsun-jdk-1.3では動くとします。こういう理由で、パッケージはunmaskされる前にすべてのvirtual provideパッケージについてテストされる必要があります。そのvirtualパッケージ自身よりもむしろそのvirtual内のパッケージの一部にのみ依存している可能性があります。

6. パッケージの移動

カテゴリー間のパッケージの移動 

時々、Portageツリーは増えすぎてしまったカテゴリーを特定の小さなカテゴリーへ再編成する必要があります。例えば、net-miscに大量のfirewall関連のパッケージがある場合に、それらを小さなカテゴリーと分割することはとても有益な再編成です。dev-perlの分割はおそらく意味を持たないでしょうが。

この種の決定は一人のデベロッパーによってされるべきではありません。 他の優れた解決方法があるかもしれませんから、まずは内部のメーリングリストで議論すべきです。

以前は、移動するパッケージにDEPENDしたパッケージのために、移動するebuildにPROVIDE行を加えることにより移動をしていました。 新しい正しいパッケージの移動方法は、Portageツリーのprofiles/updates/の適切なファイルにエントリーを加える方法です。 このフォーマットは以下のようになります。

Code listing 6.1

move net-misc/fwbuilder net-firewall/fwbuilder

このケースでは、fwbuilderパッケージをnet-miscからnet-firewallへ移動します。

  The contents of this document are licensed under the Creative Commons - Attribution / Share Alike license.