第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. Porting and being ported
5.10.1. Being kind to porters
5.10.2. Guidelines for porter uploads
5.10.3. Porting infrastructure and automation
5.10.4. あなたのパッケージが移植可能なものではない場合
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)

この章では、パッケージの作成、アップロード、メンテナンス、移植についての情報を扱います。

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 個以上) を行っている場合、メーリングリストへ個別に通知するのは鬱陶しいので、代わりにバグを登録した後で要約を送信してください。これによって、他の開発者らに次に来るパッケージを知らせ、説明とパッケージ名のレビューが可能になります。

新規パッケージがアーカイブへインストールされる際にバグ報告を自動的に閉じるため、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、あるいは native パッケージの場合は /usr/share/doc/package/changelog.gz にインストールされます。

debian/changelog ファイルは、幾つもの異なった項目からなる特定の構造に従っています。一点を取り上げてみると、distribution については「ディストリビューションを選ぶ」に記述されています。このファイルの構造について、より詳細な情報は Debian ポリシーの debian/changelog という章で確認できます。

changelog への記載は、パッケージがアーカイブにインストールされる際、自動的に Debian バグを閉じるのに利用できます。「新規アップロードでバグがクローズされる時」 を参照してください。

ソフトウェアの新しい開発元のバージョン (new upstream version) を含むパッケージの changelog エントリは、以下のようにするのが慣習です:

  * New upstream release.

changelog エントリの作成と仕上げ処理に使えるツールがあります。devscriptsdpkg-dev-el を参照してください。

「Best practices for debian/changelog も参照してください。

5.3. パッケージをテストする

パッケージをアップロードする前に、基本的なテストをする必要があります。最低限、以下の作業が必要です (同じ Debian パッケージの古いバージョンなどが必要になるでしょう):

  • パッケージをインストールしてソフトウェアが動作するのを確認する、あるいは既にそのソフトの Debian パッケージが存在している場合、パッケージを以前のバージョンから新しいバージョンにアップグレードする。

  • パッケージに対して lintian を実行する。以下のようにして lintian を実行できます: lintian -v package-version.changeslintian が生成した出力を理解していない場合は、lintian が問題の説明を非常に冗長に出力するようにする -i オプションを付けて実行してみてください。

    通常、lintian がエラーを出力するようであれば、パッケージをアップロードしてはいけません (エラーは E で始まります)。

    lintian についての詳細は、lintian を参照してください。

  • もし古いバージョンがあれば、それからの変更点を分析するために追加で debdiff を実行する (debdiff を参照) 。

  • (もしあれば) 以前のバージョンにダウングレードする — これは postrm スクリプトと prerm スクリプトをテストします。

  • パッケージを削除して、再インストールする。

  • ソースパッケージを違うディレクトリにコピーして展開し、再構築する。これは、パッケージが外部の既存ファイルに依っているか、.diff.gz ファイル内に含まれているファイルで保存されている権限に依るかどうかをテストします。

5.4. ソースパッケージの概要

Debian のソースパッケージには 2 種類あります:

  • いわゆる nativeパッケージ。元のソースと Debian で当てられたパッチの間に差が無いもの

  • オリジナルのソースコードの tarball ファイルに、Debian によって作成された変更点を含む別のファイルが付随している (より一般的な) パッケージ

native パッケージの場合、ソースパッケージは Debian のソース control ファイル (.dsc) とソースコードの tarball (.tar.{gz,bz2,lzma}) を含んでいます。native ではないパッケージのソースパッケージは Debian のソース control ファイルと、オリジナルのソースコードの tarball (.orig.tar.{gz,bz2,lzma})、そして Debian での変更点 (ソース形式“1.0”は .diff.gz、ソース形式“3.0 (quilt)”は .debian.tar.{gz,bz2,lzma}) を含んでいます。

ソース形式“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,lzma} 内に存在しないファイルのパーミッションは保持されません。しかし、ソース形式“3.0 (quilt)”を使っている場合、debian ディレクトリ内にあるファイルのパーミッションは tar アーカイブで保存されるのでそのままになります。

5.5. ディストリビューションを選ぶ

アップロードでは、パッケージがどのディストリビューション向けになっているかを指定してあることが必要です。パッケージの構築プロセスでは、debian/changelog ファイルの最初の行からこの情報を展開し、.changes ファイルの Distribution 欄に配置します。

この欄にはいくつか指定可能な値があります: stableunstabletesting-proposed-updates、そして experimental です。通常、パッケージは unstable にアップロードされます。

実際には、他に二つ指定可能なディストリビューションがあります: stable-securitytesting-security ですが、これらについての詳細は 「セキュリティ関連バグの取扱い」 を読んでください。

同時に複数のディストリビューションへパッケージをアップロードすることはできません。

5.5.1. 特別な例: 安定版 (stable)旧安定版 (oldstable) ディストリビューションへアップロードする

安定版 (stable) へのアップロードは、安定版リリースマネージャによるレビューのため、パッケージが proposed-updates-new キューに転送され、許可された場合は Debian アーカイブの stable-proposed-updates ディレクトリにインストールされます。

