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 を使うことで、パッケージのリリース前に多くのエラーを修正することが可能となります。
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_ が付けられています。
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 の役職に就く人はこれまでずっと批判され続けています。