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.8

このマニュアルはフリーソフトウェアです。あなたは、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 版を利用すると良いでしょう。このページは フランス語ドイツ語日本語でも利用可能です。

2012-06-25


目次

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.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 vs QA アップロード
5.11.7. NMU vs チームアップロード
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