Debian 開発者リファレンス --------------------------------------------------------------------- [FAMILY Given] Barth Andreas [FAMILY Given] Di Carlo Adam [FAMILY Given] Hertzog Raphaël [FAMILY Given] Nussbaum Lucas [FAMILY Given] Schwarz Christian [FAMILY Given] Jackson Ian [FAMILY Given] ver. 3.4.11 --------------------------------------------------------------------- 製作著作 © 2004, 2005, 2006, 2007 Andreas Barth 製作著作 © 1998, 1999, 2000, 2001, 2002, 2003 Adam Di Carlo 製作著作 © 2002, 2003, 2008, 2009 Raphaël Hertzog 製作著作 © 2008, 2009 Lucas Nussbaum 製作著作 © 1997, 1998 Christian Schwarz このマニュアルはフリーソフトウェアです。あなたは、Free Software     Foundation が発行した GNU 一般公衆利用許諾契約書の第二版あるいは それ以降のいずれかの版の条件に基づき、本文書の再配付および変更を することができます。 本文書はその有用性が期待されて配付されるものですが、市場性や特定     の目的への適合性に関する暗黙の保証も含め、いかなる保証も行ないま せん。詳細については GNU 一般公衆利用許諾契約書をお読みください。 GNU 一般公衆利用許諾契約書の写しは、Debian GNU/Linux ディストリビ ューション中の /usr/share/common-licenses/GPL-2 、あるいは World     Wide Web 上の GNU ウェブサイトで入手できます。また Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA へ手紙 (英語) で依頼し入手することもできます。     このリファレンスを印刷したい場合は、PDF 版を利用すると良いでしょ う。このページはフランス語、ドイツ語、日本語でも利用可能です。 2013-08-07 --------------------------------------------------------------------- 目次 1. この文書が扱う範囲について 2. 開発者になるために応募する 2.1. さあ、はじめよう 2.2. Debian メンター (mentors) とスポンサー (sponsors) について 2.3. Debian 開発者への登録を行う 3. Debian 開発者の責務 3.1. パッケージメンテナの責務 3.1.1. 次期安定版 (stable) リリースへの作業 3.1.2. 安定版 (stable) にあるパッケージをメンテナンスする 3.1.3. リリースクリティカルバグに対処する 3.1.4. 開発元/上流 (upstream) の開発者との調整 3.2. 管理者的な責務 3.2.1. あなたの Debian に関する情報をメンテナンスする 3.2.2. 公開鍵をメンテナンスする 3.2.3. 投票をする 3.2.4. 優雅に休暇を取る 3.2.5. 脱退について 3.2.6. リタイア後に再加入する 4. Debian 開発者が利用可能なリソース 4.1. メーリングリスト 4.1.1. 利用の基本ルール 4.1.2. 開発の中心となっているメーリングリスト 4.1.3. 特別なメーリングリスト 4.1.4. 新規に開発関連のメーリングリストの開設を要求する 4.2. IRC チャンネル 4.3. ドキュメント化 4.4. Debian のマシン群 4.4.1. バグ報告サーバ 4.4.2. ftp-master サーバ 4.4.3. www-master サーバ 4.4.4. people ウェブサーバ 4.4.5. VCS (バージョン管理システム) サーバ 4.4.6. 複数のディストリビューション利用のために chroot を使う 4.5. 開発者データベース 4.6. Debian アーカイブ 4.6.1. セクション 4.6.2. アーキテクチャ 4.6.3. パッケージ 4.6.4. ディストリビューション 4.6.5. リリースのコードネーム 4.7. Debian ミラーサーバ 4.8. Incoming システム 4.9. パッケージ情報 4.9.1. ウェブ上から 4.9.2. dak ls ユーティリティ 4.10. パッケージ追跡システム 4.10.1. PTS メールインターフェイス 4.10.2. PTS からのメールを振り分ける 4.10.3. PTS での VCS コミットを転送する 4.10.4. PTS ウェブインターフェイス 4.11. Developer's packages overview 4.12. Debian での FusionForge の導入例: Alioth 4.13. 開発者への特典 4.13.1. LWN の購読 4.13.2. Gandi.net ホスティング割引 5. パッケージの取扱い方 5.1. 新規パッケージ 5.2. パッケージの変更を記録する 5.3. パッケージをテストする 5.4. ソースパッケージの概要 5.5. ディストリビューションを選ぶ 5.5.1. 特別な例: 安定版 (stable) と旧安定版 (oldstable) ディ ストリビューションへアップロードする 5.5.2. 特別な例: testing/testing-proposed-updates へアップロ ードする 5.6. パッケージをアップロードする 5.6.1. ftp-master にアップロードする 5.6.2. 遅延アップロード 5.6.3. セキュリティアップロード 5.6.4. 他のアップロードキュー 5.6.5. 新しいパッケージがインストールされたことの通知 5.7. パッケージのセクション、サブセクション、優先度を指定する 5.8. バグの取扱い 5.8.1. バグの監視 5.8.2. バグへの対応 5.8.3. バグを掃除する 5.8.4. 新規アップロードでバグがクローズされる時 5.8.5. セキュリティ関連バグの取扱い 5.9. パッケージの移動、削除、リネーム、放棄、引き取り、再導入 5.9.1. パッケージの移動 5.9.2. パッケージの削除 5.9.3. パッケージをリプレースあるいはリネームする 5.9.4. パッケージを放棄する 5.9.5. パッケージを引き取る 5.9.6. パッケージの再導入 5.10. 移植作業、そして移植できるようにすること 5.10.1. 移植作業者に対して協力的になる 5.10.2. 移植作業者のアップロード (porter upload) に関するガイ ドライン 5.10.3. 移植用のインフラと自動化 5.10.4. あなたのパッケージが移植可能なものではない場合 5.10.5. non-free のパッケージを auto-build 可能であるとマーク する 5.11. Non-Maintainer Upload (NMU) 5.11.1. いつ、どうやって NMU を行うか 5.11.2. NMU と debian/changelog 5.11.3. DELAYED/ キューを使う 5.11.4. メンテナの視点から見た NMU 5.11.5. ソース NMU vs バイナリのみの NMU (binNMU) 5.11.6. NMU と QA アップロード 5.11.7. NMU とチームアップロード 5.12. 共同メンテナンス 5.13. テスト版ディストリビューション 5.13.1. 基本 5.13.2. 不安定版からの更新 5.13.3. 直接テスト版を更新する 5.13.4. よく聞かれる質問とその答え (FAQ) 6. パッケージ化のベストプラクティス 6.1. debian/rules についてのベストプラクティス 6.1.1. ヘルパースクリプト 6.1.2. パッチを複数のファイルに分離する 6.1.3. 複数のバイナリパッケージ 6.2. debian/control のベストプラクティス 6.2.1. パッケージ説明文の基本的なガイドライン 6.2.2. パッケージの概要、あるいは短い説明文 6.2.3. 長い説明文 (long description) 6.2.4. 開発元のホームページ 6.2.5. バージョン管理システムの場所 6.3. debian/changelog のベストプラクティス 6.3.1. 役立つ changelog のエントリを書く 6.3.2. changelog のエントリに関するよくある誤解 6.3.3. changelog のエントリ中のよくある間違い 6.3.4. NEWS.Debian ファイルで changelog を補足する 6.4. メンテナスクリプトのベストプラクティス 6.5. debconf による設定管理 6.5.1. debconf を乱用しない 6.5.2. 作者と翻訳者に対する雑多な推奨 6.5.3. テンプレートのフィールド定義 6.5.4. テンプレートのフィールド固有スタイルガイド 6.6. 国際化 6.6.1. debconf の翻訳を取り扱う 6.6.2. ドキュメントの国際化 6.7. パッケージ化に於ける一般的なシチュエーション 6.7.1. autoconf/automake を使っているパッケージ 6.7.2. ライブラリ 6.7.3. ドキュメント化 6.7.4. 特定の種類のパッケージ 6.7.5. アーキテクチャ非依存のデータ 6.7.6. ビルド中に特定のロケールが必要 6.7.7. 移行パッケージを deboprhan に適合するようにする 6.7.8. .orig.tar.{gz,bz2,xz} についてのベストプラクティス 6.7.9. デバッグパッケージのベストプラクティス 6.7.10. メタパッケージのベストプラクティス 7. パッケージ化、そして… 7.1. バグ報告 7.1.1. 一度に大量のバグを報告するには (mass bug filing) 7.2. 品質維持の努力 7.2.1. 日々の作業 7.2.2. バグ潰しパーティ (BSP) 7.3. 他のメンテナに連絡を取る 7.4. 活動的でない、あるいは連絡が取れないメンテナに対応する 7.5. Debian 開発者候補に対応する 7.5.1. パッケージのスポンサーを行う 7.5.2. 新たな開発者を支持する (advocate) 7.5.3. 新規メンテナ申請 (new maintainer applications) を取り 扱う 8. 国際化と翻訳 8.1. どの様にして Debian では翻訳が取り扱われているか 8.2. メンテナへの I18N & L10N FAQ 8.2.1. 翻訳された文章を得るには 8.2.2. どの様にして提供された翻訳をレビューするか 8.2.3. どの様にして翻訳してもらった文章を更新するか 8.2.4. どの様にして翻訳関連のバグ報告を取り扱うか 8.3. 翻訳者への I18N & L10N FAQ 8.3.1. どの様にして翻訳作業を支援するか 8.3.2. どの様にして提供した翻訳をパッケージに含めてもらうか 8.4. l10n に関する現状でのベストプラクティス A. Debian メンテナツールの概要 A.1. 主要なツール A.1.1. dpkg-dev A.1.2. debconf A.1.3. fakeroot A.2. パッケージチェック (lint) 用ツール A.2.1. lintian A.2.2. debdiff A.3. debian/rules の補助ツール A.3.1. debhelper A.3.2. dh-make A.3.3. equivs A.4. パッケージ作成ツール A.4.1. cvs-buildpackage A.4.2. debootstrap A.4.3. pbuilder A.4.4. sbuild A.5. パッケージのアップロード用ツール A.5.1. dupload A.5.2. dput A.5.3. dcut A.6. メンテナンスの自動化 A.6.1. devscripts A.6.2. autotools-dev A.6.3. dpkg-repack A.6.4. alien A.6.5. debsums A.6.6. dpkg-dev-el A.6.7. dpkg-depcheck A.7. 移植用ツール A.7.1. quinn-diff A.7.2. dpkg-cross A.8. ドキュメントと情報について A.8.1. docbook-xml A.8.2. debiandoc-sgml A.8.3. debian-keyring A.8.4. debian-maintainers A.8.5. debview 第1章この文書が扱う範囲について     この文書の目的は、Debian 開発者に推奨される手続きと利用可能なリソ ースに関する概要を提供することにあります。 ここで取り上げる手続きには、開発者になる方法 (2章開発者になるため に応募する) 、新しいパッケージの作り方 (「新規パッケージ」) とパ ッケージをアップロードする方法 (「パッケージをアップロードする」) 、バグ報告の取扱い方 (「バグの取扱い」)、パッケージを移動、削除、     放棄 (orphan) する方法 (「パッケージの移動、削除、リネーム、放棄 、引き取り、再導入」)、パッケージ移植のやり方 (「移植作業、そして 移植できるようにすること」)他のメンテナのパッケージを暫定的にリリ ースするのは、いつどの様にしたらよいのか (「Non-Maintainer Upload (NMU)」) が含まれます。 また、このリファレンスで触れるリソースには、メーリングリスト (「 メーリングリスト」) およびサーバ (「Debian のマシン群」)、Debian アーカイブの構成に関する解説 (「Debian アーカイブ」)、パッケージ     のアップロードを受け付ける様々なサーバの説明 (「ftp-master にアッ プロードする」)、パッケージの品質を高めるために開発者が利用できる リソースについての解説 (付録A Debian メンテナツールの概要) などが あります。 初めに明らかにしておきたいのですが、このリファレンスは Debian パ ッケージに関する技術的な詳細や、Debian パッケージの作成方法を説明     するものではありません。また、このリファレンスは Debian に含まれ るソフトウェアが準拠すべき基準を詳細に解説するようなものでもあり ません。その様な情報については全て、Debian ポリシーマニュアルに記 述されています。 さらに、この文書は公式なポリシーを明らかにするものではありません     。含まれているのは Debian システムに関する記述と、一般的な合意が なされたベストプラクティスに関する記述です。すなわち「規範」文書 と呼ばれるものではない、ということです。 第2章開発者になるために応募する 2.1. さあ、はじめよう さて、あなたは全てのドキュメントを読み終え、Debian 新メンテナガイ ドを通して例題の hello パッケージがどの様になっているのか全てを理     解し、お気に入りのソフトウェアの一つを Debianize (Debian パッケー ジ化) しようとしているところです。実際のところ、どうやったら Debian 開発者になってプロジェクトに成果を受け入れてもらえるように なるのでしょうか? まず始めに、まだであれば を購読し ましょう。subscribe という単語をサブジェクトに書いた < debian-devel-REQUEST@lists.debian.org> へのメールを送ってください 。何か問題がある場合は、 のメーリン     グリスト管理者に確認をとりましょう。メーリングリストについての詳 しい情報は「メーリングリスト」で見つけられます。そして < debian-devel-announce@lists.debian.org> は、Debian の開発に携わり たいという人は誰でも読む義務がある、もう一つのメーリングリストで す。 参加後、何かコーディングを始める前に、しばらくの間「待ち」(投稿せ     ずに読むだけ) の状態でいるのが良いでしょう。それから、重複作業を 避けるために何の作業をしようとしているのか表明をする必要がありま す。 もう一つ、購読すると良いのが で     す。詳細は「Debian メンター (mentors) とスポンサー (sponsors) に ついて」を参照してください。IRC チャンネル #debian も役に立つでし ょう。「IRC チャンネル」を見てください。 何らかの方法で Debian GNU/Linux に対して貢献したいと思った時、同 じような作業に従事している既存の Debian メンテナにコンタクトして みてください。そうすれば経験豊かな開発者から学ぶことができます。 例えば、既にあるソフトウェアを Debian 用にパッケージ化するのに興 味を持っている場合、スポンサーを探しましょう。スポンサーはあなた と一緒にパッケージ化作業を手伝い、あなたの作業が満足する出来にな ったら Debian アーカイブにパッケージをアップロードしてくれます。 スポンサーは、 メーリングリスト     へパッケージとあなた自身の説明とスポンサーを探していることをメー ルして見つけましょう (詳細については「パッケージのスポンサーを行 う」および http://wiki.debian.org/DebianMentorsFaq を参照)。さら に、Debian を他のアーキテクチャやカーネルへ移植するのに興味を持っ ている場合、移植関連のメーリングリストに参加して、どうやって始め ればいいのかを尋ねましょう。最後に、ドキュメントや品質保証 (Quality Assuarance、QA) の作業に興味がある場合は、この様な作業を 行っているメンテナ達の集まりに参加して、パッチや改善案を送ってく ださい。 メールアドレスのローカルパートが非常に一般的な場合、落とし穴にハ     マる可能性があります。mail、admin、root、master のような単語は使 わないようにするべきです。詳しくは http://www.debian.org/ MailingLists/ を参照してください。 2.2. Debian メンター (mentors) とスポンサー (sponsors) について メーリングリスト が、パッケージ 化の第一歩目や他の開発者と調整が必要な問題などで手助けを必要とし     ている新米メンテナに用意されています。新たな開発者は皆、このメー リングリストに参加することをお勧めします (詳細は「メーリングリス ト」を参照してください)。 一対一での指導 (つまり、プライベートなメールのやり取りで) の方が     良い、という人もこのメーリングリストに投稿しましょう。経験豊かな 開発者が助けになってくれるはずです。 付け加えておくと、Debian にパッケージを含める準備が出来ているもの の、新規メンテナ応募作業の完了を待っているような場合は、パッケー ジをアップロードしてくれるスポンサーを探すことも出来ます。スポン     サーは公式 Debian 開発者で、あなたのパッケージに対して問題を探し たりアップロードしようとしてくれる人達です。まずは http:// wiki.debian.org/DebianMentorsFaq にある debian-mentors FAQ を読ん でください。     メンターあるいはスポンサーになりたいという人は、「Debian 開発者候 補に対応する」でより詳細な情報が手に入ります。 2.3. Debian 開発者への登録を行う Debian GNU/Linux への登録を決める前に、新メンテナのコーナーで手に 入る全ての情報に目を通してください。Debian 開発者になるための登録 をする前に必要な準備がすべて記載されています。例えば、応募の前に     Debian 社会契約を読む必要があります。開発者として登録するというこ とは、Debian 社会契約に同意し、遵守し続けることを意味します。メン テナにとって Debian GNU/Linux の背景にある根本的な理念に従うのは 大変重要な事です。GNU Manifestoを読むのも良い考えでしょう。 開発者としての登録手順は、あなたのアイデンティティと意図と技術的 なスキルレベルの確認手順でもあります。Debian GNU/Linux について作 業をする人の数は 1000 を越えて増えつづけています。そして、我々の     システムは幾多の重要な場所で使われており、セキュリティ侵害には十 分に注意しなければなりません。つまり、新たなメンテナに我々のサー バのアカウントを与えたりパッケージのアップロードを許可したりする 前には審査する必要があるのです。 実際に登録する前に、あなたは良い仕事ができる貢献者となり得ること を示さねばなりません。バグ追跡システムを介してパッチを送ったり、 既存の Debian 開発者のスポンサーによるパッケージの管理をしばらく     の間行うなどして、これをアピールします。付け加えておくと、我々は 貢献してくれる人達が単に自分のパッケージをメンテナンスするだけに ではなく、プロジェクト全体について興味を持ってくれることを期待し ています。バグについての追加情報、できればパッチの提供などによっ て他のメンテナを手助けできるのであれば、早速実行しましょう! 登録に際しては Debian の考え方と技術文書を充分理解している必要が あります。さらに、既存のメンテナに署名をしてもらった GnuPG 鍵が必 要です。まだ GnuPG 鍵に署名してもらっていない場合は、あなたの鍵に     署名してくれる Debian 開発者に会いましょう。GnuPG Key Signing Coordination page が近くの Debian 開発者を探す手助けとなるでしょ う。(近くに Debian 開発者がいない場合は、ID チェックを通過する別 の方法としてケースバイケースで例外処理として扱うことも可能です。 詳細については身分証明のページを参照してください)。 OpenPGP 鍵をまだ持っていない場合は生成してください。全ての開発者 がパッケージをアップロードする際に署名と確認の為に OpenPGP 鍵を必 要とします。必ず、使っているソフトのマニュアルを読んでおいてくだ     さい。何故ならば、セキュリティに直結している重要な情報を含んでい るからです。多くのセキュリティ事故は、殆どがソフトウェアの問題や 高度なスパイテクニックではなく、人間が犯すミスや勘違いによるもの です。公開鍵の管理についての詳細は「公開鍵をメンテナンスする」を 参照してください。 Debian では GNU Privacy Guard (gnupg パッケージ、バージョン 1 以     降) を標準として利用しています。他の OpenPGP 実装も同様に利用でき ます。OpenPGP は RFC 2440 に準拠したオープン標準です。 Debian での開発においては、バージョン 4 の鍵の利用が求められます     。鍵の長さは少なくとも 1024 ビットが必要です。それより短い鍵を利 用する理由は何もありませんし、使った場合はあまり安全ではなくなり ます。^[1] あなたの公開鍵が subkeys.pgp.net などの公開鍵サーバにない場合は、 新規メンテナ手順 2: 身分証明にあるドキュメントを読んでください。     このドキュメントにはどうやって公開鍵サーバに鍵を登録するのかが記 載されています。新規メンテナグループは、まだ登録されていない場合 はあなたの公開鍵をサーバに登録します。 幾つかの国では、一般市民の暗号関連ソフトウェアの使用について制限 をかけています。しかし、このことは暗号関連ソフトウェアを暗号化で はなく認証に利用する際には完全に合法であるような場合には、Debian     パッケージメンテナとしての活動を妨げることにはなりません。あなた が認証目的にすら暗号技術の利用が制限される国に住んでいる、と言う 場合は、我々に連絡をしていただければ特別な措置を講じることができ ます。 新規メンテナの応募をするのであれば、既存の Debian 開発者にあなた の応募をサポートしてもらう (支持者 (Advocate) になってもらう) 必     要があります。ある程度の期間 Debian に対して貢献を行った後で、登 録された開発者になるために応募をしたい場合、過去何ヶ月かに渡って 一緒に作業をした既存の開発者に、あなたが Debian に間違いなく貢献 できることを信じている旨を表明してもらう必要があります。 支持者 (Advocate) を見つけ、GnuPG 鍵に署名をしてもらい、既にある 程度の間 Debian に対して貢献的な作業をしているのであれば、応募の 準備は完了です。すぐに応募のページで登録できます。登録後、支持者     (Advocate) はあなたの応募に関してその意志を確認する必要があります 。支持者がこの手順を完了すると応募管理者 (Application Manager) に 割り当てられます。応募管理者は、新規メンテナプロセスで必要となる 手順をあなたと共に歩んでいく存在です。進捗状況については、常に applications status board のページで確認ができます。 より詳しい内容については Debian ウェブサイトの新規メンテナのコー     ナーを参考にしてください。実際の応募前に、新規メンテナプロセスで の必要な手順について詳しく理解しておいてください。十分に準備がで きていたら、後で費やす時間を大いに減らすことができます。 --------------------------------------------------------------------- ^[1] バージョン 4 の鍵は、RFC 2440 で規定されているように OpenPGP 標準に適合します。GnuPG を使って鍵を作ると、鍵のタイプは常にバー     ジョン 4 になります。PGP はバージョン 5.x からバージョン 4 の鍵を 作ることもできるようになっています。別の選択肢としては、v3 の鍵 (PGP ではレガシー RSA とも呼ばれます) と互換性のある pgp 2.6.x に なります。 バージョン 4 (primary) 鍵は RSA アルゴリズムか DSA アルゴリズムの どちらでも利用できます。つまり、GnuPG が (1) DSA and Elgamal, (2)     DSA (sign only), (5) RSA (sign only) の中からどの種類の鍵を使いた いか質問してきても何も迷うことはありません。特別な理由がない限り は単にデフォルトを選んでください。 今ある鍵が v4 の鍵なのか v3 (あるいは v2) の鍵なのかを判断するも っとも簡単な方法はフィンガープリントを見ることです。バージョン 4 鍵のフィンガープリントは、鍵要素の一部を SHA-1 ハッシュにしたもの で、通常 4 文字ごとに区切られた 40 文字の 16 進数になります。古い     バージョンの鍵形式では、フィンガープリントは MD5 を使っており、2 文字ごとに区切られた 16 進数で表示されます。例えば、あなたのフィ ンガープリントが 5B00 C96D 5D54 AEE1 206B  AF84 DE7A AF6E 94C0 9C7F のようになって いる場合は、v4 鍵です。     別のやり方として、鍵をパイプで pgpdump に渡して Public Key Packet - Ver 4 のような出力を得るという方法もあります。 もちろん、鍵が自己署名されている必要があります (つまり、全ての鍵 は所有者の ID によって署名されている必要があります。これによって     、ユーザ ID の偽造 (タンパリング) を防いでいます)。最近の OpenPGP ソフトウェアは皆これを自動的に行いますが、古い鍵を持っているよう な場合は自分でこの署名を追加する必要があるでしょう。 第3章 Debian 開発者の責務 3.1. パッケージメンテナの責務 あなたはパッケージメンテナとして、システムにうまく適合し、Debian     ポリシーにしっかり則っている高品質のパッケージを提供していること でしょう。 3.1.1. 次期安定版 (stable) リリースへの作業 高品質のパッケージを不安定版 (unstable) へ提供するだけでは十分で はありません。多くのユーザは、パッケージが次期安定版 (stable) の     一部としてリリースされた時にのみ、その恩恵を受けるからです。です から、パッケージが次期の安定版 (stable) に含まれるようにリリース チームと上手く共同で作業することが期待されています。 より具体的には、パッケージがテスト版 (testing) に移行しているかど うかを見守る必要があります (「テスト版ディストリビューション」参 照) 。テスト期間後に移行が行われない場合は、その理由を分析してこ れを修正する必要があります。(リリースクリティカルバグや、いくつか のアーキテクチャでビルドに失敗する場合) あなたのパッケージを修正     するのが必要な場合もありますし、依存関係でパッケージが絡まってい る状態からの移行を完了する手助けとして、他のパッケージを更新 (あ るいは修正、またはテスト版 (testing) からの削除) が必要な事を意味 する場合もあります。障害となる理由 (blocker) を判別できない場合は 、リリースチームが先の移行に関する現在の障害に関する情報を与えて くれることでしょう。 3.1.2. 安定版 (stable) にあるパッケージをメンテナンスする パッケージメンテナの作業の大半は、パッケージの更新されたバージョ     ンを不安定版 (unstable) へ放り込むことですが、現状の安定版 (stable) リリースのパッケージの面倒をみることも伴っています。 安定版 (stable) への変更は推奨されてはいませんが、可能です。セキ ュリティ問題が報告された時はいつでも、セキュリティチームと修正版 を提供するように協力する必要があります (「セキュリティ関連バグの 取扱い」参照)。important (あるいはそれ以上) な重要度のバグが安定     版 (stable) のバージョンのパッケージに報告されたら、対象となる修 正の提供を検討する必要があります。安定版 (stable) リリースマネー ジャに、そのような更新を受け入れられるかどうかを尋ね、それから安 定版 (stable) のアップロードを準備するなどができます (「特別な例: 安定版 (stable) と旧安定版 (oldstable) ディストリビューションへア ップロードする」参照)。 3.1.3. リリースクリティカルバグに対処する 大抵の場合、パッケージに対するバグ報告については「バグの取扱い」 で記述されているように対応する必要があります。しかしながら、注意 を必要とする特別なカテゴリのバグがあります—リリースクリティカルバ グ (RC bug) と呼ばれるものです。critical、grave、serious の重要度 が付けられている全てのバグ報告によって、そのパッケージは次の安定     版 (stable) リリースに含めるのには適切ではないとされます。そのた め、(テスト版 (testing) にあるパッケージに影響する場合に) Debian のリリースを遅らせたり、(不安定版 (unstable) にあるパッケージにの み影響する場合に) テスト版 (testing) への移行をブロックする可能性 があります。最悪の場合は、パッケージの削除を招きます。これが RC バグを可能な限り素早く修正する必要がある理由です。 もし、何らかの理由で 2 週間以内に RC バグを修正できない場合 (例え ば時間の制約上、あるいは修正が難しいなど)、明示的にバグ報告にそれ を述べて、他のボランティアを招き入れて参加してもらうためにバグに     help タグを打ってください。大量のパッケージがテスト版 (testing) へ移行するのを妨げることがあるので、RC バグは頻繁に Non-Maintainer Upload の対象になることに注意してください (「 Non-Maintainer Upload (NMU)」参照)。 RC バグへの関心の無さは、しばしば QA チームによって、メンテナが正 しくパッケージを放棄せずに消えてしまったサインとして判断されます     。MIA チームが関わることもあり、その場合はパッケージが放棄されま す (「活動的でない、あるいは連絡が取れないメンテナに対応する」参 照)。 3.1.4. 開発元/上流 (upstream) の開発者との調整 Debian メンテナとしての仕事のうちで重要な位置を占めるのは、開発元 /上流 (upstream) の開発者との窓口であることです。Debian ユーザは     、時折バグ報告システムに Debian 特有ではないバグを報告する事があ ります。Debian メンテナは、いつか上流のリリースで修正できるように する為、このようなバグ報告を上流の開発者に転送しなくてはなりませ ん。 Debian 固有ではないバグの修正はあなたの義務ではないとはいえ、でき るなら遠慮なく修正してください。そのような修正を行った際は、上流     の開発者にも送ってください。時折 Debian ユーザ／開発者が上流のバ グを修正するパッチを送ってくる事があります。その場合は、あなたは パッチを確認して上流へ転送する必要があります。 ポリシーに準拠したパッケージをビルドするために上流のソースに手を 入れる必要がある場合、以降の上流でのリリースにおいて手を入れなく     ても済むために、ここで含まれる修正を上流の開発者にとって良い形で 提案する必要があります。必要な変更が何であれ、上流のソースからフ ォークしないように常に試みてください。 開発元の開発者らが Debian やフリーソフトウェアコミュニティに対し て敵対的である、あるいは敵対的になってきているのを見つけた場合は     、ソフトウェアを Debian に含める必要があるかを再考しなければなら なくなるでしょう。時折 Debian コミュニティに対する社会的なコスト は、そのソフトウェアがもたらすであろう利益に見合わない場合があり ます。 3.2. 管理者的な責務 Debian のような大きさのプロジェクトは、あらゆる事を追いかけられる     管理者用のインフラに依っています。プロジェクトメンバーとして、あ らゆる物事が滞り無く進むように、あなたにはいくつかの義務がありま す。 3.2.1. あなたの Debian に関する情報をメンテナンスする Debian 開発者に関する情報が含まれた LDAP データベースが https:// db.debian.org/ にあります。ここに情報を入力して、情報に変更があっ     た際に更新する必要があります。特に、あなたの debian.org アドレス 宛メールの転送先アドレスが常に最新になっているのを必ず確認してく ださい。debian-private の購読をここで設定した場合、そのメールを受 け取るアドレスについても同様です。     データベースについての詳細は「開発者データベース」を参照してくだ さい。 3.2.2. 公開鍵をメンテナンスする 秘密鍵の取扱いには十二分に注意してください。Debian サーバ (「 Debian のマシン群」参照) のような公開サーバや複数のユーザがいるマ     シンには置かないようにしてください。鍵をバックアップして、コピー はオフラインな場所に置きましょう。ソフトウェアの使い方については 付属のドキュメントを参照してください。PGP FAQ を読みましょう。 鍵が盗難に対してだけではなく、紛失についても安全であることを保証     する必要があります。失効証明書 (revocation certificate) を生成し てコピーを作って下さい (紙にも出力しておくのがベストです)。これは 鍵を紛失した場合に必要になります。 公開鍵に対して、署名したり身元情報を追加したりなどしたら、鍵を     keyring.debian.org の鍵サーバに送付することで Debian key ring を 更新できます。 まったく新しい鍵を追加したりあるいは古い鍵を削除したりする必要が ある時は、別の開発者に署名された新しい鍵が必要になります。以前の 鍵が侵害されたり利用不可能になった場合には、失効証明書     (revocation certificate) も追加する必要があります。新しい鍵が本当 に必要な理由が見当たらない場合は、Keyring メンテナは新しい鍵を拒 否することがあります。詳細は http://keyring.debian.org/ replacing_keys.html で確認できます。     同様に鍵の取り出し方について「Debian 開発者への登録を行う」で説明 されています。     Debian での鍵のメンテナンスについて、より突っ込んだ議論を debian-keyring パッケージ中のドキュメントで知ることができます。 3.2.3. 投票をする Debian は本来の意味での民主主義ではありませんが、我々はリーダーの     選出や一般投票の承認において民主主義的なプロセスを利用しています 。これらの手続きについては、Debian 憲章で規程されています。 毎年のリーダー選挙以外には、投票は定期的には実施されず、軽々しく 提案されるものではありません。提案はそれぞれ <     debian-vote@lists.debian.org> メーリングリストでまず議論され、プ ロジェクトの書記担当者が投票手順を開始する前に複数のエンドースメ ントを必要とします。 書記担当者が 上で複数回 投票の呼びかけを行うので、投票前の議論を追いかける必要はありませ     ん (全開発者がこのメーリングリストを購読することが求められていま す)。民主主義は、人々が投票に参加しないと正常に機能しません。これ が我々が全ての開発者に投票を勧める理由です。投票は GPG によって署 名／暗号化されたメールによって行われます。 (過去と現在の) 全ての提案リストが Debian 投票情報ページで閲覧でき     ます。提案について、どの様に起案され、支持され、投票が行われたの かという関連情報の確認が可能になっています。 3.2.4. 優雅に休暇を取る 予定していた休暇にせよ、それとも単に他の作業で忙しいにせよ、開発 者が不在になることがあるのはごく普通のことです。注意すべき重要な     点は、他の開発者達があなたが休暇中であるのを知る必要があることと 、あなたのパッケージについて問題が起こった場合やプロジェクト内で の責務を果たすのに問題が生じたという様な場合は、必要なことを彼ら が何であってもできるようにすることです。 通常、これはあなたが休暇中にあなたのパッケージが大きな問題 (リリ ースクリティカルバグやセキュリティ更新など) となっている場合に、     他の開発者に対して NMU (「Non-Maintainer Upload (NMU)」参照) を許 可することを意味しています。大抵の場合はそれほど致命的なことはお きませんが、他の開発者に対してあなたが作業できない状態であること を知らせるのは重要です。 他の開発者に通知するために行わなければならないことが 2 つあります     。まず、 にサブジェクトの先頭に [VAC] と付けたメールを送り^[2]、いつまで休暇なのかを示しておきま す。何か問題が起きた際への特別な指示を書いておくこともできます。 他に行うべき事は Debian developers' LDAP database 上であなたを     vacation とマークする事です (この情報は Debian 開発者のみがアクセ スできます)。休暇から戻った時には vacation フラグを削除するのを忘 れないように! 理想的には、休暇にあわせて GPG coordination pages に登録して、誰     かサインを希望している人がいるかどうかをチェックします。開発者が まだ誰もいないけれども応募に興味を持っている人がいるようなエキゾ チックな場所に行く場合、これは特に重要です。 3.2.5. 脱退について     Debian プロジェクトから去るのを決めた場合は、以下の手順に従ってく ださい: 1. 「パッケージを放棄する」の記述に従って、全てのパッケージを放 棄 (orphan) してください。 2. 何故プロジェクトを去るのかについて GPG でサインされたメールを     に投げてください。 3. 'Debian RT' という単語 (大文字小文字は関係なし) がサブジェク トのどこかに入ったメールを に投げて Debian RT でチケットをオープンして、あなたがプロジェクトを去 るのを Debian key ring メンテナに知らせてください。 上記のプロセスに従うのは重要です。何故なら活動を停止している開発     者を探してパッケージを放棄するのは、非常に時間と手間がかかること だからです。 3.2.6. リタイア後に再加入する リタイアした開発者のアカウントは、「脱退について」の手続きが開始     された際に「emeritus」であるとマークされ、それ以外の場合は「 disabled」となります。「emeritus」アカウントになっているリタイア した開発者は、以下のようにすればアカウントを再度有効にできます: * に連絡を取ります * 短縮された NM プロセスを通過します (リタイアした開発者が P&P     および T&S の肝心な部分を覚えているのを確認するためです)。 * アカウントに紐付けられた GPG 鍵を今でも管理していることを証明 する、あるいは新しい GPG 鍵について、他の開発者から少なくとも 2 つの署名を受けることにより身分証明を行う。     リタイアした開発者で「disabled」アカウントの人は、NM をもう一度通 り抜ける必要があります。 ---------------------------------------------------------------------     ^[2] これは、休暇のメッセージを読みたくない人がメッセージを簡単に 振り分け可能にするためです。 第4章 Debian 開発者が利用可能なリソース この章では、Debian メーリングリストについてのおおよその概略、開発     者であるあなたが利用できるであろう Debian マシン、メンテナとして の作業で役立つその他全ての利用可能なリソースを確認します。 4.1. メーリングリスト Debian 開発者 (それにユーザ) の間で交わされるやり取りの大半は lists.debian.org で提供されている広範囲に渡るメーリングリスト群で 行われています。どうやって購読／解除するのか、どうやって投稿する     か（あるいはしないのか）、どこで過去の投稿を見つけるのか、どうや って過去の投稿の中から探すのか、どうやってメーリングリスト管理者 と連絡をとるのか、その他メーリングリストに関する様々な情報につい ては http://www.debian.org/MailingLists/ を参照してください。 4.1.1. 利用の基本ルール メーリングリストのメッセージに返信する際には、大本の投稿者が特別     に要求しない限り、同報メール (CC) を送らないようにしてください。 メーリングリストに投稿する人は必ず返信を見ているはずです。 クロスポスト (同じメッセージを複数のメーリングリストに投稿する)     のはお止め下さい。いつものネット上と同じ様に、返信文では引用を削 って下さい。概して投稿するメッセージについては、通常の慣習をしっ かりと守ってください。     詳細については行動規範を参照してください。Debian コミュニティガイ ドラインも読むと良いでしょう。 4.1.2. 開発の中心となっているメーリングリスト     開発者が利用すべき Debian の中核メーリングリスト: * は開発者に重要な事を 伝える際に使われます。全開発者がこのメーリングリストを購読す る事が望まれます。 * は様々な技術関連の事柄を話し     合うのに使われます。 * は Debian ポリシーについて話 し合い、それに対して投票を行うのに使われます。 * はプロジェクトに関する様々 な非技術関連の事柄を話し合うのに使われます。     他にも様々な事柄に特化したメーリングリストが利用できます。一覧に ついては http://lists.debian.org/ を参照してください。 4.1.3. 特別なメーリングリスト は Debian 開発者間でのプライベ ートな話し合い用に使う特別なメーリングリストです。つまり、理由が なんであれここに投稿された文章は公開するべきではないものであるこ とを意味しています。このため、これは流量が少ないメーリングリスト で、ユーザは本当に必要でない限りは <     debian-private@lists.debian.org> を使わないように勧められています 。さらに、このメーリングリストから誰かへメールを転送してはいけま せん。様々な理由からこのメーリングリストのアーカイブはウェブから 見ることはできませんが、master.debian.org 上のシェルアカウントを 使って ~debian/archive/debian-private/ ディレクトリを参照すること で確認できます。 は、特別なメーリングリストです。 ライセンス、バグ、その他について upstream の作者にコンタクトを取     る、他の人とプロジェクトについて議論した内容をアーカイブしておく のに役立つ Debian に関するメールをまとめた「福袋」として使われて います。 4.1.4. 新規に開発関連のメーリングリストの開設を要求する パッケージ (や関連する小さなパッケージ群) の開発に関するメーリン グリストの開設をリクエストをする前に、エイリアスを利用するのを検     討してください (master.debian.org 上で .forward-aliasname ファイ ルを使うと、きちんと you-aliasname@debian.org アドレスに適切に変 換してくれます)。あるいは、Alioth 上で自分で管理するメーリングリ ストを使いましょう。     lists.debian.org 上での通常のメーリングリストが本当に必要であると 決意した場合は、HOWTO に従って進めてリクエストを埋めてください。 4.2. IRC チャンネル いくつもの IRC チャンネルが Debian の開発のために用意されています     。チャンネルは主に Open and free technology community (OFTC) のネ ットワーク上にホストされています。irc.debian.org の DNS エントリ は irc.oftc.net へのエイリアスです。 Debian 用のメインのチャンネルは一般的にいって #debian になります 。これは巨大な、多目的のチャンネルで、ユーザがトピックやボットに     よって提供される最近のニュースを見つけることができる場所です。# debian は英語を話す人たち用のもので、他の言語を話す人達のために同 様なものには #debian.de、#debian-fr、#debian-br など他にも似通っ た名前のチャンネルがあります。 Debian 開発での中心のチャンネルは #debian-devel です。これはとて もアクティブなチャンネルで、大抵 150 人以上が常にログインしていま す。このチャンネルは Debian で作業する人達のためのチャンネルであ     って、サポート用のチャンネルではありません (そのためには #debian があります)。このチャンネルは、こっそり覗いてみたい (そして学びた い) 人に対してもオープンでもあります。このチャンネルのトピックは 、開発者にとって興味深い情報に溢れています。 #debian-devel は公開チャンネルなので、< debian-private@lists.debian.org> で話されている話題について触れる     べきではありません。この目的の為には、#debian-private という鍵で 守られた他のチャンネルがあります。この鍵は master.debian.org:~debian/archive/debian-private/ で取得可能です 。 他にも、特定の話題について専用のチャンネルがあります。# debian-bugs は、バグ潰しパーティ (BSP) を開催するために使われます 。#debian-boot は、debian-installer の作業を調整するのに利用され     ています。#debian-doc は、今あなたが読んでいるような文章のドキュ メント化について話すために時折使われています。アーキテクチャやパ ッケージ群について話すため、他にも専用チャンネルがあります：# debian-kde、#debian-dpkg、#debian-jr、#debian-edu、#debian-oo (OpenOffice.org パッケージ) など… 同様に非英語圏の開発者のチャンネルも存在しています。例えば #     debian-devel-fr は Debian の開発に興味があるフランス語を使う人々 のためのチャンネルです。 Debian 専用のチャンネルが他の IRC ネットワーク上にもあります。特     に freenode IRC ネットワークは、2006 年 6 月 4 日まで irc.debian.org のエイリアスでした。 freenode でクローク担当に手助けしてもらうには、Jörg Jaspert さんに対して、利用する nick (ニックネーム) を 書いて GPG 署名したメールを送ります。メールの Subject: ヘッダのど     こかに cloak の文字を入れてください。nick は登録をする必要があり ます：ニックネームの設定の仕方を書いたページを参照下さい。メール は Debian keyring にある鍵でサインされている必要があります。クロ ーク担当についての詳細は Freenode のドキュメントを参照してくださ い。 4.3. ドキュメント化 このドキュメントは Debian 開発者にとって有用な情報をたくさん含ん     でいますが、全てを含めることは出来ていません。他の有用なドキュメ ントが開発者のコーナーからリンクされています。時間を取ってリンク を全部眺めれば、より多くの事柄を学べるでしょう。 4.4. Debian のマシン群 Debian ではサーバとして動いている複数のコンピュータがあり、この多     くは Debian プロジェクトにおいて重要な役割を果たしています。マシ ンの大半は移植作業に利用されており、全てインターネットに常時接続 されています。     マシンのうち幾つかは、Debian マシン利用ポリシーで定められたルール に従う限り、個々の開発者の利用が可能となっています。 とにかく、これらのマシンをあなたが Debian 関連の目的に合うと思っ たことに利用できます。システム管理者には丁寧に接し、システム管理     者からの許可を最初に得ることなく、非常に大量のディスク容量／ネッ トワーク帯域／CPU を消費しないようにしてください。大抵これらのマ シンはボランティアによって運用されています。 Debian で利用しているパスワードと Debian のマシンにインストールし     てある SSH 鍵を保護することに注意してください。ログインやアップロ ードの際にパスワードをインターネット越しに平文で送るような Telnet や FTP や POP などの利用方法は避けてください。     あなたが管理者でも無い限り、Debian サーバ上には Debian に関連しな いものを一切置かないようにしてください。 Debian のマシン一覧は http://db.debian.org/machines.cgi で確認可     能です。このウェブページはマシン名、管理者の連絡先、誰がログイン 可能か、SSH 鍵などの情報を含んでいます。 Debian サーバでの作業について問題があり、システム管理者らに知らせ る必要があると考えた場合は、https://rt.debian.org/ にあるリクエス トトラッカーの DSA キューで公開されている問題のリストを確認できま     す ("debian" ユーザと master.debian.org:~debian/misc/rt-password にあるパスワードでログインできます)。新たな問題を報告するには、単 に にメールを送ってください。"Debian RT" を サブジェクトのどこかに入れるのを忘れずに。 システム管理に関連しない、特定のサービスについて問題がある場合 (アーカイブからパッケージを削除する、ウェブサイトの改善提案など)     は、大抵の場合「擬似パッケージ」に対してバグを報告することになり ます。どうやってバグ報告をするかについては「バグ報告」を参照して ください。     中心となっているサーバのうち幾つかは利用が制限されていますが、そ こにある情報は他のサーバへミラーされています。 4.4.1. バグ報告サーバ     bugs.debian.org がバグ報告システム (BTS) の中心となっています。 Debian のバグについて定量的な分析や処理をするような計画がある場合     、ここで行ってください。ですが、不要な作業の重複や処理時間の浪費 を減らすため、何であれ実装する前に であなたの計画を説明してください。 4.4.2. ftp-master サーバ ftp-master.debian.org サーバは、Debian アーカイブのコピーの中心位     置を占めています。通常、ftp.upload.debian.org へアップロードされ たパッケージは最終的にはこのサーバにあります。「パッケージをアッ プロードする」を参照してください。     このサーバの利用は制限されています。ミラーが ries.debian.org 上で 利用可能です。 Debian FTP アーカイブについて問題がある場合、通常 ftp.debian.org     擬似パッケージに対するバグ報告を行うか、 へ メールをする必要がありますが、「パッケージの移動、削除、リネーム 、放棄、引き取り、再導入」にある手順も参照してください。 4.4.3. www-master サーバ     メインの web サーバが www-master.debian.org です。公式 web ページ を持ち、新たな参加者に対する Debian の顔となっています。 Debian のウェブサーバについて問題を見つけた場合、大抵の場合は擬似     パッケージ www.debian.org に対してバグを報告する必要があります。 誰か他の人が既にバグ追跡システムに問題を報告していないかどうかチ ェックするのを忘れないようにしてください。 4.4.4. people ウェブサーバ     people.debian.org は、開発者個人の何か Debian に関連するウェブペ ージのために使われているサーバです。 ウェブに置きたい何か Debian 特有の情報を持っている場合、     people.debian.org 上のホームディレクトリの public_html 以下にデー タを置くことでこれが可能となっています。これには http:// people.debian.org/~your-user-id/ という URL でアクセス可能です。 他のホストではバックアップされないのに対して、ここではバックアッ     プされるので、これを使うのは特定の位置づけのものだけにするべきで す。 大抵の場合、他のホストを使う唯一の理由はアメリカの輸出制限に抵触     する素材を公開する必要がある時です。その様な場合はアメリカ国外に 位置する他のサーバのどれかを使えます。     何か質問がある場合は、 にメールし て下さい。 4.4.5. VCS (バージョン管理システム) サーバ あなたが行っている Debian に関連する作業にバージョン管理システム が必要であれば、Alioth にホストされている既存のリポジトリを使うこ とも新しいプロジェクトを作って、それにあなたが選んだ VCS のリポジ トリを要求することも可能です。Alioth は CVS (cvs.alioth.debian.org/cvs.debian.org)、Subversion     (svn.debian.org)、Arch (tla/baz、共に arch.debian.org 上)、Bazaar (bzr.debian.org)、Darcs (darcs.debian.org)、Mercurial (hg.debian.org) そして Git (git.debian.org)をサポートしています。 パッケージを VCS リポジトリ上でメンテナンスする予定であれば、 Alioth で提供されているサービスについての詳細は「Debian での FusionForge の導入例: Alioth」を参照してください。 4.4.6. 複数のディストリビューション利用のために chroot を使う     幾つかのマシン上では、異なったディストリビューション用の chroot が利用可能です。以下の様にして使うことが出来ます：     vore$ dchroot unstable Executing shell in chroot: /org/vore.debian.org/chroots/user/unstable 全ての chroot 環境内で、一般ユーザの home ディレクトリが利用可能     になっています。どの chroot が利用可能かについては http:// db.debian.org/machines.cgi にて確認ができます。 4.5. 開発者データベース https://db.debian.org/ にある開発者データベースは、Debian 開発者 のアトリビュートを操作する LDAP ディレクトリです。このリソースは     Debian 開発者リストの検索に使えます。この情報の一部は Debian サー バの finger サービスを通じても利用可能になっています。finger yourlogin@db.debian.org として何が返ってくるかを確認してみてくだ さい。     開発者らは、以下に挙げるような自身に関する様々な情報を変更するた めにデータベースにログインができます。 * debian.org アドレス宛のメールを転送するアドレス * debian-private の購読 * 休暇中かどうか     * 住所、国名、Debian 開発者世界地図で使われている住んでいる地域 の緯度経度、電話・ファックス番号、IRC でのニックネーム、そし てウェブページのアドレスなどの個人情報 * Debian プロジェクトのマシン上でのパスワードと優先的に指定する シェル 当然ですが、ほとんどの情報は外部からはアクセス可能にはなっていま     せん。より詳細な情報については、http://db.debian.org/ doc-general.html で参照できるオンラインドキュメントを読んでくださ い。 開発者は公式 Debian マシンへの認証に使われる SSH 鍵を登録すること     もできますし、新たな *.debian.net の DNS エントリの追加すら可能で す。これらの機能は http://db.debian.org/doc-mail.html に記述され ています。 4.6. Debian アーカイブ Debian GNU/Linux ディストリビューションは大量のパッケージ (現在約     15000 個) と幾つかの追加ファイル (ドキュメントやインストール用デ ィスクイメージなど) から成り立っています。     以下が完全な Debian アーカイブのディレクトリツリーの例です： dists/stable/main/ dists/stable/main/binary-amd64/ dists/stable/main/binary-armel/ dists/stable/main/binary-i386/ ... dists/stable/main/source/ ... dists/stable/main/disks-amd64/ dists/stable/main/disks-armel/ dists/stable/main/disks-i386/ ... dists/stable/contrib/ dists/stable/contrib/binary-amd64/ dists/stable/contrib/binary-armel/ dists/stable/contrib/binary-i386/ ... dists/stable/contrib/source/ dists/stable/non-free/ dists/stable/non-free/binary-amd64/ dists/stable/non-free/binary-armel/ dists/stable/non-free/binary-i386/ ... dists/stable/non-free/source/ dists/testing/ dists/testing/main/     ... dists/testing/contrib/ ... dists/testing/non-free/ ... dists/unstable dists/unstable/main/ ... dists/unstable/contrib/ ... dists/unstable/non-free/ ... pool/ pool/main/a/ pool/main/a/apt/ ... pool/main/b/ pool/main/b/bash/ ... pool/main/liba/ pool/main/liba/libalias-perl/ ... pool/main/m/ pool/main/m/mailx/ ... pool/non-free/f/ pool/non-free/f/firmware-nonfree/ ... 見て分かるように、一番上のディレクトリは dists/ と pool/ という 2 つのディレクトリを含んでいます。後者の “pool” はパッケージが実際 に置かれており、アーカイブのメンテナンスデータベースと関連するプ ログラムによって利用されます。前者にはstable、testing、そして     unstable というディストリビューションが含まれます。ディストリビュ ーションサブディレクトリ中の Packages および Sources ファイルは pool/ ディレクトリ中のファイルを参照しています。以下の各ディスト リビューションのディレクトリツリーは全く同じ形式になっています。 以下で stable について述べていることは unstable や testing ディス トリビューションにも同様に当てはまります。     dists/stable は、main、contrib、non-free という名前の 3 つのディ レクトリを含んでいます。 それぞれ、source パッケージ (source) のディレクトリとサポートして     いる各アーキテクチャ (binary-i386、binary-amd64 など) のディレク トリがあります。 main は特定のアーキテクチャ (disks-i386、disks-amd64 など)上で     Debian ディストリビューションをインストールする際に必要となるディ スクイメージと主要なドキュメントの基本部分が入っている追加ディレ クトリを含んでいます。 4.6.1. セクション Debian アーカイブの main セクションは公式な Debian GNU/Linux ディ ストリビューションを構成するものです。main セクションが公式なのは     、我々のガイドライン全てに合致するものであるからです。他の 2 つの セクションはそうではなく、合致は異なる程度となっています…つまり、 Debian GNU/Linux の公式な一部ではありません。 main セクションにある全てのパッケージは、Debian フリーソフトウェ アガイドライン (DFSG) 及び Debian ポリシーマニュアルに記載されて     いる他のポリシーの要求事項に完全に適合していなければなりません。 DFSG は我々の定義する「フリーソフトウェア」です。詳細は Debian ポ リシーマニュアルを確認してください。 contrib セクションにあるパッケージは DFSG に適合している必要があ     りますが、他の要求事項を満たせてはいないことでしょう。例えば、 non-free パッケージに依存している、などです。 DFSG を満たさないパッケージは non-free セクションに配置されます。 これらのパッケージは Debian ディストリビューションの一部としては     考えられてはいませんが、我々はこれらを利用できるようにしており、 non-free ソフトウェアのパッケージについて (バグ追跡システムやメー リングリストなどの) インフラストラクチャを提供しています。     Debian ポリシーマニュアルは 3 つのセクションについてより正確な定 義を含んでいます。上記の説明はほんの触りに過ぎません。 アーカイブの最上位階層で 3 つのセクションに別れていることは、イン ターネット上の FTP サーバ経由であれ、CD-ROM であれ、Debian を配布     したいと考える人にとって大事なことです…その様な人は main セクショ ンと contrib セクションのみを配布することで、法的なリスクを回避で きます。例えば、non-free セクションにあるパッケージのいくつかは商 的な配布を許可していません。 その一方で、CD-ROMベンダは non-free 内のパッケージ群の個々のパッ     ケージライセンスを簡単に確認でき、問題が無ければその多くを CD-ROM に含めることが出来ます。(これはベンダによって大いに異なるので、こ の作業は Debian 開発者にはできません)。 セクションという用語は、利用可能なパッケージの構成や参照を簡単に しているカテゴリを指すことにも使われている点に注意ください。例え     ば、admin、net、utils などです。昔々、これらのセクション (むしろ サブセクション) はDebian アーカイブ内のサブディレクトリとして存在 していました。最近では、これらはパッケージのセクションヘッダにの み存在しています。 4.6.2. アーキテクチャ はじめのうちは、Linux カーネルは Intel i386 (またはそれより新し い) プラットフォーム用のみが利用可能で、Debian も同様でした。しか し、Linux は日に日に広まり、カーネルも他のアーキテクチャへと移植     され、そして Debian はそれらのサポートを始めました。そして、沢山 のハードウェアをサポートするだけでは飽き足らず、Debian は hurd や kfreebsd のような他の Unix カーネルをベースにした移植版を作成する ことを決めました。 Debian GNU/Linux 1.3 では i386 のみが利用可能でした。Debian 2.0 では、i386 と m68k アーキテクチャがリリースされました。Debian 2.1 では、i386、m68k、alpha、そして sparc アーキテクチャがリリースさ     れました。そして、Debian は巨大に成長しました。Debian 6 は、合計 9 個の Linux アーキテクチャ (amd64, armel, i386, ia64, mips, mipsel, powerpc, s390, sparc、そして 2 つの kFreeBSD アーキテクチ ャ (kfreebsd-i386 および kfreebsd-amd64) をサポートしています。     特定の移植版についての開発者／ユーザへの情報は Debian 移植版のウ ェブページで入手可能です。 4.6.3. パッケージ     Debian パッケージには２種類あります。ソースパッケージとバイナリパ ッケージです。 フォーマットに応じて、ソースパッケージは必須の .dsc ファイルに加 え、一つあるいはそれ以上のファイルから成り立ちます: * フォーマット ”1.0”では、.tar.gz ファイルか、.orig.tar.gz ファ イルと .diff.gz ファイルの二つを持っています。     * フォーマット“3.0 (quilt)”では、必須となる開発元の tarball で ある .orig.tar.{gz,bz2,xz}、それからオプションで、開発元の追 加 tarball である .orig-component.tar.{gz,bz2,xz} をいくつか 、そして必須の debian tarball、debian.tar.{gz,bz2,xz} です。 * フォーマット“3.0 (native)”では、単一の .tar.{gz,bz2,xz} tarball のみを持っています。 パッケージが特に Debian 用に作られていて Debian 以外で利用されて いない場合は、プログラムのソースを含んだ単純な 1 つの .tar. {gz,bz2,xz} ファイルがあるだけで、“native”ソースパッケージと呼ば れます。パッケージが他でも配布されている場合は、.orig.tar.     {gz,bz2,xz} は upstream ソースコードと呼ばれるものを保持していま す (訳注: upstream = 開発元)。upstream ソースコードは upstream メ ンテナ (大抵の場合はソフトウェアの作者) によって配布されているソ ースコードです。この場合、.diff.gz やdebian.tar.{gz,bz2,xz} は、 Debian パッケージメンテナによって加えられた変更を含んでいます。 .dsc ファイルはソースパッケージ中のすべてのファイルをチェックサム     (md5sums) と共にリストしたものと、パッケージ関連の追加情報 (メン テナ、バージョン、etc) を含んでいます。 4.6.4. ディストリビューション 前章で説明したディレクトリシステムは、それ自体がディストリビュー     ションディレクトリ内に含まれています。それぞれのディストリビュー ションは、実際には Debian アーカイブ自体の最上位階層の pool ディ レクトリに含まれています。 簡単にまとめると、Debian アーカイブは FTP サーバのルートディレク トリを持っています。例えば、ミラーサイトでいうと     ftp.us.debian.org では Debian アーカイブそのものは /debian に含ま れており、これは共通した配置となっています (他には /pub/debian が あります)。 ディストリビューションは Debian ソースパッケージとバイナリパッケ ージと、これに対応した Sources と Packages のインデックスファイル     (これら全てのパッケージのヘッダ情報を含む) から構成されています。 前者は pool/ ディレクトリに、そして後者はアーカイブの dists/ ディ レクトリに含まれています (後方互換性のため)。 4.6.4.1. 安定版 (stable)、テスト版 (testing)、不安定版 (unstable) 常に安定版 (stable) (dists/stable に属します)、テスト晩 (testing)     (dists/testing に属します)、不安定版 (unstable) (dists/unstable に属します) と呼ばれるディストリビューションが存在しています。こ れは Debian プロジェクトでの開発プロセスを反映しています。 活発な開発が不安定版 (unstable) ディストリビューションで行われて います (これが、何故このディストリビューションが開発ディストリビ ューションと呼ばれることがあるかという理由です)。全ての Debian 開     発者は、このディストリビューション内の自分のパッケージを何時でも 更新できます。つまり、このディストリビューションの内容は日々変化 しているのです。このディストリビューションの全てが正しく動作する かを保証することについては特別な努力は払われていないので、時には 文字通り不安定 (unstable) となります。 テスト版 (testing) ディストリビューションは、パッケージが特定の判 定規準を満たした際に不安定版から自動的に移動されることで生成され     ています。この判定規準はテスト版に含まれるパッケージとして十分な 品質であることを保証する必要があります。テスト版への更新は、新し いパッケージがインストールされた後、毎日 2 回実施されています。「 テスト版ディストリビューション」を参照してください。 一定の開発期間後、リリースマネージャが適当であると決定すると、テ スト版 (testing) ディストリビューションはフリーズされます。これは 、不安定版 (unstable) からテスト版 (testing) へのパッケージ移動を どのように行うかのポリシーがきつくなることを意味しています。バグ が多すぎるパッケージは削除されます。バグ修正以外の変更がテスト版 (testing) に入ることは許可されません。いくらかの時間経過後、進行 状況に応じてテスト版 (testing) ディストリビューションはより一層フ     リーズされます。テスト版ディストリビューションの取扱い詳細につい ては debian-devel-announce にてリリースチームが発表します。リリー スチームが満足する程度に残っていた問題が修正された後、ディストリ ビューションがリリースされます。リリースは、テスト版 (testing) が 安定版 (stable) へとリネームされる事を意味しており、テスト版 (testing) 用の新しいコピーが作成され、以前の安定版 (stable) は旧 安定版 (oldstable) にリネームされ、最終的にアーカイブされるまで存 在しています。アーカイブ作業では、コンテンツは archive.debian.org へと移動されます。 この開発サイクルは、不安定版 (unstable) ディストリビューションが 、一定期間テスト版 (testing)を過ごした後で安定版 (stable)になる仮 定に基づいています。一旦ディストリビューションが安定したと考えら れたとしても、必然的にいくつかのバグは残っています — これが安定版 ディストリビューションが時折更新されている理由です。しかし、これ らの更新はとても注意深くテストされており、新たなバグを招き入れる     リスクを避けるためにそれぞれ個々にアーカイブに収録されるようにな っています。安定版 (stable) への追加提案は、proposed-updates ディ レクトリにて参照可能です。proposed-updates にある合格したこれらの パッケージは、定期的にまとめて安定版ディストリビューションに移動 され、安定版ディストリビューションのリビジョンレベルが 1 つ増える ことになります (例: ‘6.0’ が ‘6.0.1’ に、‘5.0’ が ‘5.0.8’ に、以 下同様)。詳細に付いては、安定版 (stable) ディストリビューションへ のアップロードを参照してください。 不安定版 (unstable)での開発はフリーズ期間中も続けられていることに     注意してください。不安定版 (unstable) ディストリビューションはテ スト版 (testing) とは平行した状態でありつづけているからです。 4.6.4.2. テスト版ディストリビューションについてのさらなる情報 パッケージは通常、不安定版 (unstable) におけるテスト版への移行基     準を満たした後でテスト版 (testing) ディストリビューションへとイン ストールされます。     より詳細については、テスト版ディストリビューションについての情報 を参照してください。 4.6.4.3. 試験版 (experimental) 試験版 (experimental) は特殊なディストリビューションです。これは 、`安定版' や `不安定版' と同じ意味での完全なディストリビューショ ンではありません。その代わり、ソフトウェアがシステムを破壊する可 能性がある、あるいは不安定版ディストリビューションに導入すること ですら不安定過ぎる (だが、それにもかかわらず、パッケージにする理     由はある) ものであるような、とても実験的な要素を含むソフトウェア の一時的な置き場であることを意味しています。試験版 (experimental) からパッケージをダウンロードしてインストールするユーザは、十分に 注意を受けているのを期待されています。要するに、試験版 (experimental) ディストリビューションを利用すると、どのようになる かは全くわからないということです。     以下が、試験版 (experimental) 用の sources.list(5)です:     deb http://ftp.xy.debian.org/debian/ experimental main deb-src http://ftp.xy.debian.org/debian/ experimental main ソフトウェアがシステムに多大なダメージを与える可能性がある場合、     試験版 (experimental) へ配置する方が良いでしょう。例えば、実験的 な圧縮ファイルシステムは恐らく試験版 (experimental) に行くことに なるでしょう。 パッケージの新しい上流バージョンが新しい機能を導入するが多くの古 い機能を壊してしまう場合であれば、アップロードしないでおくか試験 版 (experimental) へアップロードするかしましょう。新しいバージョ ン、ベータ版などで、利用する設定が完全に変わっているソフトウェア     は、メンテナの配慮に従って試験版 (experimental) へ入れることがで きます。もしも非互換性や複雑なアップグレード対応について作業して いる場合などは、試験版 (experimental) をステージングエリアとして 利用することができるのです。その結果、テストユーザは早期に新しい バージョンの利用が可能になります。 試験版 (experimental) のソフトウェアは不安定版 (unstable) へ説明 文に幾つかの警告を加えた上で入れることも可能ではありますが、お勧 めはできません。それは、不安定版 (unstable) のパッケージはテスト     版 (testing) へ移行し、そして安定版 (stable) になることが期待され ているからです。試験版 (experimental) を使うのをためらうべきでは ありません。何故なら ftpmaster には何の苦痛も与えませんし、試験版 (experimental) のパッケージは一旦不安定版 (unstable) により大きな バージョン番号でアップロードされると定期的に削除されるからです。     システムにダメージを与えないような新しいソフトウェアは直接不安定 版 (unstable) へ入れることが可能です。     試験版 (experimental) の代わりとなる方法は、people.debian.org 上 の個人的な web ページを使うことです。 4.6.5. リリースのコードネーム リリースされた Debian ディストリビューションは全てコードネームを 持っています： Debian 1.1 は buzz、Debian 1.2 は rex、Debian 1.3 は bo、Debian 2.0 は hamm、Debian 2.1 は slink、Debian 2.2 は potato、Debian 3.0 は woody、Debian 3.1 は sarge、Debian 4.0 は etch、Debian 5.0 は lenny、Debian 6.0 は squeeze、そして次のリリ ースは wheezy と呼ばれています。sid と呼ばれる「擬似ディストリビ     ューション」もあり、これは現在の unstable ディストリビューション を指します。パッケージは安定に近づくと unstable から testing へと 移動されるので、sid そのものは決してリリースされません。通常の Debian ディストリビューションの内容同様に、sid は Debian ではまだ 公式にサポートあるいはリリースされていないアーキテクチャのパッケ ージを含んでいます。これらのアーキテクチャは、いつか主流ディスト リビューションに統合される予定です。 Debian はオープンな開発体制 (つまり、誰もが開発について参加／追い かけが可能) となっており、不安定版 (unstable) およびテスト版 (testing) ディストリビューションすら Debian の FTP および HTTP サ ーバネットワークを通じてインターネットへ提供されています。従って     、リリース候補版を含むディレクトリをテスト版 (testing) と呼んだ場 合、このバージョンがリリースされる際に安定版 (stable) へとリネー ムする必要があるということを意味しており、すべての FTP ミラーがデ ィストリビューションすべて (とても巨大です) を再回収することにな ります。 一方、最初からディストリビューションディレクトリを Debian-x.y と 呼んでいた場合、皆 Debian リリース x.y が利用可能になっていると考     えるでしょう。(これは過去にあったことで、CD-ROM ベンダが Debian 1.0 の CD-ROM を pre-1.0 開発版を元に作成したことによります。これ が。何故最初の公式 Debian のリリース版が 1.0 ではなく 1.1 であっ たかという理由です)。 従って、アーカイブ内のディストリビューションディレクトリの名前は リリースの状態ではなくコードネームで決定されます (例えば `squeeze' など)。これらの名称は開発期間中とリリース後も同じもので あり続けます。そして、簡単に変更可能なシンボリックリンクによって     、現在の安定版リリースディストリビューションを示すことになります 。これが、stable、testing、unstable へのシンボリックリンクがそれ ぞれ相応しいリリースディレクトリを指しているのに対して、実際のデ ィストリビューションディレクトリではコードネームを使っている理由 です。 4.7. Debian ミラーサーバ 各種ダウンロードアーカイブサイトおよびウェブサイトは、中央サーバ を巨大なトラフィックから守るために複数ミラーが利用可能となってい ます。実際のところ、中央サーバのいくつかは公開アクセスが出来るよ うにはなっていません - 代わりに一次ミラーが負荷を捌いています。こ     のようにして、ユーザは常にミラーにアクセスして利用可能になってお り、Debian を多くのサーバやネットワーク越しに配布するのに必要な帯 域が楽になり、ユーザが一次配布元に集中しすぎてサイトがダウンして しまうのをおおよそ避けられるようになります。一次配布ミラーは内部 サイトからのトリガーによって更新されるので、可能な限り最新になっ ている (我々はこれをプッシュミラーと呼んでいます)。 利用可能な公開 FTP/HTTP サーバのリストを含む、Debian ミラーサーバ についての全ての情報が http://www.debian.org/mirror/ から入手可能     です。この役立つページには、内部的なものであれ公開されるものであ れ、自分のミラーを設定することに興味を持った場合に役立つ情報とツ ールも含まれています。 注意してほしいのは、ミラーは大抵 Debian の支援に興味を抱いてくれ     た第三者によって運用されていることです。そのため、開発者は通常こ れらのマシン上にはアカウントを持ってはいません。 4.8. Incoming システム Incoming システムは、更新されたパッケージを集めて Debian アーカイ     ブにインストールする役割を果たしています。これは ftp-master.debian.org 上にインストールされたディレクトリとスクリ プトの集合体です。 全てのメンテナによってアップロードされたパッケージは UploadQueue というディレクトリに置かれます。このディレクトリは、毎分 queued と呼ばれるデーモンによってスキャンされ、*.command ファイルが実行 されて、そのまま正しく署名された *.changes ファイルが対応するファ イルと共に unchecked ディレクトリに移動されます。このディレクトリ は ftp-master の様に制限されており、ほとんどの開発者には見えるよ うにはなっていません。ディレクトリはアップロードされたパッケージ     と暗号署名の完全性を照合する dak process-upload スクリプトによっ て15分毎にスキャンされます。パッケージがインストール可能であると 判断されると、done ディレクトリに移動されます。これがパッケージの 初アップロードの場合 (あるいは新たなバイナリパッケージを含んでい る場合)、ftpmaster による許可を待つ場所である new ディレクトリに 移動されます。パッケージが ftpmaster によって手動でインストールさ れるファイルを含む場合は byhand ディレクトリに移動します。それ以 外の場合は、エラーが検出されるとパッケージは拒否されて reject デ ィレクトリへと移動されます。 パッケージが受け入れられると、システムは確認のメールをメンテナに 送り、アップロードの際に修正済みとされたバグをクローズし、 auto-builder がパッケージのリコンパイルを始めます。Debian アーカ イブに実際にインストールされるまで、パッケージはすぐに http:// incoming.debian.org/ にてアクセス可能になります。この作業は 1 日     に 4 回行われます (様々な経緯から `dinstall run' とも呼ばれていま す)。そしてパッケージは incoming から削除され、他のパッケージ全て と共に pool にインストールされます。他のすべての更新 (例えば Packages インデックスファイルや Sources インデックスファイル) が 作成されると、一次ミラー全てを更新する特別なスクリプトが呼び出さ れます。 アーカイブメンテナンスのソフトウェアは、あなたがアップロードした OpenPGP/GnuPG で署名された .changes ファイルも適切なメーリングリ ストへと送信します。パッケージの Distribution がstable に設定され     てリリースされた場合、案内は に 送られます。パッケージの Distribution として unstable や experimental が設定されている場合、案内は代わりに < debian-devel-changes@lists.debian.org> へと投稿されます。 ftp-master は利用が制限されているサーバなので、インストールされた     もののコピーは ries.debian.org 上で全ての開発者が利用できるように なっています。 4.9. パッケージ情報 4.9.1. ウェブ上から パッケージはそれぞれ複数の目的別のウェブページを持っています。 http://packages.debian.org/package-name は各ディストリビューショ     ン中でそれぞれ利用可能なパッケージバージョンを表示します。バージ ョン毎のリンク先のページはパッケージの説明、依存関係、ダウンロー ドへのリンクを含んだ情報を提供しています。 バグ追跡システムは個々のパッケージのバグを記録していきます。http:     //bugs.debian.org/package-name というような URL で与えたパッケー ジ名のバグを閲覧できます。 4.9.2. dak ls ユーティリティ dak ls は dak ツールスイートの一部で、全ディストリビューションお よびアーキテクチャの中から利用可能なパッケージバージョンをリスト     アップします。dak ツールは ftp-master.debian.org 上と、 ries.debian.org 上のミラーにて利用できます。パッケージ名に対して 一つの引数を使います。実際に例を挙げた方が分かりやすいでしょう: $ dak ls evince evince | 0.1.5-2sarge1 | oldstable | source, alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc evince | 0.4.0-5 | etch-m68k | source, m68k     evince | 0.4.0-5 | stable | source, alpha, amd64, arm, hppa, i386, ia64, mips, mipsel, powerpc, s390, sparc evince | 2.20.2-1 | testing | source evince | 2.20.2-1+b1 | testing | alpha, amd64, arm, armel, hppa, i386, ia64, mips, mipsel, powerpc, s390, sparc evince | 2.22.2-1 | unstable | source, alpha, amd64, arm, armel, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc この例では、不安定版 (unstable) でのバージョンはテスト版 (testing) のバージョンと違っており、テスト版のパッケージは全アー     キテクチャについて、binary-only NMU されたパッケージになっていま す。それぞれのバージョンのパッケージは、全アーキテクチャ上で再コ ンパイルされています。 4.10. パッケージ追跡システム パッケージ追跡システム (PTS) は、ソースパッケージの動きを追いかけ     るメールベースのツールです。これが意味する所は、PTS のパッケージ に対して購読 (subscribe) を行うだけで、パッケージメンテナが受け取 るメールとまったく同じものを受け取れるということです。     PTS から送られるメールは以下のキーワードリストのうち一つに分類さ れます。これによって、受け取りたいメールを選別できます。     デフォルトで受け取るもの: bts バグ報告とそれに続くディスカッション全て。 bts-control バグ報告の状態変更について、 からの メール通知。 upload-source アップロードされたソースパッケージが受理された際の dak からの メール通知。 katie-other dak からの他の警告／エラーメール (セクション (section) や優先 度 (priority) フィールドの相違の上書きなど)。 buildd     ビルド失敗の通知はビルドデーモンのネットワークによって送信さ れます。この通知には分析のためのビルドログへのポインタが含ま れています。 default 自動ではない、パッケージの購読者にコンタクトしたい人によって PTS に送られるメール。これは、sourcepackage @packages.qa.debian.org にメールすることで可能になります。 spam メールを防ぐため、このアドレスに送られるメッセージは全て 空の値の X-PTS-Approved ヘッダを含む必要があります。 contact *@packages.debian.org のメールエイリアスを通じてメンテナに送 信されたメール。 summary testing への移行や、DEHS での開発元の新しいバージョンの通知、 パッケージが削除あるいは放棄 (orphaned) されたなどを含むパッ ケージの状態について、定期的なメールでのサマリ。     受け取るかどうかを決められる追加情報: upload-binary バイナリパッケージが受け入れられた際に katie から送られる通知 メールです。言い換えると、あなたのパッケージがビルドデーモン や他のアーキテクチャについて移植者によってアップロードされた 場合は、どの様に全アーキテクチャに対してリコンパイルされてい るかを追跡するためのメールを受け取れるということです。 cvs パッケージが VCS リポジトリを持っていて、メンテナがコミット通 知を PTS に転送するように設定している場合の VCS コミット通知 です。歴史的な経緯から "cvs" という名前が使われていますが、大 抵の場合は subversion や git のような他の VCS からの通知です     。 ddtp Debian Description 翻訳プロジェクトに投稿された descriptions の翻訳や debconf テンプレート。 derivatives 派生ディストリビューションでのパッケージに加えられた変更の情 報 (例 Ubuntu)。 derivatives-bugs 派生ディストリビューションでのバグレポートやコメント (例 Ubuntu)。 4.10.1. PTS メールインターフェイス     PTS の購読管理は へ様々なコマンドを送信するこ とで可能です。 subscribe [] email を対応するソースパッケージ sourcepackage への連絡先とし て登録します。二番目の引数が存在しない場合には送信者アドレス が使われます。sourcepackage が正しくないソースパッケージであ る場合は、警告メールが送付されます。正しいバイナリパッケージ である場合には、PTS は対応するソースパッケージの購読者として 登録します。 unsubscribe [] 指定されたメールアドレス、あるいは二番目の引数が空の場合は送 信者のアドレスを利用して、ソースパッケージ sourcepackage に対 するそれまでの購読を取り消します。 unsubscribeall [] 指定されたメールアドレス、あるいは二つ目の引数が空白の場合は 送信者アドレスのすべての購読を停止します。 which [] 送信者あるいは追加で指定したメールアドレスに対する全購読リス トを確認する。 keyword [] キーワードは利用したいものを入れてください。キーワードの説明 は、上記を確認してください。以下が簡単なサマリです: + bts: Debian バグ追跡システムからのメール + bts-control: へ送信される返信メ ール + summary: パッケージ状態の自動サマリメール + contact: *@packages.debian.org エイリアスアドレスを通じて メンテナに送られるメール + cvs: VCS へのコミット通知 + ddtp: description や debconf テンプレートの翻訳 + derivatives: 派生ディストリビューションによるパッケージ変     更 + derivatives-bugs: 派生ディストリビューションからのバグレ ポートやコメント + upload-source: 新たなソースパッケージが受け付けられたアナ ウンス + upload-binary: 新たなバイナリのみのアップロード (binary-only upload) のアナウンス (porting) + katie-other: ftpmaster からの他のメール (override disparity など。) + buildd: ビルドデーモンからのビルド失敗の通知 + default: 他のすべてのメール (自動ではないもの) keyword [] 前の項目同様ですが、指定したソースパッケージについて、それぞ れのソースパッケージに異なったキーワードをしたい場合に利用し ます。 keyword [] {+|-|=} 指定したキーワードで、メールが許可 (+) あるいは拒否 (-) に分 類されます。許可するキーワードのリストを定義 (=) してください 。これはユーザが許可したデフォルトのキーワードリストを変更し ます。 keywordall [] {+|-|=} 指定したキーワードで、メールが許可 (+) あるいは拒否 (-) に分 類されます。許可するキーワードのリストを定義 (=) してください 。これは現在購読しているユーザによって許可されているデフォル トのキーワードリストを変更します。 keyword [] {+|-|=} 上の項目と同じですが、指定したソースパッケージのキーワードリ ストを上書きします。 quit | thanks | -- コマンド処理を終了します。これ以下の全ての行は bot からは無視 されます。 pts-subscribe コマンドラインユーティリティ (devscripts パッケージ     に含まれています) は、例えば non-maintainer アップロードが行われ た後など、手動でパッケージの一時的な購読が行えます。 4.10.2. PTS からのメールを振り分ける パッケージの購読を行うと、sourcepackage@packages.qa.debian.org へ 送られるメールを受けとるようになります。このメールは (例えば     procmail を使って) 別のメールボックスへとフィルタできるように特別 なヘッダがされています。追加されるヘッダは X-Loop、X-PTS-Package 、X-PTS-Keyword、X-Unsubscribe です。     以下は dpkg パッケージに対するソースアップロードについて付加され るヘッダの例です: X-Loop: dpkg@packages.qa.debian.org     X-PTS-Package: dpkg X-PTS-Keyword: upload-source List-Unsubscribe: 4.10.3. PTS での VCS コミットを転送する Debian パッケージのメンテナンスに公開 VCS リポジトリを使っている     場合、PTS にコミット通知を転送することで、購読者 (や共同メンテナ ら) がパッケージの変更をすぐに知ることができます。 VCS リポジトリを設定してコミット通知を行うようにするのであれば、 sourcepackage_cvs@packages.qa.debian.org にメールのコピーが送れる     ようにしなければいけません。cvs キーワードを許可した人だけがこれ らの通知を受け取ります。メールは debian.org のマシンから送られる 必要があり、それ以外の場合は X-PTS-Approved: 1 ヘッダを付け加える 必要があるのに注意してください。 Subversion のリポジトリは、svnmailer の利用が推奨されています。ど     の様に行うかは http://wiki.debian.org/Alioth/PackagingProject を 参照してください。 4.10.4. PTS ウェブインターフェイス PTS は各ソースパッケージについての大量の情報をまとめたウェブイン ターフェイスを http://packages.qa.debian.org/ に持っています。そ の機能はたくさんの有用なリンク (BTS、QA の状態、連絡先情報、DDTS     の翻訳状態、buildd のログ) や様々な所からの情報 (最近の changelog エントリ30個、testing の状態など…)を集めたものです。特定のソース パッケージについて知りたい場合に非常に有用なツールです。さらに PTS をメールを使って購読する簡単なフォームもあります。     特定のソースパッケージに関しては http://packages.qa.debian.org/ sourcepackage のような URL で直接ウェブページに飛べます。 このウェブインターフェイスは、パッケージ開発のポータルとなるよう     にデザインされました: 自分のパッケージのページ上にカスタムしたコ ンテンツを付け加えられます。固定情報 (無期限に提示され続けるニュ ース項目) や通常のニュースを latest news section に追加できます。     固定ニュースは以下を表示するのに利用できます: * 複数人でのパッケージメンテナンスのため、Alioth でホストされて いる利用可能なプロジェクト * upstream のウェブサイトへのリンク     * upstream のバグ追跡システムへのリンク * ソフトウェア専用 IRC チャンネルの存在 * パッケージのメンテナンスについて、他の利用可能な有用なリソー ス     通常のニュースは以下のアナウンスに使われます: * テスト用にベータ版パッケージが準備できたこと * 来週に最終的なパッケージが期待されている * パッケージをスクラッチから再構築中     * バックポート版が利用可能 * メンテナが休暇中 (この情報を公開したい場合に表示) * NMU 進行中 * 何かパッケージに重要な影響を与える事柄 両方共、ニュースは同様のやり方で生成します: < pts-static-news@qa.debian.org> や へとメ ールを送るだけです。メールは X-PTS-Package メールヘッダや (BTS へ     の報告のように) Package 擬似ヘッダで、度のパッケージに関連するの かをソースパッケージの名前で示す必要があります。X-PTS-Url メール ヘッダや Url 擬似ヘッダ中に URL がある場合は、完全なニュースの代 わりにその URL へのリンクとなります。 PTS 中のニュース項目の生成に使われる正しいメールの例を幾つか挙げ     ます。最初の1つ目は Static information section 中の debian-cd の viewsvn インターフェイスへのリンクを付け加えるものです: From: Raphael Hertzog To: pts-static-news@qa.debian.org     Subject: Browse debian-cd SVN repository Package: debian-cd Url: http://svn.debian.org/viewsvn/debian-cd/trunk/ 二つ目のはメーリングリストへアナウンスを送るもので、PTS にも送ら     れるのでパッケージの PTS ウェブページで公開されます。誤って PTS に返信が送られるのを避けるために BCC 欄を利用していることに注意し てください。 From: Raphael Hertzog To: debian-gtk-gnome@lists.debian.org Bcc: pts-news@qa.debian.org Subject: Galeon 2.0 backported for woody     X-PTS-Package: galeon Hello gnomers! I'm glad to announce that galeon has been backported for woody. You'll find everything here: PTS へニュースを付け加える前に、もう一度考え直して見てください。     何故なら、後でこれを削除したり編集したりできないからです。可能な のは、以前のニュースを含んだ情報を廃止する新たなニュースを送信す ることだけです。 4.11. Developer's packages overview QA (quality assurance、品質保証) ウェブポータルが http:// qa.debian.org/developer.php から利用できます。これは、一人の開発 者のすべてのパッケージの一覧表を表示します (集団で行っている場合     は、共同メンテナとしてとして表示されます) 。この表は開発者のパッ ケージについてうまく要約された情報を与えてくれます: 重要度に応じ たバグの数やそれぞれのディストリビューションで利用可能なバージョ ン番号、testing の状態やその他有用な情報源へのリンクなどを含んで います。     open な状態のバグやどのパッケージに対して責任を持っているのかを忘 れないため、定期的に自身のデータを見直すのは良い考えです。 4.12. Debian での FusionForge の導入例: Alioth Alioth は FusionForge (SourceForge と GForge から派生したソフトウ ェア) に多少変更を加えたものを基にした Debian のサービスです。こ     のソフトは開発者が容易に使えるバグトラッキングシステム、パッチ管 理、プロジェクト／タスク管理、ファイルのアップロード、メーリング リスト、VCS リポジトリなどのツールを提供します。これらの機能全て はウェブインターフェイスから管理します。 Debian がバックアップする、あるいは Debian が中心となっているフリ ーソフトウェアプロジェクトに対して支援を提供、外部の開発者からの 支援協力を Debian によって始められたプロジェクトを与えたり、     Debian やその派生ディストリビューションのプロモーションが目的であ るプロジェクトを支援する機能を提供するためにあります。多くの Debian チームに非常によく利用されており、あらゆる種類の VCS リポ ジトリを提供しています。 全ての Debian 開発者は自動的に Alioth のアカウントを持ちます。     Debian 開発者は、パスワード復旧機能を使ってアカウントを有効にする ことができます。他の開発者は Alioth 上でゲストアカウントを発行し てもらえます。     詳細な情報については、以下のリンクを参照下さい： * http://wiki.debian.org/Alioth * http://wiki.debian.org/Alioth/FAQ     * http://wiki.debian.org/Alioth/PackagingProject * http://alioth.debian.org/ 4.13. 開発者への特典 4.13.1. LWN の購読 2002 年 10 月から、HP は LWN の購読権を興味のあるすべての Debian     Developer に提供しています。この権利の利用方法については、http:// lists.debian.org/debian-devel-announce/2002/10/msg00018.html を確 認してください。 4.13.2. Gandi.net ホスティング割引 2008年11月現在、Gandi.net は Debian 開発者に対して VPS ホスティン     グを割引価格で提供しています。http://lists.debian.org/ debian-devel-announce/2008/11/msg00004.htmlを参照してください。 第5章パッケージの取扱い方     この章では、パッケージの作成、アップロード、メンテナンス、移植に ついての情報を扱います。 5.1. 新規パッケージ もしあなたが Debian ディストリビューションに対して新たなパッケー ジを作成したいという場合、まず作業が望まれるパッケージ     (Work-Needing and Prospective Packages (WNPP)) の一覧をチェックす る必要があります。WNPP 一覧をチェックすることで、まだ誰もそのソフ トをパッケージ化していないことや、作業が重複していないことを確認 します。詳細については WNPP のページを読んでください。 パッケージ化しようとしているソフトについて、誰もまだ作業していな いようであれば、まずは wnpp 擬似パッケージ (pseudo-package) に対     してバグ報告を投稿する必要があります (「バグ報告」)。このバグ報告 には、パッケージの説明、作業しようとしているパッケージのライセン ス、ダウンロードが可能な現在の URL を含めた新規パッケージの作成予 定 (自分自身が分かるだけではないもの) を記述します。 サブジェクトを ITP: foo -- short description に設定する必要があり ます。ここでは foo は新規パッケージの名前に置き換えます。バグ報告 の重要度は wishlist に設定しなければなりません。X-Debbugs-CC ヘッ ダを使ってコピーを に送信してくだ さい (CC: は使わないでください。CC: を使った場合はメールのサブジ     ェクトにバグ番号が付与されないためです)。大量の新規パッケージの作 成 (11 個以上) を行っている場合、メーリングリストへ個別に通知する のは鬱陶しいので、代わりにバグを登録した後で debian-devel メーリ ングリストへ要約を送信してください。これによって、他の開発者らに 次に来るパッケージを知らせ、説明とパッケージ名のレビューが可能に なります。 新規パッケージがアーカイブへインストールされる際にバグ報告を自動     的に閉じるため、Closes: #nnnnn というエントリを新規パッケージの changelog 内に含めてください (「新規アップロードでバグがクローズ される時」を参照)。 パッケージについて、NEW パッケージキューの管理者への説明が必要だ ろうと思う場合は、changelog に説明を含めて     へ送ってください。アップロード後であればメンテナとして受け取った メールに返信してください。もしくは既に再アップロード最中の場合は reject メールに対して返信してください。 セキュリティバグを閉じる場合は、CVE 番号を Closes: #nnnnn と同じ く含めるようにしてください。これは、セキュリティチームが脆弱性を 追跡するのに役立ちます。アドバイザリの ID が分かる前にバグ修正の     ためのアップロードが行われた場合は、以前の changelog エントリを次 のアップロード時に修正するのが推奨されています。このような場合で も、元々の changelog での記載に可能な限り背景情報へのポインタを全 て含めてください。     我々がメンテナに意図しているところをアナウンスする様に求めるのに は、いくつもの理由があります。 * (潜在的な新たな) メンテナが、メーリングリストの人々の経験を活 かすのを手助けし、もし他の誰かが既に作業を行っていた場合に知 らせる。 * そのパッケージについての作業を検討している他の人へ、既に作業 をしているボランティアがいることを知らせ、労力が共有される。 * に流される一行の説明     文 (description) と通常どおりの「Intial release」という changelog エントリよりも、残った他のメンテナがパッケージに関 してより深く知ることができる。 * 不安定版 (unstable) で暮らす人 (そして最前線のテスターである 人) の助けになる。我々はそのような人々を推奨すべきである。 * メンテナや他に興味を持つ人々へ、プロジェクトで何が行われてい るのか、何か新しいことがあるかということ関して、告知は良い印 象を与える。     新しいパッケージに対するよくある拒否理由については http:// ftp-master.debian.org/REJECT-FAQ.html を参照してください。 5.2. パッケージの変更を記録する パッケージについて行った変更は debian/changelog に記録されなくて はいけません。これらの変更には、何が変更されたのか、(不確かであれ     ば) 何故なのか、そしてどのバグが閉じられたのかの簡潔な説明文を付 加する必要があります。このファイルは /usr/share/doc/package/ changelog.Debian.gz、あるいはネイティブパッケージの場合は /usr/ share/doc/package/changelog.gz にインストールされます。 debian/changelog ファイルは、幾つもの異なった項目からなる特定の構 造に従っています。一点を取り上げてみると、distribution については     「ディストリビューションを選ぶ」に記述されています。このファイル の構造について、より詳細な情報は Debian ポリシーの debian/ changelog という章で確認できます。 changelog への記載は、パッケージがアーカイブにインストールされる     際、自動的に Debian バグを閉じるのに利用できます。「新規アップロ ードでバグがクローズされる時」を参照してください。 ソフトウェアの新しい開発元のバージョン (new upstream version) を     含むパッケージの changelog エントリは、以下のようにするのが慣習で す:     * New upstream release.     changelog エントリの作成と仕上げ処理に使えるツールがあります。「 devscripts」と「dpkg-dev-el」を参照してください。     「debian/changelog のベストプラクティス」も参照してください。 5.3. パッケージをテストする パッケージをアップロードする前に、基本的なテストをする必要があり     ます。最低限、以下の作業が必要です (同じ Debian パッケージの古い バージョンなどが必要になるでしょう): * パッケージをインストールしてソフトウェアが動作するのを確認す る、あるいは既にそのソフトの Debian パッケージが存在している 場合、パッケージを以前のバージョンから新しいバージョンにアッ プグレードする。 * パッケージに対して lintian を実行する。以下のようにして lintian を実行できます: lintian -v package-version.changes こ れによって、バイナリパッケージ同様にソースパッケージを確認で きます。lintian が生成した出力を理解していない場合は、lintian が問題の説明を非常に冗長に出力するようにする -i オプションを 付けて実行してみてください。 通常、lintian がエラーを出力するようであれば、パッケージをア ップロードしてはいけません (エラーは E で始まります)。     lintian についての詳細は、「lintian」を参照してください。 * もし古いバージョンがあれば、それからの変更点を分析するために 追加で debdiff を実行する (「debdiff」を参照) 。 * (もしあれば) 以前のバージョンにダウングレードする — これは postrm スクリプトと prerm スクリプトをテストします。 * パッケージを削除して、再インストールする。 * ソースパッケージを違うディレクトリにコピーして展開し、再構築 する。これは、パッケージが外部の既存ファイルに依っているか 、.diff.gz ファイル内に含まれているファイルで保存されている権 限に依るかどうかをテストします。 5.4. ソースパッケージの概要     Debian のソースパッケージには 2 種類あります： * いわゆるネイティブ (native) パッケージ。元のソースと Debian で当てられたパッチの間に差が無いもの     * オリジナルのソースコードの tarball ファイルに、Debian によっ て作成された変更点を含む別のファイルが付随している (より一般 的な) パッケージ ネイティブパッケージの場合、ソースパッケージは Debian のソース control ファイル (.dsc) とソースコードの tarball (.tar. {gz,bz2,xz}) を含んでいます。ネイティブではないパッケージのソース     パッケージは Debian のソース control ファイルと、オリジナルのソー スコードの tarball (.orig.tar.{gz,bz2,xz})、そして Debian での変 更点 (ソース形式“1.0”は .diff.gz、ソース形式“3.0 (quilt)”は .debian.tar.{gz,bz2,xz}) を含んでいます。 ソース形式“1.0”では、パッケージが native かどうかはビルド時に dpkg-source によって決められていました。最近では望むソース形式を     debian/source/format に“3.0 (quilt)”または“3.0 (native)”と記述す ることによって明示することが推奨されています。この章の残りの部分 は native ではないパッケージについてのみ記しています。 初回には、特定の開発元のバージョン (upstream version) に該当する バージョンがアップロードされます。元のソース tar ファイルは、アッ     プロードされて .changes ファイルに含まれている必要があります。そ の後、新しい diff ファイルや .dsc ファイルの生成には全く同じ tar ファイルを使わなければならず、これを再アップロードする必要はあり ません。 デフォルトでは、dpkg-genchanges および dpkg-buildpackage は前述さ れている changelog エントリと現在のエントリが異なった upstream バ     ージョンを持つ場合にのみ、オリジナルのソース tar ファイルを含めよ うとします。この挙動は、-sa を使って常に含めたり、-sd を使うこと で常に含めないようにするように変更できます。 アップロード時にオリジナルのソースが含まれていない場合、アップロ     ードされる .dsc と diff ファイルを構築する際に dpkg-source が使用 するオリジナルの tar ファイルは、必ず既にアーカイブにあるものと 1 バイトも違わぬものでなくてはなりません。 注意していただきたいのですが、native ではないパッケージでは、diff はパッチ内のファイルパーミッションを保存しないので、*.orig.tar.     {gz,bz2,xz} 内に存在しないファイルのパーミッションは保持されませ ん。しかし、ソース形式“3.0 (quilt)”を使っている場合、debian ディ レクトリ内にあるファイルのパーミッションは tar アーカイブで保存さ れるのでそのままになります。 5.5. ディストリビューションを選ぶ アップロードでは、パッケージがどのディストリビューション向けにな     っているかを指定してあることが必要です。パッケージの構築プロセス では、debian/changelog ファイルの最初の行からこの情報を展開し 、.changes ファイルの Distribution 欄に配置します。 この欄にはいくつか指定可能な値があります: stable、unstable、     testing-proposed-updates、そして experimental です。通常、パッケ ージは unstable にアップロードされます。 実際には、他にも指定可能なディストリビューションがあります:     codename-security ですが、その詳細については「セキュリティ関連バ グの取扱い」を読んでください。     同時に複数のディストリビューションへ、パッケージをアップロードす ることはできません。 5.5.1. 特別な例: 安定版 (stable) と旧安定版 (oldstable) ディストリビ ューションへアップロードする 安定版 (stable) へのアップロードは、安定版リリースマネージャによ るレビューのため、パッケージは proposed-updates-new キューに転送     され、許可された場合は Debian アーカイブの stable-proposed-updates ディレクトリにインストールされます。ここ から、ここから、安定版 (stable) の次期ポイントリリースに含まれる ことになります。 アップロードが許可されるのを確実にするには、アップロードの前に変 更点について安定版リリースチームと協議する必要があります。そのた めには、reportbug コマンドを使って、現在の安定版 (stable) へ適用     したいパッチを含めて release.debian.org 擬似パッケージへバグを登 録してください。安定版 (stable) ディストリビューションへアップロ ードするパッケージの changelog のエントリは、常にくどいほど詳細に してください。 安定版 (stable) へのアップロード時には特に注意を払うことが必要で     す。基本的に、以下のいずれかが起こった際にのみ安定版 (stable) へ パッケージはアップロードされます: * 本当に致命的な機能の問題がある     * パッケージがインストールできなくなる * リリースされたアーキテクチャにパッケージが無い 以前、安定版 (stable) へのアップロードはセキュリティ問題への対処 と同等に取り扱われていました。しかし、この慣習は廃れており、 Debian セキュリティ勧告がリリースされた際、セキュリティ勧告へのア ップロードに使われたものが自動的に適切な proposed-updates アーカ     イブにコピーされます。セキュリティ情報の取り扱い方の詳細について は「セキュリティ関連バグの取扱い」を参照してください。セキュリテ ィチームがその問題は DSA を通じて修正するには軽微過ぎると思った場 合であっても、安定版のリリースマネージャらはそれに関わらず安定版 (stable) への定期アップロードに修正を含めようとするでしょう。     些細な修正でも後ほどバグを引き起こすことがあるので、重要でないも のは何であろうと変更するのは推奨されません。 安定版 (stable) にアップロードされるパッケージは安定版 (stable) を動作しているシステム上でコンパイルされていなければならず、ライ ブラリ (やその他のパッケージ) への依存は安定版 (stable) で入手可 能なものに限られます。例えば、安定版 (stable) にアップロードされ     たパッケージが不安定版 (unstable) にのみ存在するライブラリパッケ ージに依存していると reject されます。他のパッケージへの依存を (提供 (Provides) や shlibs をいじることで) 変更するのは、他のパッ ケージをインストールできないようにする可能性があるので認められま せん。 旧安定版 (oldstable) ディストリビューションへのアップロードはアー     カイブされてない限り可能です。安定版 (stable)と同じルールが適用さ れます。 5.5.2. 特別な例: testing/testing-proposed-updates へアップロードする     詳細については、testing section にある情報を参照してください。 5.6. パッケージをアップロードする 5.6.1. ftp-master にアップロードする パッケージをアップロードするには、ファイル (署名された changes フ ァイルと dsc ファイル) を anonymous ftp で ftp.upload.debian.org     の /pub/UploadQueue/ へアップロードする必要があります。そこでファ イルを処理するためには、Debian Developers keyring または Debian Maintainers keyring (http://wiki.debian.org/DebianMaintainer 参 照) にある鍵で署名しておく必要があります。 changes ファイルは最後に転送する必要があることに注意してください     。そうしないとアーカイブのメンテナンスを行っているソフトが changes ファイルをパースして全てのファイルがアップロードされてい ないと判断して、アップロードは reject されるかもしれません。 パッケージのアップロードを行う際には dupload や dput が便利なこと     にも気づくことでしょう。これらの便利なプログラムは、パッケージを Debian にアップロードする作業を自動化するのに役立ちます。     パッケージを削除するには ftp://ftp.upload.debian.org/pub/ UploadQueue/README と dcut Debian パッケージを参照してください。 5.6.2. 遅延アップロード パッケージを直ちにアップロードするのが良い時もありますが、パッケ     ージがアーカイブに入るのが数日後であるのが良いと思う時もあります 。例えば、Non-Maintainer アップロードの準備をする際は、メンテナに 対して猶予期間を数日間与えたいと思うでしょう。 delayed ディレクトリにアップロードされると、パッケージは the deferred uploads queue に保存されます。指定した待ち時間が終わると 、パッケージは処理のため通常の incoming ディレクトリに移動されま     す。この作業は ftp.upload.debian.org の DELAYED/X-day ディレクト リへのアップロードを通じて自動的に処理されます (X は 0 から 15 の 間です)。0-day は一日に複数回 ftp.upload.debian.org へアップロー ドするのに使われます。     dput を使うと、パッケージを遅延キューに入れるのに --delayed DELAY パラメータを使えます。 5.6.3. セキュリティアップロード セキュリティアップロードキュー (security-master.debian.org) には 、セキュリティチームからの事前許可無しにパッケージをアップロード     しないでください。パッケージがチームの要求に完全に合致していない 場合、望まれないアップロードに対処するために多くの問題が引き起こ されたり遅延が生じることになります。詳細については「セキュリティ 関連バグの取扱い」を参照してください。 5.6.4. 他のアップロードキュー ヨーロッパにはもう一つのアップロードキューが ftp://     ftp.eu.upload.debian.org/pub/UploadQueue/ にあります。操作方法は ftp.upload.debian.org と同じですが、ヨーロッパ圏の開発者に対して は、より速いはずです。 パッケージは ssh を使って ssh.upload.debian.org へアップロードす     ることも可能です。ファイルは /srv/upload.debian.org/UploadQueue に置く必要があります。このキューは遅延アップロードをサポートして いません。 5.6.5. 新しいパッケージがインストールされたことの通知 Debian アーカイブメンテナはパッケージのアップロードに関して責任を 持っています。多くの部分は、アップロードはアーカイブ用のメンテナ ンスツール dak process-upload によって日々自動的に行われています     。特に、不安定版 (unstable) に存在しているパッケージの更新は自動 的に処理されます。それ以外の場合、特に新規パッケージの場合は、ア ップロードされたパッケージをディストリビューションに含めるのは手 動で行われます。アップロードが手動で処理される場合は、アーカイブ への変更は実施されるまでに一ヶ月ほどかかります。お待ちください。 どの場合であっても、パッケージがアーカイブに追加されたことや、バ     グがアップロードで閉じられたことを告げるメールでの通知を受け取る ことになります。あなたが閉じようとしたバグが処理されてない場合は 、この通知を注意深く確認してください。 インストール通知は、パッケージがどのセクションに入ったかを示す情     報を含んでいます。不一致がある場合は、それを示す別のメール通知を 受け取ります。以下も参照ください。     キュー経由でアップロードした場合は、キューデーモンソフトウェアも メールで通知を行うことに留意してください。 5.7. パッケージのセクション、サブセクション、優先度を指定する debian/control ファイルのセクション (Section) フィールドと優先度     (Priority) フィールドは実際にアーカイブ内でどこに配置されるか、あ るいはプライオリティが何かという指定ではありません。debian/ control ファイル中の値は、実際のところは単なるヒントです。 アーカイブメンテナは、override ファイル内でパッケージについて定め られたセクションと優先度を常に確認しています。override ファイルと debian/control で指定されたパッケージのフィールドに不一致がある場     合、パッケージがアーカイブにインストールされる際に相違について記 述されたメールを受け取ります。debian/control ファイルを次回のアッ プロード時に修正することもできますし、override ファイルに変更を加 えるように依頼するのもよいでしょう。 パッケージが現状で置かれているセクションを変更するには、まずパッ ケージの debian/control ファイルが正しいことを確認する必要があり ます。次に、ftp.debian.org に対し、あなたのパッケージに対するセク     ションあるいは優先度について古いものから新しいものへ変更する依頼 のバグ登録をします。override: PACKAGE1:section/priority, [...], PACKAGEX:section/priority のようなサブジェクトを使い、バグ報告の 本文に変更に関する根拠を記述してください。 override ファイルについての詳細は、dpkg-scanpackages(1) と http:/     /www.debian.org/Bugs/Developer#maintincorrect を参照してください 。 「セクション」で書かれているように、セクション (Section)フィール ドにはセクション同様にサブセクションも記述するのに注意ください。     セクションが main の場合は、それは書かないようにしてください。利 用可能なサブセクションは http://www.debian.org/doc/debian-policy/ ch-archive.html#s-subsections で検索できます。 5.8. バグの取扱い すべての開発者は Debian バグ追跡システムを取り扱えるようでなけれ     ばいけません。これは、どの様にしてバグ報告を正しく登録するか (「 バグ報告」参照)、どの様に更新及び整理するか、そしてどの様にして処 理をして完了するかを知っていることを含みます。 バグ追跡システムの機能は、Debian BTS 開発者向け情報に記載されてい     ます。これには、バグの完了処理・追加メッセージの送信・重要度とタ グを割り当てる・バグを転送済み (Forwarded) にする・その他が含まれ ています。 バグを他のパッケージに割り当てし直す、同じ問題についての別々のバ グ報告をマージする、早まってクローズされたバグの再オープンなどの     作業は、いわゆる制御メールサーバと呼ばれるものを使って処理されて います。このサーバで利用可能なすべてのコマンドは、BTS 制御サーバ ドキュメントに記載されています。 5.8.1. バグの監視 良いメンテナになりたい場合は、あなたのパッケージに関する Debian バグ追跡システム (BTS) のページを定期的にチェックする必要がありま     す。BTS には、あなたのパッケージに対して登録されている全てのバグ が含まれています。登録されているバグについては、以下のページを参 照することで確認できます: http://bugs.debian.org/yourlogin @debian.org メンテナは、bugs.debian.org のメールアドレス経由で BTS に対応しま す。利用可能なコマンドについてのドキュメントは http://     www.debian.org/Bugs/ で参照可能ですし、もし doc-debian パッケージ をインストールしてあれば、ローカルファイル /usr/share/doc/debian/ bug-* で見ることも可能です。 定期的にオープンになっているバグについてのレポートを受け取るのも     良いでしょう。あなたのパッケージでオープンになっているバグの全一 覧を毎週受け取りたい場合、以下のような cron ジョブを追加します:     # 自分のパッケージにあるバグのレポートを毎週取得する 0 17 * * fri echo "index maint address" | mail request@bugs.debian.org     address は、あなたの公式な Debian パッケージメンテナとしてのメー ルアドレスに置き換えてください。 5.8.2. バグへの対応 バグに対応する際は、バグについて行った議論がバグの元々の報告者と バグ自身 (例えば <123@bugs.debian.org>) の両方に送られているのを 確認してください。新しくメールを書いていて元々の報告者のメールア     ドレスを思い出せない場合は、<123-submitter@bugs.debian.org> とい うメールアドレスが報告者へ連絡するのと、さらにバグのログへあなた がメールしたのを記録するのにも使えます (これは <123 @bugs.debian.org> へメールのコピーを送らなくても済むことを意味し ています)。 FTBFS である旨のバグを受け取った場合、これはソースからビルドでき     ないこと (Fails to build from source) を意味します。移植作業をし ている人たちはこの略語をよく使います。 既にバグに対処していた場合 (例えば修正済みの時)、説明のメッセージ を <123-done@bugs.debian.org> に送ることで done とマークしておい     て (閉じて) ください。パッケージを変更してアップロードすることで バグを修正する場合は、「新規アップロードでバグがクローズされる時 」に記載されているように自動的にバグを閉じることができます。 close コマンドを に送って、バグサーバ経     由でバグを閉じるのは決してしてはいけません。そのようにした場合、 元々の報告者は何故バグが閉じられたのかという情報を得られません。 5.8.3. バグを掃除する パッケージメンテナになると、他のパッケージにバグを見つけたり、自 分のパッケージに対して報告されたバグが実際には他のパッケージにあ るバグであったりということが頻繁にあるでしょう。バグ追跡システム     の機能は Debian 開発者向けの BTS ドキュメントに記載されています。 バグ報告の再指定 (reassign) やマージ (merge)、そしてタグ付けなど の作業は BTS 制御サーバのドキュメントに記述されています。この章で は、Debian 開発者から集められた経験を元にしたバグの扱い方のガイド ラインを含んでいます。 他のパッケージで見つけた問題についてバグを登録するのは、メンテナ     としての責務の一つです。詳細については「バグ報告」を参照してくだ さい。しかし、自分のパッケージのバグを管理するのはさらに重要です 。     以下がバグ報告を取り扱う手順です: 1. 報告が実際にバグに関連するものか否かを決めてください。ユーザ はドキュメントを読んでいないため、誤ったプログラムの使い方を しているだけのことが時々あります。このように判断した場合は、 ユーザに問題を修正するのに十分な情報を与えて (良いドキュメン トへのポインタを教えるなどして) バグを閉じます。同じ報告が何 度も繰り返し来る場合には、ドキュメントが十分なものかどうか、 あるいは有益なエラーメッセージを与えるよう、誤った使い方を検 知していないのでは、と自身に問い直してください。これは開発元 の作者に伝える必要がある問題かもしれません。 バグを閉じるという貴方の判断にバグ報告者らが同意しない場合に は、それをどう取り扱うかについての同意が見つかるまで、彼らは 再度オープンな状態 (reopen) にするでしょう。そのバグについて もう議論することが無いという場合は、バグは存在するが修正する ことはないと知らせるため、バグに対して wontfix タグを付けるこ とになります。この決定が受け入れがたい時には、あなた (あるい は報告者) はバグを tech-ctte に再指定 (reassign) して技術委員 会 (technical committee) の判断を仰いでください (パッケージへ 報告されたものをそのままにしておきたい場合は、BTS の clone コ マンドを使ってください)。これを行う前には推奨手順を読んでおい てください。 2. バグが実際にあるが、他のパッケージによって引き起こされている 場合は、バグを正しいパッケージに再指定 (reassign) します。ど のパッケージに再指定するべきかが分からない場合は、IRC か < debian-devel@lists.debian.org> で聞いてください。再指定するパ ッケージのメンテナに通知をしてください。例えば 宛にメッセージを Cc: してメール中に理由 を説明するなどします。単に再指定しただけでは再指定された先の メンテナにはメールは送信されませんので、彼らがパッケージのバ グ一覧を見るまでそれを知ることはありません。 バグがあなたのパッケージの動作に影響する場合は、バグを複製し (clone)、複製したバグをその挙動を実際に起こしているパッケージ に再指定することを検討してください。さもなければ、あなたのパ ッケージのバグ一覧にバグが見つからないので、多分ユーザに同じ バグを何度も繰り返し報告される羽目になる可能性があります。あ なたは、再指定 (reassign) によって「自分の」バグということを 防ぎ、バグの複製 (clone) によって関係があることを記載しておく 必要があります。 3. 時々、重要度の定義に合うようにバグの重要度を調整する必要もあ     ります。これは、人々はバグ修正を確実に早くしてもらうために重 要度を極端に上げようとするからです。要望された変更点が単に体 裁的なものな時には、バグは要望 (wishlist) に格下げされるでし ょう。 4. バグが確かにあるが既に他の誰かによって同じ問題が報告されてい る場合は、2 つの関連したバグを BTS の merge コマンドを使って 1 つにマージします。このようにすると、バグが修正された時に全 ての投稿者に通知がいきます (ですが、そのバグ報告の投稿者への メールは報告の他の投稿者には自動的には通知されないことに注意 してください)。merge コマンドや類似の unmerge コマンドの技術 詳細については、BTS 制御サーバドキュメントを参照してください 。 5. バグ報告者は情報を書き漏らしている場合、必要な情報を尋ねる必 要があります。その様なバグに印をつけるには moreinfo タグを使 います。さらに、そのバグを再現できない場合には、 unreproducible タグを付けます。誰もそのバグを再現できない場合 、どうやって再現するのか、さらに情報を何ヶ月経っても、この情 報が誰からも送られてこない場合はバグは閉じても構いません。 6. バグがパッケージに起因する場合、さっさと直します。自分では直 せない場合は、バグに help タグを付けます。< debian-devel@lists.debian.org> や で助けを求めることも出来ます。開発元 (upstream) の問題であ れば、作者に転送する必要があります。バグを転送するだけでは十 分ではありません。リリースごとにバグが修正されているかどうか を確認しなければいけません。もし修正されていれば、それを閉じ 、そうでなければ作者に確認を取る必要があります。必要な技能を 持っていてバグを修正するパッチが用意できる場合は、同時に作者 に送りましょう。パッチを BTS に送付してバグに patch タグを付 けるのを忘れないでください。 7. ローカル環境でバグを修正した、あるいは VCS リポジトリに修正を コミットした場合には、バグに pending タグを付けてバグが修正さ れたことと次のアップロードでバグが閉じられるであろうことを回 りに知らせます (changelog に closes: を追加します)。これは複 数の開発者が同一のパッケージで作業している際に特に役立ちます 。 8. 一旦修正されたパッケージがアーカイブから入手可能になったら、 バグはどのバージョンで修正されたかを指定して閉じられる必要が あります。これは自動的に行われます。「新規アップロードでバグ がクローズされる時」を読んでください。 5.8.4. 新規アップロードでバグがクローズされる時 バグや問題があなたのパッケージで修正されたとしたら、そのバグを閉 じるのはパッケージメンテナとしての責任になります。しかし、バグを 修正したパッケージが Debian アーカイブに受け入れられるまではバグ     を閉じてはいけません。従って、一旦更新したパッケージがアーカイブ にインストールされたという通知を受け取った場合は、BTS でバグを閉 じることができますし、そうしなければいけません。もちろん、バグは 正しいバージョンで閉じなくてはいけません。 ですが、アップロード後に手動でバグをクローズしなくても済む方法が     あります — debian/changelog に以下の特定の書き方にて修正したバグ を列挙すれば、それだけで後はアーカイブのメンテナンスソフトがバグ をクローズしてくれます。例: acme-cannon (3.1415) unstable; urgency=low     * Frobbed with options (closes: Bug#98339) * Added safety to prevent operator dismemberment, closes: bug#98765, bug#98713, #98714. * Added man page. Closes: #98725.     技術的に言うと、どの様にしてバグを閉じる changelog が判別されてい るかを以下の Perl の正規表現にて記述しています:     /closes:\s*(?:bug)?\#\s*\d+(?:,\s*(?:bug)?\#\s*\d+)*/ig closes: #XXX という書き方が推奨されています。これは、最も分かり易 いエントリで、changelog の本文に挿入するのがもっとも簡単だからで     す。dpkg-buildpackage に -v スイッチを指定して別バージョンを指定 しない限り、最も新しい changelog のエントリにあるバグだけが閉じら れます (基本的には、です。正確には .changes ファイルの changelog-part で明示されたバグが閉じられます)。 歴史的に、non-maintainer upload (NMU) と判別されるアップロードは     closed ではなく fixed とタグがされてきましたが、この習慣はバージ ョントラッキングの進化によって廃れています。同じことが fixed-in-experimental タグにも言えます。 もしバグ場号を間違って入力したり、changelog のエントリにバグを入 れ忘れた場合、そのミスが起こすであろうダメージを防ぐのを躊躇わな いでください。誤って閉じたバグを再度オープンにするには、バグトラ ッキングシステムのコントロールアドレスである <     control@bugs.debian.org> に reopen XXX コマンドを投げます。アップ ロードで修正されたがまだ残っているバグを閉じるには .changes ファ イルを にメールします。XXX はバグ番号 で、メールの本文の最初の 2 行に Version: YYY と空白行を入れます。 YYY はバグが修正された最初のバージョンです。 上に書いたような changelog を使ったバグの閉じ方は必須ではない、と いうことは念頭に置いておいてください。行ったアップロードとは無関     係に単にバグを閉じたい、という場合は、説明をメールに書いて に送ってバグを閉じてください。そのバージョ ンのパッケージでの変更がバグに何も関係ない場合は、そのバージョン の changelog エントリではバグを閉じないでください。     どのように changelog のエントリを書くのか、一般的な情報については 「debian/changelog のベストプラクティス」を参照してください。 5.8.5. セキュリティ関連バグの取扱い 機密性が高いその性質上、セキュリティ関連のバグは注意深く取り扱わ ねばなりません。この作業をコーディネイトし、未処理のセキュリティ     問題を追い続け、セキュリティ問題についてメンテナを手助けしたり修 正自体を行い、セキュリティ勧告を出し、security.debian.org を維持 するために Debian セキュリティチームが存在します。 Debian パッケージ中のセキュリティ関連のバグに気づいたら、あなたが メンテナであるかどうかに関わらず、問題に関する正確な情報を集めて 、まずはセキュリティチームに連絡を取ってください。この場合、リク エストトラッカーにチケットを登録するのが好ましいです。http://     wiki.debian.org/rt.debian.org#Security_Team を参照してください。 あるいは にメールすることもできます。 チームに問い合わせること無く安定版 (stable) 向けのパッケージをア ップロードしないでください。例えば、役に立つ情報は以下を含んでい ます: * バグが既に公開されているか否か * バグによって、どのバージョンが影響を受けると分かっているか。 サポートされている Debian のリリース、ならびにテスト版 (testing) 及び不安定版 (unstable) にある各バージョンをチェッ クしてください。 * 利用可能なものがあれば、修正内容 (パッチが特に望ましい)     * 自身で準備した修正パッケージ (まずは「セキュリティ問題に対処 するパッケージを用意する」を読んで、.diff.gz と .dsc ファイル だけを送ってください) * テストについて何かしらの手助けになるもの (攻撃コード、リグレ ッションテストなど) * 勧告に必要になる情報 (「セキュリティ勧告」参照) パッケージメンテナとして、あなたは安定版リリースについてもメンテ ナンスする責任を持ちます。あなたがパッチの評価と更新パッケージの     テストを行うのに最も適任な人です。ですから、以下のセキュリティチ ームによって取り扱ってもらうため、どのようにしてパッケージを用意 するかについての章を参照してください。 5.8.5.1. セキュリティ追跡システム セキュリティチームは集約的なデータベース、Debian セキュリティ追跡 システム (Debian Security Tracker)をメンテナンスしています。これ     はセキュリティ問題として知られている全ての公開情報を含んでいます: どのパッケージ／バージョンが影響を受ける／修正されているか、つま りは安定版、テスト版、不安定版が脆弱かどうか、という情報です。ま だ機密扱いの情報は追跡システムには追加されません。 特定の問題について検索することもできますし、パッケージ名でも検索 できます。あなたのパッケージを探して、どの問題がまだ未解決かを確     認してください。できれば追加情報を提供するか、パッケージの問題に 対処するのを手伝ってください。やり方は追跡システムのウェブページ にあります。 5.8.5.2. 秘匿性 Debian 内での他の多くの活動とは違い、セキュリティ問題に関する情報 については、暫くの間秘密にしておく必要がしばしばあります。これに     よって、ソフトウェアのディストリビュータがユーザが危険にさらされ るのを最小限にするため、公開時期を合わせることができます。今回が そうであるかは、問題と対応する修正の性質や、既に既知のものとなっ ているかどうかによります。     開発者がセキュリティ問題を知る方法はいくつかあります: * 公開フォーラム (メーリングリスト、ウェブサイトなど) で知らせ る     * 誰かがバグ報告を登録している * 誰かがプライベートなメールで教えてきた 最初の二つのケースでは、情報は公開されていて可能な限り早く修正す     ることが重要です。しかしながら最後のケースは、公開情報ではないか もしれません。この場合は、問題に対処するのに幾つか取り得る選択肢 があります: * セキュリティの影響度が小さい場合、問題を秘密にしておく必要は なく、修正を行ってリリースするのが良い場合がしばしばあります 。     * 問題が深刻な場合、他のベンダと情報を共有してリリースをコーデ ィネイトする方が望ましいでしょう。セキュリティチームは様々な 組織／個人と連絡を取りつづけ、この問題に対応することができま す。 どのような場合でも、問題を報告した人がこれを公開しないように求め ているのであれば、明白な例外として Debian の安定版リリースに対す     る修正を作成してもらうためにセキュリティチームへ連絡すること以外 、この様な要求は尊重されるべきです。機密情報をセキュリティチーム に送る場合は、この点を明示しておくのを忘れないでください。 機密を要する場合は、修正を不安定版 (unstable) (や公開 VCS リポジ トリなどその他どこへも) へ修正をアップロードしないよう、注意して     ください。コードその物が公開されている場合、変更の詳細を難読化す るだけでは十分ではなく、皆によって解析され得る (そしてされる) で しょう。 機密であることを要求されたにも関わらず、情報を公開するのには 2 つ     の理由があります: 問題が一定期間既知の状態になっている、あるいは 問題や攻撃コードが公開された場合です。 セキュリティチームは、機密事項に関して通信を暗号化できる PGP 鍵を     持っています。詳細については、セキュリティチーム FAQ を参照してく ださい。 5.8.5.3. セキュリティ勧告 セキュリティ勧告は現在のところ、リリースされた安定版ディストリビ ューションについてのみ、取り扱われます。テスト版 (testing) や不安 定版 (unstable) についてではありません。リリースされると、セキュ     リティ勧告は email-debian-security-announce; メーリングリストに送 られ、セキュリティのウェブページに掲載されます。セキュリティ勧告 はセキュリティチームによって記述、掲載されます。しかし、メンテナ が情報を提供できたり、文章の一部を書けるのであれば、彼らは当然そ んなことは気にしません。勧告にあるべき情報は以下を含んでいます: * 以下のようなものを含めた問題の説明と範囲: + 問題の種類 (権限の上昇、サービス拒否など) + 何の権限が得られるのか、(もし分かれば) 誰が得るのか + どのようにして攻撃が可能なのか + 攻撃はリモートから可能なのかそれともローカルから可能なの か + どのようにして問題が修正されたのか     この情報によって、ユーザがシステムに対する脅威を評価できるよ うになります。 * 影響を受けるパッケージのバージョン番号 * 修正されたパッケージのバージョン番号 * どこで更新されたパッケージを得るかという情報 (通常は Debian のセキュリティアーカイブからです) * 開発元のアドバイザリへの参照、CVE 番号、脆弱性の相互参照につ いて役立つその他の情報 5.8.5.4. セキュリティ問題に対処するパッケージを用意する あなたがセキュリティチームに対し、彼らの職務に関して手助けできる     方法の一つは、安定版 Debian リリース用のセキュリティ勧告に適した 修正版パッケージを提供することです。 安定版について更新が作成される際、システムの挙動の変化や新しいバ グの導入を避けるように注意が必要です。これを行うため、バグを修正 するための変更は可能な限り少なくします。ユーザや管理者は一旦リリ     ースされたものの厳密な挙動を当てにしているので、どのような変更で も誰かのシステムを壊しかねません。これは特にライブラリについて当 てはまります: API や ABI を決して変更していないことを確認してくだ さい。変更がどれほど小さいものでも関係ありません。 これは、開発元の新しいリリースバージョン (new upstream version) への移行が良い解決策ではないことを意味しています。代わりに、関連     する変更を現在の Debian 安定版リリースに存在しているバージョンへ バックポートするべきです。通常、開発元のメンテナは助けが必要であ れば手伝おうとしてくれます。そうでない場合は、Debian セキュリティ チームが手助けすることができます。 いくつかのケースでは、例えば大量のソースコードの変更や書き直しが 必要など、セキュリティ修正をバックポートできないことがあります。     この様な場合、新しいバージョン (new upstream version) へ移行する 必要があるかもしれません。しかし、これは極端な状況の場合にのみ行 われるものであり、実行する前に必ずセキュリティチームと調整をしな ければなりません。 これに関してはもう一つ重要な指針があります: 必ず変更についてテス トをしてください。攻撃用コード (exploit) が入手可能な場合には、そ れを試してみて、パッチを当てていないパッケージで成功するか、修正     したパッケージでは失敗することかどうかを確かめてみてください。他 の確認として、セキュリティ修正は時折表面上はそれと関係が無いよう な機能を壊すことがあるので、通常の動作も同様にテストしてください 。 脆弱性の修正に直接関係しない変更をパッケージへ加えないようにして ください。この様な変更は元に戻さなくてはならなくなるだけで、時間 を無駄にします。他に直したいバグがパッケージにある場合は、セキュ     リティ勧告が発行された後、通常通りに proposed-update にアップロー ドを行ってください。セキュリティ更新の仕組みは、それ以外の方法で は安定版リリースから reject されるであろう変更をあなたのパッケー ジに加える方法ではありませんので、この様な事はしないでください。 変更点を可能な限り見直してください。以前のバージョンとの変更点を     繰り返し確認してください (これには patchutils パッケージの interdiff や devscripts の debdiff が役立ちます。「debdiff」を参 照してください)。     以下の項目を必ず確認してください * debian/changelog で正しいディストリビューションを対象にする: codename-security (例えば wheezy-security)。distribution -proposed-updates や stable を対象にしないでください! * アップロードは urgency=high で行う必要があります。 * 説明が十分にされている、意味がある changelog エントリを書くこ と。他の人は、これらを元に特定のバグが修正されているのかを見 つけ出します。登録されている Debian バグに対して closes: 行を 追加すること。外部のリファレンス、できれば CVE 識別番号を常に 含めること、そうすれば相互参照が可能になります。しかし、CVE 識別番号がまだ付与されていない場合には、それを待たずに作業を 進めてください。識別番号は後ほど付与することができます。 * バージョン番号が正しいことを確認する。現在のパッケージより大 きく、しかし以降のディストリビューションよりパッケージバージ ョンが小さい必要があります。分からない場合は dpkg --compare-versions でテストしてください。以前のアップロードで 既に使っているバージョン番号を再利用しないように注意してくだ さい。そうしないと番号が binNMU と衝突します。+debXu1 (X はメ     ジャーリリース番号) を追加するのが通例です。例えば 1:2.4.3-4+deb7u1 とします。もちろん 1 はアップロードするごと に増やします。 * これまでに (以前のセキュリティ更新によって) security.debian.org へ開発元のソースコードをアップロードして いなければ、開発元のソースコードを全て含めてアップロードする パッケージをビルドする (dpkg-buildpackage -sa)。以前、同じ開 発元のバージョンで security.debian.org にアップロードしたこと がある場合は、開発元のソースコード無しでアップロードしても構 いません (dpkg-buildpackage -sd)。 * 通常のアーカイブで使われているのと全く同じ *.orig.tar. {gz,bz2,xz}を必ず使うようにしてください。さもなくば、後ほどセ キュリティ修正を main アーカイブに移動することができません。 * ビルドを行っているディストリビューションからインストールした パッケージだけが含まれているクリーンなシステム上でパッケージ をビルドしてください。その様なシステムを自分で持っていない場 合は、debian.org マシン (「Debian のマシン群」を参照してくだ さい) を使うこともできますし、chroot を設定することもできます (「pbuilder」と「debootstrap」を参照してください)。 5.8.5.5. 修正したパッケージをアップロードする セキュリティアップロードキュー (security-master.debian.org) には 、セキュリティチームからの事前許可無しにパッケージをアップロード     しないでください。パッケージがチームの要求に完全に合致していない 場合、望まれないアップロードに対処するために多くの問題が引き起こ されたり遅延が生じることになります。詳細については「セキュリティ 関連バグの取扱い」を参照してください。 セキュリティチームと調整する事無しに proposed-updates へ修正した ものをアップロードしないようにしてください。security.debian.org からパッケージは proposed-updates ディレクトリに自動的にコピーさ     れます。アーカイブに同じ、あるいはより高いバージョン番号のものが 既にインストールされている場合は、セキュリティアップデートはアー カイブシステムに reject されます。そうすると、安定版ディストリビ ューションはこのパッケージに対するセキュリティ更新無しで終了して しまうでしょう。 一旦、新しいパッケージを作成してテストし、セキュリティチームによ って許可を受けたら、アーカイブへインストールできるようにするため     にアップロードをする必要があります。セキュリティに関するアップロ ードの場合、アップロード先は ftp://security-master.debian.org/pub /SecurityUploadQueue/ になります。 セキュリティキューへアップロードしたものが許可されると、パッケー     ジは自動的にすべてのアーキテクチャに対してビルドされ、セキュリテ ィチームによる確認の為に保存されます。 許可、あるいは確認を待っているアップロードには、セキュリティチー     ムのみがアクセスできます。これは、まだ公開できないセキュリティ問 題の修正があるかも知れないためです。 セキュリティチームのメンバーがパッケージを許可した場合は、     proposed パッケージに対する ftp-master.debian.org 上の適切な distribution-proposed-updates と同様に security.debian.org 上にイ ンストールされます。 5.9. パッケージの移動、削除、リネーム、放棄、引き取り、再導入 アーカイブの変更作業のいくつかは、Debian のアップロードプロセスで     は自動的なものにはなっていません。これらの手続きはメンテナによる 手動での作業である必要があります。この章では、この様な場合に何を するかのガイドラインを提供します。 5.9.1. パッケージの移動 時折、パッケージは属しているセクションが変わることがあります。例     えば「non-free」セクションのパッケージが新しいバージョンで GPL に なった場合、パッケージは「main」か「contrib」に移動する必要があり ます。^[3] パッケージのどれかがセクションを変更する必要がある場合、希望する セクションにパッケージを配置するためパッケージの control 情報を変 更してから再アップロードします (詳細については Debian ポリシーマ     ニュアルを参照してください)。必ず .orig.tar.{gz,bz2,xz} を (開発 元のバージョンが新しいものになったのではなくても) アップロードに 含める必要があります。新しいセクションが正しい場合は、自動的に移 動されます。移動されない場合には、何が起こったのかを理解するため に ftpmaster に連絡を取ります。 一方で、もしパッケージの一つのサブセクション (例:「devel」「admin 」) を変更する必要がある、という場合には、手順は全く異なります。     パッケージの control ファイルにあるサブセクションを修正して、再ア ップロードします。また、「パッケージのセクション、サブセクション 、優先度を指定する」に記述してあるように override ファイルを更新 する必要が出てくるでしょう。 5.9.2. パッケージの削除 何らかの理由でパッケージを完全に削除したくなった場合 (もう必要が なくなった古い互換用ライブラリの場合、など)、パッケージを削除する よう ftp.debian.org に対してバグ登録をする必要があります; すべて のバグ同様、通常このバグは重要度 normal です。バグの題名は RM: パ ッケージ名 [アーキテクチャ一覧] -- 理由という形式である必要があり     ます。パッケージ名は削除されるパッケージ、理由は削除を依頼する理 由の短い要約です。[アーキテクチャ一覧]はオプションで、削除依頼が 全アーキテクチャではなく一部のアーキテクチャのみに適用される場合 にのみ、必要となります。reportbug は ftp.debian.org 擬似パッケー ジに対してバグを報告しようとした場合に、これらのルールに則ってバ グの題名を作成しようとすることに注意してください。 あなたがメンテナンスしているパッケージを削除したくなった場合は、 題名の先頭に ROM (Request Of Maintainer) という文字を付けたバグに これを記述する必要があります。パッケージの削除理由に使われる他の     一般的な略語が幾つかありますので、完全な一覧については http:// ftp-master.debian.org/removals.html を参照してください。このペー ジでは、まだ作業されていない削除依頼の便利な一覧も見ることができ ます。 削除は不安定版 (unstable)、実験版 (experimental)、安定版 (stable) ディストリビューションに対してのみ実施が可能であることに注意して ください。パッケージはテスト版 (testing) から直接は削除されません     。代わりに不安定版 (unstable) から削除された後で自動的に削除され 、テスト版 (testing) にあるパッケージは削除されたパッケージに依存 しなくなります (release.debian.org 擬似パッケージへ削除依頼のバグ レポートを登録することで、テスト版 (testing)からの削除は可能では あります。「テスト版からの削除」の項目を参照して下さい)。 例外として、明示的な削除依頼が必要ない場合が一つあります: (ソース 、あるいはバイナリ) パッケージがソースからビルドされなくなった場 合、半自動的に削除されます。バイナリパッケージの場合、これはこの     バイナリパッケージを生成するソースパッケージがもはや存在しないと いうことを意味します。バイナリパッケージがいくつかのアーキテクチ ャで生成されなくなったという場合には、削除依頼は必要です。ソース パッケージの場合は、関連の全バイナリパッケージが別のソースパッケ ージによって上書きされるのを意味しています。 削除依頼では、依頼を判断する理由を詳細に書く必要があります。これ     は不必要な削除を避け、何故パッケージが削除されたのかを追跡できる ようにするためです。例えば、削除されるパッケージにとって代わるパ ッケージの名前を記述します。 通常は自分がメンテナンスしているパッケージの削除のみを依頼します 。その他のパッケージを削除したい場合は、メンテナの許可を取る必要 があります。パッケージが放棄されたのでメンテナがいない場合は、ま     ず で削除依頼について議論をしてくだ さい。パッケージの削除についての合意ができたら、削除依頼の新規バ グを登録するのではなく、wnpp パッケージに対して登録されているバグ を reassign して O: に題名を変更するべきです。 この件、あるいはパッケージ削除に関するその他のトピックについて、     さらなる情報を http://wiki.debian.org/ftpmaster_Removals や http: //qa.debian.org/howto-remove.html で参照できます。 パッケージを破棄しても構わないか迷う場合には、意見を聞きに < debian-devel@lists.debian.org> へメールしてください。apt の apt-cache プログラムも重要です。apt-cache showpkg パッケージ名と     して起動した際、プログラムはパッケージ名の非依存関係を含む詳細を 表示します。他にも apt-cache rdepends、apt-rdepends、build-rdeps (devscripts パッケージに含まれる)、grep-dctrl などの有用なプログ ラムが非依存関係を含む情報を表示します。みなしご化されたパッケー ジの削除は、 で話し合われます。 一旦パッケージが削除されたら、パッケージのバグを処理する必要があ ります。実際のコードが別のパッケージに含まれるようになったので、 別のパッケージへバグを付け替える (例えば、libfoo13 が上書きするの で、libfoo12 が削除される) か、あるいはソフトウェアがもう Debian     の一部では無くなった場合にはバグを閉じるかする必要があります。バ グを閉じる場合、過去の Debian のリリースにあるパッケージバージョ ンで修正されたとマークするのを避けてください。バージョン +rm で修正されたとマークしな ければなりません。 5.9.2.1. Incoming からパッケージを削除する 以前は、incoming からパッケージを削除することが可能でした。しかし 、新しい incoming システムが導入されたことにより、これはもはや不 可能となっています。その代わりに、置き換えたいパッケージよりも高 いバージョンのリビジョンの新しいパッケージをアップロードする必要     があります。両方のバージョンのパッケージがアーカイブにインストー ルされますが、一つ前のバージョンはすぐに高いバージョンで置き換え られるため、実際にはバージョンが高い方だけが不安定版 (unstable) で利用可能になります。しかし、もしあなたがパッケージをきちんとテ ストしていれば、パッケージを置き換える必要はそんなに頻繁には無い はずです。 5.9.3. パッケージをリプレースあるいはリネームする あなたのパッケージのどれかの開発元のメンテナらが、ソフトウェアを リネームするのを決めた時 (あるいはパッケージを間違えて名前を付け た時)、以下の二段階のリネーム手続きに従う必要があります。最初の段 階では、debian/control ファイルに新しい名前を反映し、利用しなくな るパッケージ名に対して Replace、Provides、Conflicts を設定する変     更をします (詳細に関しては Debian ポリシーマニュアルl を参照)。注 意してほしいのは、利用しなくなるパッケージ名がリネーム後も動作す る場合のみ、Provides を付け加えるべきだということです。一旦パッケ ージをアップロードがアップロードされてアーカイブに移動したら、 ftp.debian.org に対してバグを報告してください (「パッケージの削除 」参照)。同時にパッケージのバグを正しく付け替えするのを忘れないで ください。 他に、パッケージの作成でミスを犯したので置き換えたいという場合が あるかもしれません。これを行う方法は唯一つ、バージョン番号を上げ て新しいバージョンをアップロードすることです。通常、古いバージョ ンは無効になります。これはソースを含めた各パッケージ部分に適用さ れることに注意してください: パッケージの開発元のソース tarball を     入れ替えたい場合には、別のバージョンをつけてアップロードする必要 があります。よくある例は foo_1.00.orig.tar.gz を foo_1.00+0.orig.tar.gz、あるいは foo_1.00.orig.tar.bz2 で置き換え るというものです。この制約によって、ftp サイト上で各ファイルが一 意の名前を持つことになり、ミラーネットワークをまたがった一貫性を 保障するのに役立ちます。 5.9.4. パッケージを放棄する パッケージをもうメンテナンスできなくなってしまった場合、ほかの人 に知らせて、パッケージが放棄 (orphaned) とマークされたのが分かる ようにする必要があります。パッケージメンテナを Debian QA Group に設定し、疑似パッケージwnpp に対してバ グ報告を送信しなければなりません。バグ報告は、パッケージが今放棄 されていることを示すように O: パッケージ名 -- 短い要約というタイ     トルにする必要があります。バグの重要度は通常 (normal) に設定しな ければなりません; パッケージの重要 (priority) が standard より高 い場合には重要 (important) に設定する必要があります。必要だと思う のならば、メッセージの X-Debbugs-CC: ヘッダのアドレスに < debian-devel@lists.debian.org> を入れてコピーを送ってください (そ う、CC: を使わないでください。その理由は、CC: を使うと、メッセー ジの題名がバグ番号を含まないからです)。 パッケージを手放したいが、しばらくの間はメンテナンスを継続できる     場合には、代わりに wnpp へ RFA: パッケージ名 -- 短い要約という題 名でバグ報告を送信する必要があります。RFA は Request For Adoption (引き取り依頼) を意味しています。     より詳細な情報は WNPP ウェブページにあります。 5.9.5. パッケージを引き取る 新たなメンテナが必要なパッケージの一覧は作業が望まれるパッケージ (WNPP、Work-Needing and Prospective Packages list) で入手できます     。WNPP でリストに挙がっているパッケージのどれかに対するメンテナン スを引き継ぎたい場合には、情報と手続きについては前述のページを確 認してください。 メンテナンスされていないと思うパッケージを単純に持っていっても構 いませんか? —それはパッケージの乗っ取り (hijacking) です。できま     すが、もちろんのこと、現在のメンテナに確認をとってパッケージを持 って行って良いか尋ねましょう。メンテナが AWOL (absent without leave、無届け欠席状態) であると信ずる理由があれば、「活動的でない 、あるいは連絡が取れないメンテナに対応する」を参照してください。 一般的に、現在のメンテナの同意なしでパッケージを引き取るべきでは ありません。彼らがあなたのことを無視したのだとしても、それはパッ ケージを引き取る理由とはなりません。メンテナへの不満は開発者のメ     ーリングリストへ送られるべきです。議論が良い結論に至らない、かつ 問題が技術的なものなのであれば、技術委員会に相談することを検討し てください (より詳細については、Debian 技術委員会のページを参照し てください)。 古いパッケージを引き継いだ場合は、おそらくバグ追跡システムでパッ ケージの公式メンテナとして表示されるようにしたいことでしょう。こ れは、一旦 Maintainer 欄を更新した新しいバージョンをアップロード     すれば自動的に行われますが、アップロードが完了してから数時間はか かります。しばらくは新しいバージョンをアップロードする予定が無い 場合は、「パッケージ追跡システム」を使ってバグ報告を受け取ること ができます。しかし、以前のメンテナにしばらくの間はバグ報告が届き 続けても問題無いことを確認してください。 5.9.6. パッケージの再導入 パッケージは、リリースクリティカルのバグやメンテナ不在、不人気あ るいは全体的な品質の低さ等により削除されることがよくあります。再     導入プロセスはパッケージ化の開始時と似ていますが、あらかじめその 歴史的経緯を調べておくことにより、落し穴にはまるのをいくらか避け ることができます。 まず初めに、パッケージが削除された理由を確認しましょう。この情報 はそのパッケージの PTS ページのニュースから削除の項目か削除ログを 探すことにより見つけられます。削除のバグにはそのパッケージが削除     された理由や、そのパッケージの再導入にあたって必要なことがいくら か提示されているでしょう。パッケージの再導入ではなくどこか他のソ フトウェアの一部への乗り替えが最適であるということが提示されてい るかもしれません。 以前のメンテナに連絡を取り、パッケージの再導入のために作業してい     ないか、パッケージ共同保守に関心はないか、必要になったときにパッ ケージのスポンサーをしてくれないか、等を確認しておくと良いでしょ う。     新しいパッケージ (「新規パッケージ」) の導入前に必要なことは全て やりましょう。 利用できる中で適切な最新のパッケージをベースに作業しましょう。こ     れはunstable の最新版かもしれません。また、snapshot アーカイブに はまだ存在するでしょう。 前のメンテナにより利用されていたバージョン管理システムに有用な変 更が記録されているかもしれないので、確認してみるのは良いことです     。以前のパッケージの control ファイルにそのパッケージのバージョン 管理システムにリンクしているヘッダが無いか、それがまだ存在するか 確認してください。 (testing や stable、oldstable ではなく) unstable からパッケージが 削除されると、そのパッケージに関連するバグは全て閉じられます。閉 じられたバグを全て (アーカイブされているバグを含めて) 確認し、+rm     で終わるバージョンで閉じられていて現在でも有効なものを全て unarchive および reopen してください。有効ではなくなっているもの は修正されているバージョンがわかればすべて修正済みとしてください 。 5.10. 移植作業、そして移植できるようにすること Debian がサポートするアーキテクチャの数は増え続けています。あなた が移植作業者ではない、あるいは別のアーキテクチャを使うことが無い     という場合であっても、移植性の問題に注意を払うことはメンテナとし てのあなたの義務です。従って、あなたが移植作業者でなくても、この 章の大半を読む必要があります。 移植作業 (Porting) とは、パッケージメンテナが生成したバイナリパッ ケージの元々のアーキテクチャとは違うアーキテクチャの Debian パッ ケージをビルドする作業です。これは非常にユニークかつ極めて重要な     活動です。事実、移植作業者は実際の Debian パッケージのコンパイル の大半を行っています。例えば、メンテナが (移植可能な) ソースパッ ケージと i386 のバイナリをアップロードすると、他の各アーキテクチ ャ、11 以上の数のビルドが生成されます。 5.10.1. 移植作業者に対して協力的になる 移植作業者は、難解かつ他には無いタスクを抱えています。それは、彼 らは膨大な量のパッケージに対処する必要があるからです。理想を言え ば、すべてのソースパッケージは変更を加えないできちんとビルドでき     るべきです。残念なことに、その様な場合はほとんどありません。この 章は Debian メンテナによってよくコミットされる「潜在的な問題」の チェックリストを含んでいます — よく移植作業者を困らせ、彼らの作業 を不必要に難解にする共通の問題です。 まず初めの、そして最も重要な点は、バグや移植作業者から投げかけら れた問題に素早く回答することです。移植作業者をパッケージの副メン     テナ (co-maintainer) であるように丁重に扱ってください (ある意味、 その通りではあります)。簡潔、あるいは不明瞭なバグ報告に対して寛容 になってください。問題が何であれ、原因を捉えることに最善を尽くし てください。 移植作業者が遭遇する問題のほとんどは、何といっても、ソースパッケ     ージ内でのパッケージ作成のバグによって引き起こされます。以下は、 確認あるいは注意すべき項目のリストです。 1. debian/control 中の Build-Depends と Build-Depends-Indep の設 定が正しいことを確認してください。これを検証するのに最も良い 方法は debootstrap パッケージを使って不安定版 (unstable) の chroot 環境を作成することです (「debootstrap」参照)。chroot 環境内では、build-essential パッケージと、Build-Depends また は Build-Depends-Indep に記載されている依存パッケージをインス トールしてください。最後に、chroot 環境でパッケージの生成を試 してください。これらの手順は pbuilder パッケージで提供される 同名のプログラムの利用によって自動化することができます (「 pbuilder」参照)。 chroot を正しく設定できない場合は、dpkg-depcheck が手助けにな ることでしょう (「dpkg-depcheck」参照)。 ビルドの依存情報の指定方法については、Debian ポリシーマニュア ルを参照してください。 2. 意図がある場合以外は、アーキテクチャの値を all または any 以 外に指定しないでください。非常に多くの場合、メンテナが Debian ポリシーマニュアルの指示に従っていません。アーキテクチャを単 一のものに指定する (i386 あるいは amd64 など) は大抵誤りです 。 3. ソースパッケージが正しいことを確かめてください。ソースパッケ ージが正しく展開されたのを確認するため、dpkg-source -x package.dsc を実行してください。そして、ここでは、一からパッ ケージを dpkg-buildpackage でビルドするのに挑戦してみてくださ い。     4. debian/files や debian/substvars を含んだソースパッケージを出 していないかを確かめてください。これらは、debian/rules の clean ターゲットによって削除されるべきです。 5. ローカル環境にインストールされていたり、弄くられている設定や プログラムに依存していないことを確かめてください。例えば、/ usr/local/bin やその類のプログラムは決して呼び出してはいけま せん。特殊なやり方で設定されたプログラムには依存しないように してください。別のマシンでパッケージをビルドしてください。そ れが同じアーキテクチャであっても、です。 6. 構築中の既にインストールしてあるパッケージに依存しないでくだ さい (上記の話の一例です)。もちろん、このルールには例外はあり ますが、そのような場合には手動で一から環境を構築する必要があ り、パッケージ作成マシンで自動的に構築することはできません。 7. 可能であれば、特定のバージョンのコンパイラに依存しないでくだ さい。もし無理であれば、その制約をビルドの依存関係に反映され ているのを確認してください。だとしても異なったアーキテクチャ では時折異なったバージョンのコンパイラで統一されているので、 それでも恐らく問題を引き起こすことになるでしょう。 8. debian/rules で、Debian ポリシーマニュアルが定めるように、 binary-arch 及び binary-indep ターゲットに分かれて含まれてい ることを確かめてください。両方のターゲットが独立して動作する のを確かめてください。つまり、他のターゲットを事前に呼び出さ なくても、ターゲットを呼び出せるのを確かめるということです。 これをテストするには、dpkg-buildpackage -B を実行してください 。 5.10.2. 移植作業者のアップロード (porter upload) に関するガイドライン パッケージが移植作業を行うアーキテクチャで手を入れずに構築できる のであれば、あなたは幸運で作業は簡単です。この章は、その様な場合 に当てはめられます: きちんとアーカイブにインストールされるために     、どうやってバイナリパッケージを構築・アップロードするかを記述し ています。他のアーキテクチャでコンパイルできるようにするため、パ ッケージにパッチを当てる必要がある場合は、実際のところ、ソース NMU を行なうので、代わりに「いつ、どうやって NMU を行うか」を参照 してください。 移植作業者のアップロード (porter upload) は、ソースに何も変更を加     えません。ソースパッケージ中のファイルには触る必要はありません。 これは debian/changelog を含みます。 dpkg-buildpackage を dpkg-buildpackage -B -mporter-email として起     動してください。もちろん、porter-emailにはあなたのメールアドレス を設定します。これはdebian/rules の binary-arch を使ってパッケー ジのバイナリ依存部分のみのビルドを行います。 移植作業のために Debian マシン上で作業をしていて、アーカイブに入     れてもらうためにアップロードするパッケージにローカルでサインする 必要がある場合は、.changes に対して debsign を手軽に実行するのも できますし、dpkg-sig のリモート署名モードを使うこともできます。 5.10.2.1. 再コンパイル、あるいは binary-only NMU 時折、最初の移植作業者のアップロード作業は困難なものになります。 パッケージが構築された環境があまり良くないからです (古すぎる、使 われていないライブラリがある、コンパイラの問題、などなど…)。その     場合には、更新した環境で再コンパイルする必要があるでしょう。しか し、この場合にはバージョンを上げる必要があり、古いおかしなパッケ ージは Debian アーカイブ中で入れ替えられることになります (現在利 用可能なものよりバージョン番号が大きくない場合、dak は新しいパッ ケージのインストールを拒否します)。 binary-only NMU がパッケージをインストール不可能にしてしまってい ないことを確認する必要があります。ソースパッケージが、dpkg の     substitution 変数 $(Source-Version) を使って内部依存関係を生成し ているアーキテクチャ依存パッケージとアーキテクチャ非依存パッケー ジを生成した場合に起こる可能性があります。 changelog の変更が必要かどうかに関わらず、これらは binary-only     NMU と呼ばれます — この場合には、他の全アーキテクチャで古すぎるか どうかや再コンパイルが必要かなどを考える必要はありません。 このような再コンパイルは、特別な「magic」バージョン番号を付けるの を必要とするので、アーカイブのメンテナンスツールは、これを理解し     てくれます。新しい Debian バージョンで、対応するソースアップデー トが無くても、です。これを間違えた場合、アーカイブメンテナは (対 応するソースコードが欠落しているので) アップロードを拒否します。 再コンパイルのみの NMU への「magic」は、b番号という形式に従った、 パッケージのバージョン番号に対するサフィックスを追加することで引 き起こされます。例えば、再コンパイル対象の最新バージョンが 2.9-3     の場合、バイナリのみの NMU は 2.9-3+b1 というバージョンになる必要 があります。最新のバージョンが 3.4+b1 (つまり、ネイティブパッケー ジで、前回が再コンパイルの NMU) の場合、バイナリのみの NMU は 3.4+b2 というバージョン番号にならねばいけません。^[4] 最初の移植作業者のアップロード (porter upload) と同様に、パッケー     ジのアーキテクチャ依存部分をビルドするための dpkg-buildpackage の 正しい実行の仕方は dpkg-buildpackage -B です。 5.10.2.2. あなたが移植作業者の場合、source NMU を行う時は何時か 移植作業者は、通常は非移植作業者同様に「Non-Maintainer Upload (NMU)」にあるガイドラインに沿ってソース NMU を行います。しかし、 移植作業者のソース NMU に対する待ち時間は非移植作業者より小さくな     ります。これは、移植作業は大量のパッケージに対応する必要があるか らです。さらに、状況はパッケージがアップロードされるディストリビ ューションに依って変わります。これは、アーキテクチャが次の安定版 リリースに含められるかどうかによっても変わります。リリースマネー ジャはどのアーキテクチャが候補なのかを決定してアナウンスします。 あなたが不安定版 (unstable) へ NMU を行う移植作業者の場合、移植作 業についての上記のガイドライン、そして 2 つの相違点に従う必要があ ります。まず、適切な待ち時間です — バグが BTS へ投稿されてから NMU を行って OK になるまでの間 — 移植作業者が不安定版 (unstable)     ディストリビューションに対して行う場合は 7 日間になります。問題が 致命的で移植作業に困難を強いるような場合には、この期間は短くでき ます (注意してください。この何れもがポリシーではなく、単にガイド ラインに沿って相互に了解されているだけです)。安定版 (stable) やテ スト版 (testing) へのアップロードについては、まず適切なリリースチ ームと調整をしてください。 次に、ソース NMU を行う移植作業者は BTS へ登録したバグの重要度が serious かそれ以上であることを確認してください。これは単一のソー スパッケージが、すべての Debian でサポートされているアーキテクチ     ャでコンパイルされたことをリリース時に保証します。数多くのライセ ンスに従うため、すべてのアーキテクチャについて、単一のバージョン のバイナリパッケージとソースパッケージを持つことがとても重要です 。 移植作業者は、現在のバージョンのコンパイル環境やカーネル、libc に あるバグのために作られた単なる力業のパッチを極力回避すべきです。 この様なでっち上げの代物があるのは、仕方がないことが時折あります     。コンパイラのバグやその他の為にでっち上げを行う必要がある場合に は、#ifdef で作業したものが動作することを確認してください。また、 力業についてドキュメントに載せてください。一旦外部の問題が修正さ れたら、それを削除するのを皆が知ることができます。 移植作業者は、待ち期間の間、作業結果を置いておける非公式の置き場 所を持つこともあります。移植版を動作させている人が、待ち期間の間     であっても、これによって移植作業者による作業の恩恵を受けられるよ うになります。もちろん、この様な場所は、公式な恩恵や状況の確認を 受けることはできませんので、利用者は注意してください。 5.10.3. 移植用のインフラと自動化 パッケージの自動移植に役立つインフラストラクチャと複数のツールが     あります。この章には、この自動化とこれらのツールへの移植の概要が 含まれています。全体の情報に付いてはパッケージのドキュメントかリ ファレンスを参照してください。 5.10.3.1. メーリングリストとウェブページ     各移植版についての状況を含んだウェブページは http:// www.debian.org/ports/ から参照できます。 Debian の各移植版はメーリングリストを持っています。移植作業のメー     リングリストは http://lists.debian.org/ports.html で見ることがで きます。これらのリストは移植作業者の作業の調整や移植版のユーザと 移植作業者をつなぐために使われています。 5.10.3.2. 移植用ツール     移植用のツールの説明をいくつか「移植用ツール」で見ることができま す。 5.10.3.3. wanna-build wanna-build システムは、分散型の、クライアント・サーバでの構築配 布システムとして利用されています。通常、これは buildd プログラム     が動作しているビルドデーモンと連携して使われます。ビルドデーモン は、ビルドが必要なパッケージの一覧を受け取るために中央の wanna-build システムと通信する「slave」ホストです。 wanna-build は、まだパッケージとしては入手可能になっていません。 ですが、すべての Debian の移植作業ではパッケージ構築作業の自動化 にこれが使われています。実際のパッケージ構築に使われるツール、     sbuild はパッケージとして利用可能です。「sbuild」で説明を参照して ください。パッケージ化されたバージョンは、ビルドデーモンで使われ ているものとは同じではありませんが、問題を再現するには十分なもの である点に注意ください。 wanna-build によって生成される移植作業者にとって大抵有用であるデ     ータの多くは、ウェブ上の http://buildd.debian.org/ で入手可能です 。このデータには、毎晩更新される統計情報や、queue 情報、ビルド失 敗のログが含まれています。 我々はこのシステムを極めて誇りに思っています。何故ならば、様々な 利用方法の可能性があるからです。独立した開発グループは、実際に一     般的な用途に合うかどうか分からない異なった別アプローチの Debian にシステムを使うことができます (例えば、gcc の配列境界チェック付 きでビルドした Debian など)。そして、Debian がディストリビューシ ョン全体を素早く再コンパイルできるようにもなります。 buildd の担当である wanna-build チームには、 debian-wb-team@lists.debian.org で連絡が取れます。誰 (wanna-build     チーム、リリースチーム) に連絡を取るのか、どうやって (メール、 BTS) 連絡するのかを決めるには、http://lists.debian.org/ debian-project/2009/03/msg00096.html を参照してください。 binNMU や give-back (ビルド失敗後のやり直し) を依頼する時には、     http://release.debian.org/wanna-build.txt で記述されている形式を 使ってください。 5.10.4. あなたのパッケージが移植可能なものではない場合 いくつかのパッケージでは、Debian でサポートされているアーキテクチ ャのうちの幾つかで、構築や動作に問題を抱えており、全く移植できな     い、あるいは十分な時間内では移植ができないものがあります。例とし ては、SVGA に特化したパッケージ (i386 と amd64 のみで利用可能)や 、すべてのアーキテクチャではサポートされていないようなハードウェ ア固有の機能があります。 壊れたパッケージがアーカイブにアップロードされたり buildd の時間     が無駄に費やされたりするのを防ぐため、幾つかしなければならないこ とがあります: * まず、サポートできないアーキテクチャ上ではパッケージがビルド に失敗するのを確認しておく必要があります。これを行うには幾つ かやり方があります。お勧めの方法は構築時に機能をテストする小 さなテストスイートを用意して、動かない場合に失敗するようにす ることです。これは、全てのアーキテクチャ上で、壊れたものをア ップロードするのを防ぎ、必要な機能が動作するようになればパッ ケージがビルドできるようになる、良い考えです。 さらに、サポートしているアーキテクチャ一覧が一定量であると信 ずるのであれば、debian/control 内で any からサポートしている     アーキテクチャの一覧に変更するべきです。この方法であれば、ビ ルドが同様に失敗するようになるのに加え、実際に試すことなく人 間である読み手にサポートしているアーキテクチャが分かるように できます。 * autobuilder が必要もなくパッケージをビルドしようとしないよう に、wanna-build スクリプトが使うリストである Packages-arch-specific に追加しておく必要があります。現在のバ ージョンは http://buildd.debian.org/quinn-diff/ Packages-arch-specific から入手できます: 変更依頼をする相手は ファイルの一番上を参照してください。 サポートしていないアーキテクチャ上でビルドが失敗するようにせずに 、パッケージを単に Packages-arch-specific に付け加えるだけでは不 十分であることに注意してください: 移植作業者、あるいはあなたのパ     ッケージをビルドしようとしている他の人は、それが動かないのに気づ かないで誤ってアップロードするかもしれません。過去に、サポートさ れてないアーキテクチャ上にバイナリパッケージがアップロードされて しまった場合、削除依頼は ftp.debian.org に対するバグを登録するこ とによって行われました。 5.10.5. non-free のパッケージを auto-build 可能であるとマークする non-free セクションのパッケージは、デフォルトでは autobuilder ネ     ットワークではビルドされません (多くの場合は、パッケージのライセ ンスによって許可されていないためです)。パッケージをビルドできるよ うにするには、以下の手順を踏む必要があります: 1. 法的に許可されているか、技術的にパッケージが auto-build 可能 かどうかを確認する;     2. debian/control のヘッダ部分に XS-Autobuild: yes を追加する; 3. メールを に送り、何故パッケージ が合法的、かつ技術的に auto-build できるものなのかを説明する 5.11. Non-Maintainer Upload (NMU) すべてのパッケージには最低一人のメンテナがいます。通常、この人達 がパッケージに対して作業をし、新しいバージョンをアップロードしま す。時折、他の開発者らが新しいバージョンをアップロードできると便     利な場合があります。例えば、彼らがメンテナンスしていないパッケー ジにあるバグを修正したいが、メンテナが問題に対応するのには助けが 必要な場合です。このようなアップロードは Non-Maintainer Upload (NMU) と呼ばれます。 5.11.1. いつ、どうやって NMU を行うか     NMU を行う前に、以下の質問について考えてください: * NMU は本当にバグを修正しますか? NMU では、些細な問題の修正や パッケージ方式の変更は推奨されません。 * メンテナに十分な時間を与えましたか? BTS にバグが報告されたの は何時ですか? 一、二週間忙しいことはあり得ないことでは無いで す。そのバグはすぐに修正しなければならないほど重大ですか? そ れとも、あと数日待てるものですか? * その変更にどれくらい自信がありますか? ヒポクラテスの誓いを思 い出してください: 「何よりも、害を及ぼすことなかれ」動かない パッチを当てるよりもパッケージの重大なバグをそのままオープン な状態にしておく方が良いですし、パッチによってバグを解決する のではなく隠してしまうかもしれません。自分が 100% 何をしたの     か分かっていないのであれば、他の人からアドバイスをもらうのも 良い考えでしょう。NMU で何かを壊したのであれば、多くの人がと ても不幸になるであろうことを覚えておいてください。 * 少なくとも BTS で、NMU するのを明確に表明しましたか? 他の手段 (プライベートなメール、IRC) でメンテナに連絡をとるのも良い考 えです。 * メンテナがいつも活動的で応答してくれる場合、彼に連絡を取ろう としましたか? 大概の場合、メンテナ自身が問題に対応して、あな たのパッチをレビューする機会が与えられる方が好ましいと思われ ます。これは、NMU をする人が見落としているだろう潜在的な問題 にメンテナは気付くことができるからです。大抵、メンテナが自分 でアップロードする機会が与えられる方が、皆の時間を使うよりも 良いやり方です。 NMU をする際には、まず NMU をする意図を明確にしておかねばなりませ     ん。それから、BTS へ現在のパッケージと提案する NMU との差分をパッ チとして送付する必要があります。devscripts パッケージにある nmudiff スクリプトが役に立つでしょう。 パッチを準備している間、メンテナが利用しているであろうパッケージ 固有の慣例に注意を向けた方がいいでしょう。これを考慮に入れること     は、通常のパッケージの作業工程に対してあなたの変更が入る負担を減 らし、それに従って変更が入る可能性を高めます。パッケージ固有の慣 例がある可能性があるので探すと良い場所は、debian/README.source で す。 そうするべき十二分な理由が無い限り、メンテナに対応する時間を与え     るべきです (例えば DELAYED キューにアップロードすることによってこ れを行います)。以下が delayed キューを使う際のお勧めの値です: * 7 日以上経っているリリースクリティカルバグのみを修正するアッ プロードで、バグに対するメンテナの活動が 7 日間見られなく、修 正が行われている形跡が無い: 0 日 * 7 日以上経っているリリースクリティカルバグのみを修正するアッ     プロード: 2 日 * リリースクリティカルバグや重要なバグの修正のみのアップロード: 5 日 * 他の NMU: 10 日 この値は例に過ぎません。セキュリティ問題を修正するアップロードや     、移行を阻む些細なバグを修正するなど、いくつかのケースでは修正さ れたパッケージが不安定版 (unstable) にすぐ入るようになるのは望ま しいことです。 時々、リリースマネージャが特定のバグに対して短い delay 日数の NMU を許可を認めることがあります (7 日より古いリリースクリティカルバ グなど)。また、一部のメンテナは Low Threshold NMU list に自身を挙     げており、遅延なしの NMU アップロードを許可しています。しかしどの ような場合であっても、特にパッチが BTS で以前手に入らなかったり、 メンテナが大抵アクティブであるのを知っている場合など、アップロー ドの前にメンテナに対して数日与えるのは良い考えです。 NMU アップロード後、あなたは自分が導入したであろう問題に責任を持     つことになります。パッケージを見張らなければなりません (これを行 うには PTS 上のパッケージを購読するのが良い方法です)。 これは、軽率な NMU を行うための許可証ではありません。明らかにメン テナがアクティブで時期を逃さずパッチについて対応している場合や、     このドキュメントに書かれている推奨を無視している場合など、あなた によるアップロードはメンテナと衝突を起こすでしょう。NMU のメリッ トについて、自分が行ったことの賢明さを常に弁護できるようにしてお く必要があります。 5.11.2. NMU と debian/changelog 他の (ソース) アップロード同様、NMU は debian/changelog にそのア     ップロードで何を変更したのかを示すエントリを追加せねばなりません 。エントリの最初の行は、このアップロードが NMU であることを明白に 示す必要があります。例えばこうです:     * Non-maintainer upload.     NMU のバージョンのつけ方は、ネイティブなパッケージとネイティブで はないパッケージでは異なります。 パッケージがネイティブパッケージの場合 (バージョン番号に Debian リビジョンが付かない)、バージョンはメンテナの最後のアップロードの     バージョン + +nmuX となり、X は 1 から始まる数字になります。最後 のアップロードが同様に NMU の場合は、数字を増やします。例えば、現 在のバージョンが 1.5 だとすると、NMU はバージョンが 1.5+nmu1 にな ります。 パッケージがネイティブパッケージではない場合は、バージョン番号の Debian リビジョン部分 (最後のハイフン以下の部分) にマイナーバージ     ョン番号を追加します。例えば、現在のバージョンが 1.5-2 であれば、 NMU は 1.5-2.1 というバージョンになります。開発元のバージョンが新 しくなったものが NMU でパッケージになった場合は、Debian リビジョ ンは 0 に設定されます。例えば 1.6-0.1 です。 どちらの場合でも、最後のアップロードも NMU だった場合には数字が増     えます。例えば、現在のバージョンが 1.5+nmu3 (既に NMU されたネイ ティブパッケージ) の場合、NMU は 1.5+nmu4 というバージョンになり ます。 特別なバージョン付け方法が必要とされるのは、メンテナの作業を混乱 させるのを避けるためです。何故ならば、Debian リビジョンのために整     数を使っていると、NMU の際に既に準備されていたメンテナによるアッ プロードや、さらには ftp NEW queue にあるパッケージともぶつかる可 能性があります。これには、アーカイブのパッケージが公式メンテナに よるものではない、と視覚的に明らかにする利点もあります。 パッケージをテスト版や安定版にアップロードする場合、バージョン番 号を「分岐」する必要が時々あります。これは例えばセキュリティアッ プロードが該当します。そのため、+debXuY 形式のバージョン番号を使     うようにしてください。X はメジャーリリース番号で Y は 1 から始ま るカウンターです。例えば、Wheezy (Debian 7.0) が安定版の間は安定 版バージョン 1.5-3 のパッケージへのセキュリティ NMU ならバージョ ン 1.5-3+deb7u1 となりますが、Jessie へのセキュリティ NMU ではバ ージョン 1.5-3+deb8u1 となります。 5.11.3. DELAYED/ キューを使う NMU の許可を求めた後で待っているのは効率的ではありません。NMU し た人が作業にもどるために頭を切り替えるのに手間がかかるからです。 DELAYED キュー (「遅延アップロード」参照) は、開発者が NMU をする のに必要な作業を同時にできるようになります。例えば、メンテナに対     して更新したパッケージを 7 日後にアップロードするのを伝えるのでは なく、パッケージを DELAYED/7 にアップロードしてメンテナに対して対 応するのに 7 日間あることを伝えるべきです。この間、メンテナはもっ とアップロードを遅らせるかアップロードをキャンセルするかを尋ねる ことができます。 DELAYED キューは、無用のプレッシャーをメンテナに与えるために使わ     れるべきではありません。特に、メンテナはアップロードを自身ではキ ャンセルできないので、delay が完了する前にアップロードをキャンセ ルあるいは遅らせることができるのはあなただ、という点が重要です。 DELAYED を使った NMU を行って delay が完了する前にメンテナがパッ ケージを更新した場合には、アーカイブに既により新しいバージョンが     あるので、あなたのアップロードは拒否されます。理想的なのは、メン テナがそのアップロードであなたが提案した変更 (あるいは少なくとも 対応した問題の解決方法) を含めるのを取り仕切ることです。 5.11.4. メンテナの視点から見た NMU 誰かがあなたのパッケージを NMU した場合、これは彼らがパッケージを 良い形に保つのを助けたいと思っているということです。これによって 、ユーザへ修正したパッケージをより早く届けます。NMU した人に、パ     ッケージの副メンテナになることを尋ねるのを考えてみるのも良いでし ょう。パッケージに対して NMU を受け取るのは悪いことではありません 。それは、単にそのパッケージが他の人が作業する価値があるという意 味です。 NMU を承認するには、変更と changelog のエントリを次のメンテナアッ     プロードに含めます。バグは BTS で close されたままになりますが、 パッケージのメンテナバージョンに影響していると表示されます。 5.11.5. ソース NMU vs バイナリのみの NMU (binNMU) NMU のフルネームはソース NMU です。もう一つ別の種類があって、バイ     ナリのみの NMU (binary-only NMU) あるいは binNMU と名付けられてい ます。binNMU も、パッケージメンテナ以外の誰かによるパッケージのア ップロードです。しかし、これはバイナリのみのアップロードです。 ライブラリ (や他の依存関係) が更新された時、それを使っているパッ     ケージを再ビルドする必要があるかもしれません。ソースへの変更は必 要ないので、同じソースパッケージが利用されます。 binNMU は、通常 wanna-build によって buildd 上で引き起こされます 。debian/changelog にエントリが追加され、なぜアップロードが必要だ     ったのか、という説明と「再コンパイル、あるいは binary-only NMU」 で記述されているようにバージョン番号を増やします。このエントリは 、その次のアップロードに含めるべきではありません。 buildd は、アーカイブするために、バイナリのみのアップロードとして     、そのアーキテクチャに対してパッケージをアップロードします。厳密 に言えば、これは binNMU です。しかし、これは通常 NMU とは呼ばれず 、debian/changelog にエントリを追加しません。 5.11.6. NMU と QA アップロード NMU は、割り当てられているメンテナ以外の誰かによるパッケージのア     ップロードです。自分のものではないパッケージのアップロードについ ては、もう一つ、別の種類のアップロードがあります: QA アップロード です。QA アップロードは、放棄されたパッケージのアップロードです。 QA アップロードは、ほとんど通常のメンテナによるアップロードと同じ です: 些細な問題であっても、なんでも修正します。バージョン番号の     付け方は通常のものですし、delay アップロードをする必要もありませ ん。違いは、パッケージのメンテナあるいはアップローダとして記載さ れていない点です。また、QA アップロードの changelog のエントリは 以下のように最初の一行が特別になっています:     * QA upload. あなたが NMU をしたいと思い、かつ、メンテナが活動的ではない場合、 パッケージが放棄されてないかどうかを確認するのが賢明です (この情 報はパッケージ追跡システム (PTS) のページで表示されています)。放     棄されたパッケージに対して最初の QA アップロードを行うときは、メ ンテナは Debian QA Group に設定する必要 があります。まだ QA アップロードがされていない放棄されたパッケー ジには、以前のメンテナが設定されています。この一覧は http:// qa.debian.org/orphaned.html で手に入ります。 QA アップロードをする代わりに、メンテナをあなた自身に変更してパッ ケージを引き取ることも考えられます。放棄されたパッケージを引き取     るのには、誰からの許可も必要としません。メンテナをあなた自身に設 定して新しいバージョンをアップロードするだけです (「パッケージを 引き取る」を参照)。 5.11.7. NMU とチームアップロード パッケージングチーム (Maintainer あるいは Uploader としてメーリン グリストを使う。「共同メンテナンス」参照) の一員であるため、時々 パッケージを修正あるいは更新しているが、常にこの特定パッケージに     貢献する予定は無いので自分を Uploaders には加えたくはない、という 時があります。これがあなたのチームの方針に沿っているなら、直接 Maintainer 欄や Uploader 欄に記載せずとも通常のアップロードが可能 です。この場合、changelog のエントリを以下の行で始める必要があり ます:     * Team upload. 5.12. 共同メンテナンス 共同メンテナンス (collaborative maintenance) は、Debian パッケー ジのメンテナンス責任を数人でシェアすることを指す用語です。この共     同作業は、通常はより上質で短いバグ修正時間をもたらすので、大抵の 場合は常に良い考えです。優先度が標準 (standard) あるいは基本セッ ト (base) の一部であるパッケージは、副メンテナ (co-maintainer) を 持つことを強くお勧めします。 大抵の場合、主メンテナに加えて一人か二人の副メンテナが居ます。主     メンテナは debian/control ファイルの Maintainer 欄に名前が記載さ れている人です。副メンテナは他のすべてのメンテナで、通常 debian/ control ファイルの Uploaders に記載されています。     もっとも基本的なやり方では、新しい副メンテナの追加は大変簡単です: * 副メンテナが、あなたがビルドしたパッケージのソースにアクセスでき るように設定します。一般に、これはあなたが CVS や Subversion のよ うなネットワークを利用するバージョン管理システムを利用していると いうことを意味しています。Alioth (「Debian での FusionForge の導 入例: Alioth」参照) はこの様なツールを提供しており、他でも同様で す。     * 副メンテナの正確なメンテナ名とアドレスを debian/control ファイル の最初の段落の Uploaders 欄に追加します。 Uploaders: John Buzz , Adam Rex * PTS (「パッケージ追跡システム」) を使う場合、副メンテナは適切なソ ースパッケージの購読をする必要があります。 共同メンテナンスのもう一つの形態はチームメンテナンスです。これは 、複数のパッケージを同じ開発者グループでメンテナンスする場合にお     勧めです。その場合、各パッケージの Maintainer 欄と Uploaders 欄は 注意して扱わねばいけません。以下の二つの案からいずれかを選ぶのが お勧めです: 1. パッケージの主に担当をするチームメンバーを Maintainer 欄に追 加します。Uploaders 欄には、メーリングリストのアドレスとパッ ケージの面倒をみるチームメンバーを追加します。     2. メーリングリストのアドレスを Maintainer 欄に追加します。 Uploaders 欄には、パッケージの面倒をみるチームメンバーを追加 します。この場合、メーリングリストは (購読者以外に対するモデ レーションなどの) 人手を介さずにバグ報告を受け取ることを確認 する必要があります。 どのような場合でも、すべてのチームメンバーを Uploaders 欄に入れる のは良くない考えです。これは、Developer's Package Overview の一覧 (「Developer's packages overview」参照) を実際には対応していない パッケージで散らかしてしまい、偽りの良いメンテナンス状態を作り出     します。同じ理由から、パッケージを一回アップロードするのであれば 、「チームアップロード (Team Upload)」ができるので、チームメンバ ーは Uploaders 欄へ自分を追加する必要はありません (「NMU とチーム アップロード」参照)。逆にいえば、Maintainer 欄にメーリングリスト のアドレスのみで Uploaders 欄に誰も追加していないままにしておくの は良くない考えです。 5.13. テスト版ディストリビューション 5.13.1. 基本 通常、パッケージは不安定版 (unstable) での必要ないくつかのテスト     を潜り抜けた後で、テスト版ディストリビューション(testing) にイン ストールされます。 これらは、すべてのアーキテクチャ上で同期していなければならず、イ ンストールできなくなるような依存関係を持ってはいけません。また、     テスト版 (testing) にインストールされる際に既知のリリースクリティ カルバグを持っていない必要があります。このようにして、テスト版 (testing) は常にリリース候補に近いものである必要があります。詳細 は以下を参照してください。 5.13.2. 不安定版からの更新 テスト版 (testing) ディストリビューションを更新するスクリプトは、 日に二回、更新されたパッケージのインストール直後に動作します。こ     れらのスクリプトは britney と呼ばれます。これは、テスト版 (testing) ディストリビューションに対して Packages ファイルを生成 しますが、不整合を避けてバグが無いパッケージのみを利用しようとす る気の利いたやり方で行います。     不安定版 (unstable) からのパッケージの取り込みは以下の条件です: * パッケージは、urgency に応じて (high、medium、low)、2日、5日 、10日の間、不安定版 (unstable) で利用可能になっていなければ いけません。urgency は貼り付くことに注意してください。つまり 、前回のテスト版 (testing) への移行を考慮に入れてから最大の urgency でアップロードされるということです; * 新たなリリースクリティカルバグを持っていないこと (不安定版 (unstable)で利用可能なバージョンに影響する RC バグであって、 テスト版 (testing) にあるバージョンに影響するものではない); * あらかじめ unstable でビルドされた際に、全アーキテクチャで利     用可能になっていなくてはいけません。この情報をチェックするの に dak ls に興味を持つかもしれません; * 既にテスト版 (testing) で利用可能になっているパッケージの依存 関係を壊さないこと; * パッケージが依存するものは、テスト版 (testing) で利用可能なも のか、テスト版 (testing) に同時に受け入れられるものでなくては いけない (そして、それらは必要な条件をすべて満たしていれば、 テスト版 (testing)) に入る); * プロジェクトの状況。つまり、テスト版 (testing) ディストリビュ ーションのフリーズ中は、自動的な移行がオフになります。 パッケージがテスト版 (testing) に入る処理がされるかどうかは、テス ト版ディストリビューションのウェブページのテスト版 (testing) スク     リプトの出力を参照するか、devscripts パッケージ中の grep-excuses プログラムを使ってください。このユーティリティは、パッケージがテ スト版 (testing) への進行の通知をし続けるのに、crontab(5) で手軽 に使うことができます。 update_excuses は、なぜパッケージが拒否されたのか正確な理由を必ず しも表示しません。自分自身で何がパッケージが含まれるのを妨げてい     るのか、探す必要があるかもしれません。テスト版のウェブページが、 そのような問題を引き起こす良くある問題についての情報を与えてくれ るでしょう。 時折、相互依存関係の組み合わせが非常に難解なのでスクリプトが解決     できないことがあるため、パッケージがテスト版 (testing) に決して入 らないことがあります。詳細は下記を参照してください。 依存性についてのさらなる分析は、http://release.debian.org/     migration/ で表示されています — ですが、このページが britney が処 理した依存性ではないものも表示しているのに注意してください。 5.13.2.1. 時代遅れ (Out-of-date) テスト版 (testing) への移行スクリプトの場合、時代遅れ (outdated) というのが意味しているのは: リリースアーキテクチャに対して、複数 の異なったバージョンが不安定版 (unstable) にある (fuckedarches に     あるアーキテクチャを除く。fuckedarches は (update_out.py 中で) 更 新を行わないアーキテクチャの一覧ですが、現在のところは空になって います)。時代遅れ (outdated) の場合、テスト版 (testing) でこのパ ッケージが存在しているアーキテクチャに対して全く何もしません。     以下の例を考えてみましょう: +------------------+ |   |alpha|arm| |--------+-----+---|     |テスト版|1 |- | |--------+-----+---| |不安定版|1 |2 | +------------------+ 不安定版 (unstable) での alpha のパッケージは時代遅れになっている     ので、テスト版 (testing) に入りません。パッケージの削除は全く役に 立たず、alpha ではパッケージは時代遅れのままで、テスト版 (testing) には移行しません。     ですが、もしも ftp-master が不安定版 (unstable) のパッケージ (こ こでは arm の) を削除した場合: +----------------------------+ |   |alpha|arm|hurd-i386| |--------+-----+---+---------|     |テスト版|1 |1 |- | |--------+-----+---+---------| |不安定版|2 |- |1 | +----------------------------+ この場合、パッケージは不安定版 (unstable) ですべてのリリースアー     キテクチャで最新になります (それから、もう一つの hurd-i386 は、リ リースアーキテクチャではないので問題になりません)。 時折、すべてのアーキテクチャでまだビルドされていていないパッケー     ジを入れられるか、という質問がでてきます: いいえ。単純にいいえ、 です (glibc などをメンテしている場合を除きます)。 5.13.2.2. テスト版からの削除 時折、パッケージは他のパッケージがテスト版へ入るために削除されま す: これは、他のパッケージが他のすべての面で準備ができている場合     にテスト版に入るようにする場合のみ発生します。例えば、a が新しい バージョンの b とはインストールできない場合を考えてみましょう。そ の場合、a は b が入るために削除されるかもしれません。 もちろん、他にもテスト版 (testing) からパッケージが削除される理由     があります: バグが多すぎる場合です (そして RC バグが1個だけあるの もこの状態とみなすのには十分です)。 さらに、パッケージが不安定版 (unstable) から削除され、テスト版     (testing) にはこれに依存するパッケージがもうなくなった場合、パッ ケージは自動的に削除されます。 5.13.2.3. 循環依存 britney によってうまく取扱われない状況は、パッケージ a がパッケー     ジ b の新しいバージョンに依存していて、そしてその逆も、というもの です。     この場合の例: +---------------------------------+ | | テスト版 | 不安定版 | |-+---------------+---------------|     |a|1; depends: b=1|2; depends: b=2| |-+---------------+---------------| |b|1; depends: a=1|2; depends: a=2| +---------------------------------+     パッケージ a あるいはパッケージ b が更新対象と見做されない。 現状、このような場合はリリースチームによる手動でのヒントが必要に     なります。あなたのパッケージのどれかにこのような状況が起きた場合 は、 にメールを送って連絡を取っ てください。 5.13.2.4. テスト版 (testing) にあるパッケージへの影響 一般的に言って、不安定版 (unstable) にあるパッケージのステータス が意味するのは、不安定版 (unstable) からテスト版 (testing) へ移行 する次のバージョン2 つの例外があります: パッケージの RC バグ数が 減っている場合、RC バグが残っていてもテスト版に入る可能性がありま     す。2 つ目の例外は、テスト版 (testing) のパッケージのバージョンが 異なったアーキテクチャで同期していない場合です: その場合、すべて のアーキテクチャがソースパッケージのバージョンへとアップグレード されることがあります。ですが、これはパッケージが以前にアーキテク チャが、テスト版 (testing) への移行の際、不安定版 (unstable) にそ のアーキテクチャのバイナリパッケージが全くないという場合だけです この要旨: 影響は、テスト版 (testing) にあるパッケージが、同じパッ     ケージの新しいバージョンになるのは、新しいバージョンの方が楽にで きそうだから、ということです。 5.13.2.5. 詳細について     詳細について知りたい場合ですが、britney の動作は以下のようになり ます: パッケージが、適切な候補であるかどうかを決めるために確認が行われ ます。これによって、更新が実行されます。パッケージが候補とみなさ れない理由でもっともよくあるのは、まだ日数が経過していない (too     young)、RC バグがある、いくつかのアーキテクチャで古くなりすぎてい る、というものです。britney のこの部分では、リリースマネージャー が britney がパッケージを検討できるように、hints と呼ばれる様々な サイズのハンマーを使います (下記を参照してください)。 さて、より複雑な部分に差し掛かります: Britney が適正候補を使って テスト版 (testing) を更新しようとします。このため、britney はテス ト版ディストリビューションに個々の適正な候補を追加しようとします 。テスト版 (testing) でインストール不可能なパッケージの数が増えな     いのであれば、パッケージは受け入れられます。その時から、受け入れ られたパッケージはテスト版 (testing) の一部として取り扱われ、この パッケージを含めるためのインストールチェックテストが引き続き行わ れます。リリースチームからの hints は、実際の内容に応じて、このメ インの処理の前後に処理されます。     より詳細を見たい場合は、http://ftp-master.debian.org/testing/ update_output/ で探すことができます。 hints は、説明からも探せますが、http://ftp-master.debian.org/ testing/hints/ にあります。hints によって、Debian リリースチーム はパッケージを block あるいは unblock することや、パッケージをテ     スト版 (testing) へ移動する手間を減らしたり強制的に移動させたり、 あるいはテスト版 (testing) からパッケージを削除したり、 testing-proposed-updates へアップロードを許可したり、urgency を上 書きすることが可能になります。 5.13.3. 直接テスト版を更新する テスト版 (testing) ディストリビューションは、上記で説明したルール に従って不安定版 (unstable) からのパッケージで作られています。し     かし、時折、テスト版 (testing) の為だけに構築したパッケージをアッ プロードする必要があるという場合があります。そのためには、 testing-proposed-updates にアップロードするのが良いでしょう。 アップロードされたパッケージは自動的に処理されず、リリースマネー ジャの手によって処理される必要があることに注意してください。です     ので、アップロードするのに十分な理由があるのが望ましいでしょう。 何が十分な理由かを知るには、リリースマネージャの視点で、彼らが定 期的に に流している指示 を読む必要があります。 不安定版 (unstable) でパッケージを更新できるのであれば、 testing-proposed-updates にアップロードすべきではありません。更新 できない場合 (例えば、不安定版 (unstable) に新しい開発版がある場     合)、この機能を使うことができますが、まずはリリースマネージャから 許可を得るのが良いでしょう。パッケージがフリーズされていても、不 安定版 (unstable) 経由のアップロードが新たな依存関係を何も引き起 こさない場合、不安定版 (unstable) での更新は可能です。 バージョン番号は、通常テスト版 (testing) ディストリビューションの     コードネームと動作している番号を追加するなどして決定されます。例 えば、1.2squeeze1 はパッケージバージョン 1.2 の testing-proposed-updates への最初のアップロードです。     アップロードで、以下の項目のいずれも見落とさないように必ずしてく ださい: * 本当に testing-proposed-updates を通す必要があり、unstable で はダメなことを確認する; * 必ず、最小限な量だけの変更を含めるようにする; * 必ず changelog 中に適切な説明を含める; * 必ず、対象とするディストリビューションとして testing か testing-proposed-updates を記述している;     * 必ず不安定版 (unstable) ではなくテスト版 (testing) でパッケー ジを構築・テストしている; * バージョン番号が testing および testing-proposed-updates のも のよりも大きく、unstable のものよりも小さいのを確認する; * アップロードしてすべてのプラットフォームで構築が成功したら、< debian-release@lists.debian.org> 宛でリリースチームに連絡を取 って、アップロードを承認してくれるように依頼しましょう。 5.13.4. よく聞かれる質問とその答え (FAQ) 5.13.4.1. リリースクリティカルバグとは何ですか、どうやって数えるので すか? ある重要度以上のバグすべてが通常リリースクリティカルであると見な     されます。現在のところ、critical (致命的)、grave (重大)、serious (深刻) バグがそれにあたります。 そのようなバグは、Debian の安定版 (stable) リリース時に、そのパッ ケージがリリースされる見込みに影響があるものと仮定されます: 一般     的に、パッケージでオープンになっているリリースクリティカルバグが ある場合、そのパッケージはテスト版 (testing) に入らず、その結果安 定版 (stable) ではリリースされません。 不安定版 (unstable) でのバグのカウント数は、リリース対象アーキテ     クチャの不安定版 (unstable) で利用可能なパッケージ/バージョンの組 み合わせに適用されるとマークされたすべてのリリースクリティカルバ グです。テスト版 (testing) のバグのカウント数も同様に定義します。 5.13.4.2. どのようにすれば、他のパッケージを壊す可能性があるパッケー ジをテスト版 (testing) へインストールできますか? ディストリビューションにおけるアーカイブの構造では、一つのバージ ョンのパッケージだけを持つことができ、パッケージは名前によって定     義されています。そのため、ソースパッケージ acmefoo がテスト版 (testing) にインストールされると、付随するバイナリパッケージ acme-foo-bin、acme-bar-bin、libacme-foo1、libacme-foo-dev の古い バージョンが削除されます。 しかし、古いバージョンではライブラリに古い soname を含んだ     libacme-foo0 のようなバイナリパッケージを提供しているかもしれませ ん。古い acmefoo を削除するのは libacme-foo0 を削除することになり 、これに依存しているパッケージを壊してしまいます。 おそらく、これが主に影響するのは、一群のバイナリパッケージを変更     したのを別バージョンで提供しているパッケージ (つまり、主にライブ ラリ) でしょう。しかし、バージョン付きの依存関係が ==、<=、<< な どで宣言されているパッケージにも影響は及ぼします。 一つのソースパッケージによって提供されている一群のバイナリパッケ ージがこのようにして変更された場合、古いバイナリに依存しているす べてのパッケージは新しいバイナリに依存するように更新する必要があ ります。このようなソースパッケージをテスト版 (testing) にインスト     ールするとテスト版 (testing) で依存しているすべてのパッケージを壊 すことになるので、ここで注意をする必要があります: すべての依存し ているパッケージを更新し、インストールできるように準備しておくこ とで壊されないようにしておき、そして、すべての準備ができたら、通 常はリリースマネージャあるいはリリースアシスタントによる手動作業 が必要になります。 この様に複雑な組み合わせのパッケージで問題がある場合は、<     debian-devel@lists.debian.org> あるいは < debian-release@lists.debian.org> に連絡を取って手助けを求めてくだ さい。 ---------------------------------------------------------------------     ^[3] パッケージがどのセクションに属するかのガイドラインは Debian ポリシーマニュアルを参照してください。 ^[4] 過去においては、再コンパイルのみの状態を意味するために、この ような NMU はリビジョンの Debian 部分の三つ目の番号を使っていまし     た。しかし、この記法はネイティブパッケージの場合に曖昧で、同一パ ッケージでの再コンパイルのみの NMU と、ソース NMU と、セキュリテ ィ NMU の正しい順序が付けられなかったため、この新しい記法で置き換 えられました。 第6章パッケージ化のベストプラクティス Debian の品質は、全ての Debian パッケージが満たす必要がある基本的 要求を明示的に規定するDebian ポリシーに大きく依存しています。そし て、パッケージングでの長年の経験で溜め込まれた財産である、Debian     ポリシーを越えて共有してきた経験の積み重ねというものもあります。 多くの非常に優秀な人々が素晴らしいツールを作っており、このツール があなた、つまり Debian のメンテナが素晴らしいパッケージを作り、 維持していくのを手助けしてくれます。 この章では、Debian 開発者へのベストプラクティスをいくつか提供しま す。すべての勧めは単に勧めであり、要求事項やポリシーではありませ     ん。Debian 開発者らからの主観的なヒント、アドバイス、ポインタです 。あなたにとって一番うまくいくやり方を、どうぞご自由に選んでくだ さい。 6.1. debian/rules についてのベストプラクティス 以下の推奨事項は、debian/rules ファイルに適用されます。debian/     rules は、ビルド作業を管理し、(直接にせよ、そうでないにせよ) パッ ケージにどのファイルが入るかを選択します。大抵の場合、メンテナが 最も時間を費やすファイルです。 6.1.1. ヘルパースクリプト debian/rules でヘルパースクリプトを使う根拠は、多くのパッケージ間 でメンテナらに共通のロジックを利用・共有させるようになるからです 。メニューエントリのインストールについての問いを例にとってみまし ょう: ファイルを /usr/share/menu (必要であれば、実行形式のバイナ     リのメニューファイルの場合 /usr/lib/menu) に置き、メンテナスクリ プトにメニューエントリを登録・解除するためのコマンドを追加する必 要があります。これはパッケージが行う、非常に一般的なことです。な ぜ個々のメンテナがこれらのすべてを自分で書き直し、時にはバグを埋 め込む必要があるでしょう? また、メニューディレクトリが変更された 場合、すべてのパッケージを変更する必要があります。 ヘルパースクリプトがこれらの問題を引き受けてくれます。ヘルパース クリプトの期待するやり方に従っているならば、ヘルパースクリプトは     すべての詳細について考慮をします。ポリシーの変更はヘルパースクリ プト中で行えます; そして、パッケージを新しいバージョンのヘルパー スクリプトでリビルドする必要があるだけです。他に何の変更も必要あ りません。 付録A Debian メンテナツールの概要には、複数の異なったヘルパーが含 まれています。もっとも一般的で (我々の意見では) ベストなヘルパー システムは debhelper です。debmake のような、以前のヘルパーシステ ムはモノリシックでした: 使えそうなヘルパーの一部を取り出して選ぶ     ことはできず、何を行うにもヘルパーを使う必要がありました。ですが 、debhelper は、いくつもの分割された小さな dh_* プログラムです。 たとえば、dh_installman は man ページをインストールして圧縮し、 dh_installmenu は menu ファイルをインストールするなどします。つま り、debian/rules 内で使える部分では小さなヘルパースクリプトを使い 、手製のコマンドを使うといった十分な柔軟性を与えてくれます。 debhelper(1) を読んで、パッケージに付属している例を参照すれば、 debhelper を使い始めることができます。 dh-make パッケージ (「 dh-make」参照) の dh_make は、素のソースパッケージを debhelper化     されたパッケージに変換するのに利用できます。ですが、この近道では 個々の dh_* ヘルパーをわざわざ理解する必要がないので、満足できな いでしょう。ヘルパースクリプトを使おうとするのであれば、そのヘル パーを使うこと、つまり前提と動作を学ぶのに時間を割く必要がありま す。 6.1.2. パッチを複数のファイルに分離する 巨大で複雑なパッケージには、対処が必要なたくさんのバグが含まれて いるかもしれません。直接ソース中で大量のバグを修正し、あまり注意 を払っていなかった場合、適用した様々なパッチを識別するのは難しい     ことになるでしょう。(全てではなく) 幾つか修正を取り入れた新しい開 発元のバージョンへパッケージを更新する必要が出た場合、とても悲惨 なことになります。(例えば、.diff.gz から) diff をすべて適用するこ ともできませんし、開発元で修正されたバグごとにどのパッチをバック アウトするようにすればよいのか分かりません。 幸いなことに、ソースフォーマット“3.0 (quilt)”では、パッチシステム を設定するために debian/rules を変更することなく、パッチを分割し     て保持できるようになっています。パッチは debian/patches/ に保持さ れ、ソースパッケージが展開されるときに debian/patches/series に記 載されているパッチが自動的に適用されます。名前が指すように、パッ チは quilt で管理することができます。 より古いソースフォーマット“1.0”を使っている場合でも、パッチを分割 することは可能ですが、専用のパッチシステムを使う必要があります: パッチファイルは Debian パッチファイル (.diff.gz) 内に組み込まれ     、通常 debian/ ディレクトリ内にあります。違いは、すぐに dpkg-source では適用されないが、debian/rules の build ルールで patch ルールへの依存を通じて適用されることだけです。逆に言うと、 これらのパッチは unpatch ルールへの依存を通じて clean ルールで外 されます。 quilt はこの作業にお勧めのツールです。上記の全てを行う上、パッチ     一覧の管理も可能です。詳細な情報は quilt パッケージを参照してくだ さい。     他にもパッチを管理するツールはあります。dpatch や、パッチシステム が統合されている cdbs などです。 6.1.3. 複数のバイナリパッケージ 単一のソースパッケージはしばしば複数のバイナリパッケージを生成し ます。それは、同じソフトウェアで複数のフレーバーを提供することで     あったり (例: vim ソースパッケージ)、巨大なパッケージではなく複数 の小さなパッケージを作ったりします (例: ユーザがサブセットのみを インストールできるようにして、ディスク容量を節約できます)。 二つ目の例は、debian/rules で簡単に扱うことができます。ビルドディ レクトリからパッケージの一時ツリーへ、適切なファイルを移動する必     要があるだけです。これは、install または debhelper の dh_install を使ってできます。パッケージ間の依存関係を debian/control 内で正 しく設定したのを忘れずに確認してください。 最初の例は、同じソフトウェアでありながら異なった設定オプションで     複数回再コンパイルする必要があるので、ちょっと難しくなります。vim ソースパッケージは、手作りの debian/rules ファイルを使ってどのよ うにこの作業を扱うか、という例です。 6.2. debian/control のベストプラクティス     以下のプラクティスは、debian/control ファイルに関するものです。パ ッケージ説明文についてのポリシーを補完します。 パッケージの説明文は、control ファイルの対応するフィールドにて定 義されている様に、パッケージの概要とパッケージに関する長い説明文 の両方を含んでいます。「パッケージ説明文の基本的なガイドライン」     では、パッケージ説明文の双方の部分についての一般的なガイドライン が記述されています。それによると、「パッケージの概要、あるいは短 い説明文」が概要に特化したガイドラインを提供しており、そして「長 い説明文 (long description)」が説明文 (description) に特化したガ イドラインを含んでいます。 6.2.1. パッケージ説明文の基本的なガイドライン パッケージの説明文は平均的なユーザーに向けて書く必要があります。 平均的な人というのは、パッケージを使って得をするであろう人のこと     です。例えば、開発用パッケージであれば開発者向けですし、彼ら向け の言葉でテクニカルに記述することができます。より汎用的なアプリケ ーション、例えばエディタなどであれば、あまり技術的ではないユーザ 向けに書く必要があります。 パッケージ説明文のレビューを行った結果、ほとんどのものがテクニカ     ルである、つまり、技術に詳しくはないユーザに通じるようには書かれ てはいないという結論に達しました。あなたのパッケージが、本当に技 術に精通したユーザ用のみではない限り、これは問題です。 どうやって技術に詳しくはないユーザに対して書けばいいのでしょう? ジャーゴンを避けましょう。ユーザが詳しくないであろう他のアプリケ     ーションやフレームワークへの参照を避けましょうー GNOME や KDE に ついては、おそらくユーザはその言葉について知っているでしょうから 構いませんが、GTK+ はおそらくダメです。まったく知識がないと仮定し てみましょう。技術用語を使わねばならない場合は、説明しましょう。 客観的になりましょう。パッケージ説明文はあなたのパッケージの宣伝     場所ではありません。あなたがそのパッケージをどんなに愛しているか は関係ありません。その説明文を読む人は、あなたが気にすることと同 じことを気にはしないであろうことを覚えておいてください。 他のソフトウェアパッケージ、プロトコル名、標準規格、仕様の名前を 参照する場合には、もしあれば正規名称を使いましょう。X Windows や     X-Windows や X Window ではなく、X Window System あるいは X11 また は X を使いましょう。GTK や gtk ではなく GTK+ を使いましょう。 Gnome ではなく GNOME を使いましょう。Postscript や postscript で はなく PostScript を使いましょう。 説明文を書くことに問題があれば、<     debian-l10n-english@lists.debian.org> へそれを送ってフィードバッ クを求めるとよいでしょう。 6.2.2. パッケージの概要、あるいは短い説明文     ポリシーでは、概要行 (短い説明文) はパッケージ名を繰り返すのでは なく、簡潔かつ有益なものである必要がある、となっています。 概要は、完全な文章ではなくパッケージを記述するフレーズとして機能     します。ですので、句読点は不適切です: 追加の大文字や最後のピリオ ドは不要です。また、最初の不定冠詞や定冠詞 — "a", "an", or "the" を削る必要があります。つまり、例えば以下のようになります:     Package: libeg0 Description: exemplification support library 技術的に言えば、動詞のフレーズに対して、これは名詞のフレーズから     文章を差し引いたものです。パッケージ名と要約をこの決まり文句に代 入できるのがよい見つけ方です:     パッケージの名前は概要を提供します。 関連パッケージ群は、概要を 2 つに分けた別の書き方をした方が良いで     しょう。最初はその組一式の説明文で、その次はその組内でのパッケー ジの役割のサマリにします: Package: eg-tools Description: simple exemplification system (utilities)     Package: eg-doc Description: simple exemplification system - documentation これらの要約が、手が加えられた決まり文句に続きます。パッケージ "     名" が、"プログラム一式 (役割)" あるいは "プログラム一式 - 役割" という要約を持つ場合、要素はフレーズにすべきで、決まり文句に合う ようになります:     パッケージ名は、プログラム一式に対する役割を表しています。 6.2.3. 長い説明文 (long description) 長い説明文は、ユーザーがパッケージをインストールする前に利用可能     な最初の情報です。ユーザーがインストールするか否かを決めるのに必 要な情報を、すべて提供する必要があります。ユーザーがパッケージの 概要を既に読んでいると仮定してください。     長い説明文は、完全な文章から成る必要があります。 長い説明文の最初の段落は、以下の質問に答えている必要があります: このパッケージは何をするの? ユーザが作業を完了するのに、どのタス     クが役に立つの? ─ 技術寄りではない書き方でこれを記述するのが重要 です。もちろんパッケージの利用者が必然的に技術者ではない限り、で す。 続く段落は以下の質問に答える必要があります: 何故私はユーザーとし てこのパッケージを必要とするの? パッケージは他にどんな機能を持っ ているの? 他のパッケージと比べて、どんな特別な機能や不足している     部分があるがあるの? (例: X が必要な場合、代わりに Y を使いましょ う) このパッケージはパッケージマネージャーで管理していない、何ら かの方法で他のパッケージに関連している? (例: これは foo サーバの クライアントです) スペルミスや文法の間違いを避けるよう、注意してください。スペルチ     ェックを確実に行ってください。ispell と aspell の双方に、debian/ control ファイルをチェックするための特別なモードがあります:     ispell -d american -g debian/control     aspell -d en -D -c debian/control     通常、ユーザは以下のような疑問がパッケージ説明文で答えられること を期待しています: * パッケージは何をするの? 他のパッケージのアドオンだった場合、 パッケージがアドオンであるということを概要文に書く必要があり ます。 * なぜこのパッケージを使うべきなの? これは上記に関連しますが、 同じではありません (これはメールユーザーエージェントです; ク ールで速く、PGP や LDAP や IMAP のインターフェイスがあり、X や Y や Z の機能があります)。     * パッケージが直接インストールされるべきではないが、他のパッケ ージから引っ張ってこられる時には、付記しておく必要があります 。 * パッケージが実験的である、あるいは使われない方が良い他の理由 がある場合、同様にここに記載する必要があります。 * パッケージは競合のものと比べてどうでしょうか? より良い実装な のでしょうか? 機能がより豊富なのでしょうか? 違った機能がある のでしょうか? このパッケージを選ぶ理由は何でしょう。 6.2.4. 開発元のホームページ debian/control 中の Source セクションの Homepage フィールドへ、パ     ッケージのホームページの URL を追加することをお勧めします。この情 報をパッケージ説明文自身に追加するのは推奨されない (deprecated) であると考えられています。 6.2.5. バージョン管理システムの場所     debian/control には、バージョン管理システムの場所についての追加フ ィールドがあります。 6.2.5.1. Vcs-Browser このフィールドの値は、指定したパッケージのメンテナンスに使われて     いるバージョン管理システムのリポジトリのコピーがもしあれば、それ を指し示す http:// URL である必要があります。 この情報は、パッケージに行われた最新の作業を閲覧したいエンドユー     ザにとって有用であるのが目的です (例: バグ追跡システムで pending とタグがつけられているバグを修正するパッチを探している場合)。 6.2.5.2. Vcs-* このフィールドの値は、もし利用可能でなのであれば、指定されたパッ ケージをメンテナンスするのに使われているバージョン管理システムの 位置を明確に識別できる文字列である必要があります。* はバージョン 管理システムの識別に使われます; 現在では、以下のシステムがパッケ     ージ追跡システムによってサポートされています: arch、bzr (Bazaar) 、cvs、darcs、git、hg (Mercurial)、mtn (Monotone)、svn (Subversion)。同じパッケージについて異なった VCS を指定することも 可能です: これらはすべて PTS のウェブインターフェイスに表示されま す。 この情報は、そのバージョン管理システムについて知識があり、VCS ソ ースから現在のバージョンパッケージを生成ユーザにとって有益である よう意図されています。この情報の他の使い方としては、指定されたパ ッケージの最新の VCS バージョンを自動ビルドするなどがあるかもしれ     ません。このため、フィールドによって指し示される場所は、バージョ ンに関係なく、(そのようなコンセプトをサポートしている VCS であれ ば) メインブランチを指すのが良いでしょう。また、指し示される場所 は一般ユーザがアクセス可能である必要があります; この要求を満たす には SSH アクセス可能なリポジトリを指すのではなく、匿名アクセスが 可能なリポジトリを指すようにすることを意味します。 以下の例では、vim パッケージの Subversion リポジトリに対するフィ ールドの例が挙げられています。(svn+ssh:// ではなく) svn:// スキー     ム中で URL がどのようになっているか、trunk/ ブランチをどのように 指し示しているかに注意してください。上で挙げられた Vcs-Browser フ ィールドと Homepage フィールドの使い方も出ています。 Source: vim Section: editors Priority: optional     Vcs-Svn: svn://svn.debian.org/svn/pkg-vim/trunk/packages/vim Vcs-Browser: http://svn.debian.org/wsvn/pkg-vim/trunk/packages/vim Homepage: http://www.vim.org 6.3. debian/changelog のベストプラクティス     以下のプラクティスは changelog ファイルに対するポリシーを補完しま す。 6.3.1. 役立つ changelog のエントリを書く パッケージリビジョンに対する changelog エントリは、そのリビジョン     での変更それだけを記載します。最後のバージョンから行われた、重要 な、そしてユーザに見える形の変更を記述することに集中しましょう。 何が変更されたかについて集中しましょう — 誰が、どうやって、何時な     のか通常あまり重要ではありません。そうは言っても、パッケージ作成 について明記すべき手助けをしてくれた人々 (例えば、パッチを送って くれた人) を丁寧に明記するのを忘れないようにしましょう。 些細で明白な変更を詳細に書く必要はありません。複数の変更点を一つ のエントリにまとめることもできます。逆に言えば、大きな変更をした     場合には、あまりに簡潔にしすぎないようにしましょう。プログラムの 動作に影響を与える変更がある場合には、特に確認しておきましょう。 詳細な説明については、README.Debian ファイルを使ってください。 平易な英語を使いましょう。そうすれば読者の大半が理解できます。バ グをクローズする変更を説明する際には略語や、テクニカルな言い方や     ジャーゴンを避けましょう。特に、技術的に精通していないと思われる ユーザによって登録されたバグを閉じる際には気をつけましょう。礼儀 正しく、断言をしないように。 時折、changelog エントリに変更したファイルの名前を頭に付けたくな     ることがあります。ですが、個々のすべての変更したファイルを一覧に する必要性はありません。特に変更点が小さくて繰り返される場合です 。ワイルドカードを使いましょう。 バグに触れる際には、何も仮定しないようにしましょう。何が問題だっ     たのか、どうやってそれが直されたのかについて言い、closes: #nnnnn の文字列を追加しましょう。詳細については「新規アップロードでバグ がクローズされる時」を参照してください。 6.3.2. changelog のエントリに関するよくある誤解 changelog エントリは、一般的なパッケージ化の事柄 (ほら、foo.conf を探しているなら /etc/blah にあるよ) を記載するべきではありません     。何故なら、管理者やユーザは少なくとも Debian システム上でそのよ うなことがどのように扱われるかを多少は知らされているでしょうから 。ですが、設定ファイルの場所を変更したのであれば、それは一言添え ておくべきです。 changelog エントリでクローズされるバグは、実際にそのパッケージリ     ビジョンで修正されたものだけにすべきです。changelog で関係ないバ グを閉じるのは良くない習慣です。「新規アップロードでバグがクロー ズされる時」を参照してください。 changelog エントリは、バグ報告者との各種の議論の場 (foo をオプシ ョン bar 付きで起動した際にはセグメンテーションフォルトは見られま せん; もっと詳しい情報を送ってください)、生命、宇宙、そして万物に ついての概要 (すいませんが、このアップロードに時間がかかったので     風邪をひきました)、手助けの求め (このパッケージのバグ一覧は巨大で す、手を貸してください) に使うべきではありません。そのようなこと は、大抵の場合対象としている読者は気づくことが無く、パッケージで 実際にあった変更点の情報について読みたい人々を悩ますことでしょう 。どの様にバグ報告システムを使えばいいのかについて、詳細な情報は 「バグへの対応」を参照してください。 正式なメンテナによるアップロードの changelog エントリの最初で、 non-maintainer upload で修正されたバグを承認するのは、古い慣習で     す。今はバージョン管理を行っているので、NMU された changelog エン トリを残しておいて自分の changelog エントリ中でその事実に触れるだ けで十分です。 6.3.3. changelog のエントリ中のよくある間違い     以下の例で、changelog エントリ中のよくある間違いや間違ったスタイ ルの例を挙げます。     * Fixed all outstanding bugs.     これは、全く読み手に何も有用なことを教えてくれません。     * Applied patch from Jane Random.     何についてのパッチですか?     * Late night install target overhaul.     何をオーバーホールしてどうなったのですか? 深夜というのに言及して いるのは、私たちにこのコードを信用するなと言いたいのですか?     * Fix vsync FU w/ ancient CRTs. 略称が多すぎます。そして、ええっと、fsckup (あぁ、ひどい言葉!) は     実際何だったのか、あるいはどうやって修正したのかがまったく明らか ではありません。     * This is not a bug, closes: #nnnnnn. まず初めに、この情報を伝えるためにパッケージをアップロードする必     要は、全くありません; 代わりにバグ追跡システムを使ってください。 次に、何故この報告がバグではなかったのかについての説明がありませ ん。     * Has been fixed for ages, but I forgot to close; closes: #54321. 何らかの理由で以前の changelog エントリ内でバグ番号について触れて いなかったとしても、何も問題はありません。単にいつも通りに BTS で     バグをクローズしてください。修正の記述が既にあるものと考えて、 changelog ファイルに触れる必要はありません (これは、開発元の作者 ／メンテナによる修正にも同様に適用されます。彼らがずっと前に修正 したバグを、あなたの changelog 内で追いかける必要はありません)。     * Closes: #12345, #12346, #15432     説明はどこ? 説明文を考えられないのなら、それぞれのバグのタイトル を入れるところから始めてください。 6.3.4. NEWS.Debian ファイルで changelog を補足する パッケージの変更に関する重要なニュースは NEWS.Debian ファイルにも 書くことができます。このニュースは apt-listchanges のようなツール で、残りすべての changelog の前に表示されます。これは、ユーザにパ     ッケージ内の著しい変更点について知らせるのに好ましいやり方です。 インストール後にユーザが一旦戻って NEWS.Debian ファイルを参照でき るので、debconf の notes を使うより良いです。そして、目立った変更 点を README.Debian に列挙するより良いです。何故ならば、ユーザは容 易にそのような注意書きを見逃すからです。 ファイル形式は debian changelog ファイルと同じですが、アスタリス ク (*) を取って各ニュースを changelog に書くような簡潔な要約では     なく、必要に応じて完全な段落で記述してください。changelog のよう にビルド中に自動的にはチェックされないので、ファイルを dpkg-parsechangelog を実行してチェックするのは良い考えです。実際 の NEWS.Debian ファイルの例が、以下になります: cron (3.0pl1-74) unstable; urgency=low The checksecurity script is no longer included with the cron package:     it now has its own package, checksecurity. If you liked the functionality provided with that script, please install the new package. -- Steve Greenland Sat, 6 Sep 2003 17:15:03 -0500 NEWS.Debian ファイルは /usr/share/doc/package/NEWS.Debian.gz ファ イルとしてインストールされます。圧縮されていて、Debian ネイティブ     パッケージ中でも常にこの名前です。debhelper を使う場合は、 dh_installchangelogs が debian/NEWS ファイルをインストールしてく れます。 changelog ファイルと違って、毎回のリリースごとに NEWS.Debian ファ イルを更新する必要はありません。何か特にユーザが知るべき目新しい     ことがあったときにのみ、更新してください。全くニュースがない場合 、NEWS.Debian ファイルをパッケージに入れてリリースする必要はあり ません。便りが無いのは良い知らせ、です (No news is good news!)。 6.4. メンテナスクリプトのベストプラクティス メンテナスクリプトには debian/postinst、debian/preinst、debian/ prerm、debian/postrm ファイルが含まれます。これらのスクリプトは、     単なるファイルやディレクトリの作成や削除では扱われない、パッケー ジのインストールと削除のセットアップの面倒をみます。以下の説明は 、Debian ポリシーを補完します。 メンテナスクリプトは冪等でなければなりません。これは、通常は 1 回     呼ばれるスクリプトが 2 回呼ばれた場合、何も悪いことが起きないのを 保証する必要があるという意味です。 標準入出力はログの取得のためにリダイレクトされることがあります     (例: パイプへ向けられる)。ですので、これらが tty であることに依存 してはいけません。 質問や対話的な設定はすべて最小限に止めておく必要があります。必要     になった時は、インターフェイスに debconf パッケージを使いましょう 。どのような場合でも、質問は postinst スクリプトの configure 段階 にのみ、配置することができます。 メンテナスクリプトは、できる限りシンプルなものにしておきましょう 。我々は、あなたは純粋な POSIX シェルスクリプトを使っているものだ と考えています。覚えておいて欲しいのですが、何かしら bash の機能     が必要になったら、メンテナスクリプトは bash のシェバン行にしてお く必要があります。スクリプトへ簡単にちょっとした変更を追加するの に debhelper を使えるので、Perl より POSIX シェル、あるいは Bash の方が好まれます。 メンテナスクリプトを変更したら、パッケージの削除や二重インストー ル、purge のテストを確認してください。purge されたパッケージが完     全に削除されたことを確認してください。つまり、メンテナスクリプト 中で直接／間接を問わず作成されたファイルを削除する必要があるとい うことです。     コマンドの存在をチェックする必要がある場合は、このような感じで行 います     if [ -x /usr/sbin/install-docs ]; then ...     メンテナスクリプト中でコマンドの path をハードコードしたくない場 合には、以下の POSIX 互換シェル機能が役立つでしょう: pathfind() { OLDIFS="$IFS" IFS=: for p in $PATH; do if [ -x "$p/$*" ]; then     IFS="$OLDIFS" return 0 fi done IFS="$OLDIFS" return 1 } コマンド名を引数として渡すことで、$PATH の検索するのにこの関数を     使うことができます。コマンドが見つかった場合は true (ゼロ) を返し 、そうでない場合は false を返します。command -v、type、which は POSIX に無いので、これがもっとも汎用性の高いやり方です。 which は、Required となっている debianutils パッケージにあるので 、別解として利用可能ですが、ルートパーティションにありません。つ     まり、/usr/bin にあって /bin ではないので、/usr パーティションが マウントする前に走るスクリプトの中では使えないということです。ほ とんどのスクリプトは、この問題を持つようなことはありませんが。 6.5. debconf による設定管理 debconf は、(主に postinst をはじめとする) すべての様々なパッケー ジスクリプトが、ユーザはどの様にパッケージを設定したいのかという     フィードバックを問い合わせるのに使うことが可能な設定管理システム です。直接ユーザとの対話処理は、debconf での処理の方を選んだので 、現状では避けるべきです。これにより、将来には非対話的なインスト ールが可能になる予定です。 debconf は素晴らしいツールですが、しばしば適当に扱われています。     多くの共通する失敗は、debconf-devel(7) man ページに記載されていま す。これは、debconf を使うのを決めた時、あなたが読むべきものです 。また、ここではベストプラクティスを記述しています。 これらのガイドラインは、ディストリビューションの一部 (例えば、イ     ンストールシステム) に関する、より明確な推奨と同様に、幾つかの書 き方と体裁に関する推奨、そして debconf の使い方についての一般的な 考慮すべき事柄を含んでいます。 6.5.1. debconf を乱用しない debconf が Debian に現れて以来、広く乱用され続けています。そして     、debconf の乱用によって、ちょっとしたものをインストールする前に 、大量の質問に答える必要があることに由来するいくつもの非難が Debian ディストリビューションに寄せられました。 使い方のメモは載せるべきところへ載せましょう: NEWS.Debian、または README.Debian ファイルです。notes はパッケージのユーザビリティに     直接影響する重要な記述にだけ使いましょう。notes は確認する (ある いはメールでユーザを悩ます) まで、インストールを常にブロックする ことを覚えておいてください。 メンテナスクリプト中の質問の優先度を注意深く選びましょう。優先度     の詳細については、debconf-devel(7) を参照してください。ほとんどの 質問は優先度が medium あるいは low を使うべきです。 6.5.2. 作者と翻訳者に対する雑多な推奨 6.5.2.1. 正しい英語を書く ほとんどの Debian パッケージメンテナはネイティブの英語話者ではあ     りません。ですので、正しいフレーズのテンプレートを書くのは彼らに とっては容易ではありません。 メーリングリストを利用して     ください (むしろ乱用してください)。テンプレートを査読してもらいま しょう。 下手に書かれたテンプレートは、パッケージに対して、そしてあなたの     作業に対して、さらには Debian それ自体にすら対して、悪い印象を与 えます。 可能な限り技術的なジャーゴンを避けましょう。いくつかの用語があな     たにとっては普通に聞こえても、他の人には理解不可能かもしれません 。避けられない場合には、 (説明文を使って) 解説してみましょう。そ の場合には、冗長さとシンプルさのバランスを取るようにしましょう。 6.5.2.2. 翻訳者へ丁寧に接する debconf テンプレートは翻訳されるでしょう。debconf、そして関連する     姉妹パッケージ po-debconf は、テンプレートを翻訳チームやさらには 個人が翻訳できるようにする、シンプルなフレームワークを提供します 。 gettext ベースのテンプレートを使ってください。開発用のシステムに     po-debconf をインストールしてドキュメントを読みましょう (man po-debconf が取っ掛かりとして良いでしょう)。 テンプレートを頻繁に変更しすぎることを避けましょう。テンプレート 文の変更は、翻訳を fuzzy にして、さらなる作業を翻訳作業者に強いま     す。fuzzy になっている翻訳文は、翻訳されてから元の文章が変更され た文字列であり、使えるようにするには翻訳作業者による若干の更新が 必要なものです。変更点が十分に小さい場合、fuzzy とマークされます が、元の翻訳文は PO ファイル中に保持されます。 大本のテンプレートを変更する予定がある場合、po-debconf パッケージ で提供されている、podebconf-report-po という名の通知システムを使 って翻訳作業者にコンタクトを取ってください。ほとんどのアクティブ     な翻訳作業者たちはとても反応が良く、変更を加えたテンプレートに対 応するための作業をしてくれ、あなたが追加でアップロードする必要を 減らしてくれます。gettext ベースのテンプレートを使っている場合、 翻訳作業者の名前とメールアドレスは PO ファイルのヘッダに表示され ており、podebconf-report-po によって使われます。     このユーティリティの使い方のお勧めの使い方:     cd debian/po && podebconf-report-po --call --languageteam --withtranslators --deadline="+10 days" このコマンドは、まず debian/po にある PO ファイルと POT ファイル を debian/po/POTFILES.in に記載しているテンプレートファイルを使っ て同期します。そして、 メーリングリ     ストに call for new translations (新しい翻訳作業の募集) を送信し ます。最後に、call for translation updates (翻訳更新作業者の募集) を (各 PO ファイルの Language-Team 欄に記載されている) 各言語チー ムおよび (Last-translator に記載されている) 最後の翻訳者に送信し ます。 翻訳作業者に締切りを伝えるのは常にお勧めです。それによって、彼ら は作業を調整できます。いくつかの翻訳作業チームは形式化された翻訳     ／レビュープロセスを整えており、10 日未満の猶予は不合理であると考 えられています。より短い猶予期間は強すぎるプレッシャーを翻訳チー ムに与えるので、非常に些細な変更点に対してのみに留めるべきです。 迷った場合は、該当の言語の翻訳チーム     (debian-l10n-xxxxx@lists.debian.org) か < debian-i18n@lists.debian.org> にも問い合わせましょう。 6.5.2.3. 誤字やミススペルを修正する際に fuzzy を取る debconf テンプレートの文章が修正されて、その変更が翻訳に影響しな     いと確信している場合には、翻訳作業者を労って翻訳文を fuzzy を取り 除いてください。     そうしないと、翻訳作業者が更新をあなたに送るまでテンプレート全体 は翻訳されていない状態になります。     翻訳をfuzzy ではなくすために、(po4a パッケージの一部である) msguntypot を使うことができます。 1. POT ファイルと PO ファイルを再生成する。 debconf-updatepo 2. POT ファイルのコピーを作成する。 cp templates.pot templates.pot.orig 3. すべての PO ファイルのコピーを作成する。 mkdir po_fridge; cp *.po po_fridge 4. debconf テンプレートファイルを誤字修正のために変更する。 5. POT ファイルと PO ファイルを再生成する (もう一度)。 debconf-updatepo     この時点では、typo 修正はすべての翻訳を fuzzy にしており、こ の残念な変更はメインディレクトリの PO ファイルと fridge の PO ファイルのみに適用されている。ここではどの様にしてこれを解決 するかを示す。 6. fuzzy になった翻訳を捨て、fridge から作り直す。 cp po_fridge/*.po . 7. 手動で PO ファイルと新しい POT ファイルをマージするが、不要な fuzzy を考慮に入れる。 msguntypot -o templates.pot.orig -n templates.pot *.po 8. ゴミ掃除。 rm -rf templates.pot.orig po_fridge 6.5.2.4. インターフェイスについて仮定をしない テンプレートのテキストは、debconf のインターフェイスに属するウィ     ジェットには言及してはいけません。「はい」と答えた場合には... の ような文章は、2 択の質問に対してチェックボックスを使うようなグラ フィカルインターフェイスのユーザには何の意味もありません。 文字列テンプレートは、説明文中でのデフォルト値について言及するこ     とも避けましょう。まず、ユーザによってそして、デフォルト値はメン テナの考え方によって違う場合があるからです (たとえば、debconf デ ータベースが preseed で指定されている場合など)。     より一般的に言うと、ユーザの行動を参照させるのを避けるようにしま しょう。単に事実を与えましょう。 6.5.2.5. 一人称を使わない (I will do this... や We recommend... などの) 一人称の利用を避け ましょう。コンピュータは人ではなく、debconf テンプレートは Debian 開発者を代弁するものではありません。中立的な解釈を行いましょう。     あなたが科学論文を書いたことがあるならば、論文を書くのと同様にテ ンプレートを書きましょう。ですが、可能であれば This can be enabled if... ではなく Enable this if ... などとして生の声を届け るようにしましょう。 6.5.2.6. 性差に対して中立であれ     世界は、男と女によって成り立っています。記述の際には、性差に対し て中立な書き方を行ってください。 6.5.3. テンプレートのフィールド定義     この章の情報は、ほとんどを debconf-devel(7) マニュアルページから 得ています。 6.5.3.1. Type 6.5.3.1.1. string     ユーザがどのような文字列でも記述可能な自由記述形式の入力フィール ドの結果。 6.5.3.1.2. password ユーザにパスワードの入力を求めます。これを使う場合は注意して使っ     てください: ユーザが入力したパスワードは debconf のデータベースに 書き込まれることに注意してください。おそらく、この値をデータベー スから可能な限り早く消す必要があります。 6.5.3.1.3. boolean     true/false の選択です。注意点: true/false であって、yes/no ではあ りません... 6.5.3.1.4. select 複数の値から一つを選びます。選択するものは 'Choices' というフィー     ルド名で指定されている必要があります。利用可能な値をコンマとスペ ースで区切ってください。以下のようになります: Choices: yes, no, maybe 選択肢が翻訳可能な文字列である場合、'Choices' フィールドは     __Choices を使って翻訳可能であることを示しておくと良いでしょう。2 つのアンダースコアは、各選択肢を分かれた文字列に分割してくれます 。     po-debconf システムは、翻訳可能ないくつかの選択肢のみをマークする 面白い機能を提供してくれます。例: Template: foo/bar Type: Select     #flag:translate:3 __Choices: PAL, SECAM, Other _Description: TV standard: Please choose the TV standard used in your country. この例では、他は頭文字から構成されていて翻訳できませんが、'Other'     文字列だけは翻訳可能です。上記では 'Other' だけが PO および POT ファイルに含めることができます。 debconf テンプレートのフラグシステムは、この様な機能をたくさん提     供します。po-debconf(7) マニュアルページでは、これらの利用可能な 機能をすべて列挙しています。 6.5.3.1.5. multiselect select データ型とそっくりですが、ユーザが選択肢一覧からいくつでも     項目を選べる (あるいはどれも選ばないこともできる) 点だけが違いま す。 6.5.3.1.6. note 本来質問ではありませんが、このデータ型が示すのはユーザに表示する ことができる覚え書きです。debconf はユーザが必ず参照するようにす     るため、多大な苦痛を与えることになる (キーを押すためにインストー ルを休止したり、ある場合にはメモをメールさえする) ので、ユーザが 知っておく必要がある重要な記述にのみ使うべきです。 6.5.3.1.7. text     この type は現状では古すぎるものと考えられています: 使わないでく ださい。 6.5.3.1.8. error この type はエラーメッセージを取り扱うためにデザインされています     。ほとんど note 型と似通っています。違いはフロントエンドが存在し ているであろうことです (例えば、cdebconf の dialog フロントエンド は通常の青い画面ではなく、赤い画面を描画します)。     何かを補正するためにユーザの注意を引く必要があるメッセージに対し 、この type を使うのがお勧めです。 6.5.3.2. Description: short および extended 説明文 テンプレート説明文は 2 つのパートに分かれます: short と extended     です。短い説明文 (short description) はテンプレートの Description: 行にあります。 短い説明文は、ほとんどの debconf インターフェイスに適用するように     、短く (50 文字程度に) しておく必要があります。通常、翻訳はオリジ ナルよりも長くなる傾向にあるので、短くすることは翻訳作業者を助け ます。 短い説明文はそれ単体で成り立つようにしておく必要があります。いく     つかのインターフェイスは、デフォルトでは長い説明文を表示せず、ユ ーザが明示的に尋ねたときに表示するか、あるいは全く表示しません。 「What do you want to do?」のような表現を避けてください。     短い説明文は完全な文章である必要はありません。これは文章を短くし ておき、効率的に推奨を行うためです。 拡張された説明文 (extended description) は、短い説明文を一語一句 繰り返しをしてはなりません。長い説明文章を思いつかなければ、まず     、もっと考えてください。debian-devel に投稿しましょう。助けを求め ましょう。文章の書き方講座を受講しましょう! この拡張された説明文 は重要です。もし、まったく何も思いつかなければ、空のままにしてお きましょう。 拡張された説明文は完全な文章である必要があります。段落を短くして     おくのは可読性を高めます。同じ段落で 2 つの考えを混ぜてはいけませ ん。代わりに別の段落を書きます。 あまり冗長にしないようにしてください。ユーザは長すぎる画面を無視 しようとします。経験からすると、20 行が越えてはならない境界です。     何故ならば、クラシックなダイアログインターフェイスでは、スクロー ルする必要がでてくることになり、そして多くの人がスクロールなどし ないからです。     拡張された説明文では、質問を含めては決していけません。     テンプレートの type (string、boolean など) に応じた特別なルールに ついては、以下を読んでください。 6.5.3.3. Choices このフィールドは select あるいは multiselect 型に使ってください。     これには、ユーザに表示される可能な選択肢が含まれます。これらの選 択肢はコンマで区切る必要があります。 6.5.3.4. Default このフィールドはオプションです。これには、string、select あるいは     multiselect のデフォルトでの答えが含まれます。multiselect テンプ レートの場合、コンマで区切られた選択肢一覧が含まれます。 6.5.4. テンプレートのフィールド固有スタイルガイド 6.5.4.1. Type フィールド     特別な指定はありません。一点だけ、その前のセクションを参照して適 切な type を使ってください。 6.5.4.2. Description フィールド     以下は、テンプレートの型に応じて適切な Description (short および extended) を書くための特別な指示です。 6.5.4.2.1. String/password テンプレート * 短い説明文は、プロンプトであってタイトルではありません。質問 形式のプロンプト (IP アドレスは?) を避け、代わりに閉じていな い形のプロンプト (IP アドレス:) を使ってください。コロン (:) の使用をお勧めします。     * 拡張された説明文は、短い説明文を補足します。拡張の部分では、 長い文章を使って同じ質問を繰り返すのではなく、何を質問されて いるのかを説明します。完全な文章を書いてください。簡潔な書き 方は強く忌避されます。 6.5.4.2.2. Boolean テンプレート * 短い説明文は、短いままで大抵の場合は ? で終わる質問の体裁の言 い回しをせねばなりません。簡潔な書き方は許されており、質問が 若干長い場合は推奨されすらしています (翻訳文は、大抵の場合原     文よりも長くなるのを覚えておきましょう)。 * 繰り返しますが、特定のインターフェイスのウィジェットを参照す るのを避けてください。このようなテンプレートで良くある間違い は、「はい」と答える形かどうかです。 6.5.4.2.3. Select/Multiselect * 短い説明文は、プロンプトであってタイトルではありません。「 Please choose...」のような意味の無い文章を文章を使わないでく ださい。ユーザは何かを選ぶ必要があるくらいには十分賢いです... :)     * 拡張された説明文は、短い説明文を完備します。これでは、利用可 能な選択肢に言及することがあります。テンプレートが multiselect なものの場合、ユーザが選べる選択肢が 1 つではない ことについても言及するかもしれません (インターフェイスが大抵 これを明確にはしてくれますが)。 6.5.4.2.4. Note * 短い説明文はタイトルとして扱われます。 * 拡張された説明文では、note のより詳細な説明を表示します。フレ ーズで、簡潔過ぎない書き方です。 * debconf を乱用しないでください。 note は、debconf の乱用で最     も良く使われます。debconf-devel マニュアルページに書かれてい ます: とても深刻な問題について警告する場合のみに使うのがベス トです。多くの覚え書きについては、NEWS.Debian ファイルや README.Debian ファイルが適切な場所です。もし、これを読んで、 Note 型のテンプレートを NEWS.Debian あるいは README.Debian 中 のエントリに変換することを考えた場合、既存の翻訳を捨てないこ とを検討してください。 6.5.4.3. Choices フィールド もし Choise が頻繁に変わるようであれば、__Choices という使い方を     するのを検討してください。これは個々の選択項目を単一の文字列に分 割するので、翻訳作業者が作業を行うのを助けてくれると考えられてい ます。 6.5.4.4. Default フィールド select のテンプレートで、デフォルト値がユーザの言語に応じて変化す     るようであれば、_Default という使い方をしてください (例えば、選択 肢が言語の選択の場合等) 。 この特別なフィールドによって、翻訳作業者は言語に応じたもっとも適     切な選択肢を挿入することができるようになります。彼らの言語が選択 された場合にデフォルトの選択になりますが、英語を使うときには最初 に提示された Default Choice が使われます。     geneweb パッケージのテンプレートを例にとってみましょう: Template: geneweb/lang Type: select __Choices: Afrikaans (af), Bulgarian (bg), Catalan (ca), Chinese (zh), Czech (cs), Danish (da), Dutch (nl), English (en), Esperanto (eo), Estonian (et), Finnish (fi), French (fr), German (de), Hebrew (he), Icelandic (is), Italian (it), Japanese (ja), Latvian (lv), Norwegian (no), Polish (pl), Portuguese (pt), Romanian (ro), Russian (ru), Spanish (es), Swedish (sv) # This is the default choice. Translators may put their own language here     # instead of the default. # WARNING : you MUST use the ENGLISH NAME of your language # For instance, the french translator will need to put French (fr) here. _Default: English[ translators, please see comment in PO files] _Description: Geneweb default language: ブラケットを使うと、debconf のフィールド中に内部コメントができる     ことに注意してください。コメントの利用は、翻訳作業者が作業するフ ァイルに表示されるのにも注意ください。     _Default を使うやり方は、若干混乱するのでコメントが必要です: 翻訳 者は自身の選択肢を書きます。 6.5.4.5. Default フィールド     空のデフォルトフィールドを使っては「いけません」。デフォルト値を 設定したくないのであれば、Default は使うべきではありません。 po-debconf を使うのであれば (そして使うべきです、「翻訳者へ丁寧に     接する」参照)、このフィールドが翻訳できるのであれば、翻訳可能な状 態にするのを検討しましょう。 (例えば言語選択のデフォルト値など) デフォルト値が言語／地域に応じ     て変化するようであれば、po-debconf(7) に記載されている特別な _Default 型を使うことを考えましょう。 6.6. 国際化 この章では、開発者に対して、翻訳作業者の作業がより楽になるように     するための大まかな情報を含めています。国際化について興味を持って いる翻訳作業者と開発者への詳細な情報は、Internationalisation and localisation in Debian で入手できます。 6.6.1. debconf の翻訳を取り扱う 移植作業者同様に、翻訳作業者は難しい課題を抱えています。多くのパ ッケージについて作業を行い、多くの異なったメンテナと共同作業をす     る必要があります。さらには、ほとんどの場合、彼らはネイティブな英 語話者ではないので、あなたは特に忍耐強くあらねばいけないでしょう 。 debconf のゴールはメンテナとユーザにとってパッケージ設定を簡単に することでした。元々、debconf テンプレートの翻訳は debconf-mergetemplate で行われていました。しかし、このやり方は現     在は非推奨 (deprecated) です; debconf の国際化を成し遂げる最も良 いやり方は、po-debconf パッケージを使うことです。このやり方はメン テナと翻訳者の双方にとって、より楽なやり方です; 移行スクリプトが 提供されています。 po-debconf を使うと、翻訳は .po ファイルに収められます (gettext による翻訳技術からの引き出しです)。特別なテンプレートファイルには 、元の文章と、どのフィールドが翻訳可能かがマークされています。翻 訳可能なフィールドの値を変更すると、debconf-updatepo を呼び出すこ     とで、翻訳作業者の注意が必要なように翻訳にマークがされます。そし て、生成時には dh_installdebconf プログラムが、テンプレートに加え 、最新の翻訳をバイナリパッケージに追加するのに必要となる魔法につ いて、すべての面倒を見ます。詳細は po-debconf(7) マニュアルページ を参照してください。 6.6.2. ドキュメントの国際化 ドキュメントの国際化はユーザにとって極めて重要ですが、多くの労力     がかかります。この作業をすべて除去する方法はありませんが、翻訳作 業者を気楽にはできます。 どのようなサイズであれドキュメントをメンテナンスしている場合、翻 訳作業者がソースコントロールシステムにアクセスできるのであれば、 彼らの作業が楽になるでしょう。翻訳作業者が、ドキュメントの 2 つの バージョン間の違いを見ることができるので、例えば、何を再翻訳すれ ばいいのかがわかるようになります。翻訳されたドキュメントは、翻訳 作業がどのソースコントロールリビジョンをベースにしているのかとい     う記録を保持しておくことをお勧めします。debian-installer パッケー ジ中の doc-check では興味深いシステムが提供されています。これは、 翻訳すべき現在のリビジョンのファイルに対する構造化されているコメ ントを使って、指定されたあらゆる言語の翻訳状況の概要を表示し、翻 訳されたファイルについては、翻訳がベースにしているオリジナルのフ ァイルのリビジョンを表示します。自分の VCS 領域でこれを導入して利 用した方が良いでしょう。 XML あるいは SGML のドキュメントをメンテナンスしているのであれば 、言語非依存の情報を分離し、それらをすべての異なった翻訳に含まれ     る分割されたファイルにエンティティとして定義した方が良いでしょう 。これは、URL を複数のファイル間で最新に保つなど、作業をより楽に してくれます。 いくつかのツール (例: po4a、poxml、translate-toolkit) は異なった 形式から翻訳可能な素材を展開するのに特化しています。これらは、翻     訳作業者には極めて馴染み深い形式である PO ファイルを生成します。 これによって、翻訳したドキュメントが更新された際に何を再翻訳すれ ばよいのかを見ることを可能にしてくれます。 6.7. パッケージ化に於ける一般的なシチュエーション 6.7.1. autoconf/automake を使っているパッケージ autoconf の config.sub および config.guess を最新に保ちつづけるの は、移植作業者、特により移行中の状況であるアーキテクチャの移植作 業者にとって非常に重要です。autoconf や automake を使うあらゆるパ     ッケージについてのとても素晴らしいパッケージ化における教訓が autotools-dev パッケージの /usr/share/doc/autotools-dev/ README.Debian.gz にまとめられています。このファイルを読んで書かれ ている推奨に従うことを強くお勧めします。 6.7.2. ライブラリ ライブラリは様々な理由から常にパッケージにするのが難しいです。ポ リシーは、メンテナンスに楽にし、新しいバージョンが開発元から出た     際にアップグレードを可能な限りシンプルであることを確保するため、 多くの制約を課しています。ライブラリでの破損は、依存している何十 ものパッケージの破損を招き得ます。     ライブラリのパッケージ化の良い作法が the library packaging guide にまとめられています。 6.7.3. ドキュメント化     ドキュメント化のポリシーに忘れず従ってください。 あなたのパッケージが XML や SGML から生成されるドキュメントを含ん     でいる場合、XML や SGML のソースをバイナリパッケージに含めてリリ ースしないことをお勧めします。ユーザがドキュメントのソースを欲し い場合には、ソースパッケージを引っ張ってくれば良いのです。 ポリシーではドキュメントは HTML 形式でリリースされるべきであると 定めています。我々は、もし手がかからないで問題ない品質の出力が可     能であれば、ドキュメントを PDF 形式とテキスト形式でもリリースする ことをお勧めしています。ですが、ソースの形式が HTML のドキュメン トを普通のテキスト版でリリースするのは、大抵の場合は適切ではあり ません。 リリースされたメジャーなマニュアルは、インストール時にdoc-baseで     登録されるべきです。詳細については、doc-base パッケージのドキュメ ントを参照してください。 Debian ポリシー (12.1 章) では、マニュアルページはすべてのプログ ラム・ユーティリティ・関数に対して付属すべきであり、設定ファイル     のようなその他のものについては付属を提案を示しています。もし、あ なたがパッケージングをしているものがそのようなマニュアルページを 持っていない場合は、パッケージに含めるために記述を行い、開発元 (upstream) へ送付することを検討してください。 manpage は直接 troff 形式で書く必要はありません。よく使われるソー     ス形式は、Docbook、POD、reST で、それぞれ xsltproc、pod2man、 rst2man を使うことで変換できます。少なくとも、スタブを書くために help2man プログラムを使うことは可能です。 6.7.4. 特定の種類のパッケージ     いくつかの特定の種類のパッケージは、特別なサブポリシーと対応する パッケージ化ルールおよびプラクティスを持っています: * Perl 関連パッケージは、Perl ポリシーがあり、このポリシーに従 っているパッケージの例が libdbd-pg-perl (バイナリ perl モジュ ール) または libmldbm-perl (アーキテクチャ非依存 perl モジュ ール) です。 * Python 関連パッケージは、python ポリシーを持っています; python パッケージ中の /usr/share/doc/python/ python-policy.txt.gz を参照してください。 * Emacs 関連パッケージには、emacs ポリシーがあります。     * Java 関連パッケージには、java ポリシーがあります。 * Ocaml 関連パッケージは、固有のポリシーを持っており、ocaml パ ッケージの /usr/share/doc/ocaml/ocaml_packaging_policy.gz で みることができます。良い例は camlzip ソースパッケージです。 * XML や SGML DTD を提供しているパッケージは、sgml-base-doc パ ッケージ中の推奨に従わねばなりません。 * lisp パッケージは、パッケージ自身を common-lisp-controller に 登録する必要があります。これについては、/usr/share/doc/ common-lisp-controller/README.packaging を参照してください。 6.7.5. アーキテクチャ非依存のデータ 大量のアーキテクチャ非依存データがプログラムと共にパッケージ化さ れるのは、良くあることではありません。例えば、音声ファイル、アイ     コン集、様々な模様の壁紙、その他一般的な画像ファイルです。このデ ータのサイズがパッケージの残りのサイズと比較して取るに足らないの であれば、おそらくは単一パッケージでひとまとめにしておくのがベス トでしょう。 しかし、データのサイズが考えた方が良い程であれば、分かれたアーキ テクチャ非依存パッケージ (_all.deb) に分割するのを考えてください 。これによって、11 あるいはそれ以上の .deb ファイルについて、1ア ーキテクチャごとに同じデータの不必要な重複を避けられます。これは     Packages ファイルに更なるオーバーヘッドを追加しますが、Debian ミ ラーサーバ上で多くのディスク容量を節約します。アーキテクチャ非依 存のデータを分割することは、Debian アーカイブ全体に対して実行され る lintian の処理時間の削減にもつながります (「パッケージチェック (lint) 用ツール」参照)。 6.7.6. ビルド中に特定のロケールが必要     ビルド中に特定のロケールを必要とする場合、こんな技を使えば一時フ ァイルを作成できます: LOCPATH を /usr/lib/locale と同等のものに、そして LC_ALL を生成し     たロケールの名前に設定すれば、root にならなくても欲しいものが手に 入ります。こんな感じです: LOCALE_PATH=debian/tmpdir/usr/lib/locale LOCALE_NAME=en_IN LOCALE_CHARSET=UTF-8     mkdir -p $LOCALE_PATH localedef -i $LOCALE_NAME.$LOCALE_CHARSET -f $LOCALE_CHARSET $LOCALE_PATH/$LOCALE_NAME.$LOCALE_CHARSET # ロケールを使う LOCPATH=$LOCALE_PATH LC_ALL=$LOCALE_NAME.$LOCALE_CHARSET date 6.7.7. 移行パッケージを deboprhan に適合するようにする deborphan は、どのパッケージがシステムから安全に削除できるか、ユ ーザが検出するのを助けてくれるプログラムです; すなわち、どのパッ     ケージも依存していないものです。デフォルトの動作は、使われていな いライブラリを見つけ出すために libs と oldlibs セクションからのみ 検索を行います。ですが、正しい引数を渡せば、他の使われていないパ ッケージを捕らえようとします。 例えば、--guess-dummy つきだと、deborphan はアップグレードに必要     ではあったが、現在は問題なく削除できるすべての移行パッケージを探 そうとします。これには、それぞれの短い説明文中に dummy あるいは transitional の文字列を探します。 ですので、あなたがそのようなパッケージを作る際には、この文章を短     い説明文に必ず追加してください。例を探す場合は、以下を実行してく ださい: apt-cache search .|grep dummy または apt-cache search .| grep transitional     それから、deborphan の作業を楽にするため、section を oldlibs、 priority を extra にするのもお勧めです。 6.7.8. .orig.tar.{gz,bz2,xz} についてのベストプラクティス オリジナルのソース tarball には 2 種類あります: 手が入れられてい     ない素のソース (Pristine source) と再パッケージした開発元のソース (repackaged upstream source) です。 6.7.8.1. 手が入れられていないソース (Pristine source) 素のソース tarball (pristine source tarball) の特徴の定義は 、.orig.tar.{gz,bz2,xz} は、開発元の作者によって公式に配布された tarball と 1 バイトたりとも違わない、というものです。^[5] これは     、Debian diff 内に含まれているDebian バージョンと開発元のバージョ ン間のすべての違いを簡単に比較するのにチェックサムを使えるように なります。また、オリジナルのソースが巨大な場合、既に upstream の tarball を持っている upstream の作者と他の者は、あなたのパッケー ジを詳細に調査したい場合、ダウンロード時間を節約できます。 tarball 中のディレクトリ構成に関して開発元の作者が従う、万人に受     け入れられているガイドラインというものはありませんが、それにも関 わらず dpkg-source はほとんどの upstream の tarball を素のソース (pristine source) として対処できます。そのやり方は以下の通りです: 1. 以下のようにして空の一時ディレクトリに tarball を展開します zcat path/to/パッケージ名_開発元のバージョン.orig.tar.gz | tar xf - 2. もし、この後で、一時ディレクトリが 1 つのディレクトリ以外含まず他 にどのファイルも無い場合、dpkg-source はそのディレクトリをパッケ     ージ名-開発元のバージョン(.orig) にリネームします。tarball 中の最 上位のディレクトリ名は問題にはされず、忘れられます。 3. それ以外の場合、upstream の tarball は共通の最上位ディレクトリ無 しでパッケージされなくてはいけません (upstream の作者よ、恥を知り なさい!)。この場合、dpkg-source は一時ディレクトリそのものをパッ ケージ名-開発元のバージョン(.orig) へリネームします。 6.7.8.2. upstream のソースをパッケージしなおす パッケージは手が入っていない素のソース tarball と共にアップロード すべきですが、それが可能ではない場合が色々とあります。upstream が     ソースを gzip 圧縮した tarball を全く配布していない場合や、 upstream の tarball が DFSG-free ではない、あなたがアップロード前 に削除しなければならない素材を含んでいる場合がこれにあたります。 この様な場合、開発者は適切な .orig.tar.{gz,bz2,xz} ファイルを自身 で準備する必要があります。この様な tarball を、再パッケージした開 発元のソース (repackaged upstream source) と呼びます。再パッケー     ジした開発元のソースでは Debian ネイティブパッケージとは違うこと に注意してください。再パッケージしたソースは、Debian 固有の変更点 は分割された .diff.gz または .debian.tar.{gz,bz2,xz} のままであり 、バージョン番号は開発元のバージョンと debian リビジョンから構成 されたままです。 開発元が、原則的にはそのままの形で使える .tar.{gz,bz2,xz} を配布 していたとしても再パッケージをしたくなるという場合がありえます。     最も明解なのは、tar アーカイブを再圧縮することや upstream のアー カイブから純粋に使われていないゴミを削除することで、非常に容量を 節約できる時です。ここで慎重になって頂きたいのですが、ソースを再 パッケージする場合は、決定を貫く用意をしてください。     .orig.tar.{gz,bz2,xz} についてのベストプラクティス 1. ソースパッケージの由来をドキュメントにすべきです。どうやって ソースを得たのかという詳細情報が得たのか、どの様にすれば再生 成できるのかを debian/copyright で提供しましょう。ポリシーマ ニュアルで、メイン構築スクリプト: debian/rules に記述している ように、debian/rules に作業を繰り返してくれる get-orig-source ターゲットを追加するのも良い考えです。 2. 開発元の作者由来ではないファイルや、あなたが内容を変更したフ ァイルを含めるべきではありません。^[6] 3. 法的理由から不可能であるものを除いて、開発元の作者が提供して いるビルドおよび移植作業環境を完全に保全すべきです。例えば、 ファイルを省略する理由として MS-DOS でのビルドにしか使われな いから、というのは十分な理由にはなりません。同様に、開発元か     ら提供されている Makefile を省略すべきではありません。たとえ debian/rules が最初にすることが configure スクリプトを実行し てそれを上書きすることであったとしても、です。 (理由: Debian 以外のプラットフォームのためにソフトウェアをビ ルドする必要がある Debian ユーザが、開発元の一次配布先を探そ うとせずに Debian ミラーからソースを取得する、というのは普通 です)。 4. tarball の最上位ディレクトリの名前としてパッケージ名-開発元の バージョン.orig を使うべきです。これは、大元の使用されていな い tarball と再パッケージしたものを判別できるようにしてくれま す。 5. gzip あるいは bzip で最大限圧縮されるべきです。 6.7.8.3. バイナリファイルの変更 オリジナルの tarball に含まれているバイナリファイルを変更する、あ るいは存在していなかったバイナリファイルを追加する必要がある場合 がしばしばあります。これは、ソースパッケージが“3.0 (quilt)”形式を     使っている場合は完全にサポートされています。詳細は dpkg-source(1) マニュアルのページを参照してください。古い“1.0”形式を使っている場 合、バイナリファイルを .diff.gz 中に保存できないので、uuencode (か類似のもの) を使ったファイルを保存し、debian/rules 中でビルド 時にデコードします (そしてファイルを正しい位置へ移動する)。 6.7.9. デバッグパッケージのベストプラクティス デバッグパッケージは名前が -dbg で終わっているもので、gdb が利用 可能な追加情報を含んでいます。Debian のバイナリはデフォルトで     strip されているので、関数名や行番号を含むデバッグ情報は、Debian のバイナリに gdb を走らせたときに利用できません。デバッグパッケー ジは、この追加デバッグ情報を必要とするユーザが、通常のシステムを 巨大化させること無く使えるようにしてくれます。 デバッグパッケージを作るか否かは、パッケージのメンテナ次第です。 メンテナは、ライブラリパッケージについてデバッグパッケージを作成 するのが推奨されています。これは、ライブラリにリンクしている沢山 のプログラムをデバッグする助けになるからです。一般的に言って、デ     バッグパッケージはすべてのプログラムに追加する必要はありません; これを行うとアーカイブが巨大なものになるでしょう。しかし、メンテ ナは、ユーザがデバッグ版のプログラムを頻繁に必要とするのに気づい た場合、デバッグパッケージを作るのに値するでしょう。インフラスト ラクチャの核となっている、apache や X サーバのようプログラムも、 デバッグパッケージの良い作成候補です。 デバッグパッケージのうちいくつかは、ライブラリあるいは他のバイナ リの完全に特別なデバッグビルドを含むでしょうが、それらの大半は容 量やビルドする時間を節約できます。/usr/lib/debug/path の場合、     path は実行ファイルかライブラリへのパスになります。例えば、/usr/ bin/foo のデバッグシンボルは /usr/lib/debug/usr/bin/foo に行き、/ usr/lib/libfoo.so.1 のデバッグシンボルは /usr/lib/debug/usr/lib/ libfoo.so.1 になります。 デバッグシンボルは objcopy --only-keep-debug を使ってオブジェクト ファイルから展開できます。そうすればオブジェクトファイルを strip     することができ、objcopy --add-gnu-debuglink がデバッグシンボルフ ァイルへのパスを指定するのに使われます。objcopy(1) で、これがどの 様に動作するのかを詳細に説明しています。 debhelper 中の dh_strip コマンドは、デバッグパッケージの作成をサ ポートし、デバッグシンボルを分離するのに objcopy の利用の面倒を見     てくれます。あなたのパッケージが debhelper を使っている場合、あな たがする必要があるのは dh_strip --dbg-package=libfoo-dbg を呼び出 し、debian/control にデバッグパッケージのエントリを追加することだ けです。 デバッグパッケージは、そのパッケージがデバッグシンボルを提供する     パッケージに依存する必要があり、この依存関係はバージョン指定が必 要であるということに注意してください。以下のような例になります:     Depends: libfoo (= ${binary:Version}) 6.7.10. メタパッケージのベストプラクティス メタパッケージは、時間がかかる一貫したセットのパッケージをインス トールするのを楽にしてくれる、ほぼ空のパッケージです。そのセット の全パッケージに依存することで、これを実現しています。APT の力の おかげで、メタパッケージのメンテナは依存関係を調整すればユーザの     システムが自動的に追加パッケージを得ることができます。自動的にイ ンストールされていてメタパッケージから落とされたパッケージは、削 除候補としてマークされます (そして aptitude によって自動的に削除 もされます)。gnome と linux-image-amd64 は、メタパッケージの 2 つ の例です (ソースパッケージ meta-gnome2 and linux-latest から生成 されています)。 メタパッケージの長い説明文は、目的を明確に記述している必要があり ます。これによって、ユーザはもしそのパッケージを削除した場合に何 を失うことになるのかを知ることができます。のちの影響について明示     的にするのもお勧めです。これは、初めのインストール時にインストー ルされており、ユーザが明示的にインストールしたわけではないメタパ ッケージにとって、特に重要です。システムのアップグレードをスムー スに保証するのに重要になり、潜在的な破損をさけるためにユーザに対 してアンインストールする気をなくさせることでしょう。 --------------------------------------------------------------------- ^[5] 我々は、配布されている tarball がバージョン番号をインクリメ ントすることなく、開発元の作者によって変更されるのを防ぐことはで きません。ですので、手が入れられていない素の tarball が、どの時点 でも開発元が現在配布していると等しいものである保証はありません。     期待できることは、一度は配布されたものと等しいものであるというこ とだけです。後から違いが発生した場合 (そう、例えば upstream が元 々の配布物が最大の圧縮率を使っていなかったことに気づいて、再度 gzip しなおした場合など)、それはとても残念なことです。同じバージ ョンに対して新しい .orig.tar.{gz,bz2,xz} をアップロードするのには 良い方法がないので、この状況をバグと考える意味はありません。 ^[6] 特別な例外として、non-free なファイルが Debian diff からの助 けが無いとソースからのビルド失敗を引き起こす場合、適切な処置はフ     ァイルを編集するのではなく、non-free な部分を削除して、ソースツリ ーのルートに README.source ファイルとして状況を説明することです。 ですがその場合、開発元の作者に non-free なコンポーネントを残りの ソースから分離しやすくするように促してください。 第7章パッケージ化、そして… Debian は、単にソフトウェアのパッケージを作ってメンテナンスをして     いるだけではありません。この章では、単にパッケージを作ってメンテ ナンスする以外で Debian へ協力・貢献するやり方、多くの場合とても 重要となるやり方の情報を取り扱います。 ボランティア組織の例にたがわず、Debian の活動はメンバーが何をした     いのか、時間を割くのに最も重大だと思われることが何か、というメン バーの判断に依っています。 7.1. バグ報告 我々としては、Debian パッケージで見つけたバグを登録することを勧め     ています。実際のところ、大抵の場合は Debian 開発者が第一線でのテ スト作業者となっています。他の開発者のパッケージで見つけたバグを 報告することで Debian の品質が向上されています。     Debian バグ追跡システム (BTS) のバグ報告のやり方について (instructions for reporting bugs) を参照してください。 いつも使っているメールを受け取れるユーザアカウントからバグを送っ     てみてください。そうすることで、開発者がそのバグに関するより詳細 な情報を必要とする場合にあなたに尋ねることができます。root ユーザ でバグを報告しないでください。     バグを報告するには、reportbug(1) のようなツールが使えます。これに よって作業を自動化し、かなり簡単なものにできます。 パッケージに対して既にバグが報告されていないことを確認しておいて ください。個々のパッケージに対するバグのリストは http://     bugs.debian.org/パッケージ名にて簡単に確認できます。querybts(1) のようなユーティリティでもこの情報を入手できます (なお、reportbug では大抵の場合、バグを送信する前に querybts の実行も行っています) 。 正しい所にバグを報告する様に心がけてください。例えばあるパッケー     ジが他のパッケージのファイルを上書きしてしまうバグの場合ですが、 バグ報告が重複して登録されるのを避けるため、これらのパッケージの 両方のバグリストを確認してください。 さらに言うと、他のパッケージについても、何度も報告されているバグ をマージしたり既に修正されているバグに「fixed」タグをつけたりする     こともできます。そのバグの報告者であったりパッケージメンテナでは ない場合は (メンテナから許可をもらっていなければ)、実際にバグをク ローズしてはいけないことに注意してください。 時折、あなたが登録したバグ報告について何が起こっているのかをチェ ックしたくなることでしょう。これは、もう再現できないものをクロー     ズするきっかけになります。報告した全てのバグ報告を確認するには、 http://bugs.debian.org/from:your-email-addr を参照すればいいだけ です。 7.1.1. 一度に大量のバグを報告するには (mass bug filing) 大量の異なるパッケージに対して、同じ問題についての非常に多くのバ グ (例えば 10 個以上) を報告するのは、推奨されていないやり方です     。不要なバグ報告を避けるため、可能な限りの手続きを踏むようにしま しょう。例えば、問題の確認を自動化できる場合は lintian に新しくチ ェック項目を追加すれば、エラーや警告が明確になります。 同じ問題について一度に 10 個以上のバグを報告する場合は、バグ報告 を登録する前に へ送ることをお勧め します。バグ報告を送る前に注意点を記述し、メールのサブジェクトに     事実を挙げておきます。これで他の開発者がそのバグが本当に問題であ るかどうかを確認できるようになります。さらに、これによって複数の メンテナが平行して同じバグ報告を登録するのを防止できるようになり ます。 dd-list プログラムを利用することと、明確になっているのであれば影     響を受けるパッケージのリストを (devscripts パッケージの) whodepends を使って出力して、 への メールに含めて下さい。 同じサブジェクトで大量のバグを送信する際は、バグ報告がバグ情報用     メーリングリストへ転送されないように　 へバグ報告を送るべきであるの注意してください。 7.1.1.1. Usertag 多数のパッケージに対するバグを登録する際に BTS の usertag を使い たくなるかもしれません。usertag は 'patch' や 'wishlist' のような     通常のタグに似ていますが、ユーザが定義する事と特定のユーザに対し て一意な名前空間を占めるという点で違っています。これによって、同 じバグについて衝突する事無しに、開発者がそれぞれ別のやり方で複数 の設定ができるようになります。     バグを登録する際に usertag を追加するには、擬似ヘッダ (pseudo-header) User と Usertags を指定します。 To: submit@bugs.debian.org Subject: バグタイトル Package: パッケージ名     [ ... ] User: メールアドレス Usertags: タグ名 [ タグ名 ... ] バグの説明 ... タグは空白で区切られ、アンダースコア (_) を含められないことに注意     してください。特定のグループやチームについてのバグを登録する場合 は、適切なメーリングリストで注意を促した上で User をそのメーリン グリストに設定するのをお勧めします。 特定の usertag でバグを参照する場合は http://bugs.debian.org/     cgi-bin/pkgreport.cgi?users=メールアドレス&tag=タグ名を指定してく ださい。 7.2. 品質維持の努力 7.2.1. 日々の作業 品質保証に割り当てられたグループの人々がいたとしても、QA 作業は彼 らのみに課せられるものではありません。あなたもパッケージを可能な 限りバグが無いように保ち、できるだけ lintian clean な状態 (「 lintian」を参照) にすることで品質保証の作業に参加することができる のです。それが可能ではないように思えるなら、パッケージをいくつか     「放棄 (orphan)」してください (「パッケージを放棄する」参照)。ま たは、溜まったバグ処理に追いつくため、他の人々に助力を願い出るこ とも可能です ( や < debian-devel@lists.debian.org> で助けを求めることができます)。同 時に共同メンテナ (co-maintainer) を探すことも可能です (「共同メン テナンス」を参照してください)。 7.2.2. バグ潰しパーティ (BSP) 時折、QA グループは可能な限りの問題を無くすためにバグ潰しパーティ (BSP) を開催しています。開催案内は < debian-devel-announce@lists.debian.org> で行われ、パーティがどの     部分に集中して行われるのかが告知されます。大抵はリリースクリティ カルバグ (RC) への対応に当てられますが、大きなアップグレード (新 しい perl バージョンでの全バイナリモジュールを再コンパイルのよう な) を完了する手助けのために開かれることもあります。 メンテナ以外によるアップロード (non-maintainer upload) のルールは パーティの開催中とそれ以外で違います。これは、パーティのアナウン スは NMU の予告であると考えられているためです。パーティによって影     響を受けるパッケージを持っている場合 (例えばリリースクリティカル バグを持っている場合) は、それぞれ対応するバグについて現状説明と このパーティでどの様なことを期待しているのかを説明しないといけま せん。NMU を望まない、パッチでの対応にのみ興味がある、あるいは自 分自身で対処をする予定の場合は、BTS で説明をしてください。 パーティに参加している人には NMU についての特別ルールが割り当てら れます。NMU について、少なくとも 3 日遅延してアップロードを行う場 合 (DELAYED/3-day キューなどへのアップロードの場合) は予告無しで     NMU できるのです。他の NMU ルールは全て通常通りに適用されます - NMU のパッチを BTS に送付する必要があります (修正されていないバグ のいずれかを NMU で修正する、あるいは新たなバグにパッチを送り、 fixed とタグを付けるなど)。それから、作業者は各メンテナの要望に沿 う必要があります。     NMU をする自信が無い場合は、BTS へパッチを投げるだけにしてくださ い。NMU でパッケージを壊してしまうより、遥かに良いことです。 7.3. 他のメンテナに連絡を取る Debian と共に過ごす間、様々な理由で他のメンテナに連絡を取りたくな     ることでしょう。関連パッケージ間での共同作業の新たなやり方につい て協議したい場合や、開発元で自分が使いたい新しいバージョンが利用 可能になっていることを単に知らせたい場合などです。 パッケージメンテナのメールアドレスを探しだすのは骨が折れます。幸 いな事に、パッケージ名@packages.debian.org というシンプルなメール     のエイリアスがあり、メンテナらの個人アドレスが何であれメンテナへ メールを届ける手段となっています。パッケージ名はパッケージのソー ス名かバイナリパッケージ名に置き換えてください。 「パッケージ追跡システム」経由でソースパッケージの購読を行ってい     る人に連絡を取りたくなるかもしれません。その場合はパッケージ名 @packages.qa.debian.org メールアドレスが使えます。 7.4. 活動的でない、あるいは連絡が取れないメンテナに対応する パッケージがメンテナンスされていないと気づいた場合、メンテナが活 動的でパッケージの作業を続けるかどうかを確認する必要があります。     もはや活動的な状態ではない可能性もありますが、言わばシステムに登 録していなかったという可能性もあります。あるいは、単に確認が必要 なだけという可能性もあります。 Missing In Action (行方不明) だと考えられているメンテナについての 情報が記録されるシンプルなシステム (MIA データベース) があります 。品質保証グループ (QA グループ) のメンバーが活動的ではないメンテ ナに連絡を取った場合や、そのメンテナについて新たな情報がもたらさ れた場合、その記録が MIA データベースに残されます。このシステムは     qa.debian.org ホスト上の /org/qa.debian.org/mia で利用可能になっ ており、mia-query ツールで検索ができます。どうやってデータベース を検索するのかについては mia-query --help と入力してください。活 動的ではないメンテナについての情報がまだ記録されていない、あるい はそのメンテナについての情報を追加できる場合は、おおよそ以下の手 続きを行う必要があります。 最初の一歩はメンテナに丁寧にコンタクトを取り、応答するのに充分な 時間待つことです。充分な時間というのを定義するのは非常に困難です     が、実生活では時折非常に多忙になるのを考慮に入れると重要なことで す。一つのやり方としては、リマインダーを二週間後に送るという方法 があります。 メンテナが４週間 (１ヶ月）応答をしない場合、おそらく反応がないと     判断できます。この様な場合はより詳細に確認し、可能な限り問題とな っているメンテナに関する有用な情報をかき集める必要があります。こ れには以下のようなものが含まれています。 * 開発者 LDAP データベースを通じて得られる echelon 情報は、開発 者が最後に Debian メーリングリストに投稿したはいつなのかを示 します (これには での 配布物のアップロードのメールも含まれます)。また、データベース でメンテナが休暇中かどうかも確認してください * このメンテナが対応しているパッケージ数やパッケージの状態。特     に、長期間放置され続けている RC バグがあるかどうか? さらに通 常どの程度の数のバグがあるか? もう一つの重要な情報はパッケー ジが NMU されているかどうか、されているとしたら誰によって行わ れているか、です。 * Debian 以外でメンテナの活動があるかどうか? 例えば、近頃 Debian 以外のメーリングリストや news グループへの投稿をしてい るなど。 パッケージがスポンサーされている、つまりメンテナが公式の Debian 開発者ではない場合はちょっとした問題となります。例えば echelon の 情報は、スポンサーされている人は利用できません。そのため実際にパ     ッケージをアップロードした Debian 開発者を探して確認を取る必要が あります。彼らがパッケージにサインしたということは、アップロード について何であれ責任を持ち、スポンサーした人に何が起こっているか を知っていそうだということです。 に、活動が見えないメンテナの居所     に誰か気づいているかという質問を投稿するのもありです。問題の人を Cc: に入れてください。 ここに書かれた全てを収集したなら、に連絡しまし ょう。この名前の宛先を担当している人は、あなたが供給した情報を使 ってどう進めるかを判断します。例えば、そのメンテナのパッケージの     一部または全てを放棄 (Orphan) するかもしれません。パッケージがNMU されていた場合は、パッケージを放棄 (Orphan) する前にNMUをした人に 連絡する事を選ぶかもしれません — NMUをした人はきっとパッケージに 関心があるでしょうから。 最後に一言: 礼儀正しく振る舞いましょう。我々は所詮ボランティアで 、全ての時間を Debian に捧げられるわけではありません。また、関わ っている人の状況がわかるわけでもありません。重い病気にかかってい     るかかもしれないし、あるいは死んでしまっているかもしれません - メ ッセージを受け取る側にどんな人がいるかは分かりません。亡くなった 方のご親戚の方がメールを読んだ場合に、非常に無礼で怒った叱責調の メッセージを見つけてどうお感じになるかを想像してください。 一方で、我々はボランティアではありますが責任を持っています。全体     の幸せの重要性をよく考える必要があります — もしメンテナが時間が足 りなかったり、もう興味を無くしてしまった場合は、パッケージを誰か 他のより時間がある人間に与えるべきです。 MIA チームで働くのに興味を持った場合は、技術上の詳細と MIA の手順     が記載されている qa.debian.org 上の /org/qa.debian.org/mia 内の README ファイルを参照して、 に連絡を取ってくだ さい。 7.5. Debian 開発者候補に対応する Debian の成功は新たな才能あるボランティアをどう魅了し確保するかに     かかっています。あなたが経験豊かな開発者なら、新たな開発者を呼び 込むプロセスに関与するべきです。このセクションでは新たな開発者候 補者をどうやって手助けするのかについて記述します。 7.5.1. パッケージのスポンサーを行う パッケージのスポンサーになるというのは、自分の権限ではパッケージ をアップロードできないメンテナのためにパッケージをアップロードす     る、ということです。これは些細な問題ではなく、スポンサーはパッケ ージを精査して Debian が求めるような高いレベルの品質であることを 保証する必要があります。     Debian 開発者はパッケージをスポンサーできます。Debian メンテナは できません。 パッケージのスポンサー作業の流れは以下の通りです: 1. メンテナはソースパッケージ (.dsc) を用意してオンライン上の何 処か (例えば mentors.debian.net) に置く、あるいはもっと良いの は、パッケージがメンテナンスされている公開 VCS リポジトリへの リンクを提供することです (「VCS (バージョン管理システム) サー バ」参照)。     2. スポンサーはソースパッケージをダウンロード (あるいはチェック アウト) します。 3. スポンサーはソースパッケージをレビューします。問題を見つけた ら、メンテナに知らせて修正版をくれるように尋ねます (作業は step 1 へやり直しされます)。 4. スポンサーは、何も問題が残っているのを見つけられませんでした 。パッケージをビルドし、署名し、Debian へアップロードします。 パッケージのスポンサーのやり方について詳細を詰める前に、提案され     たパッケージを追加することが Debian にとって有益であるかどうか、 自分自身に問いかける必要があります。 この質問に答えるのは単純ではなく、多くの要因に依っています: 開発 元のコードは成熟していて、セキュリティホールの山ではないですか?     同じことができる既存パッケージがありませんか? そしてこの新しいパ ッケージと比べてどうですか? 新しいパッケージはユーザから要求され たものですか? そしてユーザ数はどの程度の大きさですか? 大本の開発 者らはアクティブですか? それから、メンテナ候補者が良いメンテナになるであろうことを保証す る必要があります。他のパッケージでの経験がありますか? そうであれ     ば、良い仕事をしていますか (バグを確認している)? パッケージと使わ れているプログラミング言語について詳しいですか? そのパッケージに 必要なスキルを持っていますか? そうでなければ、学ぶことが可能でし ょうか? 候補者が、Debian に対してどの様な態度を取っているかを知るのも良い 考えです: Debian の哲学に賛同していて、Debian に参加したいと思っ     ていますか? Debian メンテナになるのがどれくらい簡単なのかを考えて 、参加を検討している人たちだけをスポンサーするのが良いでしょう。 こうすれば、最初からずっとスポンサーとして行動しなくて良いと思っ ておけます。 7.5.1.1. 新しいパッケージのスポンサーを行う 新たなメンテナは、Debian パッケージの作成する際に大抵何らかの困難 に会いますーこれは非常に理解できることです。彼らは間違いを犯しま す。これは、全く新しいパッケージを Debian でスポンサーするのに、     Debian パッケージングの徹底的なレビューを受ける必要がある根拠です 。時折、パッケージが Debian へアップロードされるのに十分な状態に なるまで、複数回のやり取りが必要になることがあります。それゆえ、 スポンサーになることは、メンターになることを伴います。 レビューをせずに新しいパッケージのスポンサーをしないでください。 ftpmaster による新しいパッケージのレビューは、主にソフトウェアが 本当にフリーなものであるかを確認するためです。もちろん、パッケー     ジ化に関する問題に偶然気づくことはありますが、それを期待すべきで はありません。アップロードされたパッケージが、Debian フリーソフト ウェアガイドラインに適合し、良い品質であるのを保証するのは、あな たの仕事です。 パッケージをビルドし、ソフトウェアのテストを行うのはレビューの一     部ではありますが、それだけでは十分ではありません。この章の残りの 部分では、レビューでチェックするポイントの一覧を述べます (徹底的 なものではありません)。^[7] * upstream の tarball として提供されているものが、upstream の作 者が配布しているものと同じかどうかを確認する (ソースが Debian 用に再パッケージされている場合、修正した tarball を自分自身で 生成する)。 * lintian を実行する (「lintian」参照)。多くの一般的な問題を見 つけてくれます。lintian の overrides 設定がメンテナによって設 定されている場合、完全に問題がないことを確認してください。 * licensecheck(「devscripts」の一部) を実行し、debian/copyright が正しく、そして完全な事を確認する。ライセンス問題を探してく ださい (頭に“All rights reserved”とあるファイルや、DFSG に適 合しないライセンスがあるなど)。この作業には、grep -ri が助け となることでしょう。 * ビルドの依存関係が完全であるのを保証するため、パッケージを pbuilder (やその他類似のツール) でビルドする (「pbuilder」参 照)。 * debian/control を査読する: ベストプラクティスに従っている? ( 「debian/control のベストプラクティス」参照) 依存関係は完璧で すか?     * debian/rules を査読する: ベストプラクティスに従っている? 改善 可能な点がある? * メンテナスクリプト (preinst, postinst, prerm, postrm, config) を査読する: 依存関係がインストールされていない時でも動作する? 全てのスクリプトが等羃 (idempotent、すなわち、問題無しに複数 回実行できる)? * 開発元のファイルに対する変更 (.diff.gz、debian/patches/、ある いは直接 debian tarball に埋め込まれているバイナリファイル) をレビューする。十分な根拠がありますか? (パッチに対し、DEP-3 に沿って) 正しくドキュメント化されている? * すべてのファイルについて、そのファイルが何故そこにあるのか、 望んでいる結果をもたらすためにそれが正しいやり方かどうかを自 身に問いかけてください。メンテナはパッケージ化のベストプラク ティスに従っていますか? (6章パッケージ化のベストプラクティス 参照) * パッケージをビルドし、インストールし、ソフトウェアを使ってみ てください。パッケージを削除 (remove)、及び完全削除 (purge) できることを確認してください。piuparts でテストすると良いかも しれません。 監査で何も問題が見つからなかった場合には、パッケージをビルドして Debian へアップロードすることができます。あなたがメンテナでなかっ     たとしても、スポンサーとして Debian へアップロードされたものへの 責任を持つことを覚えておいてください。これが、「パッケージ追跡シ ステム」を使ってパッケージを追いかけておくことが推奨される理由で す。 changelog ファイルや control ファイルにあなたの名前を入れるために 、ソースパッケージを変更する必要はないことに注意してください。     control ファイルのMaintainer 欄と changelog にはパッケージ作業を 行った人を記載する必要があります。つまりはスポンサー対象者、とい うことです。そうすることで、メンテナはすべての BTS メールを受け取 るようになります。     代わりに、署名にあなたの鍵を使うために dpkg-buildpackage に指示す る必要があります。これは -k オプションを使って行います:     dpkg-buildpackage -kKEY-ID     debuild と debsign を使う場合は、~/.devscripts に設定を決め打ちで 書いても構いません:     DEBSIGN_KEYID=KEY-ID 7.5.1.2. 既存パッケージの更新をスポンサーする 通常、パッケージは既に全体的なレビューを受けているとします。です ので、もう一度すべてを行う代わりに、現在のバージョンとメンテナに     よって準備された新しいバージョンとの差分を注意深く分析することに なります。最初のレビューをあなた自身が行っていない場合は、最初の レビュワーがいい加減であった場合に備えて、より子細に確認を行った 方が良いかもしれません。 差分を分析する為には両方のバージョンが必要です。ソースパッケージ の現在のバージョンをダウンロードし (apt-get source)、リビルドしま     す (あるいは aptitude download で現在のバイナリパッケージをダウン ロードします)。それから、スポンサー用のソースパッケージをダウンロ ードします (通常、dget を使います)。 まず、changelog の新しいエントリを読みます。これで、レビュー中に 予期しておく事柄を知ることができます。使うことになる主なツールは debdiff です (devscripts パッケージに含まれています)。2 つのソー     スパッケージ (.dsc ファイル) に対して実行するか、2 つのバイナリパ ッケージ、あるいは 2 つの .changes ファイルに対して実行することが できます (その場合は .changes に記載されているすべてのバイナリフ ァイルを比較します)。 ソースパッケージを比較した場合 (新しい開発元のバージョンの場合に は、例えば debdiff の出力を filterdiff -i '*/debian/*' などとして     、開発元のファイルを除外します)、確認したすべての変更点を理解して 、この変更点が Debian の changelog に正しく記載されている必要があ ります。 何も問題がなければ、パッケージをビルドし、ソースパッケージ上の変     更が期待していない結果 (ミスのためファイルがなくなっている、依存 関係の欠落など) をもたらしていないかを確認するため、バイナリパッ ケージを比較します。 メンテナが何か重要なことを見逃していないかを確認する為に、パッケ ージ追跡システム (PTS、「パッケージ追跡システム」参照) を見るのが 良いかもしれません。追加が可能な翻訳の更新が BTS にあるかもしれま せん。パッケージが NMU されていて、メンテナが NMU での変更をパッ     ケージへ取り入れるのを忘れているかもしれません。リリースクリティ カルバグがあって、メンテナが放置しているためにテスト版 (testing) への移行が阻まれているかもしれません。メンテナが何か (より良く) できることを見つけたら、それを伝えましょう。次回に改善ができます し、メンテナは責務についてより深く理解することになります。 何も大きな問題を見つけなければ、新しいバージョンをアップロードし     ます。そうでなければ、メンテナに修正したバージョンをアップロード するよう要請します。 7.5.2. 新たな開発者を支持する (advocate)     Debian ウェブサイトの開発者志願者の支持者になる (advocating a prospective developer)のページを参照してください。 7.5.3. 新規メンテナ申請 (new maintainer applications) を取り扱う     Debian のウェブサイトにある申請管理者用チェックリスト (Checklist for Application Managers) を参照してください。 ---------------------------------------------------------------------     ^[7] もっと多くのチェック項目について、複数の開発者が持ち寄ってい るsponsorship checklists で見ることができます。 第8章国際化と翻訳 Debian がサポートしている自然言語の数は未だ増え続けています。あな たが英語圏のネイティブスピーカーで他の言語を話さないとしても、国 際化の問題について注意を払うことはメンテナとしてのあなたの責務で     す (internationalization の 'i' と 'n' の間に 18 文字があるので i18n と略されます)。つまり、あなたが英語のみのプログラムを扱って いて問題がない場合であっても、この章の大部分を読んでおく必要があ るということです。 久保田智広さんによる Introduction to i18n によると、I18N (internationalization) はソフトウェアや関連する技術を調整し、ソフ     トウェアが複数の言語、習慣、その他世界の物事などを扱えるようにし ておくことで、対して L10N (localization) は既に国際化されているソ フトウェアに対して特定の言語を実装することを意味します。 l10n と i18n は関連していますが、それぞれ関連する難しさについては 違います。プログラムをユーザの設定に応じて表示されるテキストの言     語を変更するようにするのはあまり難しくはありませんが、実際にメッ セージを翻訳するのはとても時間がかかります。一方、文字のエンコー ド設定は些細な事ですが、複数の文字エンコードを扱えるようなコード にするのはとても難しい問題です。 i18n の問題を横においたとしても、一般的なガイドラインは与えられて     おらず、移植作業用の buildd のメカニズムと比較できるような、 Debian での l10n 用の中心となるインフラは実際のところ存在していま せん。そのため、多くの作業は手動で行わねばなりません。 8.1. どの様にして Debian では翻訳が取り扱われているか     パッケージに含まれている文章の翻訳の取り扱いは未だ手動であり、作 業のやり方は翻訳を表示させたい文の種類に因ります。 プログラムのメッセージについては、ほとんどの場合 gettext という仕 組みが使われています。多くの場合、翻訳は Free Translation Project や Gnome 翻訳プロジェクト、KDE one などの開発元 (upstream) のプロ     ジェクトで取り扱われています。Debian で唯一の集約化された情報は Debian の翻訳に関する統計で、実際のパッケージ内での翻訳ファイルの 状況について確認できますが、翻訳作業を実際に容易にする仕組みでは ありません。 パッケージ説明文の翻訳作業はかなり昔に始まりました―実際にそれを使 うツールがほんの少ししか機能を提供していなかったとしても (つまり     、APT だけが設定を正確に行ったときのみ利用できたのです)。メンテナ はパッケージの説明文をサポートするのに何も特別なことをする必要は ありません。翻訳者は Debian Description Translation Project (DDTP) を使う必要があります。 debconf テンプレートについては、メンテナは翻訳者の作業を容易にす るため po-debconf パッケージを使う必要があります。翻訳者は作業に     DDTP を使うことが出来ます (フランスチームとブラジルチームは使って いませんが)。DDTP のサイト (実際に何が翻訳されているか) と Debian の翻訳に関する統計サイト (パッケージに何が含まれているか) の双方 で統計情報を得ることが出来ます。 ウェブページについては、それぞれの l10n チームが対応する VCS にア     クセスし、Debian の翻訳に関する統計サイトから統計情報が取得できま す。 Debian についての一般的なドキュメントは、作業は多少の差はあれウェ     ブページと同じです (翻訳者は VCS にアクセスします)。ですが、統計 情報のページはありません。     パッケージ固有のドキュメント (man ページ、info ドキュメントその 他) は、ほとんどすべてが手付かずです。     特記しておくこととして、KDE プロジェクトはドキュメントの翻訳をプ ログラムのメッセージと同じやり方で取り扱っています。     Debian 固有の man ページを特定の VCS リポジトリで取り扱おうという 動きもあります。 8.2. メンテナへの I18N & L10N FAQ これはメンテナが i18n や l10n を考えるのにあたって直面するであろ う問題の一覧です。読み進める間、Debian でこれらの点について実際の コンセンサスは得られていないことを念頭においてください。これは単     にアドバイスです。出てきた問題についてもっと良い考えがある、ある いはいくかの点で賛同できないという場合は、連絡をして頂いて構いま せん。そのことによって、この文章の質をさらに高めることができます 。 8.2.1. 翻訳された文章を得るには パッケージの説明文や debconf テンプレートを翻訳してもらうには、あ     なたは何もする必要はありません。DDTP のインフラが作業者に翻訳して もらう素材を割り当てるのに、あなた側から働きかける必要はありませ ん。 他の素材 (gettext ファイル、man ページ、その他のドキュメント) に ついては、最も良い解決策は文章をインターネットのどこかに置いて、     debian-i18n で他の言語へ翻訳を頼むことです。翻訳チームのメンバー の何名かはこのメーリングリストに登録しており、翻訳とレビュー作業 を担当します。一旦作業が完了すれば、翻訳された文章があなたのメー ルボックスへと届くでしょう。 8.2.2. どの様にして提供された翻訳をレビューするか 時折、あなたのパッケージ内の文章を訳して翻訳をパッケージに含める ように依頼する人が出てきます。これはあなたがその言語に詳しくない     場合、問題となり得ます。その文章を対応する l10n メーリングリスト に投稿し、レビューを依頼するのが良い考えです。一旦レビューが終わ れば、翻訳の質に自信を持つでしょうし、パッケージに含めるのにも安 心を覚えるでしょう。 8.2.3. どの様にして翻訳してもらった文章を更新するか 古いままになっていた文章に対して翻訳文がある場合、元の文章を更新 する度に、以前翻訳した人に新たに変更した点に合わせて翻訳を更新し     てもらうように依頼する必要があります。この作業には時間がかかるこ とを覚えておいてください―更新をレビューしてもらったりするには少な くとも1週間はかかります。 翻訳者が応答してこない場合、対応する l10n メーリングリストに助力     を願い出ましょう。すべてうまくいかなかった場合は、翻訳した文中に 翻訳がとにかく古い事の警告を入れておくの忘れないようにして、でき れば読者がオリジナルの文章を参照するようにしましょう。 古くなっているからといって翻訳を全て削除するのは避けてください。     非英語圏のユーザにとって何もドキュメントが無いよりは古いドキュメ ントがある方が有益であることが往々にしてあります。 8.2.4. どの様にして翻訳関連のバグ報告を取り扱うか 最も良い解決策は開発元のバグという印を付けておいて (forward)、以     前の翻訳者と関連するチーム (対応する debian-l10n-XXX メーリングリ スト) に転送することです。 8.3. 翻訳者への I18N & L10N FAQ これを読み進める間、Debian においてこれらの点に関する一般的な手続     きは存在していないこと、そしていかなる場合でもチームやパッケージ メンテナと協調して作業する必要があることを念頭においてください。 8.3.1. どの様にして翻訳作業を支援するか 翻訳したい文章を選び、誰もまだ作業をしていないことを確認し (debian-l10n-XXX メーリングリストを参照。日本語の場合は     debian-doc@debian.or.jp を参照してください)、翻訳し、l10n メーリ ングリストで他のネイティブスピーカーにレビューをしてもらい、パッ ケージメンテナに提供します (次の段を参照)。 8.3.2. どの様にして提供した翻訳をパッケージに含めてもらうか 含めてもらう翻訳が正しいかどうかを提供する前に確認してください     (l10n メーリングリストでレビューを依頼しましょう)。皆の時間を節約 し、バグレポートに複数バージョンの同じ文章があるというカオス状態 を避けることになります。 最も良いやり方は、パッケージに対して翻訳を含めて通常のバグとして     登録することです。忘れずに「patch」タグを使い、翻訳が欠けていたと してもプログラムの動作に支障は無いので「wishlist」以上の重要度を 使わないようにしましょう。 8.4. l10n に関する現状でのベストプラクティス * メンテナとしては、翻訳については関連の l10n メーリングリスト に尋ねること無くどの様な方法であれいじらないこと (レイアウト を変えることでさえしないこと) です。もしいじってしまうと、例 えばファイルのエンコーディングを破壊する危険があります。さら に、あなたが間違いだと思っていることがその言語では正解である (または必要ですらある) ことがあり得ます。 * 翻訳者としては、元の文章に間違いを見つけた場合は必ず報告する ことです。翻訳者はしばしばその文章の最も注意深い読者であり、 翻訳者が見つけた間違いを報告しないのならば誰も報告しないでし     ょう。 * いずれの場合でも、l10n に関する最も大きな問題は複数人の協調で あり、誤解から小さな問題でフレームウォーを起こすのはとても簡 単だということです。ですから、もし、あなたの話し相手と問題が 起こっている場合は、関連する l10n メーリングリストや debian-i18n メーリングリスト、さらにあるいは debian-devel メ ーリングリストに助けを求めてください (ですが、ご注意を。l10n 関連の議論は debian-devel では頻繁にフレームウォーになります :) * 何にせよ、協調は互いを尊敬しあうことによってのみ成し得ます。 付録A Debian メンテナツールの概要 この章には、メンテナが利用できるツールについて大まかな概要が含ま     れています。以下は完全なものでも決定版的なものでもありませんが、 よく使われているツールについての説明です。 Debian メンテナツールは、開発者を手助けし、重要な作業のために時間     を作れるようにしてくれるものです。Larry Wall が言うように、やり方 は一つではありません (there's more than one way to do it)。 高度なパッケージメンテナンスツールを使うのを好む人もいればそうで はない人もいます。Debian は公式にはこの問題を不可知論であるとして     います。どのようなツールでも作業ができるのであれば構いません。つ まり、この章は誰もがどのツールを使うべきか、メンテナンス上で何を すべきかと要求する為のものではないということです。あるいは競合す るツールを排して特定のツールを勧める訳でもありません。 パッケージの説明文のほとんどは実際のパッケージの説明から取ったも     のです。より詳細な情報はパッケージ内のドキュメントで確認できます 。apt-cache show パッケージ名コマンドでも情報を得られます。 A.1. 主要なツール     以下のツールはどのメンテナであっても、必ず必要とするものです。 A.1.1. dpkg-dev dpkg-dev は、パッケージを展開、ビルド、Debian ソースパッケージを アップロードするのに必要なツールを含んでいます (dpkg-source を含     む) 。これらのユーティリティはパッケージを作成・操作するのに必要 な基礎的で、低レイヤの機能を含んでいます。そのため、これらはあら ゆる Debian メンテナにとって必要不可欠なものです。 A.1.2. debconf debconf は、パッケージを対話形式で設定できる一貫したインターフェ イスを提供します。これはユーザインターフェイスに依存せず、エンド     ユーザがテキストのみのインターフェイス、HTML インターフェイス、ダ イアログ形式のインターフェイスでパッケージを設定できます。新たな インターフェイスはモジュールとして追加できます。     このパッケージに関するドキュメントは debconf-doc パッケージ中で確 認できます。 多くの人が、対話的な設定を必要とする全てのパッケージにこのシステ     ムが使われるべきだと感じています。「debconf による設定管理」を参 照してください。現在は debconf は Debian ポリシーで必要であるとは されていませんが、将来には変更されることでしょう。 A.1.3. fakeroot fakeroot は root 特権をシミュレートします。これは root になること 無しにパッケージをビルドできるようにしてくれます (パッケージは通     常 root の所有権でファイルをインストールしようとします)。fakeroot をインストールしているならば、通常のユーザでパッケージをビルドで きます: dpkg-buildpackage -rfakeroot A.2. パッケージチェック (lint) 用ツール コンピュータ用のフリーオンライン辞書 (Free On-line Dictionary of Computing, FOLDOC) によると、「lint」は C コンパイラよりもより網     羅的なチェックを行う Unix C 言語処理器とあります。パッケージ lint ツールは、パッケージ内の一般的な問題やポリシー違反を自動的に見つ けてくれることで、パッケージメンテナを助けてくれます。 A.2.1. lintian lintian は Debian パッケージを解剖してバグやポリシー違反の情報を     出力します。一般的なエラーへのチェック同様にDebian ポリシーの多く の部分を自動チェックする機能を含んでいます。 定期的に最新の lintian を unstable から取得し、パッケージを全てチ ェックするべきです。-i オプションは、各エラーや警告が何を意味して     いるのか、ポリシーを元に、詳細な説明を提供してくれ、一般的に問題 をどのように修正するべきかを説明してくれることに留意してください 。     何時、どのようにして Lintian を使うのか、詳細については「パッケー ジをテストする」を参照してください。 あなたのパッケージに対して Lintian によって報告されたの問題の要約     はすべて http://lintian.debian.org/ から確認することもできます。 このレポートは、最新の lintian による開発版ディストリビューション 　(unstable) 全体についての出力を含んでいます。 A.2.2. debdiff (devscripts パッケージ、「devscripts」より) debdiff は二つのパッ ケージのファイルのリストと control ファイルを比較します。前回のア ップロードからバイナリパッケージ数が変わったことや、control ファ     イル内で何が変わったのかなどに気付く手助けをしてくれるなど、簡単 なリグレッションテストとなります。もちろん、報告される変更の多く は問題ありませんが、様々なアクシデントを防止するのに役立ってくれ るでしょう。     バイナリパッケージのペアに対して実行することができます:     debdiff package_1-1_arch.deb package_2-1_arch.deb     changes ファイルのペアに対してさえも実行できます:     debdiff package_1-1_arch.changes package_2-1_arch.changes     より詳細については、debdiff(1)を参照してください。 A.3. debian/rules の補助ツール パッケージ構築ツールは debian/rules ファイルを書く作業を楽にして     くれます。これらが望ましい、あるいは望ましくない理由の詳細につい ては「ヘルパースクリプト」を参照してください。 A.3.1. debhelper debhelper は、Debian パッケージのバイナリを作成するにあたっての共 通な作業を自動化するため、debian/rules 内で使うことができるプログ     ラムの集合体です。debhelper は、パッケージに様々なファイルをイン ストールし、ファイルを圧縮し、ファイルの権限を修正し、パッケージ を Debian のメニューシステムに統合するプログラムを含んでいます。 いくつかのアプローチとは違って、debhelper は複数の小さな、シンプ     ルな一貫した方法で動作するコマンドに分割されています。そのため、 他の debian/rules 用ツールよりも細やかなコントロールが可能になっ ています。 ここに記すには一時的な、大量の小さな debhelper のアドオンパッケー     ジがあります。apt-cache search ^dh- と実行することで一覧の多くを 参照できます。 A.3.2. dh-make dh-make パッケージは、ソースツリーを Debian パッケージをビルドす るのに必要な雛形ファイルを作成するプログラム dh_make を含んでいま     す。その名が示すように、dh_make は debmake を書き直したもので、そ のテンプレートファイルはdebhelper の dh_* プログラムを使うように なっています。 dh_make によって生成された rules ファイルは、大抵の場合作業するパ ッケージに対して十分な基礎にはなりますが、まだこれは下地でしかあ     りません。メンテナに残っている責務は、生成されたファイルをきれい に整理して、完全に動作してポリシーに準拠したパッケージにすること です。 A.3.3. equivs equivs はパッケージ作成用のもう一つのパッケージです。単純に依存関 係を満たしたいだけのパッケージを作成する必要がある場合に、しばし     ばローカルでの使用を勧められます。時折、他のパッケージに依存する ことだけが目的のパッケージ、「メタパッケージ (meta-packages)」を 作る際にも使われます。 A.4. パッケージ作成ツール 以下のパッケージは、パッケージ作成作業を手助けしてくれます。通常     実行する dpkg-buildpackage と同様に、パッケージ作成支援の作業を取 り扱ってくれます。 A.4.1. cvs-buildpackage cvs-buildpackage は、Debian ソースパッケージを CVS リポジトリに挿     入あるいはインポートし、Debian パッケージを CVS リポジトリから生 成、そして開発元での変更をリポジトリに統合するのに役立つ機能を提 供します。 これらのユーティリティは、Debian メンテナによる CVS の利用を促進 するインフラストラクチャを提供します。これは、バージョンコントロ     ールシステムの他の利点と同様に、stable、unstable、おそらく experimental ディストリビューション用にパッケージに個々の CVS ブ ランチを持つことができます。 A.4.2. debootstrap debootstrap パッケージとスクリプトは、システムのどこででも Debian     ベースシステムをブートストラップできるようにしてくれます。ベース システムとは、操作するのに必要となる素の最小限パッケージ群を意味 し、それに加えてシステムの残りの部分をインストールします。 この様なシステムを持つことは、様々な面で役に立つでしょう。例えば 、ビルドの依存関係をテストしたい場合に chroot でそのシステムの中     に入ることができます。あるいは素のベースシステムにインストールし た際にパッケージがどのように振る舞うかをテストできます。chroot 作 成ツールはこのパッケージを使います。以下を参照ください。 A.4.3. pbuilder pbuilder は chroot されたシステムを構築し、パッケージを chroot 内     部でビルドします。パッケージのビルド依存関係が正しいかどうかをチ ェックするのにとても役立ち、生成されたパッケージに不必要な誤った ビルド依存関係が存在していないことを確かめられるでしょう。     User Mode Linux 環境でビルドを実行することで、よりさらに推し進め た関連パッケージが pbuilder-uml です。 A.4.4. sbuild sbuild はもう一つの自動ビルドシステムです。同様に chroot された環 境を使うことが出来ます。単独で使うことも、分散ビルド環境のネット ワークの一部として使うこともできます。文字通り、移植者たちによっ     て利用可能な全アーキテクチャのバイナリパッケージをビルドするのに 使われているシステムの一部です。詳細については「wanna-build」を参 照してください。それからシステムの動作については http:// buildd.debian.org/ を参照してください。 A.5. パッケージのアップロード用ツール     以下のパッケージはパッケージを公式アーカイブにアップロードする作 業を自動化、あるいは単純化してくれるのに役立ちます。 A.5.1. dupload dupload は、自動的に Debian パッケージを Debian アーカイブにアッ     プロードし、アップロードを記録し、パッケージのアップロードについ てのメールを送信してくれるパッケージであり、スクリプトです。新し いアップロード先や方法を設定することもできます。 A.5.2. dput dput パッケージとスクリプトは dupload と同じことを違ったやり方で     行います。GnuPG 署名とチェックサムをアップロード前にチェックする 機能や、アップロード後に dinstall を dry-run モードで実行できるな ど、dupload よりもいくつか機能が多くなっています。 A.5.3. dcut     dcut スクリプト (dput パッケージの一部、「dput」参照)は、ftp アッ プロードディレクトリからファイルを削除するのに役立ちます。 A.6. メンテナンスの自動化 以下のツールは changelog のエントリや署名行の追加、Emacs 内でのバ     グの参照から最新かつ公式の config.sub を使うようにするまで、様々 なメンテナンス作業を自動化するのに役立ちます。 A.6.1. devscripts devscripts は、Debian パッケージをメンテナンスするのに非常に有用 なラッパーやツールを含むパッケージです。スクリプトの例としては debian/changelog ファイルをコマンドラインから操作する debchange および dch、そして dpkg-buildpackage 関連のラッパーである debuild     を含んでいます。bts ユーティリティも、バグ報告の状態をコマンドラ イン上で更新するのにとても役立ちます。uscan はパッケージの新しい バージョン (new upstream version) をチェックするのに使えます。 debrsign は、リモートでアップロード前にパッケージにサインするのに 利用できます。これは GPG があるのとは違うマシンでパッケージをビル ドした際に便利です。     利用可能なスクリプトの全リストについては devscripts(1) マニュアル ページを参照してください。 A.6.2. autotools-dev autotools-dev は、autoconf や automake を使っているパッケージをメ     ンテナンスする人にとってのベストプラクティスを含んでいます。また 、全ての Debian 移植版で動作することを知られている正規の config.sub および config.guess ファイルを含んでいます。 A.6.3. dpkg-repack dpkg-repack は既にインストールされているパッケージから Debian パ     ッケージを生成します。パッケージが展開されてから何かしら変更が加 えられている場合 (例えば、/etc にあるファイルが変更されているな ど)、新しいパッケージは変更を含みます。 このユーティリティは、一つのコンピュータから他のコンピュータへパ ッケージをコピーするのを簡単にできるようにしてくれます。また、あ     なたのシステムにはインストールされているがどこでも入手できなくな ってしまったパッケージを再作成したり、アップグレード前にパッケー ジの現在の状態を保存するのに使えます。 A.6.4. alien alien は、Debian、RPM (RedHat)、LSB (Linux Standard Base)、     Solaris、Slackware などの各種バイナリパッケージのパッケージ形式を 変換します。 A.6.5. debsums debsums は、インストールされたパッケージについて MD5 sum をチェッ     クします。ポリシーでは必要とされていないため、全てのパッケージが MD5 sum を持ってはいないことに注意ください。 A.6.6. dpkg-dev-el dpkg-dev-el は、パッケージの debian ディレクトリにあるファイルを 編集する際に手助けしてくれる Emacs lisp パッケージです。例えば、     パッケージの現在のバグをリストアップしてくれたり、debian/ changelog ファイル中の最新のエントリの終端処理してくれたりするの ための手軽な機能があります。 A.6.7. dpkg-depcheck (devscripts パッケージ、「devscripts」より) dpkg-depcheck は、指     定されたコマンドによって使われた全てのパッケージを確認するため、 コマンドを strace の下で実行します。 Debian パッケージについていうと、これは新しいパッケージの     Build-Depends 行を構成するのが必要になった際に役立ちます。 dpkg-depcheck を通してビルド作業を実行すると、最初の大まかなビル ドの依存関係を良い形で得られます。例えば以下の様にします:     dpkg-depcheck -b debian/rules build dpkg-depcheck は、特にパッケージが他のプログラムを実行するのに     exec(2) を使っている場合に実行時の依存性を確認するのにも使えます 。     より詳細については、dpkg-depcheck(1) を参照してください。 A.7. 移植用ツール     以下のツールが、移植作業者やクロスコンパイル作業に役立ちます。 A.7.1. quinn-diff quinn-diff は、あるアーキテクチャと他のアーキテクチャとの違いを確     認するのに使われます。例えば、X アーキテクチャをベースに Y アーキ テクチャに移植するにはどのパッケージが必要なのかを教えてくれます 。 A.7.2. dpkg-cross dpkg-cross は、dpkg に似た方法でクロスコンパイルするためのライブ     ラリとヘッダをインストールするツールです。さらに、 dpkg-buildpackage および dpkg-shlibdeps の機能がクロスコンパイル をサポートするように拡張されます。 A.8. ドキュメントと情報について     以下のパッケージが、メンテナへの情報提供やドキュメントの作成に役 立ちます。 A.8.1. docbook-xml docbook-xml は Debian のドキュメントで一般的に使われている     DocBook XML DTD を提供します (古いものは debiandoc SGML DTD を使 っています) 。例えば、このマニュアルは DocBook XML で書かれていま す。 docbook-xsl パッケージは、ソースをビルドして様々な出力フォーマッ トに整形する XSL ファイルを提供します。XSL スタイルシートを使うに     は xsltproc のような XSLT プロセッサが必要になります。スタイルシ ートのドキュメントは各種 docbook-xsl-doc-* パッケージで確認できま す。 FO から PDF を生成するには、xmlroff や fop のような FO プロセッサ     が必要です。他に DocBook XML から PDF を生成するツールとしては dblatex があります。 A.8.2. debiandoc-sgml debiandoc-sgml は Debian のドキュメントで一般的に使われている DebianDoc SGML DTD を提供します。しかし、現在は非推奨     (deprecated) となっています (代わりにdocbook-xml を使うようにして ください)。これも、ソースをビルドして様々な出力フォーマットに整形 するスクリプトを提供します。     ドキュメント用の DTD は debiandoc-sgml-doc パッケージで確認できま す。 A.8.3. debian-keyring Debian 開発者の公開 GPG/PGP 鍵を含んでいます。詳細については     http://wiki.debian.org/DebianMaintainer とパッケージ内のドキュメ ントを参照してください。 A.8.4. debian-maintainers     Debian メンテナの公開 GPG 鍵を含んでいます。詳細については http:/ /wiki.debian.org/DebianMaintainer を参照してください。 A.8.5. debview debview は、Debian バイナリパッケージを参照する Emacs モードを提     供します。これを使うと、パッケージを展開しなくても実行できるよう になります。