第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.8.5.1. セキュリティ追跡システム
5.8.5.2. 秘匿性
5.8.5.3. セキュリティ勧告
5.8.5.4. セキュリティ問題に対処するパッケージを用意する
5.8.5.5. 修正したパッケージをアップロードする
5.9. パッケージの移動、削除、リネーム、放棄、引き取り、再導入
5.9.1. パッケージの移動
5.9.2. パッケージの削除
5.9.2.1. Incoming からパッケージを削除する
5.9.3. パッケージをリプレースあるいはリネームする
5.9.4. パッケージを放棄する
5.9.5. パッケージを引き取る
5.9.6. パッケージの再導入
5.10. 移植作業、そして移植できるようにすること
5.10.1. 移植作業者に対して協力的になる
5.10.2. 移植作業者のアップロード (porter upload) に関するガイドライン
5.10.2.1. 再コンパイル、あるいは binary-only NMU
5.10.2.2. あなたが移植作業者の場合、source NMU を行う時は何時か
5.10.3. 移植用のインフラと自動化
5.10.3.1. メーリングリストとウェブページ
5.10.3.2. 移植用ツール
5.10.3.3. wanna-build
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.2.1. 時代遅れ (Out-of-date)
5.13.2.2. テスト版からの削除
5.13.2.3. 循環依存
5.13.2.4. テスト版 (testing) にあるパッケージへの影響
5.13.2.5. 詳細について
5.13.3. 直接テスト版を更新する
5.13.4. よく聞かれる質問とその答え (FAQ)
5.13.4.1. リリースクリティカルバグとは何ですか、どうやって数えるのですか?
5.13.4.2. どのようにすれば、他のパッケージを壊す可能性があるパッケージをテスト版 (testing) へインストールできますか?

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

もしあなたが 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) で暮らす人 (そして最前線のテスターである人) の助けになる。我々はそのような人々を推奨すべきである。

  • メンテナや他に興味を持つ人々へ、プロジェクトで何が行われているのか、何か新しいことがあるかということ関して、告知は良い印象を与える。

新しいパッケージに対するよくある拒否理由については https://ftp-master.debian.org/REJECT-FAQ.html を参照してください。

パッケージについて行った変更は 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 エントリの作成と仕上げ処理に使えるツールがあります。devscriptsdpkg-dev-el を参照してください。

debian/changelog のベストプラクティス」 も参照してください。

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

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 アーカイブで保存されるのでそのままになります。

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

パッケージは、通常 unstable へアップロードされます。unstable あるいは experimental へのアップロードはこれらの suite を changelog のエントリに記します。サポートされている他の suite へのアップロードは、曖昧さを避けるために suite のコードネームを使う必要があります。

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

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

安定版 (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)と同じルールが適用されます。

パッケージをアップロードするには、ファイル (署名された changes ファイルと dsc ファイル) を anonymous ftp で ftp.upload.debian.org/pub/UploadQueue/ へアップロードする必要があります。そこでファイルを処理するためには、Debian Developers keyring または Debian Maintainers keyring (https://wiki.debian.org/DebianMaintainer 参照) にある鍵で署名しておく必要があります。

changes ファイルは最後に転送する必要があることに注意してください。そうしないとアーカイブのメンテナンスを行っているソフトが changes ファイルをパースして全てのファイルがアップロードされていないと判断して、アップロードは reject されるかもしれません。

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

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

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

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

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

ヨーロッパにはもう一つのアップロードキューが ftp://ftp.eu.upload.debian.org/pub/UploadQueue/ にあります。操作方法は ftp.upload.debian.org と同じですが、ヨーロッパ圏の開発者に対しては、より速いはずです。

パッケージは ssh を使って ssh.upload.debian.org へアップロードすることも可能です。ファイルは /srv/upload.debian.org/UploadQueue に置く必要があります。このキューは遅延アップロードをサポートしていません。

Debian アーカイブメンテナはパッケージのアップロードに関して責任を持っています。多くの部分は、アップロードはアーカイブ用のメンテナンスツール dak process-upload によって日々自動的に行われています。特に、不安定版 (unstable) に存在しているパッケージの更新は自動的に処理されます。それ以外の場合、特に新規パッケージの場合は、アップロードされたパッケージをディストリビューションに含めるのは手動で行われます。アップロードが手動で処理される場合は、アーカイブへの変更は実施されるまでに一ヶ月ほどかかります。お待ちください。

どの場合であっても、パッケージがアーカイブに追加されたことや、バグがアップロードで閉じられたことを告げるメールでの通知を受け取ることになります。あなたが閉じようとしたバグが処理されてない場合は、この通知を注意深く確認してください。

インストール通知は、パッケージがどのセクションに入ったかを示す情報を含んでいます。不一致がある場合は、それを示す別のメール通知を受け取ります。以下も参照ください。

キュー経由でアップロードした場合は、キューデーモンソフトウェアもメールで通知を行うことに留意してください。

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)https://www.debian.org/Bugs/Developer#maintincorrect を参照してください。

「セクション」 で書かれているように、セクション (Section)フィールドにはセクション同様にサブセクションも記述するのに注意ください。セクションが main の場合は、それは書かないようにしてください。利用可能なサブセクションは https://www.debian.org/doc/debian-policy/ch-archive.html#s-subsections で検索できます。

すべての開発者は Debian バグ追跡システムを取り扱えるようでなければいけません。これは、どの様にしてバグ報告を正しく登録するか (「バグ報告」 参照)、どの様に更新及び整理するか、そしてどの様にして処理をして完了するかを知っていることを含みます。

バグ追跡システムの機能は、Debian BTS 開発者向け情報に記載されています。これには、バグの完了処理・追加メッセージの送信・重要度とタグを割り当てる・バグを転送済み (Forwarded) にする・その他が含まれています。

バグを他のパッケージに割り当てし直す、同じ問題についての別々のバグ報告をマージする、早まってクローズされたバグの再オープンなどの作業は、いわゆる制御メールサーバと呼ばれるものを使って処理されています。このサーバで利用可能なすべてのコマンドは、BTS 制御サーバドキュメントに記載されています。

