6 【でびあん】 Debian パッケージメンテナというお仕事【現在募集中】

やまねひで き

6.1 Debian パ ッケ ー ジ メ ン テ ナ の お 仕 事

実は、 Debian パッケージのメンテナになるにはそんなに敷居は高くありません。 よっぽど入学試験／就職／転職活動の方が 難しいと思うほどです。 恐れることはありません。 多少なりとも興味がある方はこれからの説明をご覧くだ さい。

6.2 メンテナになる前の下準備

1. GPG 鍵を作っておく (aptitude install gpg && gpg –gen-key)
2. 公的な身分証明書を用意しておく
3. 先ほど作った GPG 鍵と身分証明書を利用して、 既存の Debian Developer と GPG キーサインの交換を行っ ておく
4. メンテナや Developer として問題ないと見なされる作業をしておく (contribute!)

この 4 つだけ準備したら、 さぁ、 メンテナになる作業の始まりです。

6.3 The way to Debian package maintainer

メンテナになる方法としては 2 点あります。

1. 自分から「このソフトを Debian パッケージにしたい」 と申請する
2. 既存のパッケージのメンテナからメンテナンスを引き継ぐ

1. は ITP (Intent To Package) という形で行います。 特に RFP (Request For Package) という形でユーザから「このソ フトを Debian パッケージにして欲しいなぁ」 という声に答えるのが望ましいでしょう。

2. は RFH (Request For Help、 協力者募集中)、 RFA (Request for Adoption、 新メンテナ募集中) や O (Orphaned、 みなしご化) というステータスになったパッケージに対して「自分がメンテナになります」 と宣言し ます。

ITP, RFP, RFA, Orphaned は全て Debian Bug Tracking System (BTS) で管理登録されます (BTS の使 い方についてはそのうち別途)。 これらを総称して「作業が望まれるパッケージ (Work-Needing and Prospective Packages; WNPP)」 と呼びます。 この WNPP、 BTS で追うのは結構辛いので wnpp.debian.net ^*7 を使いましょう。 各略語の意味などについては http://www.jp.debian.org/devel/wnpp/ をご覧くだ さい。

6.3.1 ITP、 RFP パッケージ化

大抵 1 からパッケージ化作業ですので、 ウェブサイトからソースを取得してライセンスを確認の上、 パッケージ作りのお作法 に従ってパッケージを作成します。 パッケージを作成する際は、 unstable 環境の lintian で warning などが 出なくなるよう (Debian Policy Manual に準拠するよう) に頑張りましょう。 パッケージが作成できたら pbuilder でクリーンルーム環境でビルド可能かどうか (Build-Depends に間違いが無いか) のチェックを行います。 問題なくビルドできたら piuparts を使ってインストール／アンインストールで問題が無いか (Depends や preinst,postinst,prerm,postrm スクリプトに問題が無いか) を確認しましょう。 ここまで来て問題なければ「Eat your own dog food」 、 つまり自分の環境にパッケージを入れて問題が起きないかどうかチェックするとベストで しょう。

______________________________________________________________________________________________

6.3.2 RFA, Orphan への対処

すでに現在のメンテナが引き継ぎ手を募集している状態 (RFA) や、 完全にギブアップ or 興味を失ってしまった (Orphan) になったパッケージについては、 BTS を利用してパッケージを引き取る旨の宣言 (ITA, Intend To Adapt) を行いましょ う。 加えて関連のメーリングリストで「自分がやろうと思うけど、 どう？」 と聞いてみるとさらに良いでしょ う。 合意がとれたら、 debian/changelog にて該当の RFA/Orphan バグを閉じるエントリを追記しておき ます。 大抵の場合は色々とバグレポートが溜まっているので片付けて同様に changelog に記載しておきま しょう。

6.4 アップロード