アップロードが許可されるのを確実にするには、アップロードの前に変更点について安定版リリースチームと協議する必要があります。そのためには、安定版 (stable) にある現在のパッケージバージョンに適用したいパッチを含めたメールを メーリングリストに送ってください。安定版 (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 されるかもしれません。

パッケージのアップロードを行う際には duploaddput が便利なことにも気づくことでしょう。これらの便利なプログラムは、パッケージを Debian にアップロードする作業を自動化するのに役立ちます。

パッケージを削除するには ftp://ftp.upload.debian.org/pub/UploadQueue/READMEdcut Debian パッケージを参照してください。

5.6.2. 遅延アップロード

パッケージを直ちにアップロードするのが良い時もありますが、パッケージがアーカイブに入るのが数日後であるのが良いと思う時もあります。例えば、Non-Maintainer アップロードの準備をする際は、メンテナに対して猶予期間を数日間与えたいと思うでしょう。

delayed ディレクトリにアップロードされると、パッケージは the deferred uploads queue に保存されます。指定した待ち時間が終わると、パッケージは処理のため通常の incoming ディレクトリに移動されます。この作業は ftp.upload.debian.orgDELAYED/[012345678]-day ディレクトリへのアップロードを通じて自動的に処理されます。0-day は一日に複数回 ftp.upload.debian.org へアップロードするのに使われます。

dput を使うと、パッケージを遅延キューに入れるのに --delayed DELAY パラメータを使えます。

5.6.3. セキュリティアップロード

セキュリティアップロードキュー (oldstable-securitystable-security 等) には、セキュリティチームからの事前許可無しにパッケージをアップロードしないでください。パッケージがチームの要求に完全に合致していない場合、望まれないアップロードに対処するために多くの問題が引き起こされたり遅延が生じることになります。詳細については 「セキュリティ関連バグの取扱い」 を参照してください。

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 アーカイブメンテナはパッケージのアップロードに関して責任を持っています。多くの部分は、アップロードはアーカイブ用のメンテナンスツール katie によって日々自動的に行われています。特に、不安定版 (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. バグへの対応

バグに対応する際は、バグについて行った議論がバグの元々の報告者とバグ自身 (例えば ) の両方に送られているのを確認してください。新しくメールを書いていて元々の報告者のメールアドレスを思い出せない場合は、 というメールアドレスが報告者へ連絡するのと、さらにバグのログへあなたがメールしたのを記録するのにも使えます (これは へメールのコピーを送らなくても済むことを意味しています)。

FTBFS である旨のバグを受け取った場合、これはソースからビルドできないこと (Fails to build from source) を意味します。移植作業をしている人たちはこの略語をよく使います。

既にバグに対処していた場合 (例えば修正済みの時)、説明のメッセージを に送ることで done とマークしておいて (閉じて) ください。パッケージを変更してアップロードすることでバグを修正する場合は、「新規アップロードでバグがクローズされる時」 に記載されているように自動的にバグを閉じることができます。

close コマンドを に送って、バグサーバ経由でバグを閉じるのは決してしてはいけません。そのようにした場合、元々の報告者は何故バグが閉じられたのかという情報を得られません。

5.8.3. バグを掃除する

パッケージメンテナになると、他のパッケージにバグを見つけたり、自分のパッケージに対して報告されたバグが実際には他のパッケージにあるバグであったりということが頻繁にあるでしょう。バグ追跡システムの機能は Debian 開発者向けの BTS ドキュメント に記載されています。バグ報告の再指定 (reassign) やマージ (merge)、そしてタグ付けなどの作業は BTS 制御サーバのドキュメント に記述されています。この章では、Debian 開発者から集められた経験を元にしたバグの扱い方のガイドラインを含んでいます。

他のパッケージで見つけた問題についてバグを登録するのは、メンテナとしての責務の一つです。詳細については 「バグ報告」 を参照してください。しかし、自分のパッケージのバグを管理するのはさらに重要です。

以下がバグ報告を取り扱う手順です:

  1. 報告が実際にバグに関連するものか否かを決めてください。ユーザはドキュメントを読んでいないため、誤ったプログラムの使い方をしているだけのことが時々あります。このように判断した場合は、ユーザに問題を修正するのに十分な情報を与えて (良いドキュメントへのポインタを教えるなどして) バグを閉じます。同じ報告が何度も繰り返し来る場合には、ドキュメントが十分なものかどうか、あるいは有益なエラーメッセージを与えるよう、誤った使い方を検知していないのでは、と自身に問い直してください。これは開発元の作者に伝える必要がある問題かもしれません。

    バグを閉じるという貴方の判断にバグ報告者らが同意しない場合には、それをどう取り扱うかについての同意が見つかるまで、彼らは再度オープンな状態 (reopen) にするでしょう。そのバグについてもう議論することが無いという場合は、バグは存在するが修正することはないと知らせるため、バグに対して wontfix タグを付けることになります。この決定が受け入れがたい時には、あなた (あるいは報告者) はバグを tech-ctte に再指定 (reassign) して技術委員会 (technical committee) の判断を仰いでください (パッケージへ報告されたものをそのままにしておきたい場合は、BTS の clone コマンドを使ってください)。これを行う前には推奨手順を読んでおいてください。

  2. バグが実際にあるが、他のパッケージによって引き起こされている場合は、バグを正しいパッケージに再指定 (reassign) します。どのパッケージに再指定するべきかが分からない場合は、IRC で聞いてください。再指定するパッケージのメンテナに通知をしてください。例えば 宛にメッセージを Cc: してメール中に理由を説明するなどします。単に再指定しただけでは再指定された先のメンテナにはメールは送信されませんので、彼らがパッケージのバグ一覧を見るまでそれを知ることはありません。

    バグがあなたのパッケージの動作に影響する場合は、バグを複製し (clone)、複製したバグをその挙動を実際に起こしているパッケージに再指定することを検討してください。さもなければ、あなたのパッケージのバグ一覧にバグが見つからないので、多分ユーザに同じバグを何度も繰り返し報告される羽目になる可能性があります。あなたは、再指定 (reassign) によって「自分の」バグということを防ぎ、バグの複製 (clone) によって関係があることを記載しておく必要があります。

  3. 時々、重要度の定義に合うようにバグの重要度を調整する必要もあります。これは、人々はバグ修正を確実に早くしてもらうために重要度を極端に上げようとするからです。要望された変更点が単に体裁的なものな時には、バグは要望 (wishlist) に格下げされるでしょう。

  4. バグが確かにあるが既に他の誰かによって同じ問題が報告されている場合は、2 つの関連したバグを BTS の merge コマンドを使って 1 つにマージします。このようにすると、バグが修正された時に全ての投稿者に通知がいきます (ですが、そのバグ報告の投稿者へのメールは報告の他の投稿者には自動的には通知されないことに注意してください)。merge コマンドや類似の unmerge コマンドの技術詳細については、BTS 制御サーバドキュメントを参照してください。

  5. バグ報告者は情報を書き漏らしている場合、必要な情報を尋ねる必要があります。その様なバグに印をつけるには moreinfo タグを使います。さらに、そのバグを再現できない場合には、unreproducible タグを付けます。誰もそのバグを再現できない場合、どうやって再現するのか、さらに情報を何ヶ月経っても、この情報が誰からも送られてこない場合はバグは閉じても構いません。

  6. バグがパッケージに起因する場合、さっさと直します。自分では直せない場合は、バグに help タグを付けます。 で助けを求めることも出来ます。開発元 (upstream) の問題であれば、作者に転送する必要があります。バグを転送するだけでは十分ではありません。リリースごとにバグが修正されているかどうかを確認しなければいけません。もし修正されていれば、それを閉じ、そうでなければ作者に確認を取る必要があります。必要な技能を持っていてバグを修正するパッチが用意できる場合は、同時に作者に送りましょう。パッチを BTS に送付してバグに patch タグを付けるのを忘れないでください。

  7. ローカル環境でバグを修正した、あるいは VCS リポジトリに修正をコミットした場合には、バグに pending タグを付けてバグが修正されたことと次のアップロードでバグが閉じられるであろうことを回りに知らせます (changelogcloses: を追加します)。これは複数の開発者が同一のパッケージで作業している際に特に役立ちます。

  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 のエントリにバグを入れ忘れた場合、そのミスが起こすであろうダメージを防ぐのを躊躇わないでください。誤って閉じたバグを再度オープンにするには、バグトラッキングシステムのコントロールアドレスである reopen XXX コマンドを投げます。アップロードで修正されたがまだ残っているバグを閉じるには .changes ファイルを にメールします。XXX はバグ番号で、メールの本文の最初の 2 行に Version: YYY と空白行を入れます。YYY はバグが修正された最初のバージョンです。

上に書いたような changelog を使ったバグの閉じ方は必須ではない、ということは念頭に置いておいてください。行ったアップロードとは無関係に単にバグを閉じたい、という場合は、説明をメールに書いて に送ってバグを閉じてください。そのバージョンのパッケージでの変更がバグに何も関係ない場合は、そのバージョンの changelog エントリではバグを閉じないでください。

どのように changelog のエントリを書くのか、一般的な情報については 「Best practices for debian/changelog を参照してください。

5.8.5. セキュリティ関連バグの取扱い

機密性が高いその性質上、セキュリティ関連のバグは注意深く取り扱わねばなりません。この作業をコーディネイトし、未処理のセキュリティ問題を追い続け、セキュリティ問題についてメンテナを手助けしたり修正自体を行い、セキュリティ勧告を出し、security.debian.org を維持するために Debian セキュリティチームが存在します。

Debian パッケージ中のセキュリティ関連のバグに気づいたら、あなたがメンテナであるかどうかに関わらず、問題に関する正確な情報を集めて、まずは可能な限り早く 宛でセキュリティチームに連絡を取ってください。チームに問い合わせること無く 安定版 (stable) 向けのパッケージをアップロードしないでください。例えば、役に立つ情報は以下を含んでいます:

  • バグによって、どのバージョンが影響を受けると分かっているか。サポートされている Debian のリリース、ならびに テスト版 (testing) 及び 不安定版 (unstable) にある各バージョンをチェックしてください。

  • 利用可能なものがあれば、修正内容 (パッチが特に望ましい)

  • 自身で準備した修正パッケージ (まずは 「セキュリティ問題に対処するパッケージを用意する」 を読んで、.diff.gz.dsc ファイルだけを送ってください)

  • テストについて何かしらの手助けになるもの (攻撃コード、リグレッションテストなど)

  • 勧告に必要になる情報 (「セキュリティ勧告」 参照)

パッケージメンテナとして、あなたは安定版リリースについてもメンテナンスする責任を持ちます。あなたがパッチの評価と更新パッケージのテストを行うのに最も適任な人です。ですから、以下のセキュリティチームによって取り扱ってもらうため、どのようにしてパッケージを用意するかについての章を参照してください。

5.8.5.1. セキュリティ追跡システム

セキュリティチームは集約的なデータベース、Debian セキュリティ追跡システムをメンテナンスしています。これはセキュリティ問題として知られている全ての公開情報を含んでいます: どのパッケージ/バージョンが影響を受ける/修正されているか、つまりは安定版、テスト版、不安定版が脆弱かどうか、という情報です。まだ機密扱いの情報は追跡システムには追加されません。

特定の問題について検索することもできますし、パッケージ名でも検索できます。あなたのパッケージを探して、どの問題がまだ未解決かを確認してください。できれば追加情報を提供するか、パッケージの問題に対処するのを手伝ってください。やり方は追跡システムのウェブページにあります。

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 パッケージの interdiffdevscriptsdebdiff が役立ちます。debdiff を参照してください)。

以下の項目を必ず確認してください

  • debian/changelog正しいディストリビューションを対象にする安定版 (stable) の場合、これは stable-security になり、テスト版 (testing) の場合は testing-security に、そして以前の安定版リリースへの場合は oldstable-security となります。distribution-proposed-updatesstable を対象にしないでください!

  • アップロードは urgency=high で行う必要があります。

  • 説明が十分にされている、意味がある changelog エントリを書くこと。他の人は、これらを元に特定のバグが修正されているのかを見つけ出します。登録されている Debian バグ に対して closes: 行を追加すること。外部のリファレンス、できれば CVE 識別番号 を常に含めること、そうすれば相互参照が可能になります。しかし、CVE 識別番号がまだ付与されていない場合には、それを待たずに作業を進めてください。識別番号は後ほど付与することができます。

  • バージョン番号が正しいことを確認する。現在のパッケージより大きく、しかし以降のディストリビューションよりパッケージバージョンが小さい必要があります。分からない場合は dpkg --compare-versions でテストしてください。以前のアップロードで既に使っているバージョン番号を再利用しないように注意してください。そうしないと番号が binNMU と衝突します。+codename1 を追加するのが通例です。例えば 1:2.4.3-4+lenny1 とします。もちろん 1 はアップロードするごとに増やします。

  • これまでに (以前のセキュリティ更新によって) security.debian.org へ開発元のソースコードをアップロードしていなければ、開発元のソースコードを全て含めてアップロードするパッケージをビルドする (dpkg-buildpackage -sa)。以前、同じ開発元のバージョンで security.debian.org にアップロードしたことがある場合は、開発元のソースコード無しでアップロードしても構いません (dpkg-buildpackage -sd)。

  • 通常のアーカイブで使われているのと全く同じ *.orig.tar.{gz,bz2,lzma}を必ず使うようにしてください。さもなくば、後ほどセキュリティ習性を main アーカイブに移動することができません。

  • ビルドを行っているディストリビューションからインストールしたパッケージだけが含まれているクリーンなシステム上でパッケージをビルドしてください。その様なシステムを自分で持っていない場合は、debian.org マシン (「Debian のマシン群」 を参照してください) を使うこともできますし、chroot を設定することもできます (pbuilderdebootstrap を参照してください)。

5.8.5.5. 修正したパッケージをアップロードする

セキュリティアップロードキュー (oldstable-securitystable-security 等) には、セキュリティチームからの事前許可無しにパッケージをアップロードしないでください。パッケージがチームの要求に完全に合致していない場合、望まれないアップロードに対処するために多くの問題が引き起こされたり遅延が生じることになります。詳細については 「セキュリティ関連バグの取扱い」 を参照してください。

セキュリティチームと調整する事無しに 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,lzma} を (開発元のバージョンが新しいものになったのではなくても) アップロードに含める必要があります。新しいセクションが正しい場合は、自動的に移動されます。移動されない場合には、何が起こったのかを理解するために ftpmaster に連絡を取ります。

