Product SiteDocumentation Site

15.4. パッケージメンテナになる

15.4.1. パッケージを作るための知識

上質な Debian パッケージを作成することは簡単な作業ではありません。パッケージメンテナになるためには理論と実践の両方の知識が必要です。ソフトウェアをビルドしたりインストールすることは簡単ではありません; むしろ複雑さの大部分は他の無数の利用可能なパッケージとの問題と対立、より一般には相関性、を理解することに由来します。

15.4.1.1. 規則

Debian パッケージは必ず Debian ポリシーにまとめられた正確な規則に従わなければいけません。各パッケージメンテナはこの規則を知らなければいけません。規則を暗記する必要はありませんが、規則の存在を知り、重要な判断を下す局面では常に規則を参照する必要があります。Debian メンテナは全員規則をよく知らない事が原因で間違いを犯した経験がありますが、これは大きな問題ではありません。なぜなら、ユーザがバグ報告としてこの間違いを報告すればすぐにその間違いは修正されるからです。上級ユーザのお陰で修正はかなり素早く行われる事が多いです。

15.4.1.2. 手続き

Debian は各パッケージを単純に集めたものではありません。全員のパッケージ化作業は共同プロジェクトの一部です; Debian 開発者になるには、Debian プロジェクトが全体としてどのように運営されているかを知る必要があります。Debian 開発者は全員、遅かれ早かれ、他人と協力して行動することになるでしょう。Debian 開発者リファレンス (developers-reference パッケージに含まれます) では、開発者全員が、プロジェクト内の様々なチームと可能な限り円滑に一緒に仕事を行ったり利用可能な資源を大いに活用するために、必ず知らなければいけない事を要約しています。また、Debian 開発者リファレンスは管理者が果たすべき数多くの義務も列挙しています。

15.4.1.3. ツール

数多くのツールがパッケージメンテナの仕事を手伝います。この節では、それらのツールを簡単に説明し、詳細は説明しません。なぜなら、これらのツールには、総合的な文書が用意されているからです。
15.4.1.3.1. lintian プログラム
lintian は最も重要なツールの 1 つです: lintian は Debian パッケージをチェックします。lintian は Debian ポリシーから作成された大量のテスト群に基づき、パッケージがリリースされる前に修正する事が可能な多くのエラーを素早く自動的に検出します。
lintian の情報は参考程度にしかならず、間違いを犯す事もあります (例えば、Debian ポリシーは常に変わるものなので、しばしば lintian は時代遅れになる事があります)。lintian は徹底的な調査を行いません: Lintian エラーが無いからと言って、対象のパッケージが完全であることの証明にはなりません; せいぜい、最も一般的な間違いを犯していない事がわかるだけです。
15.4.1.3.2. piuparts プログラム
piuparts もまた重要なツールの 1 つです; piuparts は (隔離環境の中で) パッケージのインストール、アップグレード、削除、完全消去の作業を自動化し、これらの作業中にエラーが起きない事を確認します。piuparts は不足している依存関係を検出することにも役立ち、パッケージが完全消去された後にファイルが誤って残されたこと検出します。
15.4.1.3.3. devscripts
devscripts パッケージには、Debian 開発者が行う作業の大部分に対する手助けを行う数多くのプログラムが含まれます:
  • debuild を使うことで、(dpkg-buildpackage から) パッケージを生成したり、Debian ポリシーへの遵守を確認するために後から lintian を実行する事が可能です。
  • debclean を使うことで、バイナリパッケージを生成した後にソースパッケージの後片付けをする事が可能です。
  • dch を使うことで、素早く簡単にソースパッケージ中の debian/changelog ファイルを編集する事が可能です。
  • uscan を使うことで、上流開発者がソフトウェアの新しいバージョンをリリースしたか否かを確認する事が可能です; これを行うにはリリースの場所が書かれた debian/watch ファイルが必要です。
  • debi を使うことで、Debian パッケージを生成した直後に (dpkg -i から) そのパッケージをインストールする事が可能です。パッケージの完全な名前やパスを指定する必要はありません。
  • 同様の方法で、debc を使うことで、(dpkg -c から) 最近生成されたパッケージの内容を走査する事が可能です。パッケージの完全な名前やパスを指定する必要はありません。
  • bts を使うことで、コマンドラインからバグ追跡システムを制御する事が可能です; このプログラムは適切なメールを自動生成します。
  • debrelease を使うことで、最近生成されたパッケージをリモートサーバにアップロードする事が可能です。関連する .changes ファイルの完全な名前やパスを指定する必要はありません。
  • debsign を使うことで、*.dsc*.changes ファイルに署名する事が可能です。
  • uupdate を使うことで、新しい上流開発版がリリースされた場合にパッケージの新しい修正版の作成を自動化する事が可能です。
