Product SiteDocumentation Site

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

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

Creating a quality Debian package is not always a simple task, and becoming a package maintainer takes some learning, both with theory and practice. It is not a simple matter of building and installing software; rather, the bulk of the complexity comes from understanding the problems and conflicts, and more generally the interactions, with the myriad of other packages available.

15.4.1.1. 規則

A Debian package must comply with the precise rules compiled in the Debian policy, and each package maintainer must know them. There is no requirement to know them by heart, but rather to know they exist and to refer to them whenever a choice presents a non-trivial alternative. Every Debian maintainer has made mistakes by not knowing about a rule, but this is not a huge problem as long as the error gets fixed when a user reports it as a bug report (which tends to happen fairly soon thanks to advanced users). The Standards-Version field in debian/control specifies the version of the Debian policy with which a package complies. Maintainers should comply to the latest version of the Debian policy.

15.4.1.2. 手続き

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

15.4.1.3. ツール

パッケージメンテナの作業を手助けする数多くのツールが存在します。この節では、それらのツールを簡単に説明します (詳細は説明しません)。なぜなら、これらのツールには自分自身を解説する総合的な文書が用意されているからです。
15.4.1.3.1. lintian プログラム
This tool is one of the most important: it is the Debian package checker. It is based on a large array of tests created from the Debian policy, and detects quickly and automatically many errors that can then be fixed before packages are released.
lintian の情報は参考程度にしかならず、間違いを犯すこともあります (たとえば、Debian ポリシーは常に変わるものなので、しばしば lintian は時代遅れになることがあります)。また、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 を使うことで、Debian パッケージを生成した直後に (dpkg -c を使って) そのパッケージの内容を調査することが可能です。パッケージの完全な名前やパスを指定する必要はありません。
  • bts を使うことで、コマンドラインからバグ追跡システムを制御することが可能です。bts プログラムは適切なメールを自動的に生成します。
  • debrelease を使うことで、Debian パッケージを生成した直後にそのパッケージをリモートサーバにアップロードすることが可能です。関連する .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 パッケージを生成するために必要なファイルを作成します。dh_make という名前から推測される通り、生成されたファイルはデフォルトで debhelper を使います。
15.4.1.3.5. autopkgtest
autopkgtest runs tests on binary packages, using the tests supplied in the source package.
15.4.1.3.6. reprotest
reprotest builds the same source code twice in different environments, and then checks the binaries produced by each build for differences. If any are found, then diffoscope (if unavailable, diff) is used to display them in detail for later analysis.
15.4.1.3.7. 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. 登録

候補者が最初に (現実的な意味で) やることは保証人か支持者を見つけることです。そしてこれは公式の開発者が候補者を受け入れることが Debian のためになると信じていると喜んで宣言すること意味します。通常これは候補者が既にコミュニティ内で活発に活動し続けており、候補者の業績が受け入れられ続けていることを暗黙的に意味します。候補者が遠慮がちで候補者の業績が公に注目されていなければ、候補者は Debian 開発者に対して個人的な方法で自分の業績を明らかにして自分を支持することを納得するように試みることが可能です。
同時に、候補者は GnuPG を使って RSA 公開鍵と秘密鍵のペアを生成しなければいけません。候補者の公開鍵は少なくとも 2 人の公式 Debian 開発者の秘密鍵によって署名されるべきです。この署名は候補者の公開鍵に書かれた名前が本物であることを証明するものです。実質的なことを言えば、候補者はキーサインパーティで公式 Debian 開発者に直接会って、自分の公開鍵を公式 Debian 開発者の秘密鍵によって署名してもらう必要があります。キーサインパーティの参加者は鍵 ID と一緒に必ず公式の身分証明書 (通常 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 の役職に就く人はこれまでずっと批判され続けています。