5. パッケージの取扱い方

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

5.1. 新規パッケージ

もしあなたが Debian ディストリビューションに対して新たなパッケージを作成したいという場合、まず 作業が望まれるパッケージ (Work-Needing and Prospective Packages (WNPP)) の一覧をチェックする必要があります。WNPP 一覧をチェックすることで、まだ誰もそのソフトをパッケージ化していないことや、作業が重複していないことを確認します。詳細については WNPP のページ を読んでください。

パッケージ化しようとしているソフトについて、誰もまだ作業していないようであれば、まずは wnpp 擬似パッケージ (pseudo-package) に対してバグ報告を投稿する必要があります (バグ報告)。このバグ報告には、パッケージの説明 (他の人がレビューできます)、作業しようとしているパッケージのライセンス、ダウンロードが可能な現在の URL を含めた新規パッケージの作成予定 (自分自身が分かるだけではないもの) を記述します。

サブジェクトを ITP:foo--short description に設定する必要があります。ここでは foo は新規パッケージの名前に置き換えます。バグ報告の重要度は wishlist に設定しなければなりません。X-Debbugs-CC ヘッダを使ってコピーを debian-devel@lists.debian.org に送信してください (CC: は使わないでください。CC: を使った場合はメールのサブジェクトにバグ番号が付与されないためです)。大量の新規パッケージの作成 (11 個以上) を行っている場合、メーリングリストへ個別に通知するのは鬱陶しいので、代わりにバグを登録した後で debian-devel メーリングリストへ要約を送信してください。これによって、他の開発者らに次に来るパッケージを知らせ、説明とパッケージ名のレビューが可能になります。

新規パッケージがアーカイブへインストールされる際にバグ報告を自動的に閉じるため、Closes: #nnnnn というエントリを新規パッケージの changelog 内に含めてください (新規アップロードでバグがクローズされる時 を参照)。

パッケージについて、NEW パッケージキューの管理者への説明が必要だろうと思う場合は、changelog に説明を含めて ftpmaster@debian.org へ送ってください。アップロード後であればメンテナとして受け取ったメールに返信してください。もしくは既に再アップロード最中の場合は reject メールに対して返信してください。

セキュリティバグを閉じる場合は、CVE 番号を Closes: #nnnnn と同じく含めるようにしてください。これは、セキュリティチームが脆弱性を追跡するのに役立ちます。アドバイザリの ID が分かる前にバグ修正のためのアップロードが行われた場合は、以前の changelog エントリを次のアップロード時に修正するのが推奨されています。このような場合でも、元々の changelog での記載に可能な限り背景情報へのポインタを全て含めてください。

我々がメンテナに意図しているところをアナウンスする様に求めるのには、いくつもの理由があります。

  • (潜在的な新たな) メンテナが、メーリングリストの人々の経験を活かすのを手助けし、もし他の誰かが既に作業を行っていた場合に知らせる。

  • そのパッケージについての作業を検討している他の人へ、既に作業をしているボランティアがいることを知らせ、労力が共有される。

  • debian-devel-changes@lists.debian.org に流される一行の説明文 (description) と通常どおりの「Intial release」という changelog エントリよりも、残った他のメンテナがパッケージに関してより深く知ることができる。

  • 不安定版 (unstable) で暮らす人 (そして最前線のテスターである人) の助けになる。我々はそのような人々を推奨すべきである。

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

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

5.2. パッケージの変更を記録する

パッケージについて行った変更は debian/changelog に記録されなくてはいけません。これらの変更には、何が変更されたのか、(不確かであれば) 何故なのか、そしてどのバグが閉じられたのかの簡潔な説明文を付加する必要があります。このファイルは /usr/share/doc/package/changelog.Debian.gz、あるいはネイティブパッケージの場合は /usr/share/doc/package/changelog.gz にインストールされます。

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

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

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

* New upstream release.

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

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

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

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

  • パッケージに対して lintian を実行する。以下のようにして lintian を実行できます: lintian -vpackage-version.changes これによって、バイナリパッケージ同様にソースパッケージを確認できます。lintian が生成した出力を理解していない場合は、lintian が問題の説明を非常に冗長に出力するようにする -i オプションを付けて実行してみてください。

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

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

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

  • Install the package and make sure the software works in an up-to-date unstable system.

  • Upgrade the package from an older version to your new version.

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

  • Installing, upgrading and removal of packages can either be tested manually or by using the piuparts tool.

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

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

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

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

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

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

ソース形式“1.0”では、パッケージが native かどうかはビルド時に dpkg-source によって決められていました。最近では望むソース形式を debian/source/format に“3.0 (quilt)”または“3.0 (native)”と記述することによって明示することが推奨されています。この章の残りの部分は native ではないパッケージについてのみ記しています。

The first time a version is uploaded that corresponds to a particular upstream version, the original source tar file must be uploaded and included in the .changes file. Subsequently, this very same tar file should be used to build the new diffs and .dsc files, and will not need to be re-uploaded.

デフォルトでは、dpkg-genchanges および dpkg-buildpackage は前述されている changelog エントリと現在のエントリが異なった upstream バージョンを持つ場合にのみ、オリジナルのソース tar ファイルを含めようとします。この挙動は、-sa を使って常に含めたり、-sd を使うことで常に含めないようにするように変更できます。

アップロード時にオリジナルのソースが含まれていない場合、アップロードされる .dsc と diff ファイルを構築する際に dpkg-source が使用するオリジナルの tar ファイルは、必ず既にアーカイブにあるものと 1 バイトも違わぬものでなくてはなりません。