良いメンテナになりたい場合は、あなたのパッケージに関する Debian バグ追跡システム (BTS) のページを定期的にチェックする必要があります。BTS には、あなたのパッケージに対して登録されている全てのバグが含まれています。登録されているバグについては、以下のページを参照することで確認できます: https://bugs.debian.org/yourlogin@debian.org

メンテナは、bugs.debian.org のメールアドレス経由で BTS に対応します。利用可能なコマンドについてのドキュメントは https://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 パッケージメンテナとしてのメールアドレスに置き換えてください。

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

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

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

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

パッケージメンテナになると、他のパッケージにバグを見つけたり、自分のパッケージに対して報告されたバグが実際には他のパッケージにあるバグであったりということが頻繁にあるでしょう。バグ追跡システムの機能は 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. 一旦修正されたパッケージがアーカイブから入手可能になったら、バグはどのバージョンで修正されたかを指定して閉じられる必要があります。これは自動的に行われます。「新規アップロードでバグがクローズされる時」 を読んでください。

バグや問題があなたのパッケージで修正されたとしたら、そのバグを閉じるのはパッケージメンテナとしての責任になります。しかし、バグを修正したパッケージが 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 のエントリを書くのか、一般的な情報については debian/changelog のベストプラクティス」 を参照してください。

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

Debian パッケージ中のセキュリティ関連のバグに気づいたら、あなたがメンテナであるかどうかに関わらず、問題に関する正確な情報を集め、まずは 宛にメールを出してセキュリティチームへ連絡を取ってください。お望みであれば、Debian セキュリティ担当窓口の鍵を使ってメールを暗号化できます。詳細は https://www.debian.org/security/faq#contact を参照してください。チームに問い合わせること無く 安定版 (stable) 向けのパッケージをアップロードしないでください。例として、役に立つ情報は以下のようなものになります:

  • バグが既に公開されているか否か

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

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

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

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

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

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

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

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

Debian 内での他の多くの活動とは違い、セキュリティ問題に関する情報については、暫くの間秘密にしておく必要がしばしばあります。これによって、ソフトウェアのディストリビュータがユーザが危険にさらされるのを最小限にするため、公開時期を合わせることができます。今回がそうであるかは、問題と対応する修正の性質や、既に既知のものとなっているかどうかによります。

開発者がセキュリティ問題を知る方法はいくつかあります:

  • 公開フォーラム (メーリングリスト、ウェブサイトなど) で知らせる

  • 誰かがバグ報告を登録している

  • 誰かがプライベートなメールで教えてきた

最初の二つのケースでは、情報は公開されていて可能な限り早く修正することが重要です。しかしながら最後のケースは、公開情報ではないかもしれません。この場合は、問題に対処するのに幾つか取り得る選択肢があります:

  • セキュリティの影響度が小さい場合、問題を秘密にしておく必要はなく、修正を行ってリリースするのが良い場合がしばしばあります。

  • 問題が深刻な場合、他のベンダと情報を共有してリリースをコーディネイトする方が望ましいでしょう。セキュリティチームは様々な組織/個人と連絡を取りつづけ、この問題に対応することができます。

どのような場合でも、問題を報告した人がこれを公開しないように求めているのであれば、明白な例外として Debian の安定版リリースに対する修正を作成してもらうためにセキュリティチームへ連絡すること以外、この様な要求は尊重されるべきです。機密情報をセキュリティチームに送る場合は、この点を明示しておくのを忘れないでください。

機密を要する場合は、修正を不安定版 (unstable) (や公開 VCS リポジトリなどその他どこへも) へ修正をアップロードしないよう、注意してください。コードその物が公開されている場合、変更の詳細を難読化するだけでは十分ではなく、皆によって解析され得る (そしてされる) でしょう。

機密であることを要求されたにも関わらず、情報を公開するのには 2 つの理由があります: 問題が一定期間既知の状態になっている、あるいは問題や攻撃コードが公開された場合です。

セキュリティチームは、機密事項に関して通信を暗号化できる PGP 鍵を持っています。詳細については、セキュリティチーム FAQ を参照してください。

セキュリティ勧告は現在のところ、リリースされた安定版ディストリビューションについてのみ、取り扱われます。テスト版 (testing)不安定版 (unstable) についてではありません。リリースされると、セキュリティ勧告は email-debian-security-announce; メーリングリストに送られ、セキュリティのウェブページに掲載されます。セキュリティ勧告はセキュリティチームによって記述、掲載されます。しかし、メンテナが情報を提供できたり、文章の一部を書けるのであれば、彼らは当然そんなことは気にしません。勧告にあるべき情報は以下を含んでいます:

  • 以下のようなものを含めた問題の説明と範囲:

    • 問題の種類 (権限の上昇、サービス拒否など)

    • 何の権限が得られるのか、(もし分かれば) 誰が得るのか

    • どのようにして攻撃が可能なのか

    • 攻撃はリモートから可能なのかそれともローカルから可能なのか

    • どのようにして問題が修正されたのか

    この情報によって、ユーザがシステムに対する脅威を評価できるようになります。

  • 影響を受けるパッケージのバージョン番号

  • 修正されたパッケージのバージョン番号

  • どこで更新されたパッケージを得るかという情報 (通常は Debian のセキュリティアーカイブからです)

  • 開発元のアドバイザリへの参照、CVE 番号、脆弱性の相互参照について役立つその他の情報

あなたがセキュリティチームに対し、彼らの職務に関して手助けできる方法の一つは、安定版 Debian リリース用のセキュリティ勧告に適した修正版パッケージを提供することです。

安定版について更新が作成される際、システムの挙動の変化や新しいバグの導入を避けるように注意が必要です。これを行うため、バグを修正するための変更は可能な限り少なくします。ユーザや管理者は一旦リリースされたものの厳密な挙動を当てにしているので、どのような変更でも誰かのシステムを壊しかねません。これは特にライブラリについて当てはまります: API や ABI を決して変更していないことを確認してください。変更がどれほど小さいものでも関係ありません。

これは、開発元の新しいリリースバージョン (new upstream version) への移行が良い解決策ではないことを意味しています。代わりに、関連する変更を現在の Debian 安定版リリースに存在しているバージョンへバックポートするべきです。通常、開発元のメンテナは助けが必要であれば手伝おうとしてくれます。そうでない場合は、Debian セキュリティチームが手助けすることができます。