15.4.1.3.4. debhelperdh-make
debhelper はポリシーを遵守するパッケージの作成を簡単にするスクリプト群です; これらのスクリプトは debian/rules から実行されます。大多数の公式 Debian パッケージが debhelper を使っているという事実からも分かる通り、debhelper は Debian の中で広く適用されています。debhelper から提供されるすべてのコマンドは名前の頭に dh_ が付けられています。debhelper は主として Joey Hess さんによって開発されています。
dh_make スクリプト (dh-make パッケージに含まれます) はソフトウェアのソースが最初に含まれるディレクトリ内で Debian パッケージを生成するために必要なファイルを作成します。プログラムの名前から推測されるとおり、生成されたファイルはデフォルトで debhelper を使います。
15.4.1.3.5. duploaddput
duploaddput コマンドを使うことで、Debian パッケージを (場合によってはリモート) サーバにアップロードする事が可能です。duploaddput コマンドを使うことで、開発者は主たる Debian サーバ (ftp-master.debian.org) 上で自分のパッケージを公開する事が可能です。こうすることで、パッケージはアーカイブに統合され、ミラーによって配布されます。duploaddput コマンドは *.changes ファイルをパラメータとして受け取り、*.changes ファイルの内容から他の関連するファイルを推測します。

15.4.2. 受け入れ過程

Debian 開発者になることは単なる管理上の手続きを経るだけの問題ではありません。受け入れ過程は復数の段階からなり、選考過程に匹敵する入会儀式と言えます。いかなる場合も、受け入れ過程は公認されよく文書化されています。そのため、誰でも新メンバー過程専用のウェブサイト上で進み具合を追跡する事が可能です。

15.4.2.1. 必要条件

すべての候補者は少なくとも実務に役立つ英語力を持つ事を期待されます。英語力はすべての段階で要求されます: 試験官に対する最初の連絡はもちろんその後も必要です。なぜなら、英語はほとんどの文書で推奨される言語だからです; また、パッケージのユーザはバグを報告する際に英語で連絡を取るでしょうし、ユーザは英語で返信をもらう事を期待するでしょう。
他の必要条件は意欲です。Debian 開発者になることは、候補者が Debian に対する自分の関心が何ヶ月も続く事を判っている場合のみ、合理的な行為です。受け入れ過程は数ヶ月間続き、Debian は開発者に長期に渡る苦労を要求します; それぞれのパッケージは永久的なメンテナンスが必要で、最初のアップロードで終わりではありません。

15.4.2.2. 登録

最初の (現実的な) 段階は保証人か支持者を見つける事です; これは、公式の開発者が X さんを受け入れる事が Debian のためになると信じていると喜んで宣言すること意味します。通常これは、候補者が既にコミュニティ内で活発に活動し続けており、候補者の業績が受け入れられ続けている、事を暗黙的に意味します。候補者が遠慮がちで、候補者の業績が公に注目されていなければ、候補者は Debian 開発者に対して個人的な方法で自分の業績を明らかにして自分を支持する事を納得するように試みる事が可能です。
同時に、候補者は GnuPG を使って RSA 公開鍵と秘密鍵のペアを生成しなければいけません。鍵ペアは少なくとも 2 人の公式 Debian 開発者によって署名されるべきです。この署名は鍵に書かれた名前が本物である事を証明するものです。実質的に言えば、キーサインパーティの間、各参加者は鍵識別子と一緒に必ず公式の身分証明書 (ID カードかパスポート) を見せなければいけません。この段階は人と鍵の間の正式な関連付けを行います。このため、署名を受けるには実際に会う必要があります。あなたが公のフリーソフトウェアカンファレンスで Debian 開発者と会っていない場合、あなたは以下のウェブページに載っているリストを足掛かりとして、近くに住んでいる開発者を探す事が可能です。
支持者が nm.debian.org 上の登録内容の正当性を認めたら、対象の候補者に対して 1 人の応募管理者が割り当てられます。応募管理者は復数の事前に定義された段階と確認を通じて作業を進めます。
最初の妥当性確認事項は本人確認です。既に 2 人の Debian 開発者が鍵に署名している場合、この段階は簡単です; そうでなければ、応募管理者はあなたに対して、近くにいる Debian 開発者を探し、会ってキーサインする段取りを付けるように指導するでしょう。このプロセスの始まった当初、開発者の数が少なかったとき、この手続には例外規定があり、公式の身分証明書のデジタルスキャンを使ってこの手続きを済ませる事が可能でした; これはもはや当てはまりません。