Please notice that, in non-native packages, permissions on files that are not present in the *.orig.tar.{gz,bz2,xz} will not be preserved, as diff does not store file permissions in the patch. However, when using source format “3.0 (quilt)”, permissions of files inside the debian directory are preserved since they are stored in a tar archive.

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

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

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

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

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

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

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

Uploads to a supported stable release should target their suite name in the changelog, i.e. bookworm or bullseye. You should normally use reportbug and the release.debian.org pseudo-package to send a source debdiff, rationale and associated bug numbers to the stable release managers, and await a request to upload or further information.

If you are confident that the upload will be accepted without changes, please feel free to upload at the same time as filing the release.debian.org bug. However if you are new to the process, we would recommend getting approval before uploading so you get a chance to see if your expectations align with ours.

Either way, there must be an accompanying bug for tracking, and your upload must comply with these acceptance criteria defined by the the stable release managers. These criteria are designed to help the process be as smooth and frustration-free as possible.

  • The bug you want to fix in stable must be fixed in unstable already (and not waiting in NEW or the delayed queue).

  • The bug should be of severity "important" or higher.

  • Bug meta-data - particularly affected versions - must be up to date.

  • Fixes must be minimal and relevant and include a sufficiently detailed changelog entry.

  • A source debdiff of the proposed change must be included in your request (not just the raw patches or "a debdiff can be found at $URL").

  • The proposed package must have a correct version number (e.g. ...+deb12u1 for bookworm or +deb11u1 for bullseye) and you should be able to explain what testing it has had. See the Debian Policy for the version number: https://www.debian.org/doc/debian-policy/ch-controlfields.html#special-version-conventions

  • The update must be built in an stable environment or chroot (or oldstable if you target that).

  • Fixes for security issues should be co-ordinated with the security team, unless they have explicitly stated that they will not issue an DSA for the bug (e.g. via a "no-dsa" marker in the セキュリティ追跡システム).

  • Do not close release.debian.org bugs in debian/changelog. They will be closed by the release team once the package has reached the respective point release.

It is recommended to use reportbug as it eases the creation of bugs with correct meta-data. The release team makes extensive use of usertags to sort and manage requests and incorrectly tagged reports may take longer to be noticed and processed.

旧安定版 (oldstable) ディストリビューションへのアップロードはアーカイブされてない限り可能です。安定版 (stable)と同じルールが適用されます。

In the past, uploads to stable were used to address security problems as well. However, this practice is deprecated, as uploads used for Debian security advisories (DSA) are automatically copied to the appropriate proposed-updates archive when the advisory is released. See セキュリティ関連バグの取扱い for detailed information on handling security problems. If the security team deems the problem to be too benign to be fixed through a DSA, the stable release managers are usually willing to include your fix nonetheless in a regular upload to stable.

5.5.2. Special case: the stable-updates suite

Sometimes the stable release managers will decide that an update to stable should be made available to users sooner than the next scheduled point release. In such cases, they can copy the update to the stable-updates suite, use of which is enabled by the installer by default.

Initially, the process described in 特別な例: 安定版 (stable) と 旧安定版 (oldstable) ディストリビューションへアップロードする. should be followed as usual. If you think that the upload should be released via stable-updates, mention this in your request. Examples of circumstances in which the upload may qualify for such treatment are:

  • The update is urgent and not of a security nature. Security updates will continue to be pushed through the security archive. Examples include packages broken by the flow of time (c.f. spamassassin and the year 2010 problem) and fixes for bugs introduced by point releases.

  • The package in question is a data package and the data must be updated in a timely manner (e.g. tzdata).

  • Fixes to leaf packages that were broken by external changes (e.g. video downloading tools and tor).

  • Packages that need to be current to be useful (e.g. clamav).

  • Uploads to stable-updates should target their suite name in the changelog as usual, e.g. bookworm.

Once the upload has been accepted to proposed-updates and is ready for release, the stable release managers will then copy it to the stable-updates suite and issue a Stable Update Announcement (SUA) via the debian-stable-announce mailing list.

Any updates released via stable-updates will be included in stable with the next point release as usual.

5.5.3. 特別な例: testing/testing-proposed-updates へアップロードする

詳細については、直接テスト版を更新する にある情報を参照してください。

5.6. パッケージをアップロードする

5.6.1. Source and binary uploads

Each upload to Debian consists of a signed .changes file describing the requested change to the archive, plus the source and binary package files that are referenced by the .changes file.

If possible, the version of a package that is uploaded should be a source-only changes file. These are typically named *_source.changes, and reference the source package, but no binary .deb or .udeb packages. All of the corresponding architecture-dependent and architecture-independent binary packages, for all architectures, will be built automatically by the build daemons in a controlled and predictable environment (see wanna-build for more details). However, there are several situations where this is not possible.

The first upload of a new source package (see 新規パッケージ) must include binary packages, so that they can be reviewed by the archive administrators before they are added to Debian.

If new binary packages are added to an existing source package, then the first upload that lists the new binary packages in debian/control must include binary packages, again so that they can be reviewed by the archive administrators before they are added to Debian. It is preferred for these uploads to be done via the experimental suite.

Uploads that will be held for review in other queues, such as packages being added to the *-backports suites, might also require inclusion of binary packages.

The build daemons will automatically attempt to build any main or contrib package for which the build-dependencies are available. Packages in non-free and non-free-firmware will not be built by the build daemons unless the package has been marked as suitable for auto-building (see non-free のパッケージを auto-build 可能であるとマークする).