いくつかのケースでは、例えば大量のソースコードの変更や書き直しが必要など、セキュリティ修正をバックポートできないことがあります。この様な場合、新しいバージョン (new upstream version) へ移行する必要があるかもしれません。しかし、これは極端な状況の場合にのみ行われるものであり、実行する前に必ずセキュリティチームと調整をしなければなりません。

これに関してはもう一つ重要な指針があります: 必ず変更についてテストをしてください。攻撃用コード (exploit) が入手可能な場合には、それを試してみて、パッチを当てていないパッケージで成功するか、修正したパッケージでは失敗することかどうかを確かめてみてください。他の確認として、セキュリティ修正は時折表面上はそれと関係が無いような機能を壊すことがあるので、通常の動作も同様にテストしてください。

脆弱性の修正に直接関係しない変更をパッケージへ加えないようにしてください。この様な変更は元に戻さなくてはならなくなるだけで、時間を無駄にします。他に直したいバグがパッケージにある場合は、セキュリティ勧告が発行された後、通常通りに proposed-update にアップロードを行ってください。セキュリティ更新の仕組みは、それ以外の方法では安定版リリースから reject されるであろう変更をあなたのパッケージに加える方法ではありませんので、この様な事はしないでください。

変更点を可能な限り見直してください。以前のバージョンとの変更点を繰り返し確認してください (これには patchutils パッケージの interdiffdevscriptsdebdiff が役立ちます。debdiff を参照してください)。

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

  • debian/changelog正しいディストリビューションを対象にする: codename-security (例えば jessie-security)。distribution-proposed-updatesstable を対象にしないでください!

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

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

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

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

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

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