If, on the other hand, you need to change the subsection of one of your packages (e.g., ``devel'', ``admin''), the procedure is slightly different. Correct the subsection as found in the control file of the package, and re-upload that. Also, you'll need to get the override file updated, as described in 「パッケージのセクション、サブセクション、優先度を指定する」.

5.9.2. パッケージの削除

何らかの理由でパッケージを完全に削除したくなった場合 (もう必要がなくなった古い互換用ライブラリの場合、など)、パッケージを削除するよう ftp.debian.org に対してバグ登録をする必要があります; すべてのバグ同様、通常このバグは重要度 normal です。バグの題名は RM: パッケージ名 [アーキテクチャ一覧] -- 理由 という形式である必要があります。パッケージ名は削除されるパッケージ、理由は削除を依頼する理由の短い要約です。[アーキテクチャ一覧]はオプションで、削除依頼が全アーキテクチャではなく一部のアーキテクチャのみに適用される場合にのみ、必要となります。reportbugftp.debian.org 擬似パッケージに対してバグを報告しようとした場合に、これらのルールに則ってバグの題名を作成しようとすることに注意してください。

あなたがメンテナンスしているパッケージを削除したくなった場合は、題名の先頭に ROM (Request Of Maintainer) という文字を付けたバグにこれを記述する必要があります。パッケージの削除理由に使われる他の一般的な略語が幾つかありますので、完全な一覧については http://ftp-master.debian.org/removals.html を参照してください。このページでは、まだ作業されていない削除依頼の便利な一覧も見ることができます。

削除は不安定版 (unstable)実験版 (experimental)安定版 (stable) ディストリビューションに対してのみ実施が可能であることに注意してください。パッケージは テスト版 (testing) から直接は削除されません。代わりに不安定版 (unstable) から削除された後で自動的に削除され、テスト版 (testing) にあるパッケージは削除されたパッケージに依存しなくなります。

