状況によっては、あるパッケージをその公式な開発者以外の誰かが リリースしなければならないことがあります。 このことはノンメンテナアップロード、すなわち NMU と呼ばれています。
異なるアーキテクチャ向けのパッケージを作成するという Debian の移植作業に携わる人にとっては、 この NMU は正規の移植作業の一環にあります。 (移植作業と移植版, 章 8 をご覧ください。) 他にも、特にフリーズ期間などに、 セキュリティや機能に関する深刻な問題を処理するために、 Debian 開発者が他の開発者のパッケージを修正する必要がある場合、 つまり、パッケージ開発者が修正版を即座にリリースできない場合には NMU が行なわれます。
この章では、NMU がいつどのように行なわれるべきかについての ガイドラインを扱います。 なお次節で説明しますが、この NMU には source NMU と binary NMU の二つがあります。
この節の全体にわたって二つの新たな用語、``binary NMU'' と ``source NMU'' を用います。 これらの用語は、この文書の中では技術上の特別な意味を示すものとして用います。 binary NMU と source NMU は、あるパッケージが公式な開発者以外の開発者 によってアップロードされる点では同じです。 ノンメンテナアップロードと呼ばれるのはこのためです。
source NMU とは、あるパッケージがそのバグ修正のために、
公式開発者以外の開発者によってアップロードされることを指します。 source NMU
は、(debian/changelog の改変のみかもしれませんが、)
常にソースの改変を伴います。 この改変はアップストリームソースと、 Debian
で加えられたソースのどちらに対して行なうことができます。
binary NMU は、新たなアーキテクチャ向けにバイナリパッケージを 再コンパイルしアップロードすることを指します。 そのため、こちらは移植に関する正規の作業一環にあるものです。 つまり binary NMU とは、ソース改変を必要としない、 (普通は他アーキテクチャ用) パッケージのバイナリバージョンが ノンメンテナアップロードされたものです。 ただ、ターゲットとするアーキテクチャでコンパイルを通すために、 移植作業者がソース上の問題を修正することはよくあることです。 そのため、こちらは binary NMU というよりもむしろ source NMU とみなされるものです。 このように、私たちは、移植作業者による NMU と非移植作業者による NMU を用語の上では区別していません。
source および binary の両 NMU は、``NMU'' という用語で一括りされえます。 しかしながら、``NMU'' という用語が使われる際に多くの人々は ``source NMU''を想定するために、このことはしばしば混乱をもたらしがちです。 そのためこの区別については注意を払っておくべきでしょう。 この章で私が不特定に ``NMU'' という用語を使う場合、 それは source および binary の両 NMU を指すものとします。
Debian 開発者として正式に登録された者のみが binary NMU あるいは source NMU を行なうことができます。 公式な開発者とは、Debian キーリングに自分の鍵が登録されている者のことです。 もちろん、非開発者の場合もソースパッケージをダウンロードして、 問題を修正するためにそのハックを始めることは奨励されています。 ただその際には、NMU を行なう代わりに バグ追跡システムへ適切なパッチを登録するべきです。 開発者は質の高いパッチやバグ報告に対して普通いつでも感謝しています。
source NMU を行なう場合のガイドラインは、 ターゲットとするディストリビューション (つまり stable や、unstable あるいは frozen) によって異なります。 なお、移植作業者が従うルールは、その特別な状況 (移植作業者が source NMU を行なう場合には, Section 8.2.1 をご覧ください) のために、非移植作業者の場合とは若干異なります。
stable 版に対して行なえるものは、critical なバグの修正や、 セキュリティ上のバグに関する修正のみです。 セキュリティ上のバグが発覚した場合、 修正版パッケージは可能な限り早くアップロードされるべきです。 この場合、Debian セキュリティマネージャは、 修正版パッケージを適切な期限内 (48 時間以内) に確実にアップロードできるよう該当パッケージの開発者と連絡をとるべきです。 パッケージ開発者が修正版パッケージを十分に早くは提供できない場合や、 その開発者にすぐに連絡の取れない場合には、 セキュリティマネージャが修正版パッケージ (つまり source NMU ) をアップロードすることができます。
リリースのフリーズ期間 (frozen へのアップロード, Section 6.2.2.1 をご覧ください) には、 important バグや重要度の高いバグの修正は奨励されており認められます。 しかし、この期間においても、 そのパッケージの現行開発者と連絡をとるよう努めなければなりません。 現行開発者がその問題の修正をちょうどアップロードしようとしているところ なのかもしれないからです。 また、いかなる source NMU を行なう場合でも、source NMU を行なうには, Section 7.4 にて掲げられているガイドラインには従う必要があります。
非開発者による unstable 版へのバグ修正も、 最終手段として行なわれる場合や許可がある場合のみ 認められています。 以下の各ステップを踏んでみて、 その結果それが上手くいかない場合には、 おそらく NMU を行なうに問題はないでしょう。
以下の記述は、移植作業者が パッケージのバグ修正ならびにパッケージの移植の両方の役割を果たす場合のみ 当てはまります。 移植作業者が Debian ソースアーカイブに変更を加える必要がある場合、 そのアップロードはすなわち source NMU であり、 その際には source NMU に関するルールにしたがわなければなりません。 単に再コンパイルしたバイナリパッケージをアップロードする場合、 適用されるルールは異なってきます。 こちらに関しては 移植作業者によるアップロードに関するガイドライン, Section 8.2 をご覧ください。
まず第一に、ソースに対する NMU パッチは、 元のソースをなるべく改変しないものであることが重要です。 あれこれとソースを整理したりしないでください。 モジュール名やファイル名は変更しないでください。 ディレクトリは移動しないでください。 つまり、一般的には問題のない箇所に変更を加えないでください。 パッチはなるべく小さなものとなるようにしてください。 あなたの審美的な観点から何とかしたいことがあるならば、 Debian 開発者やアップストリーム開発者に連絡を取るか、 バグ報告を行なってください。 ともあれ、審美的な観点からの変更は ノンメンテナアップロードで行なうべきではありません。
パッケージに変更を加える際には常に、 それがどんなに些細なものであろうとも、 バージョン番号を変更しなければなりません。 そうしなければ、パッケージングシステムが正しく機能しません。
ノンメンテナアップロード (NMU) を行なう場合、 バージョン番号の
debian-revision 部分 (最後のハイフン以降の部分)
に新たなマイナーバージョン番号を追加しなければなりません この拡張マイナー番号は
`1' から始められます。 例えば、1.1-3 というバージョンの `foo'
というパッケージの場合を考えてみましょう。 Debian
アーカイブにおいては、そのソースパッケージの制御ファイルは、
foo_1.1-3.dsc になります。 つまり、アップストリームバージョンは
`1.1' で、 Debian バージョンは `3' です。 そして、次の NMU
では新たなマイナー番号 `.1' を Debian リビジョンに追加することになります。
つまり、新たなソース制御ファイルは foo_1.1-3.1.dsc になります。
Debian リビジョンマイナー番号は、パッケージ開発者のバージョン番号の いずれかと衝突しないようにするために必要になるものです。 これがなければパッケージ開発者の作業が混乱してしまいます。 また、こうすることには、 Debian アーカイブ中のあるパッケージが公式な開発者によるもの でないことが見てすぐわかるという利点もあります。
もしバージョン番号に debian-revision 部分がない場合は、 `0.1'
で始まるように追加しなければなりません。
正規の開発者以外の誰かが、新たなアップストリームバージョンベースのリリース
をどうしても行なう必要がある場合は、`0.1' という debian-revision
を付けてリリースを行なってください。 正規のパッケージ開発者の場合は、
debian-revision を `1' から始めてください。 ただこちらを行なう場合、
構築システムに新たなソースパッケージを強制的に選択させるために、
-sa スイッチを付けて dpkg-buildpackage
を起動する必要があるでしょう。 (普通このプログラムは、Debian リビジョン が '0'
あるいは '1' かどうかのみを確認します。 -- `0.1'
という数字を認識するほどにはまだ賢くないのです。)
注意していただきたいのですが、移植作業者が異なるアーキテクチャ向けに パッケージを単に再コンパイルする場合は、 バージョン番号を付け直す必要はありません。 移植作業者は、何らかの方法でソースパッケージに変更を加えた場合、 つまり、binary NMU ではなく source NMU を行なう場合 (のみ)、 新たなバージョン番号を用いるべきです。
source NMU を行なう非公式開発者は、 NMU によってどのバグが修正されたのか、 また通常は NMU がなぜ必要でどこを修正したのかを説明する changelog エントリを作成しなければなりません。 changelog エントリの log エントリには、 その非公式開発者の電子メールアドレスと NMU バージョン番号が含められます。
慣例によって、source NMU の changelog エントリは次の行で始められます。
* Non-maintainer upload
公式なパッケージ開発者以外の開発者がパッケージに変更を加える場合、 その変更はなるべく小さなものに留めるべきです。 また、変更箇所を詳しく説明するために必ず、 そのパッチを unified context diff (diff -u) の形でバグ追跡システムに送るべきです。
単にパッケージを再コンパイルする場合はどうするのでしょうか？
この場合、すでに述べたように移植作業者の場合と非移植作業者の場合では
その手順が異なります。 移植作業者ではない開発者が単に再コンパイルが必要なだけの
NMU を行なう場合、 (つまり、新たな共有ライブラリが利用できるようになった場合や
debhelper でバグ修正が行なわれた場合) やはり changelog
エントリが必要になり、 それゆえパッチが存在することになります。
一方、移植作業者の場合は、おそらく単に binary NMU を行なうことになります。
(注意: このことは、本来再コンパイルをしなければならない移植作業者が
それを行なわないことに関しては考慮していません。 --
こちらは、私たちのアーカイブ管理に関する問題点の一つでしょう。)
source NMU (ノンメンテナアップロード) によって
バグ追跡システムに登録されている既存のバグを修正した場合、
非公式開発者はそのバグをクローズするのではなく、
その旨を通知しなければなりません。
規則の上では、バグをクローズすることができるのは、
公式パッケージ開発者か元のバグ報告者のみです。
しかしながら、ノンメンテナリリースを行なった者は、適切なバグに対して、
そのバグが NMU によって修正されたことを説明する
手短なメッセージを送付しなければなりません。 また、control@bugs.debian.org
を利用する場合、 NMU を行なった当事者は NMU で修正したバグの重要度を `fixed'
に設定しなければなりません。 こうすることによって、そのバグが NMU
によって修正されたことを、 確実に皆に知らせることができるわけです。 ただ、NMU
で加えられた変更が、公式なパッケージ開発者によって正式に採用され
るまで、そのバグは開かれたままです。
また、その問題を修正するために必要となるパッチを添えてバグをオープンするか、
(すでにオープンされている)
他のバグ報告のいずれかにそのパッチを追加してください。
正規の開発者は、そのパッチを採用するか、 あるいはその問題を修正する他の方途を用いることになります。 時にはバグがアップストリームで独自に修正されることもあります。 このことは NMU によるパッチが退けられる十分な理由のひとつです。 新たなバージョンをリリースする際に、 正規の開発者が NMU によるパッチを採用しない場合、 その開発者はノンメンテナリリースで修正された問題のそれぞれが 新たなアップストリームバージョンで確実に修正されていること を保証しなければなりません。
さらに正規の開発者は、changelog ファイルのエントリに ノンメンテナアップロードに関する記述を 常に残すようにしておかなければなりません。
source NMU パッケージは、通常どおりに構築されます。 ディストリビューションの選択には、 ディストリビューションの選択, Section 6.2.2 で説明したものと同じルールが適用されます。 また パッケージをアップロードする, Section 6.2 で説明したとおり、 通常の changes ファイルなどが構築されます。 実際、パッケージのアップロード, 章 6 で説明したルールは、 適切なメーリングリストへの NMU のアナウンスの必要性も含めて すべて適用されます。
debian/control ファイルにある開発者の名前は、
変更しないように気をつけてください。
なお、debian/changelog ファイルの NMU エントリにある
あなたの名前は、changes ファイルに署名する際に用いられます。
aph@debian.orgschwarz@debian.orgijackson@gnu.ai.mit.edu