セキュリティアップロードキュー (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 上にインストールされます。

アーカイブの変更作業のいくつかは、Debian のアップロードプロセスでは自動的なものにはなっていません。これらの手続きはメンテナによる手動での作業である必要があります。この章では、この様な場合に何をするかのガイドラインを提供します。

時折、パッケージは属しているセクションが変わることがあります。例えば「non-free」セクションのパッケージが新しいバージョンで GPL になった場合、パッケージは「main」か「contrib」に移動する必要があります。[3]

パッケージのどれかがセクションを変更する必要がある場合、希望するセクションにパッケージを配置するためパッケージの control 情報を変更してから再アップロードします (詳細については Debian ポリシーマニュアルを参照してください)。必ず .orig.tar.{gz,bz2,xz} を (開発元のバージョンが新しいものになったのではなくても) アップロードに含める必要があります。新しいセクションが正しい場合は、自動的に移動されます。移動されない場合には、何が起こったのかを理解するために ftpmaster に連絡を取ります。

一方で、もしパッケージの一つのサブセクション (例:「devel」「admin」) を変更する必要がある、という場合には、手順は全く異なります。パッケージの control ファイルにあるサブセクションを修正して、再アップロードします。また、「パッケージのセクション、サブセクション、優先度を指定する」 に記述してあるように override ファイルを更新する必要が出てくるでしょう。

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

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

削除は不安定版 (unstable)実験版 (experimental)安定版 (stable) ディストリビューションに対してのみ実施が可能であることに注意してください。パッケージは テスト版 (testing) から直接は削除されません。代わりに不安定版 (unstable) から削除された後で自動的に削除され、テスト版 (testing) にあるパッケージは削除されたパッケージに依存しなくなります (release.debian.org 擬似パッケージへ削除依頼のバグレポートを登録することで、テスト版 (testing)からの削除は可能ではあります。「テスト版からの削除」の項目を参照して下さい)。

例外として、明示的な削除依頼が必要ない場合が一つあります: (ソース、あるいはバイナリ) パッケージがソースからビルドされなくなった場合、半自動的に削除されます。バイナリパッケージの場合、これはこのバイナリパッケージを生成するソースパッケージがもはや存在しないということを意味します。バイナリパッケージがいくつかのアーキテクチャで生成されなくなったという場合には、削除依頼は必要です。ソースパッケージの場合は、関連の全バイナリパッケージが別のソースパッケージによって上書きされるのを意味しています。

削除依頼では、依頼を判断する理由を詳細に書く必要があります。これは不必要な削除を避け、何故パッケージが削除されたのかを追跡できるようにするためです。例えば、削除されるパッケージにとって代わるパッケージの名前を記述します。

通常は自分がメンテナンスしているパッケージの削除のみを依頼します。その他のパッケージを削除したい場合は、メンテナの許可を取る必要があります。パッケージが放棄されたのでメンテナがいない場合は、まず で削除依頼について議論をしてください。パッケージの削除についての合意ができたら、削除依頼の新規バグを登録するのではなく、wnpp パッケージに対して登録されているバグを reassign して O: に題名を変更するべきです。

この件、あるいはパッケージ削除に関するその他のトピックについて、さらなる情報を https://wiki.debian.org/ftpmaster_Removalshttps://qa.debian.org/howto-remove.html で参照できます。

パッケージを破棄しても構わないか迷う場合には、意見を聞きに へメールしてください。aptapt-cache プログラムも重要です。apt-cache showpkg パッケージ名 として起動した際、プログラムはパッケージ名の非依存関係を含む詳細を表示します。他にも apt-cache rdependsapt-rdependsbuild-rdeps (devscripts パッケージに含まれる)、grep-dctrl などの有用なプログラムが非依存関係を含む情報を表示します。みなしご化されたパッケージの削除は、 で話し合われます。

一旦パッケージが削除されたら、パッケージのバグを処理する必要があります。実際のコードが別のパッケージに含まれるようになったので、別のパッケージへバグを付け替える (例えば、libfoo13 が上書きするので、libfoo12 が削除される) か、あるいはソフトウェアがもう Debian の一部では無くなった場合にはバグを閉じるかする必要があります。バグを閉じる場合、過去の Debian のリリースにあるパッケージバージョンで修正されたとマークするのを避けてください。バージョン <most-recent-version-ever-in-Debian>+rm で修正されたとマークしなければなりません。

あなたのパッケージのどれかの開発元のメンテナらが、ソフトウェアをリネームするのを決めた時 (あるいはパッケージを間違えて名前を付けた時)、以下の二段階のリネーム手続きに従う必要があります。最初の段階では、debian/control ファイルに新しい名前を反映し、利用しなくなるパッケージ名に対して Replace、Provides、Conflicts を設定する変更をします (詳細に関しては Debian ポリシーマニュアルl を参照)。注意してほしいのは、利用しなくなるパッケージ名がリネーム後も動作する場合のみ、Provides を付け加えるべきだということです。一旦パッケージをアップロードがアップロードされてアーカイブに移動したら、ftp.debian.org に対してバグを報告してください (「パッケージの削除」 参照)。同時にパッケージのバグを正しく付け替えするのを忘れないでください。

他に、パッケージの作成でミスを犯したので置き換えたいという場合があるかもしれません。これを行う方法は唯一つ、バージョン番号を上げて新しいバージョンをアップロードすることです。通常、古いバージョンは無効になります。これはソースを含めた各パッケージ部分に適用されることに注意してください: パッケージの開発元のソース tarball を入れ替えたい場合には、別のバージョンをつけてアップロードする必要があります。よくある例は foo_1.00.orig.tar.gzfoo_1.00+0.orig.tar.gz、あるいは foo_1.00.orig.tar.bz2 で置き換えるというものです。この制約によって、ftp サイト上で各ファイルが一意の名前を持つことになり、ミラーネットワークをまたがった一貫性を保障するのに役立ちます。

パッケージをもうメンテナンスできなくなってしまった場合、ほかの人に知らせて、パッケージが放棄 (orphaned) とマークされたのが分かるようにする必要があります。パッケージメンテナを Debian QA Group <packages@qa.debian.org> に設定し、疑似パッケージwnpp に対してバグ報告を送信しなければなりません。バグ報告は、パッケージが今放棄されていることを示すように O: パッケージ名 -- 短い要約 というタイトルにする必要があります。バグの重要度は 通常 (normal) に設定しなければなりません; パッケージの重要 (priority) が standard より高い場合には重要 (important) に設定する必要があります。必要だと思うのならば、メッセージの X-Debbugs-CC: ヘッダのアドレスに を入れてコピーを送ってください (そう、CC: を使わないでください。その理由は、CC: を使うと、メッセージの題名がバグ番号を含まないからです)。

パッケージを手放したいが、しばらくの間はメンテナンスを継続できる場合には、代わりに wnppRFA: パッケージ名 -- 短い要約 という題名でバグ報告を送信する必要があります。RFARequest For Adoption (引き取り依頼) を意味しています。

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

新たなメンテナが必要なパッケージの一覧は 作業が望まれるパッケージ (WNPP、Work-Needing and Prospective Packages list) で入手できます。WNPP でリストに挙がっているパッケージのどれかに対するメンテナンスを引き継ぎたい場合には、情報と手続きについては前述のページを確認してください。

メンテナンスされていないと思うパッケージを単純に持っていっても構いませんか? —それはパッケージの乗っ取り (hijacking) です。できますが、もちろんのこと、現在のメンテナに確認をとってパッケージを持って行って良いか尋ねましょう。メンテナが AWOL (absent without leave、無届け欠席状態) であると信ずる理由があれば、「活動的でない、あるいは連絡が取れないメンテナに対応する」 を参照してください。

一般的に、現在のメンテナの同意なしでパッケージを引き取るべきではありません。彼らがあなたのことを無視したのだとしても、それはパッケージを引き取る理由とはなりません。メンテナへの不満は開発者のメーリングリストへ送られるべきです。議論が良い結論に至らない、かつ問題が技術的なものなのであれば、技術委員会に相談することを検討してください (より詳細については、Debian 技術委員会のページ を参照してください)。

古いパッケージを引き継いだ場合は、おそらくバグ追跡システムでパッケージの公式メンテナとして表示されるようにしたいことでしょう。これは、一旦 Maintainer 欄を更新した新しいバージョンをアップロードすれば自動的に行われますが、アップロードが完了してから数時間はかかります。しばらくは新しいバージョンをアップロードする予定が無い場合は、「Debian パッケージトラッカー」 を使ってバグ報告を受け取ることができます。しかし、以前のメンテナにしばらくの間はバグ報告が届き続けても問題無いことを確認してください。

パッケージは、リリースクリティカルのバグやメンテナ不在、不人気あるいは全体的な品質の低さ等により削除されることがよくあります。再導入プロセスはパッケージ化の開始時と似ていますが、あらかじめその歴史的経緯を調べておくことにより、落し穴にはまるのをいくらか避けることができます。

まず初めに、パッケージが削除された理由を確認しましょう。この情報はそのパッケージの PTS ページのニュースから削除の項目か削除ログを探すことにより見つけられます。削除のバグにはそのパッケージが削除された理由や、そのパッケージの再導入にあたって必要なことがいくらか提示されているでしょう。パッケージの再導入ではなくどこか他のソフトウェアの一部への乗り替えが最適であるということが提示されているかもしれません。

以前のメンテナに連絡を取り、パッケージの再導入のために作業していないか、パッケージ共同保守に関心はないか、必要になったときにパッケージのスポンサーをしてくれないか、等を確認しておくと良いでしょう。

新しいパッケージ (「新規パッケージ」) の導入前に必要なことは全てやりましょう。

利用できる中で適切な最新のパッケージをベースに作業しましょう。これはunstable の最新版かもしれません。また、snapshot アーカイブにはまだ存在するでしょう。

前のメンテナにより利用されていたバージョン管理システムに有用な変更が記録されているかもしれないので、確認してみるのは良いことです。以前のパッケージの control ファイルにそのパッケージのバージョン管理システムにリンクしているヘッダが無いか、それがまだ存在するか確認してください。

(testingstableoldstable ではなく) unstable からパッケージが削除されると、そのパッケージに関連するバグは全て閉じられます。閉じられたバグを全て (アーカイブされているバグを含めて) 確認し、+rm で終わるバージョンで閉じられていて現在でも有効なものを全て unarchive および reopen してください。有効ではなくなっているものは修正されているバージョンがわかればすべて修正済みとしてください。

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

移植作業 (Porting) とは、パッケージメンテナが生成したバイナリパッケージの元々のアーキテクチャとは違うアーキテクチャの Debian パッケージをビルドする作業です。これは非常にユニークかつ極めて重要な活動です。事実、移植作業者は実際の Debian パッケージのコンパイルの大半を行っています。例えば、メンテナが (移植可能な) ソースパッケージと i386 のバイナリをアップロードすると、他の各アーキテクチャ、11 以上の数のビルドが生成されます。

移植作業者は、難解かつ他には無いタスクを抱えています。それは、彼らは膨大な量のパッケージに対処する必要があるからです。理想を言えば、すべてのソースパッケージは変更を加えないできちんとビルドできるべきです。残念なことに、その様な場合はほとんどありません。この章は Debian メンテナによってよくコミットされる「潜在的な問題」のチェックリストを含んでいます — よく移植作業者を困らせ、彼らの作業を不必要に難解にする共通の問題です。

まず初めの、そして最も重要な点は、バグや移植作業者から投げかけられた問題に素早く回答することです。移植作業者をパッケージの副メンテナ (co-maintainer) であるように丁重に扱ってください (ある意味、その通りではあります)。簡潔、あるいは不明瞭なバグ報告に対して寛容になってください。問題が何であれ、原因を捉えることに最善を尽くしてください。

移植作業者が遭遇する問題のほとんどは、何といっても、ソースパッケージ内でのパッケージ作成のバグによって引き起こされます。以下は、確認あるいは注意すべき項目のリストです。

  1. debian/control 中の Build-DependsBuild-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/filesdebian/substvars を含んだソースパッケージを出していないかを確かめてください。これらは、debian/rulesclean ターゲットによって削除されるべきです。

  5. ローカル環境にインストールされていたり、弄くられている設定やプログラムに依存していないことを確かめてください。例えば、/usr/local/bin やその類のプログラムは決して呼び出してはいけません。特殊なやり方で設定されたプログラムには依存しないようにしてください。別のマシンでパッケージをビルドしてください。それが同じアーキテクチャであっても、です。

  6. 構築中の既にインストールしてあるパッケージに依存しないでください (上記の話の一例です)。もちろん、このルールには例外はありますが、そのような場合には手動で一から環境を構築する必要があり、パッケージ作成マシンで自動的に構築することはできません。

  7. 可能であれば、特定のバージョンのコンパイラに依存しないでください。もし無理であれば、その制約をビルドの依存関係に反映されているのを確認してください。だとしても異なったアーキテクチャでは時折異なったバージョンのコンパイラで統一されているので、それでも恐らく問題を引き起こすことになるでしょう。

  8. debian/rules で、Debian ポリシーマニュアルが定めるように、binary-arch 及び binary-indep ターゲットに分かれて含まれていることを確かめてください。両方のターゲットが独立して動作するのを確かめてください。つまり、他のターゲットを事前に呼び出さなくても、ターゲットを呼び出せるのを確かめるということです。これをテストするには、dpkg-buildpackage -B を実行してください。

パッケージが移植作業を行うアーキテクチャで手を入れずに構築できるのであれば、あなたは幸運で作業は簡単です。この章は、その様な場合に当てはめられます: きちんとアーカイブにインストールされるために、どうやってバイナリパッケージを構築・アップロードするかを記述しています。他のアーキテクチャでコンパイルできるようにするため、パッケージにパッチを当てる必要がある場合は、実際のところ、ソース NMU を行なうので、代わりに 「いつ、どうやって NMU を行うか」 を参照してください。

移植作業者のアップロード (porter upload) は、ソースに何も変更を加えません。ソースパッケージ中のファイルには触る必要はありません。これは debian/changelog を含みます。

dpkg-buildpackagedpkg-buildpackage -B -mporter-email として起動してください。もちろん、porter-emailにはあなたのメールアドレスを設定します。これはdebian/rulesbinary-arch を使ってパッケージのバイナリ依存部分のみのビルドを行います。

移植作業のために Debian マシン上で作業をしていて、アーカイブに入れてもらうためにアップロードするパッケージにローカルでサインする必要がある場合は、.changes に対して debsign を手軽に実行するのもできますし、dpkg-sig のリモート署名モードを使うこともできます。

時折、最初の移植作業者のアップロード作業は困難なものになります。パッケージが構築された環境があまり良くないからです (古すぎる、使われていないライブラリがある、コンパイラの問題、などなど…)。その場合には、更新した環境で再コンパイルする必要があるでしょう。しかし、この場合にはバージョンを上げる必要があり、古いおかしなパッケージは 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 です。

移植作業者は、通常は非移植作業者同様に 「Non-Maintainer Upload (NMU)」 にあるガイドラインに沿ってソース NMU を行います。しかし、移植作業者のソース NMU に対する待ち時間は非移植作業者より小さくなります。これは、移植作業は大量のパッケージに対応する必要があるからです。さらに、状況はパッケージがアップロードされるディストリビューションに依って変わります。これは、アーキテクチャが次の安定版リリースに含められるかどうかによっても変わります。リリースマネージャはどのアーキテクチャが候補なのかを決定してアナウンスします。

あなたが不安定版 (unstable) へ NMU を行う移植作業者の場合、移植作業についての上記のガイドライン、そして 2 つの相違点に従う必要があります。まず、適切な待ち時間です — バグが BTS へ投稿されてから NMU を行って OK になるまでの間 — 移植作業者が 不安定版 (unstable) ディストリビューションに対して行う場合は 7 日間になります。問題が致命的で移植作業に困難を強いるような場合には、この期間は短くできます (注意してください。この何れもがポリシーではなく、単にガイドラインに沿って相互に了解されているだけです)。安定版 (stable)テスト版 (testing) へのアップロードについては、まず適切なリリースチームと調整をしてください。

次に、ソース NMU を行う移植作業者は BTS へ登録したバグの重要度が serious かそれ以上であることを確認してください。これは単一のソースパッケージが、すべての Debian でサポートされているアーキテクチャでコンパイルされたことをリリース時に保証します。数多くのライセンスに従うため、すべてのアーキテクチャについて、単一のバージョンのバイナリパッケージとソースパッケージを持つことがとても重要です。

移植作業者は、現在のバージョンのコンパイル環境やカーネル、libc にあるバグのために作られた単なる力業のパッチを極力回避すべきです。この様なでっち上げの代物があるのは、仕方がないことが時折あります。コンパイラのバグやその他の為にでっち上げを行う必要がある場合には、#ifdef で作業したものが動作することを確認してください。また、力業についてドキュメントに載せてください。一旦外部の問題が修正されたら、それを削除するのを皆が知ることができます。

移植作業者は、待ち期間の間、作業結果を置いておける非公式の置き場所を持つこともあります。移植版を動作させている人が、待ち期間の間であっても、これによって移植作業者による作業の恩恵を受けられるようになります。もちろん、この様な場所は、公式な恩恵や状況の確認を受けることはできませんので、利用者は注意してください。

パッケージの自動移植に役立つインフラストラクチャと複数のツールがあります。この章には、この自動化とこれらのツールへの移植の概要が含まれています。全体の情報に付いてはパッケージのドキュメントかリファレンスを参照してください。

各移植版についての状況を含んだウェブページは https://www.debian.org/ports/ から参照できます。

Debian の各移植版はメーリングリストを持っています。移植作業のメーリングリストは https://lists.debian.org/ports.html で見ることができます。これらのリストは移植作業者の作業の調整や移植版のユーザと移植作業者をつなぐために使われています。

wanna-build システムは、分散型の、クライアント・サーバでの構築配布システムとして利用されています。通常、これは buildd プログラムが動作しているビルドデーモンと連携して使われます。ビルドデーモンは、ビルドが必要なパッケージの一覧を受け取るために中央の wanna-build システムと通信する「slave」ホストです。

wanna-build は、まだパッケージとしては入手可能になっていません。ですが、すべての Debian の移植作業ではパッケージ構築作業の自動化にこれが使われています。実際のパッケージ構築に使われるツール、sbuild はパッケージとして利用可能です。sbuild で説明を参照してください。パッケージ化されたバージョンは、ビルドデーモンで使われているものとは同じではありませんが、問題を再現するには十分なものである点に注意ください。

wanna-build によって生成される移植作業者にとって大抵有用であるデータの多くは、ウェブ上の https://buildd.debian.org/ で入手可能です。このデータには、毎晩更新される統計情報や、queue 情報、ビルド失敗のログが含まれています。

我々はこのシステムを極めて誇りに思っています。何故ならば、様々な利用方法の可能性があるからです。独立した開発グループは、実際に一般的な用途に合うかどうか分からない異なった別アプローチの Debian にシステムを使うことができます (例えば、gcc の配列境界チェック付きでビルドした Debian など)。そして、Debian がディストリビューション全体を素早く再コンパイルできるようにもなります。

buildd の担当である wanna-build チームには、debian-wb-team@lists.debian.org で連絡が取れます。誰 (wanna-build チーム、リリースチーム) に連絡を取るのか、どうやって (メール、BTS) 連絡するのかを決めるには、https://lists.debian.org/debian-project/2009/03/msg00096.html を参照してください。

binNMU や give-back (ビルド失敗後のやり直し) を依頼する時には、https://release.debian.org/wanna-build.txt で記述されている形式を使ってください。

いくつかのパッケージでは、Debian でサポートされているアーキテクチャのうちの幾つかで、構築や動作に問題を抱えており、全く移植できない、あるいは十分な時間内では移植ができないものがあります。例としては、SVGA に特化したパッケージ (i386amd64 のみで利用可能)や、すべてのアーキテクチャではサポートされていないようなハードウェア固有の機能があります。

壊れたパッケージがアーカイブにアップロードされたり buildd の時間が無駄に費やされたりするのを防ぐため、幾つかしなければならないことがあります:

サポートしていないアーキテクチャ上でビルドが失敗するようにせずに、パッケージを単に Packages-arch-specific に付け加えるだけでは不十分であることに注意してください: 移植作業者、あるいはあなたのパッケージをビルドしようとしている他の人は、それが動かないのに気づかないで誤ってアップロードするかもしれません。過去に、サポートされてないアーキテクチャ上にバイナリパッケージがアップロードされてしまった場合、削除依頼は ftp.debian.org に対するバグを登録することによって行われました。

すべてのパッケージには最低一人のメンテナがいます。通常、この人達がパッケージに対して作業をし、新しいバージョンをアップロードします。時折、他の開発者らが新しいバージョンをアップロードできると便利な場合があります。例えば、彼らがメンテナンスしていないパッケージにあるバグを修正したいが、メンテナが問題に対応するのには助けが必要な場合です。このようなアップロードは Non-Maintainer Upload (NMU) と呼ばれます。

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

  • NMU がメンテナを援助するような形にしましたか? メンテナが実際に助けを必要としているかどうか、意見に不一致があるかもしれないため、DELAYED キューが存在しています。DELAYED キューは、メンテナに対処する時間を与えるために存在しており、NMU diff の個別レビューが可能になるという有益な影響があります。

  • NMU がバグを本当に修正しますか? ("バグ" はあらゆる種類のバグを意味しています。例えば新しいバージョンをパッケージにしてほしいという wishlist バグもそうですが、メンテナへの影響を最小化するよう注意を払う必要があります)。NMU において、些細な表面的な問題やパッケージングスタイルの変更 (例えば cdbs から dh への変更) を行うのは推奨されていません。

  • メンテナに十分な時間を与えましたか? 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 のメリットについて、自分が行ったことの賢明さを常に弁護できるようにしておく必要があります。

他の (ソース) アップロード同様、NMU は debian/changelog にそのアップロードで何を変更したのかを示すエントリを追加せねばなりません。エントリの最初の行は、このアップロードが NMU であることを明白に示す必要があります。例えばこうです:

  * Non-maintainer upload.

NMU のバージョンのつけ方は、ネイティブなパッケージとネイティブではないパッケージでは異なります。

パッケージがネイティブパッケージの場合 (バージョン番号に Debian リビジョンが付かない)、バージョンはメンテナの最後のアップロードのバージョン + +nmuX となり、X1 から始まる数字になります。最後のアップロードが同様に 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 はメジャーリリース番号で Y1 から始まるカウンターです。例えば、jessie (Debian 8) が安定版の間は安定版バージョン 1.5-3 のパッケージへのセキュリティ NMU ならバージョン 1.5-3+deb8u1 となりますが、stretch へのセキュリティ NMU ではバージョン 1.5-3+deb9u1 となります。

NMU の許可を求めた後で待っているのは効率的ではありません。NMU した人が作業にもどるために頭を切り替えるのに手間がかかるからです。DELAYED キュー (「遅延アップロード」 参照) は、開発者が NMU をするのに必要な作業を同時にできるようになります。例えば、メンテナに対して更新したパッケージを 7 日後にアップロードするのを伝えるのではなく、パッケージを DELAYED/7 にアップロードしてメンテナに対して対応するのに 7 日間あることを伝えるべきです。この間、メンテナはもっとアップロードを遅らせるかアップロードをキャンセルするかを尋ねることができます。

DELAYED キューは、無用のプレッシャーをメンテナに与えるために使われるべきではありません。特に、メンテナはアップロードを自身ではキャンセルできないので、delay が完了する前にアップロードをキャンセルあるいは遅らせることができるのはあなただ、という点が重要です。

DELAYED を使った NMU を行って delay が完了する前にメンテナがパッケージを更新した場合には、アーカイブに既により新しいバージョンがあるので、あなたのアップロードは拒否されます。理想的なのは、メンテナがそのアップロードであなたが提案した変更 (あるいは少なくとも対応した問題の解決方法) を含めるのを取り仕切ることです。

NMU は、割り当てられているメンテナ以外の誰かによるパッケージのアップロードです。自分のものではないパッケージのアップロードについては、もう一つ、別の種類のアップロードがあります: QA アップロードです。QA アップロードは、放棄されたパッケージのアップロードです。

QA アップロードは、ほとんど通常のメンテナによるアップロードと同じです: 些細な問題であっても、なんでも修正します。バージョン番号の付け方は通常のものですし、delay アップロードをする必要もありません。違いは、パッケージのメンテナあるいはアップローダとして記載されていない点です。また、QA アップロードの changelog のエントリは以下のように最初の一行が特別になっています:

 * QA upload.

あなたが NMU をしたいと思い、かつ、メンテナが活動的ではない場合、パッケージが放棄されてないかどうかを確認するのが賢明です (この情報はパッケージ追跡システム (PTS) のページで表示されています)。放棄されたパッケージに対して最初の QA アップロードを行うときは、メンテナは Debian QA Group <packages@qa.debian.org> に設定する必要があります。まだ QA アップロードがされていない放棄されたパッケージには、以前のメンテナが設定されています。この一覧は https://qa.debian.org/orphaned.html で手に入ります。

QA アップロードをする代わりに、メンテナをあなた自身に変更してパッケージを引き取ることも考えられます。放棄されたパッケージを引き取るのには、誰からの許可も必要としません。メンテナをあなた自身に設定して新しいバージョンをアップロードするだけです (「パッケージを引き取る」 を参照)。

パッケージングチーム (Maintainer あるいは Uploader としてメーリングリストを使う。「共同メンテナンス」 参照) の一員であるため、時々パッケージを修正あるいは更新しているが、常にこの特定パッケージに貢献する予定は無いので自分を Uploaders には加えたくはない、という時があります。これがあなたのチームの方針に沿っているなら、直接 Maintainer 欄や Uploader 欄に記載せずとも通常のアップロードが可能です。この場合、changelog のエントリを以下の行で始める必要があります:

 * Team upload.

共同メンテナンス (collaborative maintenance) は、Debian パッケージのメンテナンス責任を数人でシェアすることを指す用語です。この共同作業は、通常はより上質で短いバグ修正時間をもたらすので、大抵の場合は常に良い考えです。優先度が標準 (standard) あるいは基本セット (base) の一部であるパッケージは、共同メンテナ (co-maintainer) を持つことを強くお勧めします。

大抵の場合、主メンテナに加えて一人か二人の共同メンテナが居ます。主メンテナは debian/control ファイルの Maintainer 欄に名前が記載されている人です。共同メンテナは他のすべてのメンテナで、通常 debian/control ファイルの Uploaders に記載されています。

もっとも基本的なやり方では、新しい副メンテナの追加は大変簡単です:

共同メンテナンスのもう一つの形態はチームメンテナンスです。これは、複数のパッケージを同じ開発者グループでメンテナンスする場合にお勧めです。その場合、各パッケージの Maintainer 欄と Uploaders 欄は注意して扱わねばいけません。以下の二つの案からいずれかを選ぶのがお勧めです:

  1. パッケージの主に担当をするチームメンバーを Maintainer 欄に追加します。Uploaders 欄には、メーリングリストのアドレスとパッケージの面倒をみるチームメンバーを追加します。

  2. メーリングリストのアドレスを Maintainer 欄に追加します。Uploaders 欄には、パッケージの面倒をみるチームメンバーを追加します。この場合、メーリングリストは (購読者以外に対するモデレーションなどの) 人手を介さずにバグ報告を受け取ることを確認する必要があります。

どのような場合でも、すべてのチームメンバーを Uploaders 欄に入れるのは良くない考えです。これは、Developer's Package Overview の一覧 (「Developer's packages overview」 参照) を実際には対応していないパッケージで散らかしてしまい、偽りの良いメンテナンス状態を作り出します。同じ理由から、パッケージを一回アップロードするのであれば、「チームアップロード (Team Upload)」ができるので、チームメンバーは Uploaders 欄へ自分を追加する必要はありません (「NMU とチームアップロード」 参照)。逆にいえば、Maintainer 欄にメーリングリストのアドレスのみで Uploaders 欄に誰も追加していないままにしておくのは良くない考えです。

