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

アップロードが許可されるのを確実にするには、アップロードの前に変更点について安定版リリースチームと協議する必要があります。そのためには、安定版 (stable) にある現在のパッケージバージョンに適用したいパッチを含めたメールを <debian-release@lists.debian.org> メーリングリストに送ってください。安定版 (stable) ディストリビューションへアップロードするパッケージの changelog のエントリには常にくどいほど詳細にしてください。

安定版 (stable) へのアップロード時には特に注意を払うことが必要です。基本的に、以下のいずれかが起こった際にのみ 安定版 (stable) へパッケージはアップロードされます:

以前、安定版 (stable) へのアップロードはセキュリティ問題への対処と同等に取り扱われていました。しかし、この慣習は廃れており、Debian セキュリティ勧告がリリースされた際、セキュリティ勧告へのアップロードに使われたものが自動的に適切な proposed-updates アーカイブにコピーされます。セキュリティ情報の取り扱い方の詳細については 「セキュリティ関連バグの取扱い」 を参照してください。セキュリティチームがその問題は DSA を通じて修正するには軽微過ぎると思った場合であっても、安定版のリリースマネージャらはそれに関わらず 安定版 (stable) への定期アップロードに修正を含めようとするでしょう。

些細な修正でも後ほどバグを引き起こすことがあるので、重要でないものは何であろうと変更するのは推奨されません。

安定版 (stable) にアップロードされるパッケージは安定版 (stable) を動作しているシステム上でコンパイルされていなければならず、ライブラリ (やその他のパッケージ) への依存は安定版 (stable) で入手可能なものに限られます。例えば、安定版 (stable) にアップロードされたパッケージが不安定版 (unstable) にのみ存在するライブラリパッケージに依存していると reject されます。他のパッケージへの依存を (提供 (Provides) や shlibs をいじることで) 変更するのは、他のパッケージをインストールできないようにする可能性があるので認められません。

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

詳細については、testing section にある情報を参照してください。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

メンテナは、bugs.debian.org のメールアドレス経由で BTS に対応します。利用可能なコマンドについてのドキュメントは http://www.debian.org/Bugs/ で参照可能ですし、もし doc-debian パッケージをインストールしてあれば、ローカルファイル /usr/share/doc/debian/bug-* で見ることも可能です。

定期的にオープンになっているバグについてのレポートを受け取るのも良いでしょう。あなたのパッケージでオープンになっているバグの全一覧を毎週受け取りたい場合、以下のような cron ジョブを追加します:

# 自分のパッケージにあるバグのレポートを毎週取得する
0 17 * * fri   echo "index maint address" | mail request@bugs.debian.org

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

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

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

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

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

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

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

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

バグや問題があなたのパッケージで修正されたとしたら、そのバグを閉じるのはパッケージメンテナとしての責任になります。しかし、バグを修正したパッケージが Debian アーカイブに受け入れられるまではバグを閉じてはいけません。従って、一旦更新したパッケージがアーカイブにインストールされたという通知を受け取った場合は、BTS でバグを閉じることができますし、そうしなければいけません。もちろん、バグは正しいバージョンで閉じなくてはいけません。

ですが、アップロード後に手動でバグをクローズしなくても済む方法があります — debian/changelog に以下の特定の書き方にて修正したバグを列挙すれば、それだけで後はアーカイブのメンテナンスソフトがバグをクローズしてくれます。例:

acme-cannon (3.1415) unstable; urgency=low

  * Frobbed with options (closes: Bug#98339)
  * Added safety to prevent operator dismemberment, closes: bug#98765,
    bug#98713, #98714.
  * Added man page. Closes: #98725.

技術的に言うと、どの様にしてバグを閉じる changelog が判別されているかを以下の Perl の正規表現にて記述しています:

  /closes:\s*(?:bug)?\#\s*\d+(?:,\s*(?:bug)?\#\s*\d+)*/ig

closes: #XXX という書き方が推奨されています。これは、最も分かり易いエントリで、changelog の本文に挿入するのがもっとも簡単だからです。dpkg-buildpackage に -v スイッチを指定して別バージョンを指定しない限り、最も新しい changelog のエントリにあるバグだけが閉じられます (基本的には、です。正確には .changes ファイルの changelog-part で明示されたバグが閉じられます)。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  * Non-maintainer upload.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 * QA upload.

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

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

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.

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

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

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

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

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

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

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

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

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

Keep in mind that packages uploaded there are not automatically processed, they have to go through the hands of the release manager. So you'd better have a good reason to upload there. In order to know what a good reason is in the release managers' eyes, you should read the instructions that they regularly give on <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, but it is recommended that you ask for authorization from the release manager first. Even if a package is frozen, updates through unstable are possible, if the upload via unstable does not pull in any new dependencies.

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

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