The build daemons only install build-dependencies from the main archive area. This means that if a source package has build-dependencies that are in the contrib, non-free or non-free-firmware archive areas, then uploads of that package need to include prebuilt binary packages for every architecture that will be supported. By definition this can only be the case for source packages that are themselves in the contrib, non-free or non-free-firmware archive areas.

Bootstrapping a new architecture, or a new version of a package with circular dependencies (such as a self-hosting compiler), will sometimes also require an upload that includes binary packages.

Binary packages in the main archive area that were not built by Debian's official build daemons will not usually be allowed to migrate from unstable to testing, so an upload that contains binary packages built by the package's maintainer must usually be followed by a source-only upload after the binary upload has been accepted. This restriction does not apply to contrib, non-free or non-free-firmware packages.

5.6.2. ftp-master にアップロードする

To upload a package, you should upload the files (including the signed changes and dsc file) with anonymous ftp to ftp.upload.debian.org in the directory /pub/UploadQueue/. To get the files processed there, they need to be signed with a key in the Debian Developers keyring or the Debian Maintainers keyring (see https://wiki.debian.org/DebianMaintainer).

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

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

パッケージを削除もしくはアップロードを取り消すには ftp://ftp.upload.debian.org/pub/UploadQueue/README と dcut Debian パッケージを参照してください。

Finally, you should think about the status of your package with relation to testing before uploading to unstable. If you have a version in unstable waiting to migrate then it is generally a good idea to let it migrate before uploading another new version. You should also check the Debian パッケージトラッカー for transition warnings to avoid making uploads that disrupt ongoing transitions.

5.6.3. 遅延アップロード

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

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

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

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

Do NOT upload a package to the security upload queue (on *.security.upload.debian.org) without prior authorization from the security team. If the package does not exactly meet the team's requirements, it will cause many problems and delays in dealing with the unwanted upload. For details, please see セキュリティ関連バグの取扱い.

5.6.5. 他のアップロードキュー

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

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

5.6.6. Notifications

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

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

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

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

Also note that new uploads are announced on the IRC チャンネル channel #debian-devel-changes. If your upload fails silently, it could be that your package is improperly signed, in which case you can find more explanations on ssh.upload.debian.org:/srv/upload.debian.org/queued/run/log.

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

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

5.8. バグの取扱い

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

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

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

5.8.1. バグの監視

良いメンテナになりたい場合は、あなたのパッケージに関する 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 ジョブを追加します:

# ask for weekly reports of bugs in my packages
0 17 * * fri   echo "index maint address" | mail request@bugs.debian.org

address は、あなたの公式な Debian パッケージメンテナとしてのメールアドレスに置き換えてください。

5.8.2. バグへの対応

When responding to bugs, make sure that any discussion you have about bugs is sent to the original submitter of the bug, the bug itself and (if you are not the maintainer of the package) the maintainer. Sending an email to 123@bugs.debian.org will send the mail to the maintainer of the package and record your email with the bug log. If you don't remember the submitter email address, you can use 123-submitter@bugs.debian.org to also contact the submitter of the bug. The latter address also records the email with the bug log, so if you are the maintainer of the package in question, it is enough to send the reply to 123-submitter@bugs.debian.org. Otherwise you should include 123@bugs.debian.org so that you also reach the package maintainer.

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

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

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

5.8.3. バグを掃除する

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

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

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

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

    If the bug submitter disagrees with your decision to close the bug, they may reopen it until you find an agreement on how to handle it. If you don't find any, you may want to tag the bug wontfix to let people know that the bug exists but that it won't be corrected. Please make sure that the bug submitter understands the reasons for your decision by adding an explanation to the message that adds the wontfix tag.

    If this situation is unacceptable, you (or the submitter) may want to require a decision of the technical committee by filing a new bug against the tech-ctte pseudo-package with a summary of the situation. Before doing so, please read the recommended procedure.

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

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

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

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

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

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

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

  8. Once a corrected package is available in the archive, the bug should be closed indicating the version in which it was fixed. This can be done automatically; read 新規アップロードでバグがクローズされる時.

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

We prefer the closes: #XXX syntax, as it is the most concise entry and the easiest to integrate with the text of the changelog. Unless specified differently by the -v-switch to dpkg-buildpackage, only the bugs closed in the most recent changelog entry are closed (basically, exactly the bugs mentioned in the changelog-part in the .changes file are closed).

歴史的に、Non-Maintainer Upload (NMU) と判別されるアップロードは closed ではなく fixed とタグがされてきましたが、この習慣はバージョントラッキングの進化によって廃れています。同じことが fixed-in-experimental タグにも言えます。

If you happen to mistype a bug number or forget a bug in the changelog entries, don't hesitate to undo any damage the error caused. To reopen wrongly closed bugs, send a reopen XXX command to the bug tracking system's control address, control@bugs.debian.org. To close any remaining bugs that were fixed by your upload, email the .changes file to XXX-done@bugs.debian.org, where XXX is the bug number, and put Version: YYY and an empty line as the first two lines of the body of the email, where YYY is the first version where the bug has been fixed.

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

どのように changelog のエントリを書くのか、一般的な情報については debian/changelog のベストプラクティス を参照してください。

5.9. パッケージの移動、削除、リネーム、放棄、引き取り、再導入

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

5.9.1. パッケージの移動

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

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

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

5.9.2. パッケージの削除

If for some reason you want to completely remove a package (say, if it is an old compatibility library which is no longer required), you need to file a bug against ftp.debian.org asking that the package be removed; as with all bugs, this bug should normally have normal severity. The bug title should be in the form RM: package [architecture list] -- reason, where package is the package to be removed and reason is a short summary of the reason for the removal request. [architecture list] is optional and only needed if the removal request only applies to some architectures, not all. Note that the reportbug will create a title conforming to these rules when you use it to report a bug against the ftp.debian.org pseudo-package.

If you want to remove a package you maintain, you should note this in the bug title by prepending ROM (Request Of Maintainer). There are several other standard acronyms used in the reasoning for a package removal; see https://ftp-master.debian.org/removals.html for a complete list. That page also provides a convenient overview of pending removal requests.

Note that removals can only be done for the unstable, experimental and stable distributions. Packages are not removed from testing directly. Rather, they will be removed automatically after the package has been removed from unstable and no package in testing depends on it. (Removals from testing are possible though by filing a removal bug report against the release.debian.org pseudo-package. See テスト版からの削除.)

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

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

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

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

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

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

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

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

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

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

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

5.9.4. パッケージを放棄する

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

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

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

5.9.5. パッケージを引き取る

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

It is not OK to simply take over a package without assent of the current maintainer — that would be package hijacking. You can, of course, contact the current maintainer and ask them for permission to take over the package.

However, when a package has been neglected by the maintainer, you might be able to take over package maintainership by following the package salvaging process as described in Package Salvaging. If you have reason to believe a maintainer is no longer active at all, see 活動的でない、あるいは連絡が取れないメンテナに対応する.

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

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

5.9.6. パッケージの再導入

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

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

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

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

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

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

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

Package removals from unstable also trigger marking the package as removed in the セキュリティ追跡システム. Debian members should mark removed issues as unfixed in the security tracker repository and all others should contact the security team to report reintroduced packages.

5.10. 移植作業、そして移植できるようにすること

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 package with binaries for the i386 architecture, it will be built for each of the other architectures, amounting to 10 more builds.

5.10.1. 移植作業者に対して協力的になる

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

The first and most important thing is to respond quickly to bugs 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.

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

  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. ソースパッケージが正しいことを確かめてください。ソースパッケージが正しく展開されたのを確認するため、dpkg-source -xpackage.dsc を実行してください。そして、ここでは、一からパッケージを dpkg-buildpackage でビルドするのに挑戦してみてください。

  4. debian/files や debian/substvars を含んだソースパッケージを出していないかを確かめてください。これらは、debian/rules の clean ターゲットによって削除されるべきです。

  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 set up in a special way. Try building your package on another machine, even if it's the same architecture.

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

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

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

  9. When you can't support your package on a particular architecture, you shouldn't use the Architecture field to reflect that (it's also a pain to maintain correctly). If the package fails to build from source, you can just let it be and interested people can take a look at the build logs. If the package would actually build, the trick is to add a Build-Depends on unsupported-architecture [!the-not-supported-arch]. The buildds will not build the package as the build dependencies are not fullfiled on that arch. To prevent building on 32-bits architectures, the architecture-is-64bit build dependency can be used, as architecture-is-little-endian can be used to prevent building on big endian systems.

5.10.2. 移植作業者のアップロード (porter upload) に関するガイドライン

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

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

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

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

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

時折、最初の移植作業者のアップロード作業は困難なものになります。パッケージが構築された環境があまり良くないからです (古すぎる、使われていないライブラリがある、コンパイラの問題、などなど…)。その場合には、更新した環境で再コンパイルする必要があるでしょう。しかし、この場合にはバージョンを上げる必要があり、古いおかしなパッケージは Debian アーカイブ中で入れ替えられることになります (現在利用可能なものよりバージョン番号が大きくない場合、dak は新しいパッケージのインストールを拒否します)。

binary-only NMU がパッケージをインストール不可能にしてしまっていないことを確認する必要があります。ソースパッケージが、dpkg の substitution 変数 $(Source-Version) を使って内部依存関係を生成しているアーキテクチャ依存パッケージとアーキテクチャ非依存パッケージを生成した場合に起こる可能性があります。

changelog の変更が必要かどうかに関わらず、これらは binary-only NMU と呼ばれます — この場合には、他の全アーキテクチャで古すぎるかどうかや再コンパイルが必要かなどを考える必要はありません。

このような再コンパイルは、特別な「magic」バージョン番号を付けるのを必要とするので、アーカイブのメンテナンスツールは、これを理解してくれます。新しい Debian バージョンで、対応するソースアップデートが無くても、です。これを間違えた場合、アーカイブメンテナは (対応するソースコードが欠落しているので) アップロードを拒否します。

再コンパイルのみの NMU への「magic」は、b番号 という形式に従った、パッケージのバージョン番号に対するサフィックスを追加することで引き起こされます。例えば、再コンパイル対象の最新バージョンが 2.9-3 の場合、バイナリのみの NMU は 2.9-3+b1 というバージョンになる必要があります。最新のバージョンが 3.4+b1 (つまり、ネイティブパッケージで、前回が再コンパイルの NMU) の場合、バイナリのみの NMU は 3.4+b2 というバージョン番号にならねばいけません。 [2]

最初の移植作業者のアップロード (porter upload) と同様に、パッケージのアーキテクチャ依存部分をビルドするための dpkg-buildpackage の正しい実行の仕方は dpkg-buildpackage -B です。

5.10.2.2. あなたが移植作業者の場合、source NMU を行う時は何時か

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

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

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

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

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

5.10.3. 移植用のインフラと自動化

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

5.10.3.1. メーリングリストとウェブページ

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

Debian の各移植版はメーリングリストを持っています。移植作業のメーリングリストは https://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 that is generally useful to porters is available on the web at https://buildd.debian.org/. This data includes nightly updated statistics, queueing information and logs for build attempts.

我々はこのシステムを極めて誇りに思っています。何故ならば、様々な利用方法の可能性があるからです。独立した開発グループは、実際に一般的な用途に合うかどうか分からない異なった別アプローチの 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で記述されている形式を使ってください。

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

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

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

  • まず、サポートできないアーキテクチャ上ではパッケージがビルドに失敗するのを確認しておく必要があります。これを行うには幾つかやり方があります。お勧めの方法は構築時に機能をテストする小さなテストスイートを用意して、動かない場合に失敗するようにすることです。これは、全てのアーキテクチャ上で、壊れたものをアップロードするのを防ぎ、必要な機能が動作するようになればパッケージがビルドできるようになる、良い考えです。

    さらに、サポートしているアーキテクチャ一覧が一定量であると信ずるのであれば、debian/control 内で any からサポートしているアーキテクチャの一覧に変更するべきです。この方法であれば、ビルドが同様に失敗するようになるのに加え、実際に試すことなく人間である読み手にサポートしているアーキテクチャが分かるようにできます。

  • autobuilder が必要もなくパッケージをビルドしようとしないように、wanna-build スクリプトが使うリストである Packages-arch-specific に追加しておく必要があります。現在のバージョンは https://wiki.debian.org/PackagesArchSpecific から入手できます: 変更依頼をする相手はファイルの一番上を参照してください。

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 accidentally 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.10.5. non-free のパッケージを auto-build 可能であるとマークする

By default packages from the non-free and non-free-firmware sections are not built by the autobuilder network (mostly because the license of the packages could disapprove). To enable a package to be built, you need to perform the following steps:

  1. 法的に許可されているか、技術的にパッケージが auto-build 可能かどうかを確認する;

  2. debian/control のヘッダ部分に XS-Autobuild: yes を追加する;

  3. メールを non-free@buildd.debian.org に送り、何故パッケージが合法的、かつ技術的に auto-build できるものなのかを説明する

5.11. Non-Maintainer Upload (NMU)

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

5.11.1. いつ、どうやって 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 スクリプトが役に立つでしょう。

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

そうするべき十二分な理由が無い限り、メンテナに対応する時間を与えるべきです (例えば DELAYED キューにアップロードすることによってこれを行います)。以下が delayed キューを使う際のお勧めの値です:

  • 7 日以上経っているリリースクリティカルバグのみを修正するアップロードで、バグに対するメンテナの活動が 7 日間見られなく、修正が行われている形跡が無い: 0 日

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

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

  • 他の NMU: 10 日

この値は例に過ぎません。セキュリティ問題を修正するアップロードや、移行を阻む些細なバグを修正するなど、いくつかのケースでは修正されたパッケージが 不安定版 (unstable) にすぐ入るようになるのは望ましいことです。

時々、リリースマネージャが特定のバグに対して短い delay 日数の NMU を許可を認めることがあります (7 日より古いリリースクリティカルバグなど)。また、一部のメンテナは Low Threshold NMU list に自身を挙げており、遅延なしの NMU アップロードを許可しています。しかしそのような場合であっても、特にパッチが BTS で以前手に入らなかったり、メンテナが大抵アクティブであるのを知っている場合など、アップロードの前にメンテナに対して数日与えるのは良い考えです。

NMU アップロード後、あなたは自分が導入したであろう問題に責任を持つことになります。パッケージを見張らなければなりません (これを行うには PTS 上のパッケージを購読するのが良い方法です)。

これは、軽率な NMU を行うための許可証ではありません。明らかにメンテナがアクティブで時期を逃さずパッチについて対応している場合や、このドキュメントに書かれている推奨を無視している場合など、あなたによるアップロードはメンテナと衝突を起こすでしょう。NMU のメリットについて、自分が行ったことの賢明さを常に弁護できるようにしておく必要があります。

5.11.2. NMU と debian/changelog

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 explicitly mention that this upload is an NMU, e.g.:

* Non-maintainer upload.

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

パッケージがネイティブパッケージの場合 (バージョン番号に Debian リビジョンが付かない)、バージョンはメンテナの最後のアップロードのバージョン + +nmuX となり、X は 1 から始まる数字になります。最後のアップロードが同様に NMU の場合は、数字を増やします。例えば、現在のバージョンが 1.5 だとすると、NMU はバージョンが 1.5+nmu1 になります。

パッケージがネイティブパッケージではない場合は、バージョン番号の Debian リビジョン部分 (最後のハイフン以下の部分) にマイナーバージョン番号を追加します。例えば、現在のバージョンが 1.5-2 であれば、NMU は 1.5-2.1 というバージョンになります。開発元のバージョンが新しくなったものが NMU でパッケージになった場合は、Debian リビジョンは 0 に設定されます。例えば 1.6-0.1 です。

どちらの場合でも、最後のアップロードも NMU だった場合には数字が増えます。例えば、現在のバージョンが 1.5+nmu3 (既に NMU されたネイティブパッケージ) の場合、NMU は 1.5+nmu4 というバージョンになります。

特別なバージョン付け方法が必要とされるのは、メンテナの作業を混乱させるのを避けるためです。何故ならば、Debian リビジョンのために整数を使っていると、NMU の際に既に準備されていたメンテナによるアップロードや、さらには ftp NEW queue にあるパッケージともぶつかる可能性があります。これには、アーカイブのパッケージが公式メンテナによるものではない、と視覚的に明らかにする利点もあります。

パッケージをテスト版や安定版にアップロードする場合、バージョン番号を「分岐」する必要が時々あります。これは例えばセキュリティアップロードが該当します。そのため、+debXuY 形式のバージョン番号を使うようにしてください。X はメジャーリリース番号で Y は 1 から始まるカウンターです。例えば、bookworm (Debian 12) が安定版の間は安定版バージョン 1.5-3 のパッケージへのセキュリティ NMU ならバージョン 1.5-3+deb12u1 となりますが、trixie へのセキュリティ NMU ではバージョン 1.5-3+deb13u1 となります。

5.11.3. DELAYED/ キューを使う

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

You can cancel your upload using dcut. In case you uploaded foo_1.2-1.1_all.changes to a DELAYED queue, you can run dcut cancel foo_1.2-1.1_all.changes to cancel your upload. The .changes file does not need to be present locally as you instruct dcut to upload a command file removing a remote filename. The .changes file name is the same that you used when uploading.

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

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

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

誰かがあなたのパッケージを NMU した場合、これは彼らがパッケージを良い形に保つのを助けたいと思っているということです。これによって、ユーザへ修正したパッケージをより早く届けます。NMU した人に、パッケージの副メンテナになることを尋ねるのを考えてみるのも良いでしょう。パッケージに対して NMU を受け取るのは悪いことではありません。それは、単にそのパッケージが他の人が作業する価値があるという意味です。

NMU を承認するには、変更と changelog のエントリを次のメンテナアップロードに含めます。バグは BTS で close されたままになりますが、パッケージのメンテナバージョンに影響していると表示されます。

Note that if you ever need to revert a NMU that packages a new upstream version, it is recommended to use a fake upstream version like CURRENT+reallyFORMER until one can upload the latest version again. More information can be found in https://www.debian.org/doc/debian-policy/ch-controlfields.html#epochs-should-be-used-sparingly.

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

NMU のフルネームはソース NMU です。もう一つ別の種類があって、バイナリのみの NMU (binary-only NMU) あるいは binNMU と名付けられています。binNMU も、パッケージメンテナ以外の誰かによるパッケージのアップロードです。しかし、これはバイナリのみのアップロードです。

ライブラリ (や他の依存関係) が更新された時、それを使っているパッケージを再ビルドする必要があるかもしれません。ソースへの変更は必要ないので、同じソースパッケージが利用されます。

binNMU は、通常 wanna-build によって buildd 上で引き起こされます。debian/changelog にエントリが追加され、なぜアップロードが必要だったのか、という説明と 再コンパイル、あるいは binary-only NMU で記述されているようにバージョン番号を増やします。このエントリは、その次のアップロードに含めるべきではありません。

buildd は、アーカイブするために、バイナリのみのアップロードとして、そのアーキテクチャに対してパッケージをアップロードします。厳密に言えば、これは binNMU です。しかし、これは通常 NMU とは呼ばれず、debian/changelog にエントリを追加しません。

5.11.6. NMU と QA アップロード

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

* QA upload.

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

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. Package Salvaging

Package salvaging is the process by which one attempts to save a package that, while not officially orphaned, appears poorly maintained or completely unmaintained. This is a weaker and faster procedure than orphaning a package officially through the powers of the MIA team. Salvaging a package is not meant to replace MIA handling, and differs in that it does not imply anything about the overall activity of a maintainer. Instead, it handles a package maintainership transition for a single package only, leaving any other package or Debian membership or upload rights (when applicable) untouched.

Note that the process is only intended for actively taking over maintainership. Do not start a package salvaging process when you do not intend to maintain the package for a prolonged time. If you only want to fix certain things, but not take over the package, you must use the NMU process, even if the package would be eligible for salvaging. The NMU process is explained in Non-Maintainer Upload (NMU).

Another important thing to remember: It is not acceptable to hijack others' packages. If followed, this salvaging process will help you to ensure that your endeavour is not a hijack but a (legal) salvaging procedure, and you can counter any allegations of hijacking with a reference to this process. Thanks to this process, new contributors should no longer be afraid to take over packages that have been neglected or entirely forgotten.

The process is split into two phases: In the first phase you determine whether the package in question is eligible for the salvaging process. Only when the eligibility has been determined you may enter the second phase, the actual package salvaging.

For additional information, rationales and FAQs on package salvaging, please visit the Salvaging Packages page on the Debian wiki.

5.12.1. When a package is eligible for package salvaging

A package becomes eligible for salvaging when it has been neglected by the current maintainer. To determine that a package has really been neglected by the maintainer, the following indicators give a rough idea what to look for:

  • NMUs, especially if there has been more than one NMU in a row.

  • Bugs filed against the package do not have answers from the maintainer.

  • Upstream has released several versions, but despite there being a bug entry asking for it, it has not been packaged.

  • There are QA issues with the package.

You will have to use your judgement as to whether a given combination factors constitutes neglect; in case the maintainer disagrees they have only to say so (see below). If you're not sure about your judgement or simply want to be on the safe side, there is a more precise (and conservative) set of conditions in the Package Salvaging wiki page. These conditions represent a current Debian consensus on salvaging criteria. In any case you should explain your reasons for thinking the package is neglected when you file an Intent to Salvage bug later.

5.12.2. How to salvage a package

If and only if a package has been determined to be eligible for package salvaging, any prospective maintainer may start the following package salvaging procedure.

  1. Open a bug with the severity "important" against the package in question, expressing the intent to take over maintainership of the package. For this, the title of the bug should start with ITS: package-name [3]. You may alternatively offer to only take co-maintenance of the package. When you file the bug, you must inform all maintainers, uploaders and if applicable the packaging team explicitly by adding them to X-Debbugs-CC. Additionally, if the maintainer(s) seem(s) to be generally inactive, please inform the MIA team by adding mia@qa.debian.org to X-Debbugs-CC as well. As well as the explicit expression of the intent to salvage, please also take the time to document your assessment of the eligibility in the bug report, for example by listing the criteria you've applied and adding some data to make it easier for others to assess the situation.

  2. In this step you need to wait in case any objections to the salvaging are raised; the maintainer, any current uploader or any member of the associated packaging team of the package in question may object publicly in response to the bug you've filed within 21 days, and this terminates the salvaging process.

    The current maintainers may also agree to your intent to salvage by filing a (signed) public response to the the bug. They might propose that you become a co-maintainer instead of the sole maintainer. On team maintained packages, a member of the associated team can accept your salvaging proposal by sending out a signed agreement notice to the ITS bug, alternatively inviting you to become a new co-maintainer of the package. The team may require you to keep the package under the team's umbrella, but then may ask or invite you to join the team. In any of these cases where you have received the OK to proceed, you can upload the new package immediately as the new (co-)maintainer, without the need to utilise the DELAYED queue as described in the next step.

  3. After the 21 days delay, if no answer has been sent to the bug from the maintainer, one of the uploaders or team, you may upload the new release of the package into the DELAYED queue with a minimum delay of seven days. You should close the salvage bug in the changelog and you must also send an nmudiff to the bug ensuring that copies are sent to the maintainer and any uploaders (including teams) of the package by CC'ing them in the mail to the BTS.

    During the waiting time of the DELAYED queue, the maintainer can accept the salvaging, do an upload themselves or (ask to) cancel the upload. The latter two of these will also stop the salvaging process, but the maintainer must reply to the salvaging bug with more information about their action.

5.13. 共同メンテナンス

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

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

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

  • Set up 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 Git. Salsa (see salsa.debian.org: Git repositories and collaborative development platform) provides Git repositories, amongst other collaborative tools.

  • 共同メンテナの正確なメンテナ名とアドレスを debian/control ファイルの最初の段落の Uploaders 欄に追加します。

    Uploaders: John Buzz <jbuzz@debian.org>, Adam Rex <arex@debian.org>

  • PTS (Debian パッケージトラッカー) を使う場合、共同メンテナは適切なソースパッケージの購読をする必要があります。

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

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

  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 accepts bug reports without any human interaction (like moderation for non-subscribers).

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

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

5.14.1. 基本

パッケージは通常、不安定版 (unstable) におけるテスト版への移行基準を満たした後でテスト版 (testing) ディストリビューションへとインストールされます。

これらは、すべてのアーキテクチャ上で同期していなければならず、インストールできなくなるような依存関係を持ってはいけません。また、テスト版 (testing) にインストールされる際に既知のリリースクリティカルバグを持っていない必要があります。このようにして、テスト版 (testing) は常にリリース候補に近いものである必要があります。詳細は以下を参照してください。

5.14.2. 不安定版からの更新

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

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

  • The package must have been available in unstable for a certain number of days, see Selecting the upload urgency. Please note that the urgency is sticky, meaning that the highest urgency uploaded since the previous testing transition is taken into account;

  • 新たなリリースクリティカルバグを持っていないこと (不安定版 (unstable)で利用可能なバージョンに影響する RC バグであって、テスト版 (testing) にあるバージョンに影響するものではない);

  • あらかじめ unstable でビルドされた際に、全アーキテクチャで利用可能になっていなくてはいけません。この情報をチェックするのに dak ls ユーティリティ に興味を持つかもしれません;

  • 既にテスト版 (testing) で利用可能になっているパッケージの依存関係を壊さないこと;

  • パッケージが依存するものは、テスト版 (testing) で利用可能なものか、テスト版 (testing) に同時に受け入れられるものでなくてはいけない (そして、それらは必要な条件をすべて満たしていれば、テスト版 (testing)) に入る);

  • プロジェクトの状況。つまり、テスト版 (testing) ディストリビューションのフリーズ中は、自動的な移行がオフになります。

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

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

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

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

5.14.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 outofsync_arches; outofsync_arches is a list of architectures that don't keep up (in britney.py), but currently, it's empty). Outdated has nothing whatsoever to do with the architectures this package has in testing.