テスト版 (testing) ディストリビューションを更新するスクリプトは、日に二回、更新されたパッケージのインストール直後に動作します。これらのスクリプトは britney と呼ばれます。これは、テスト版 (testing) ディストリビューションに対して Packages ファイルを生成しますが、不整合を避けてバグが無いパッケージのみを利用しようとする気の利いたやり方で行います。

不安定版 (unstable) からのパッケージの取り込みは以下の条件です:

パッケージがテスト版 (testing) に入る処理がされるかどうかは、テスト版ディストリビューションのウェブページテスト版 (testing) スクリプトの出力を参照するか、devscripts パッケージ中の grep-excuses プログラムを使ってください。このユーティリティは、パッケージがテスト版 (testing) への進行の通知をし続けるのに、crontab(5) で手軽に使うことができます。

update_excuses は、なぜパッケージが拒否されたのか正確な理由を必ずしも表示しません。自分自身で何がパッケージが含まれるのを妨げているのか、探す必要があるかもしれません。テスト版のウェブページが、そのような問題を引き起こす良くある問題についての情報を与えてくれるでしょう。

時折、相互依存関係の組み合わせが非常に難解なのでスクリプトが解決できないことがあるため、パッケージがテスト版 (testing) に決して入らないことがあります。詳細は下記を参照してください。