There is one exception when an explicit removal request is not necessary: If a (source or binary) package is an orphan, it will be removed semi-automatically. For a binary-package, this means if there is no longer any source package producing this binary package; if the binary package is just no longer produced on some architectures, a removal request is still necessary. For a source-package, this means that all binary packages it refers to have been taken over by another source package.

In your removal request, you have to detail the reasons justifying the request. This is to avoid unwanted removals and to keep a trace of why a package has been removed. For example, you can provide the name of the package that supersedes the one to be removed.

Usually you only ask for the removal of a package maintained by yourself. If you want to remove another package, you have to get the approval of its maintainer. Should the package be orphaned and thus have no maintainer, you should first discuss the removal request on . If there is a consensus that the package should be removed, you should reassign and retitle the O: bug filed against the wnpp package instead of filing a new bug as removal request.

Further information relating to these and other package removal related topics may be found at http://wiki.debian.org/ftpmaster_Removals and http://qa.debian.org/howto-remove.html.

If in doubt concerning whether a package is disposable, email asking for opinions. Also of interest is the apt-cache program from the apt package. When invoked as apt-cache showpkg package, the program will show details for package, including reverse depends. Other useful programs include apt-cache rdepends, apt-rdepends, build-rdeps (in the devscripts package) and grep-dctrl. Removal of orphaned packages is discussed on .

Once the package has been removed, the package's bugs should be handled. They should either be reassigned to another package in the case where the actual code has evolved into another package (e.g. libfoo12 was removed because libfoo13 supersedes it) or closed if the software is simply no longer part of Debian. When closing the bugs, to avoid marking the bugs as fixed in versions of the packages in previous Debian releases, they should be marked as fixed in the version <most-recent-version-ever-in-Debian>+rm.

5.9.2.1. Incoming からパッケージを削除する

以前は、incoming からパッケージを削除することが可能でした。しかし、新しい incoming システムが導入されたことにより、これはもはや不可能となっています。その代わりに、置き換えたいパッケージよりも高いバージョンのリビジョンの新しいパッケージをアップロードする必要があります。両方のバージョンのパッケージがアーカイブにインストールされますが、一つ前のバージョンはすぐに高いバージョンで置き換えられるため、実際にはバージョンが高い方だけが 不安定版 (unstable) で利用可能になります。しかし、もしあなたがパッケージをきちんとテストしていれば、パッケージを置き換える必要はそんなに頻繁には無いはずです。

5.9.3. パッケージをリプレースあるいはリネームする

When the upstream maintainers for one of your packages chose to rename their software (or you made a mistake naming your package), you should follow a two-step process to rename it. In the first step, change the debian/control file to reflect the new name and to replace, provide and conflict with the obsolete package name (see the Debian Policy Manual for details). Please note that you should only add a Provides relation if all packages depending on the obsolete package name continue to work after the renaming. Once you've uploaded the package and the package has moved into the archive, file a bug against ftp.debian.org asking to remove the package with the obsolete name (see 「パッケージの削除」). Do not forget to properly reassign the package's bugs at the same time.

At other times, you may make a mistake in constructing your package and wish to replace it. The only way to do this is to increase the version number and upload a new version. The old version will be expired in the usual manner. Note that this applies to each part of your package, including the sources: if you wish to replace the upstream source tarball of your package, you will need to upload it with a different version. An easy possibility is to replace foo_1.00.orig.tar.gz with foo_1.00+0.orig.tar.gz or foo_1.00.orig.tar.bz2. This restriction gives each file on the ftp site a unique name, which helps to ensure consistency across the mirror network.

5.9.4. パッケージをみなしご化する

If you can no longer maintain a package, you need to inform others, and see that the package is marked as orphaned. You should set the package maintainer to Debian QA Group <packages@qa.debian.org> and submit a bug report against the pseudo package wnpp. The bug report should be titled O: package -- short description indicating that the package is now orphaned. The severity of the bug should be set to normal; if the package has a priority of standard or higher, it should be set to important. If you feel it's necessary, send a copy to by putting the address in the X-Debbugs-CC: header of the message (no, don't use CC:, because that way the message's subject won't indicate the bug number).

If you just intend to give the package away, but you can keep maintainership for the moment, then you should instead submit a bug against wnpp and title it RFA: package -- short description. RFA stands for Request For Adoption.

より詳細な情報は WNPP ウェブページにあります。

5.9.5. パッケージに変更を加える

A list of packages in need of a new maintainer is available in the Work-Needing and Prospective Packages list (WNPP). If you wish to take over maintenance of any of the packages listed in the WNPP, please take a look at the aforementioned page for information and procedures.

It is not OK to simply take over a package that you feel is neglected — that would be package hijacking. You can, of course, contact the current maintainer and ask them if you may take over the package. If you have reason to believe a maintainer has gone AWOL (absent without leave), see 「活動的でない、あるいは連絡が取れないメンテナに対応する」.

Generally, you may not take over the package without the assent of the current maintainer. Even if they ignore you, that is still not grounds to take over a package. Complaints about maintainers should be brought up on the developers' mailing list. If the discussion doesn't end with a positive conclusion, and the issue is of a technical nature, consider bringing it to the attention of the technical committee (see the technical committee web page for more information).

If you take over an old package, you probably want to be listed as the package's official maintainer in the bug system. This will happen automatically once you upload a new version with an updated Maintainer field, although it can take a few hours after the upload is done. If you do not expect to upload a new version for a while, you can use 「パッケージ追跡システム」 to get the bug reports. However, make sure that the old maintainer has no problem with the fact that they will continue to receive the bugs during that time.

5.10. Porting and being ported

Debian がサポートするアーキテクチャの数は増え続けています。あなたが移植作業者ではない、あるいは別のアーキテクチャを使うことが無いという場合であっても、移植性の問題に注意を払うことはメンテナとしてのあなたの義務です。従って、あなたが移植作業者でなくても、この章の大半を読む必要があります。

Porting is the act of building Debian packages for architectures that are different from the original architecture of the package maintainer's binary package. It is a unique and essential activity. In fact, porters do most of the actual compiling of Debian packages. For instance, when a maintainer uploads a (portable) source packages with binaries for the i386 architecture, it will be built for each of the other architectures, amounting to 12 more builds.

5.10.1. Being kind to porters

Porters have a difficult and unique task, since they are required to deal with a large volume of packages. Ideally, every source package should build right out of the box. Unfortunately, this is often not the case. This section contains a checklist of ``gotchas'' often committed by Debian maintainers — common problems which often stymie porters, and make their jobs unnecessarily difficult.

The first and most important thing is to respond quickly to bug or issues raised by porters. Please treat porters with courtesy, as if they were in fact co-maintainers of your package (which, in a way, they are). Please be tolerant of succinct or even unclear bug reports; do your best to hunt down whatever the problem is.