ここまでが終わったらアップロードを行います。 Debian Developer であればパッケージを dput や dupload と呼ばれるコ マンドを使って、 作成されたソースパッケージとバイナリパッケージを直接 Debian へアップロードします。 そうでない場合は 適当な場所にアップロードして、 Debian Developer に代理アップロードをお願いしましょう (アップロード先は、 http:://mentors.debian.net、 代理アップロード依頼先は debian-devel@debian.or.jp がおすすめ です)。

この時点でツールは dsc ファイルや changes ファイルに gpg 署名されているかどうかをチェックして、 されていない場合 はアップロードしないなどしてくれます。

サーバ側では、 まず「既にあるパッケージの更新なのか、 それとも新規パッケージなのか」 の判断を行います。 新規パッ ケージの場合は NEW Queue ( http://ftp-master.debian.org/new.html) と呼ばれる所に自動的に移されて、 ftpmaster が逐次入れてよいものかどうかのチェックを行っています。 おおよそこの工程は１、 2 週間程度かかり ます。

チェックは特にライセンスの問題が無いかについてなどが争点となります。 この作業は高度な判断が要求されるため、 人的 リソース的にボトルネックになりやすいところと、 拒否された場合に「何故このパッケージが拒否されたのか」 の記録が容易に トラッキングできないのが問題点です。 人的リソースについては、 アクティブなメンバーを入れることで以前と比較しても改善 がされており、 トラッキングについては最近になってシステマチックにチェック可能なように提案が出てきているところ で す 。

更新パッケージについては、 サーバ側でソースパッケージの gpg 署名をチェックなどをして「本当にこれは入れていいも のかどうか」 を判断してダメな場合は reject されます。 このチェックについては、 アップロード後にサーバから受け入れ／拒否 のメールが届きます。

まずアップロードされたパッケージの処理を始めたよ、 というメール

チェックして incoming repository に入れたよ、 というメール

これでパッケージのアップロードが完了しました。 BTS に記載されているバグを修正した旨を debian/changelog に適切 なスタイルで記述しておくと、 BTS から bug closed のメールがやってきます。

6.4.1 その他アップロードに関する注意

ちなみに、 Debian バージョンのみの更新の場合 (foo 1.0-1 から foo 1.0-2 への更新など) はオリジナルのソースファイル (orig.tar.gz) をアップロードしないことになっています。 もし、 orig.tar.gz をアップロードした場合は後から拒否のメールが 届きます。

あと注意として、 ライブラリファイルや他の多くのパッケージと関連しているようなパッケージで更新をかけると unstable 環境が壊れるような場合は、 experimental へアップロードして関係者と調整することが推奨されてい ます。

6.5 メンテナンス作業

BTS を通じてユーザからバグ報告メールが来るので、 それに対応してパッケージの debian ディレクトリ以下を更新して、 修正出来たら changelog に完了した旨を記載しておきます (dch コマンドが便利です)。 特に RC (Release Critical) バグは早 めに修正しましょう。 バグが他のパッケージと関連する場合は適当なメーリングリストで関係者と対応を協議して進め て い き ま す 。 場 合 に よ って は 、 自 分 の パ ッケ ー ジ の バ グ で は な く 、 他 の パ ッケ ー ジ の バ グ で あ る 場 合 も あ り ますので、 その場合はバグを BTS で reassign しておきます。 パッケージとしてのバグではなく、 元々の ソース由来のバグの場合は、 バグを upstream (開発元) に転送するかパッチを作って upstream と協議しま しょう。

そして upstream での更新に合わせてパッケージも更新します。 upstream の更新は debian/watch ファイルを適切に記載 していれば、 DEHS (Debian External Health Status、 http://dehs.alioth.debian.org) によって定期的にチェックさ れ、 Debian Quality Assuarance の developer ページ ( http://qa.debian.org/developer.php) で状況を確認できます (あとは upstream のリリースアナウンスが流れるメーリングリストに入っておくと良いでしょう)。 きちん と設定された debian/watch ファイルがあれば、 パッケージによっては更新がものの 1 分も経たずに出来 ます。

チーム制でメンテナンスをするような場合は共有 repository に更新したソースを忘れずに commit しておきましょう。 commit 出来ない場合は、 チームのメーリングリストにパッチを送ります。 幾度か適切なパッチを送りつづけていると、 いつの 間にか commit 権が与えられていることが多い様です。

なお、 バグ修正や Debian Policy に適合するために Debian パッケージ側で色々とパッチを当てている (dpatch や quilt を利用する) と新バージョン側のソースとコンフリクトを起こしてその修正に時間がかかることがありますので、 なるべく upstream の開発者とメーリングリストなどを通じて普段からコンタクトを取り合っておいて、 パッチ自体が取り込まれて不要 になるように働きかけましょう。

この様にしてパッケージ化、 メンテナンス等をメンテナは日々行っていきます。 特に問題なく時間が経過したパッケージは unstable から testing に移行され、 次のリリースを待つことになります。 そして、 リリースの日を迎えたパッケージは stable へと移されます。

6.6 特殊な場合

以下に頻繁には起きないはずの、 ちょっと変わった場合の対応を挙げておきます。

6.6.1 NMU

Non-Maintainer Upload の略で、 既存のメンテナ以外の人間がバグ修正のためにパッケージをアップロードすることを指し ます。 あまり頻繁に NMU があるようなパッケージについては、 メンテナが本当に活動しているのかどうかをチェックした方が いいでしょう。

6.6.2 FREEEEEEZE!!

特にリリース前には「システム全体の安定化」 が必要なため、 freeze、 つまりパッケージの unstable から testing への自動 移行が停止されます。 しかし、 freeze の間に発覚した、 そのままリリースされてしまっては困るようなバグ の修正が必要な場合もあります。 その場合はリリースマネージャ (RM) に対して「私のこのパッケージを testing に入れるようにしてください！」 とお願いします。 これを「unblock (exception) request」 と一般 に呼びます。 やり方としてはメーリングリストで RM が理解しやすいフォーマットでメールを投げるだけ です。

うまくすれば RM から ”unblocked” という素っ気ないメールが届きます。 これが来たら大成功です。 今 unstable にある パッケージは testing へ移行することが可能になります。

6.7 メンテナ権の移譲

パッケージメンテナも人の子、 残念ながら諸事情によりメンテナンスが出来なくなるような事態が起きるか もしれません。 なるべく一人でメンテナンスせずチームあるいは自分以外の詳しい／信用できるメンテナも アップロードできるようにしておきます。 具体的には debian/control の Uploaders フィールドにアップロー ドしてもいい人の名前とメールアドレスを書いておきます (GPG 署名に使うものと同一である必要があり ます)。

そして、 メンテナンスが出来なくなりそうな場合は、 あまり粘らずにさっさと宣言 (RFA, Orphan) しておきましょ う。 宣言が無いと「このパッケージ古いな」 という悪評が立つだけ…という結果になりかねません。 なお、 日 本の首相と違ってメンテナは頻繁に交代してもきちんとした理由があれば文句は言われることはありません :-) （できれば最初の方から複数人でのチームメンテナンスなどしておくと困ったことになる確率は減り ます）

6.8 終わりに

如何でしたか？パッケージメンテナというお仕事がどのようなものか、 多少理解が深まっていただければ幸い です。 ____________________________________________________________________________________________

Debian 勉強会資料

2008 年9 月20 日  初版第1 刷発行
東 京 エ リ ア Debian 勉強会 （編集・印刷・発行）
__________________________