以下の例を考えてみましょう:

alpha

arm

テスト版

1

-

不安定版

1

2

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.

ですが、もしも ftp-master が不安定版 (unstable) のパッケージ (ここでは arm の) を削除した場合:

alpha

arm

hurd-i386

テスト版

1

1

-

不安定版

2

-

1

この場合、パッケージは不安定版 (unstable) ですべてのリリースアーキテクチャで最新になります (それから、もう一つの hurd-i386 は、リリースアーキテクチャではないので問題になりません)。

時折、すべてのアーキテクチャでまだビルドされていていないパッケージを入れられるか、という質問がでてきます: いいえ。 単純にいいえ、です (glibc などをメンテしている場合を除きます)。

5.14.2.2. テスト版からの削除

時折、パッケージは他のパッケージがテスト版へ入るために削除されます: これは、他のパッケージが他のすべての面で準備ができている場合にテスト版に入るようにする場合のみ発生します。例えば、a が新しいバージョンの b とはインストールできない場合を考えてみましょう。その場合、a は b が入るために削除されるかもしれません。

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

さらに、パッケージが 不安定版 (unstable) から削除され、テスト版 (testing) にはこれに依存するパッケージがもうなくなった場合、パッケージは自動的に削除されます。

5.14.2.3. 循環依存