依存性についてのさらなる分析は、https://release.debian.org/migration/ で表示されています — ですが、このページが britney が処理した依存性ではないものも表示しているのに注意してください。

テスト版 (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 などをメンテしている場合を除きます)。

詳細について知りたい場合ですが、britney の動作は以下のようになります:

パッケージが、適切な候補であるかどうかを決めるために確認が行われます。これによって、更新が実行されます。パッケージが候補とみなされない理由でもっともよくあるのは、まだ日数が経過していない (too young)、RC バグがある、いくつかのアーキテクチャで古くなりすぎている、というものです。britney のこの部分では、リリースマネージャーが britney がパッケージを検討できるように、hints と呼ばれる様々なサイズのハンマーを使います (下記を参照してください)。

さて、より複雑な部分に差し掛かります: Britney が適正候補を使ってテスト版 (testing) を更新しようとします。このため、britney はテスト版ディストリビューションに個々の適正な候補を追加しようとします。テスト版 (testing) でインストール不可能なパッケージの数が増えないのであれば、パッケージは受け入れられます。その時から、受け入れられたパッケージはテスト版 (testing) の一部として取り扱われ、このパッケージを含めるためのインストールチェックテストが引き続き行われます。リリースチームからの hints は、実際の内容に応じて、このメインの処理の前後に処理されます。