15.4.2.3. 原則の受け入れ

次の管理上の手続きは哲学の検討です。ここで、候補者は社会契約とフリーソフトウェアの背後にある原理を理解して受け入れることに対する確認を取られます。Debian に参加するには、必ず創設理念に表されている (1章Debian プロジェクトにまとめられている) 現在の開発者を団結させている価値に共感する必要があります。
加えて、Debian に参加したいと思っている各候補者はプロジェクトの仕組みと、時間が経てば間違いなく直面するであろう問題を解決する際に適切に相互協力する方法を知る事を期待されます。すべての情報は新しいメンテナ向けのマニュアルと Debian 開発者リファレンスの中でおおまかに説明されています。試験官の質問に答えるには、この文書を注意深く読むだけで十分です。回答が不十分な場合、候補者は知らされます。候補者は再試験を受ける前に関連する文書を (再度) 読まなければいけません。既存の文書に質問に対する適切な回答が含まれなかった場合、候補者は Debian 内の実務経験を使うか他の Debian 開発者との議論を通じて回答に到達する事が可能です。このメカニズムによって、候補者が Debian のすべての部分に参加する前に一部分だけに参加する事が保証されます。これは慎重な方針です。この方針によって最終的に Debian プロジェクトに参加する候補者は永久的に広がるジグソーパズルのピースの 1 つとして統合されます。
この段階は新メンバー過程に参加する開発者の間で使われる用語の Philosophy & Procedures (略して P&P、哲学と手順) として知られています。

15.4.2.4. 能力の確認

公式 Debian 開発者になるための申込は理にかなったものでなければいけません。プロジェクトメンバーになるには、プロジェクトメンバーの地位の申し込みが適切なこと、プロジェクトメンバーの地位を得ることで Debian の手助けに関する候補者の仕事が容易になる事を示す必要があります。最も一般的な理由付けは Debian 開発者の地位が Debian パッケージのメンテナンスを簡単にするというものです。しかしこれは唯一の理由ではありません。特定のアーキテクチャへの移植に貢献するためにプロジェクトに参加している開発者もいれば、文書を改良したいと思ってプロジェクトに参加している開発者もいます。
この段階で、候補者は Debian プロジェクトの中で何をしたいと思っているのか宣言し、その目的のためにこれまで何をしてきたか示す機会を与えられます。Debian は実用主義的なプロジェクトで、やっている事が言っていることと食い違っている場合、言うだけでは不十分です。一般的に言って、プロジェクト内で希望する役割がパッケージメンテナンスに関連する場合、候補となっているパッケージの最初のバージョンは必ず技術的な正当性を確認され、既存の Debian 開発者から選ばれた保証人によって Debian サーバにアップロードされます。
最後に、試験官は詳細な質問を投げかけて技術的な (パッケージ化) スキルを確認します。間違った回答は許されませんが、回答時間に制限はありません。すべての文書は利用可能で、最初の回答が不十分な場合、何回でも回答を作る事が可能です。この段階は候補者を不当に冷遇するためのものではなく、新しい貢献者が共通に認識しておくべき最低限の僅かな知識を保証するためのものです。
この段階は試験官の隠語 Tasks & Skills (略して T&S、仕事と技能) として知られています。

15.4.2.5. 最後の承認

最後の段階で、DAM (Debian アカウントマネージャ) がすべてのプロセスを再確認します。DAM は試験官が集めた候補者に関するすべての情報を再確認し、Debian サーバにアカウントを作成するか否かについて決断を下します。追加的情報が必要な場合、アカウントの作成が遅れるかもしれません。試験官がプロセスに従って良い仕事をしていれば、ここで不合格になることはかなりまれです。しかし、不合格なる場合も時々あります。不合格は永久的なものではありません。候補者は暫くの後再度試験を受ける事が可能です。
DAM の決定は権威的なもので (ほとんど) 覆されません。このお陰で、DAM の役職に就く人 (現在では、Jörg Jaspert さん、Christoph Berg さん、Enrico Zini さん) はこれまずっと批判され続けています。