britney によってうまく取扱われない状況は、パッケージ a がパッケージ b の新しいバージョンに依存していて、そしてその逆も、というものです。

この場合の例:

テスト版

不安定版

a

1; depends: b=1

2; depends: b=2

b

1; depends: a=1

2; depends: a=2

パッケージ a あるいはパッケージ b が更新対象と見做されない。

現状、このような場合はリリースチームによる手動でのヒントが必要になります。あなたのパッケージのどれかにこのような状況が起きた場合は、debian-release@lists.debian.org にメールを送って連絡を取ってください。

5.14.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 outofsync_arches, or there was no binary package of that arch present in unstable at all during the testing migration.

この要旨: 影響は、テスト版 (testing) にあるパッケージが、同じパッケージの新しいバージョンになるのは、新しいバージョンの方が楽にできそうだから、ということです。

5.14.2.5. 詳細について

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

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

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

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

The hints are available via https://release.debian.org/britney/hints/, where you can find the description as well. With the hints, the Debian Release team can block or unblock packages, ease or force packages into testing, remove packages from testing, approve uploads to 直接テスト版を更新する or override the urgency.

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

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

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. Even if a package is frozen, updates through unstable are possible, if the upload via unstable does not pull in any new dependencies.

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

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

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

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

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

  • 必ず、対象とするディストリビューションとして testing リリースのコードネーム (e.g. trixie) を記述している;

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

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

  • Ask for authorization for uploading from the release managers.

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