より詳細を見たい場合は、https://ftp-master.debian.org/testing/update_output/ で探すことができます。

hints は、説明からも探せますが、https://ftp-master.debian.org/testing/hints/ にあります。hints によって、Debian リリースチームはパッケージを block あるいは unblock することや、パッケージをテスト版 (testing) へ移動する手間を減らしたり強制的に移動させたり、あるいはテスト版 (testing) からパッケージを削除したり、testing-proposed-updates へアップロードを許可したり、urgency を上書きすることが可能になります。

テスト版 (testing) ディストリビューションは、上記で説明したルールに従って 不安定版 (unstable) からのパッケージで作られています。しかし、時折、テスト版 (testing) の為だけに構築したパッケージをアップロードする必要があるという場合があります。そのためには、testing-proposed-updates にアップロードするのが良いでしょう。

アップロードされたパッケージは自動的に処理されず、リリースマネージャの手によって処理される必要があることに注意してください。ですので、アップロードするのに十分な理由があるのが望ましいでしょう。何が十分な理由かを知るには、リリースマネージャの視点で、彼らが定期的に に流している指示を読む必要があります。

不安定版 (unstable) でパッケージを更新できるのであれば、testing-proposed-updates にアップロードすべきではありません。更新できない場合 (例えば、不安定版 (unstable) に新しい開発版がある場合)、この機能を使うことができますが、まずはリリースマネージャから許可を得るのが良いでしょう。パッケージがフリーズされていても、不安定版 (unstable) 経由のアップロードが新たな依存関係を何も引き起こさない場合、不安定版 (unstable) での更新は可能です。