By far, most of the problems encountered by porters are caused by packaging bugs in the source packages. Here is a checklist of things you should check or be aware of.

  1. Make sure that your Build-Depends and Build-Depends-Indep settings in debian/control are set properly. The best way to validate this is to use the debootstrap package to create an unstable chroot environment (see debootstrap). Within that chrooted environment, install the build-essential package and any package dependencies mentioned in Build-Depends and/or Build-Depends-Indep. Finally, try building your package within that chrooted environment. These steps can be automated by the use of the pbuilder program which is provided by the package of the same name (see pbuilder).

    chroot を正しく設定できない場合は、dpkg-depcheck が手助けになることでしょう (dpkg-depcheck 参照)。

    ビルドの依存情報の指定方法については、Debian ポリシーマニュアルを参照してください。

  2. 意図がある場合以外は、アーキテクチャの値を all または any 以外に指定しないでください。非常に多くの場合、メンテナが Debianポリシーマニュアル の指示に従っていません。アーキテクチャを単一のものに指定する (i386 あるいは amd64 など) は大抵誤りです。

  3. Make sure your source package is correct. Do dpkg-source -x package.dsc to make sure your source package unpacks properly. Then, in there, try building your package from scratch with dpkg-buildpackage.

  4. Make sure you don't ship your source package with the debian/files or debian/substvars files. They should be removed by the clean target of debian/rules.

  5. Make sure you don't rely on locally installed or hacked configurations or programs. For instance, you should never be calling programs in /usr/local/bin or the like. Try not to rely on programs being setup in a special way. Try building your package on another machine, even if it's the same architecture.

  6. Don't depend on the package you're building being installed already (a sub-case of the above issue). There are, of course, exceptions to this rule, but be aware that any case like this needs manual bootstrapping and cannot be done by automated package builders.

  7. Don't rely on the compiler being a certain version, if possible. If not, then make sure your build dependencies reflect the restrictions, although you are probably asking for trouble, since different architectures sometimes standardize on different compilers.

  8. Make sure your debian/rules contains separate binary-arch and binary-indep targets, as the Debian Policy Manual requires. Make sure that both targets work independently, that is, that you can call the target without having called the other before. To test this, try to run dpkg-buildpackage -B.

5.10.2. Guidelines for porter uploads

If the package builds out of the box for the architecture to be ported to, you are in luck and your job is easy. This section applies to that case; it describes how to build and upload your binary package so that it is properly installed into the archive. If you do have to patch the package in order to get it to compile for the other architecture, you are actually doing a source NMU, so consult 「いつ、どうやって NMU を行うか」 instead.

For a porter upload, no changes are being made to the source. You do not need to touch any of the files in the source package. This includes debian/changelog.

The way to invoke dpkg-buildpackage is as dpkg-buildpackage -B -mporter-email. Of course, set porter-email to your email address. This will do a binary-only build of only the architecture-dependent portions of the package, using the binary-arch target in debian/rules.

If you are working on a Debian machine for your porting efforts and you need to sign your upload locally for its acceptance in the archive, you can run debsign on your .changes file to have it signed conveniently, or use the remote signing mode of dpkg-sig.

5.10.2.1. 再コンパイル、あるいは binary-only NMU