5.14.4. よく聞かれる質問とその答え (FAQ)

5.14.4.1. リリースクリティカルバグとは何ですか、どうやって数えるのですか?

ある重要度以上のバグすべてが通常リリースクリティカルであると見なされます。現在のところ、critical (致命的)、grave (重大)、serious (深刻) バグがそれにあたります。

そのようなバグは、Debian の 安定版 (stable) リリース時に、そのパッケージがリリースされる見込みに影響があるものと仮定されます: 一般的に、パッケージでオープンになっているリリースクリティカルバグがある場合、そのパッケージはテスト版 (testing) に入らず、その結果安定版 (stable) ではリリースされません。

The unstable bug count comprises all release-critical bugs that are marked to apply to package/version combinations available in unstable for a release architecture. The testing bug count is defined analogously.

5.14.4.2. どのようにすれば、他のパッケージを壊す可能性があるパッケージをテスト版 (testing) へインストールできますか?

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

However, the old version may have provided a binary package with an old soname of a library, such as libacme-foo0. Removing the old acmefoo will remove libacme-foo0, which will break any packages that depend on it.

Evidently, this mainly affects packages that 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 changes 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.

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

5.15. The Stable backports archive

5.15.1. 基本

Once a package reaches the testing distribution, it is possible for anyone with upload rights in Debian (see below about this) to build and upload a backport of that package to stable-backports, to allow easy installation of the version from testing onto a system that is tracking the stable distribution.