バージョン番号は、通常 +debXuY を付加することで指定されます。X は Debian のメジャーリリース番号で Y1 から始まる数です。例: 1:2.4.3-4+deb8u1

アップロードでは、以下の項目のいずれも見落とさないように必ずしてください:

  • 本当に testing-proposed-updates を通す必要があり、unstable ではダメなことを確認する;

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

  • 必ず changelog 中に適切な説明を含める;

  • 必ず、対象とするディストリビューションとして testing code name (e.g. stretch) を記述している;

  • 必ず 不安定版 (unstable) ではなく テスト版 (testing) でパッケージを構築・テストしている;

  • バージョン番号が testing および testing-proposed-updates のものよりも大きく、unstable のものよりも小さいのを確認する;

  • アップロードしてすべてのプラットフォームで構築が成功したら、 宛でリリースチームに連絡を取って、アップロードを承認してくれるように依頼しましょう。

ディストリビューションにおけるアーカイブの構造では、一つのバージョンのパッケージだけを持つことができ、パッケージは名前によって定義されています。そのため、ソースパッケージ acmefooテスト版 (testing) にインストールされると、付随するバイナリパッケージ acme-foo-binacme-bar-binlibacme-foo1libacme-foo-dev の古いバージョンが削除されます。

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

おそらく、これが主に影響するのは、一群のバイナリパッケージを変更したのを別バージョンで提供しているパッケージ (つまり、主にライブラリ) でしょう。しかし、バージョン付きの依存関係が ==、<=、<< などで宣言されているパッケージにも影響は及ぼします。

一つのソースパッケージによって提供されている一群のバイナリパッケージがこのようにして変更された場合、古いバイナリに依存しているすべてのパッケージは新しいバイナリに依存するように更新する必要があります。このようなソースパッケージをテスト版 (testing) にインストールするとテスト版 (testing) で依存しているすべてのパッケージを壊すことになるので、ここで注意をする必要があります: すべての依存しているパッケージを更新し、インストールできるように準備しておくことで壊されないようにしておき、そして、すべての準備ができたら、通常はリリースマネージャあるいはリリースアシスタントによる手動作業が必要になります。

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



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

[4] 過去においては、再コンパイルのみの状態を意味するために、このような NMU はリビジョンの Debian 部分の三つ目の番号を使っていました。しかし、この記法はネイティブパッケージの場合に曖昧で、同一パッケージでの再コンパイルのみの NMU と、ソース NMU と、セキュリティ NMU の正しい順序が付けられなかったため、この新しい記法で置き換えられました。