Sometimes the initial porter upload is problematic because the environment in which the package was built was not good enough (outdated or obsolete library, bad compiler, etc.). Then you may just need to recompile it in an updated environment. However, you have to bump the version number in this case, so that the old bad package can be replaced in the Debian archive (dak refuses to install new packages if they don't have a version number greater than the currently available one).

You have to make sure that your binary-only NMU doesn't render the package uninstallable. This could happen when a source package generates arch-dependent and arch-independent packages that have inter-dependencies generated using dpkg's substitution variable $(Source-Version).

Despite the required modification of the changelog, these are called binary-only NMUs — there is no need in this case to trigger all other architectures to consider themselves out of date or requiring recompilation.

Such recompilations require special ``magic'' version numbering, so that the archive maintenance tools recognize that, even though there is a new Debian version, there is no corresponding source update. If you get this wrong, the archive maintainers will reject your upload (due to lack of corresponding source code).

The ``magic'' for a recompilation-only NMU is triggered by using a suffix appended to the package version number, following the form bnumber. For instance, if the latest version you are recompiling against was version 2.9-3, your binary-only NMU should carry a version of 2.9-3+b1. If the latest version was 3.4+b1 (i.e, a native package with a previous recompilation NMU), your binary-only NMU should have a version number of 3.4+b2.[4]

Similar to initial porter uploads, the correct way of invoking dpkg-buildpackage is dpkg-buildpackage -B to only build the architecture-dependent parts of the package.

5.10.2.2. When to do a source NMU if you are a porter

Porters doing a source NMU generally follow the guidelines found in 「Non-Maintainer Upload (NMU)」, just like non-porters. However, it is expected that the wait cycle for a porter's source NMU is smaller than for a non-porter, since porters have to cope with a large quantity of packages. Again, the situation varies depending on the distribution they are uploading to. It also varies whether the architecture is a candidate for inclusion into the next stable release; the release managers decide and announce which architectures are candidates.

If you are a porter doing an NMU for unstable, the above guidelines for porting should be followed, with two variations. Firstly, the acceptable waiting period — the time between when the bug is submitted to the BTS and when it is OK to do an NMU — is seven days for porters working on the unstable distribution. This period can be shortened if the problem is critical and imposes hardship on the porting effort, at the discretion of the porter group. (Remember, none of this is Policy, just mutually agreed upon guidelines.) For uploads to stable or testing, please coordinate with the appropriate release team first.

Secondly, porters doing source NMUs should make sure that the bug they submit to the BTS should be of severity serious or greater. This ensures that a single source package can be used to compile every supported Debian architecture by release time. It is very important that we have one version of the binary and source package for all architectures in order to comply with many licenses.

Porters should try to avoid patches which simply kludge around bugs in the current version of the compile environment, kernel, or libc. Sometimes such kludges can't be helped. If you have to kludge around compiler bugs and the like, make sure you #ifdef your work properly; also, document your kludge so that people know to remove it once the external problems have been fixed.

Porters may also have an unofficial location where they can put the results of their work during the waiting period. This helps others running the port have the benefit of the porter's work, even during the waiting period. Of course, such locations have no official blessing or status, so buyer beware.

5.10.3. Porting infrastructure and automation

There is infrastructure and several tools to help automate package porting. This section contains a brief overview of this automation and porting to these tools; see the package documentation or references for full information.

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

The wanna-build system is used as a distributed, client-server build distribution system. It is usually used in conjunction with build daemons running the buildd program. Build daemons are ``slave'' hosts which contact the central wanna-build system to receive a list of packages that need to be built.

wanna-build is not yet available as a package; however, all Debian porting efforts are using it for automated package building. The tool used to do the actual package builds, sbuild is available as a package, see its description in sbuild. Please note that the packaged version is not the same as the one used on build daemons, but it is close enough to reproduce problems.

Most of the data produced by wanna-build which is generally useful to porters is available on the web at http://buildd.debian.org/. This data includes nightly updated statistics, queueing information and logs for build attempts.

We are quite proud of this system, since it has so many possible uses. Independent development groups can use the system for different sub-flavors of Debian, which may or may not really be of general interest (for instance, a flavor of Debian built with gcc bounds checking). It will also enable Debian to recompile entire distributions quickly.

The wanna-build team, in charge of the buildds, can be reached at debian-wb-team@lists.debian.org. To determine who (wanna-build team, release team) and how (mail, BTS) to contact, refer to http://lists.debian.org/debian-project/2009/03/msg00096.html.

When requesting binNMUs or give-backs (retries after a failed build), please use the format described at http://release.debian.org/wanna-build.txt.

5.10.4. あなたのパッケージが移植可能なものではない場合

Some packages still have issues with building and/or working on some of the architectures supported by Debian, and cannot be ported at all, or not within a reasonable amount of time. An example is a package that is SVGA-specific (only available for i386 and amd64), or uses other hardware-specific features not supported on all architectures.

In order to prevent broken packages from being uploaded to the archive, and wasting buildd time, you need to do a few things:

  • First, make sure your package does fail to build on architectures that it cannot support. There are a few ways to achieve this. The preferred way is to have a small testsuite during build time that will test the functionality, and fail if it doesn't work. This is a good idea anyway, as this will prevent (some) broken uploads on all architectures, and also will allow the package to build as soon as the required functionality is available.

    Additionally, if you believe the list of supported architectures is pretty constant, you should change any to a list of supported architectures in debian/control. This way, the build will fail also, and indicate this to a human reader without actually trying.

  • In order to prevent autobuilders from needlessly trying to build your package, it must be included in Packages-arch-specific, a list used by the wanna-build script. The current version is available as http://buildd.debian.org/quinn-diff/Packages-arch-specific; please see the top of the file for whom to contact for changes.

Please note that it is insufficient to only add your package to Packages-arch-specific without making it fail to build on unsupported architectures: A porter or any other person trying to build your package might accidently upload it without noticing it doesn't work. If in the past some binary packages were uploaded on unsupported architectures, request their removal by filing a bug against ftp.debian.org.

5.11. Non-Maintainer Upload (NMU)

Every package has one or more maintainers. Normally, these are the people who work on and upload new versions of the package. In some situations, it is useful that other developers can upload a new version as well, for example if they want to fix a bug in a package they don't maintain, when the maintainer needs help to respond to issues. Such uploads are called Non-Maintainer Uploads (NMU).

5.11.1. いつ、どうやって NMU を行うか

NMU を行う前に、以下の質問について考えてください:

  • Does your NMU really fix bugs? Fixing cosmetic issues or changing the packaging style in NMUs is discouraged.

  • Did you give enough time to the maintainer? When was the bug reported to the BTS? Being busy for a week or two isn't unusual. Is the bug so severe that it needs to be fixed right now, or can it wait a few more days?

  • How confident are you about your changes? Please remember the Hippocratic Oath: "Above all, do no harm." It is better to leave a package with an open grave bug than applying a non-functional patch, or one that hides the bug instead of resolving it. If you are not 100% sure of what you did, it might be a good idea to seek advice from others. Remember that if you break something in your NMU, many people will be very unhappy about it.

  • Have you clearly expressed your intention to NMU, at least in the BTS? It is also a good idea to try to contact the maintainer by other means (private email, IRC).

  • If the maintainer is usually active and responsive, have you tried to contact him? In general it should be considered preferable that a maintainer takes care of an issue himself and that he is given the chance to review and correct your patch, because he can be expected to be more aware of potential issues which an NMUer might miss. It is often a better use of everyone's time if the maintainer is given an opportunity to upload a fix on their own.

When doing an NMU, you must first make sure that your intention to NMU is clear. Then, you must send a patch with the differences between the current package and your proposed NMU to the BTS. The nmudiff script in the devscripts package might be helpful.

While preparing the patch, you should better be aware of any package-specific practices that the maintainer might be using. Taking them into account reduces the burden of getting your changes integrated back in the normal package workflow and thus increases the possibilities that that will happen. A good place where to look for for possible package-specific practices is debian/README.source.

Unless you have an excellent reason not to do so, you must then give some time to the maintainer to react (for example, by uploading to the DELAYED queue). Here are some recommended values to use for delays:

  • 7 日以上経っているリリースクリティカルバグのみを修正するアップロード: 2 日

  • リリースクリティカルバグや重要なバグの修正のみのアップロード: 5 日

  • 他の NMU: 10 日

Those delays are only examples. In some cases, such as uploads fixing security issues, or fixes for trivial bugs that blocking a transition, it is desirable that the fixed package reaches unstable sooner.

Sometimes, release managers decide to allow NMUs with shorter delays for a subset of bugs (e.g release-critical bugs older than 7 days). Also, some maintainers list themselves in the Low Threshold NMU list, and accept that NMUs are uploaded without delay. But even in those cases, it's still a good idea to give the maintainer a few days to react before you upload, especially if the patch wasn't available in the BTS before, or if you know that the maintainer is generally active.

After you upload an NMU, you are responsible for the possible problems that you might have introduced. You must keep an eye on the package (subscribing to the package on the PTS is a good way to achieve this).

This is not a license to perform NMUs thoughtlessly. If you NMU when it is clear that the maintainers are active and would have acknowledged a patch in a timely manner, or if you ignore the recommendations of this document, your upload might be a cause of conflict with the maintainer. You should always be prepared to defend the wisdom of any NMU you perform on its own merits.

5.11.2. NMU と debian/changelog

Just like any other (source) upload, NMUs must add an entry to debian/changelog, telling what has changed with this upload. The first line of this entry must explicitely mention that this upload is an NMU, e.g.:

  * Non-maintainer upload.

The way to version NMUs differs for native and non-native packages.

If the package is a native package (without a Debian revision in the version number), the version must be the version of the last maintainer upload, plus +nmuX, where X is a counter starting at 1. If the last upload was also an NMU, the counter should be increased. For example, if the current version is 1.5, then an NMU would get version 1.5+nmu1.

If the package is a not a native package, you should add a minor version number to the Debian revision part of the version number (the portion after the last hyphen). This extra number must start at 1. For example, if the current version is 1.5-2, then an NMU would get version 1.5-2.1. If a new upstream version is packaged in the NMU, the Debian revision is set to 0, for example 1.6-0.1.

In both cases, if the last upload was also an NMU, the counter should be increased. For example, if the current version is 1.5+nmu3 (a native package which has already been NMUed), the NMU would get version 1.5+nmu4.

A special versioning scheme is needed to avoid disrupting the maintainer's work, since using an integer for the Debian revision will potentially conflict with a maintainer upload already in preparation at the time of an NMU, or even one sitting in the ftp NEW queue. It also has the benefit of making it visually clear that a package in the archive was not made by the official maintainer.

If you upload a package to testing or stable, you sometimes need to "fork" the version number tree. This is the case for security uploads, for example. For this, a version of the form +debXYuZ should be used, where X and Y are the major and minor release numbers, and Z is a counter starting at 1. When the release number is not yet known (often the case for testing, at the beginning of release cycles), the lowest release number higher than the last stable release number must be used. For example, while Lenny (Debian 5.0) is stable, a security NMU to stable for a package at version 1.5-3 would have version 1.5-3+deb50u1, whereas a security NMU to Squeeze would get version 1.5-3+deb60u1. After the release of Squeeze, security uploads to the testing distribution will be versioned +deb61uZ, until it is known whether that release will be Debian 6.1 or Debian 7.0 (if that becomes the case, uploads will be versioned as +deb70uZ).

5.11.3. DELAYED/ キューを使う

Having to wait for a response after you request permission to NMU is inefficient, because it costs the NMUer a context switch to come back to the issue. The DELAYED queue (see 「遅延アップロード」) allows the developer doing the NMU to perform all the necessary tasks at the same time. For instance, instead of telling the maintainer that you will upload the updated package in 7 days, you should upload the package to DELAYED/7 and tell the maintainer that he has 7 days to react. During this time, the maintainer can ask you to delay the upload some more, or cancel your upload.

The DELAYED queue should not be used to put additional pressure on the maintainer. In particular, it's important that you are available to cancel or delay the upload before the delay expires since the maintainer cannot cancel the upload himself.

If you make an NMU to DELAYED and the maintainer updates his package before the delay expires, your upload will be rejected because a newer version is already available in the archive. Ideally, the maintainer will take care to include your proposed changes (or at least a solution for the problems they address) in that upload.

5.11.4. メンテナの視点から見た NMU

When someone NMUs your package, this means they want to help you to keep it in good shape. This gives users fixed packages faster. You can consider asking the NMUer to become a co-maintainer of the package. Receiving an NMU on a package is not a bad thing; it just means that the package is interesting enough for other people to work on it.

To acknowledge an NMU, include its changes and changelog entry in your next maintainer upload. If you do not acknowledge the NMU by including the NMU changelog entry in your changelog, the bugs will remain closed in the BTS but will be listed as affecting your maintainer version of the package.

5.11.5. ソース NMU vs バイナリのみの NMU (binNMU)

The full name of an NMU is source NMU. There is also another type, namely the binary-only NMU, or binNMU. A binNMU is also a package upload by someone other than the package's maintainer. However, it is a binary-only upload.

When a library (or other dependency) is updated, the packages using it may need to be rebuilt. Since no changes to the source are needed, the same source package is used.

BinNMUs are usually triggered on the buildds by wanna-build. An entry is added to debian/changelog, explaining why the upload was needed and increasing the version number as described in 「再コンパイル、あるいは binary-only NMU」. This entry should not be included in the next upload.

Buildds upload packages for their architecture to the archive as binary-only uploads. Strictly speaking, these are binNMUs. However, they are not normally called NMU, and they don't add an entry to debian/changelog.

5.11.6. NMU vs QA アップロード

NMUs are uploads of packages by somebody else than their assigned maintainer. There is another type of upload where the uploaded package is not yours: QA uploads. QA uploads are uploads of orphaned packages.

QA uploads are very much like normal maintainer uploads: they may fix anything, even minor issues; the version numbering is normal, and there is no need to use a delayed upload. The difference is that you are not listed as the Maintainer or Uploader for the package. Also, the changelog entry of a QA upload has a special first line:

 * QA upload.

If you want to do an NMU, and it seems that the maintainer is not active, it is wise to check if the package is orphaned (this information is displayed on the package's Package Tracking System page). When doing the first QA upload to an orphaned package, the maintainer should be set to Debian QA Group <packages@qa.debian.org>. Orphaned packages which did not yet have a QA upload still have their old maintainer set. There is a list of them at http://qa.debian.org/orphaned.html.

Instead of doing a QA upload, you can also consider adopting the package by making yourself the maintainer. You don't need permission from anybody to adopt an orphaned package, you can just set yourself as maintainer and upload the new version (see 「パッケージに変更を加える」).

5.11.7. NMU vs チームアップロード

Sometimes you are fixing and/or updating a package because you are member of a packaging team (which uses a mailing list as Maintainer or Uploader, see 「共同メンテナンス」) but you don't want to add yourself to Uploaders because you do not plan to contribute regularly to this specific package. If it conforms with your team's policy, you can perform a normal upload without being listed directly as Maintainer or Uploader. In that case, you should start your changelog entry with the following line:

 * Team upload.

5.12. 共同メンテナンス

Collaborative maintenance is a term describing the sharing of Debian package maintenance duties by several people. This collaboration is almost always a good idea, since it generally results in higher quality and faster bug fix turnaround times. It is strongly recommended that packages with a priority of standard or which are part of the base set have co-maintainers.

Generally there is a primary maintainer and one or more co-maintainers. The primary maintainer is the person whose name is listed in the Maintainer field of the debian/control file. Co-maintainers are all the other maintainers, usually listed in the Uploaders field of the debian/control file.

In its most basic form, the process of adding a new co-maintainer is quite easy:

  • Setup the co-maintainer with access to the sources you build the package from. Generally this implies you are using a network-capable version control system, such as CVS or Subversion. Alioth (see 「Debian での FusionForge の導入例: Alioth」) provides such tools, amongst others.

  • Add the co-maintainer's correct maintainer name and address to the Uploaders field in the first paragraph of the debian/control file.

    Uploaders: John Buzz <jbuzz@debian.org>, Adam Rex <arex@debian.org>
    
  • Using the PTS (「パッケージ追跡システム」), the co-maintainers should subscribe themselves to the appropriate source package.

Another form of collaborative maintenance is team maintenance, which is recommended if you maintain several packages with the same group of developers. In that case, the Maintainer and Uploaders field of each package must be managed with care. It is recommended to choose between one of the two following schemes:

  1. Put the team member mainly responsible for the package in the Maintainer field. In the Uploaders, put the mailing list address, and the team members who care for the package.

  2. Put the mailing list address in the Maintainer field. In the Uploaders field, put the team members who care for the package. In this case, you must make sure the mailing list accept bug reports without any human interaction (like moderation for non-subscribers).

In any case, it is a bad idea to automatically put all team members in the Uploaders field. It clutters the Developer's Package Overview listing (see 「Developer's packages overview」) with packages one doesn't really care for, and creates a false sense of good maintenance. For the same reason, team members do not need to add themselves to the Uploaders field just because they are uploading the package once, they can do a “Team upload” (see 「NMU vs チームアップロード」). Conversely, it is a bad idea to keep a package with only the mailing list address as a Maintainer and no Uploaders.

5.13. テスト版ディストリビューション

5.13.1. 基本

Packages are usually installed into the testing distribution after they have undergone some degree of testing in unstable.

They must be in sync on all architectures and mustn't have dependencies that make them uninstallable; they also have to have generally no known release-critical bugs at the time they're installed into testing. This way, testing should always be close to being a release candidate. Please see below for details.

5.13.2. 不安定版からの更新

The scripts that update the testing distribution are run twice each day, right after the installation of the updated packages; these scripts are called britney. They generate the Packages files for the testing distribution, but they do so in an intelligent manner; they try to avoid any inconsistency and to use only non-buggy packages.

The inclusion of a package from unstable is conditional on the following:

  • The package must have been available in unstable for 2, 5 or 10 days, depending on the urgency (high, medium or low). Please note that the urgency is sticky, meaning that the highest urgency uploaded since the previous testing transition is taken into account. Those delays may be doubled during a freeze, or testing transitions may be switched off altogether;

  • It must not have new release-critical bugs (RC bugs affecting the version available in unstable, but not affecting the version in testing);

  • It must be available on all architectures on which it has previously been built in unstable. dak ls may be of interest to check that information;

  • It must not break any dependency of a package which is already available in testing;

  • The packages on which it depends must either be available in testing or they must be accepted into testing at the same time (and they will be if they fulfill all the necessary criteria).

To find out whether a package is progressing into testing or not, see the testing script output on the web page of the testing distribution, or use the program grep-excuses which is in the devscripts package. This utility can easily be used in a crontab(5) to keep yourself informed of the progression of your packages into testing.

The update_excuses file does not always give the precise reason why the package is refused; you may have to find it on your own by looking for what would break with the inclusion of the package. The testing web page gives some more information about the usual problems which may be causing such troubles.

Sometimes, some packages never enter testing because the set of inter-relationship is too complicated and cannot be sorted out by the scripts. See below for details.

Some further dependency analysis is shown on http://release.debian.org/migration/ — but be warned, this page also shows build dependencies which are not considered by britney.

5.13.2.1. Out-of-date

For the testing migration script, outdated means: There are different versions in unstable for the release architectures (except for the architectures in fuckedarches; fuckedarches is a list of architectures that don't keep up (in update_out.py), but currently, it's empty). outdated has nothing whatsoever to do with the architectures this package has in testing.

Consider this example:

 alphaarm
テスト版1-
不安定版12

The package is out of date on alpha in unstable, and will not go to testing. Removing the package would not help at all, the package is still out of date on alpha, and will not propagate to testing.

However, if ftp-master removes a package in unstable (here on arm):

 alphaarmhurd-i386
テスト版11-
不安定版2-1

In this case, the package is up to date on all release architectures in unstable (and the extra hurd-i386 doesn't matter, as it's not a release architecture).

Sometimes, the question is raised if it is possible to allow packages in that are not yet built on all architectures: No. Just plainly no. (Except if you maintain glibc or so.)

5.13.2.2. テスト版からの削除

Sometimes, a package is removed to allow another package in: This happens only to allow another package to go in if it's ready in every other sense. Suppose e.g. that a cannot be installed with the new version of b; then a may be removed to allow b in.

Of course, there is another reason to remove a package from testing: It's just too buggy (and having a single RC-bug is enough to be in this state).

Furthermore, if a package has been removed from unstable, and no package in testing depends on it any more, then it will automatically be removed.

5.13.2.3. 循環依存

A situation which is not handled very well by britney is if package a depends on the new version of package b, and vice versa.

この場合の例:

 テスト版不安定版
a1; depends: b=12; depends: b=2
b1; depends: a=12; depends: a=2

Neither package a nor package b is considered for update.

Currently, this requires some manual hinting from the release team. Please contact them by sending mail to if this happens to one of your packages.

5.13.2.4. テスト版 (testing) にあるパッケージへの影響

Generally, there is nothing that the status of a package in testing means for transition of the next version from unstable to testing, with two exceptions: If the RC-bugginess of the package goes down, it may go in even if it is still RC-buggy. The second exception is if the version of the package in testing is out of sync on the different arches: Then any arch might just upgrade to the version of the source package; however, this can happen only if the package was previously forced through, the arch is in fuckedarches, or there was no binary package of that arch present in unstable at all during the testing migration.

In summary this means: The only influence that a package being in testing has on a new version of the same package is that the new version might go in easier.

5.13.2.5. 詳細について

If you are interested in details, this is how britney works:

The packages are looked at to determine whether they are valid candidates. This gives the update excuses. The most common reasons why a package is not considered are too young, RC-bugginess, and out of date on some arches. For this part of britney, the release managers have hammers of various sizes to force britney to consider a package. (Also, the base freeze is coded in that part of britney.) (There is a similar thing for binary-only updates, but this is not described here. If you're interested in that, please peruse the code.)

Now, the more complex part happens: Britney tries to update testing with the valid candidates. For that, britney tries to add each valid candidate to the testing distribution. If the number of uninstallable packages in testing doesn't increase, the package is accepted. From that point on, the accepted package is considered to be part of testing, such that all subsequent installability tests include this package. Hints from the release team are processed before or after this main run, depending on the exact type.

If you want to see more details, you can look it up on merkel:/org/ftp.debian.org/testing/update_out/ (or in merkel:~aba/testing/update_out to see a setup with a smaller packages file). Via web, it's at http://ftp-master.debian.org/testing/update_out_code/.

The hints are available via http://ftp-master.debian.org/testing/hints/.

5.13.3. 直接テスト版を更新する

The testing distribution is fed with packages from unstable according to the rules explained above. However, in some cases, it is necessary to upload packages built only for testing. For that, you may want to upload to testing-proposed-updates.

Keep in mind that packages uploaded there are not automatically processed, they have to go through the hands of the release manager. So you'd better have a good reason to upload there. In order to know what a good reason is in the release managers' eyes, you should read the instructions that they regularly give on .

You should not upload to testing-proposed-updates when you can update your packages through unstable. If you can't (for example because you have a newer development version in unstable), you may use this facility, but it is recommended that you ask for authorization from the release manager first. Even if a package is frozen, updates through unstable are possible, if the upload via unstable does not pull in any new dependencies.

Version numbers are usually selected by adding the codename of the testing distribution and a running number, like 1.2squeeze1 for the first upload through testing-proposed-updates of package version 1.2.

Please make sure you didn't miss any of these items in your upload:

  • Make sure that your package really needs to go through testing-proposed-updates, and can't go through unstable;

  • 必ず最小限な量だけの変更を含めるようにする;

  • Make sure that you included an appropriate explanation in the changelog;

  • Make sure that you've written testing or testing-proposed-updates into your target distribution;

  • Make sure that you've built and tested your package in testing, not in unstable;

  • Make sure that your version number is higher than the version in testing and testing-proposed-updates, and lower than in unstable;

  • After uploading and successful build on all platforms, contact the release team at and ask them to approve your upload.

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-binacme-bar-binlibacme-foo1libacme-foo-dev の古いバージョンが削除されます。

しかし、古いバージョンではライブラリに古い soname を含んだ libacme-foo0 のようなバイナリパッケージを提供しているかもしれません。古い acmefoo を削除するのは libacme-foo0 を削除することになり、これに依存しているパッケージを壊してしまいます。

Evidently, this mainly affects packages which provide changing sets of binary packages in different versions (in turn, mainly libraries). However, it will also affect packages upon which versioned dependencies have been declared of the ==, <=, or << varieties.

When the set of binary packages provided by a source package change in this way, all the packages that depended on the old binaries will have to be updated to depend on the new binaries instead. Because installing such a source package into testing breaks all the packages that depended on it in testing, some care has to be taken now: all the depending packages must be updated and ready to be installed themselves so that they won't be broken, and, once everything is ready, manual intervention by the release manager or an assistant is normally required.

この様に複雑な組み合わせのパッケージで問題がある場合は、 あるいは に連絡を取って手助けを求めてください。



[3] パッケージがどのセクションに属するかのガイドラインは Debian ポリシーマニュアルを参照してください。

[4] In the past, such NMUs used the third-level number on the Debian part of the revision to denote their recompilation-only status; however, this syntax was ambiguous with native packages and did not allow proper ordering of recompile-only NMUs, source NMUs, and security NMUs on the same package, and has therefore been abandoned in favor of this new syntax.