One should not upload a version of a package to stable-backports until the matching version has already reached the testing archive.

5.15.2. Exception to the testing-first rule

The only exception to the above rule, is when there's an important security fix that deserves a quick upload: in such a case, there is no need to delay an upload of the security fix to the stable-backports archive. However, it is strongly advised that the package is first fixed in unstable before uploading a fix to the stable-backports archive.

5.15.3. Who can maintain packages in the stable-backports archive?

It is not necessarily up to the original package maintainer to maintain the stable-backports version of the package. Anyone can do it, and one doesn't even need approval from the original maintainer to do so. It is however good practice to first get in touch with the original maintainer of the package before attempting to start the maintenance of a package in stable-backports. The maintainer can, if they wish, decide to maintain the backport themselves, or help you doing so. It is not uncommon, for example, to apply a patch to the unstable version of a package, to facilitate its backporting.

5.15.4. When can one start uploading to stable-backports?

The new stable-backports is created before the freeze of the next stable suite. However, it is not allowed to upload there until the very end of the freeze cycle. The stable-backports archive is usually opened a few weeks before the final release of the next stable suite, but it doesn't make sense to upload until the release has actually happened.

5.15.5. How long must a package be maintained when uploaded to stable-backports?

The stable-backports archive is maintained for bugs and security issues during the whole life-cycle of the Debian stable suite. Therefore, an upload to stable-backports, implies a willingness to maintain the backported package for the duration of the stable suite, which can be expected to be about 3 years from its initial release.

The person uploading to backports is also supposed to maintain the backported packages for security during the lifetime of stable.

It is to be noted that the stable-backports isn't part of the LTS or ELTS effort. The stable-backports FTP masters will close the stable-backports repositories for uploads once stable reaches end-of-life (ie: when stable becomes maintained by the LTS team only). Therefore there won't be any maintenance of packages from stable-backports after the official end of life of the stable suite, as uploads will not be accepted.

5.15.6. How often shall one upload to stable-backports?

The packages in backports are supposed to follow the developments that are happening in Testing. Therefore, it is expected that any significant update in testing should trigger an upload into stable-backports, until the new stable is released. However, please do not backport minor version changes without user visible changes or bugfixes.

5.15.7. How can one learn more about backporting?

You can learn more about how to contribute directly on the backport web site.

It is also recommended to read the Frequently Asked Questions (FAQ).