目次
この章では、パッケージの作成、アップロード、メンテナンス、移植についての情報を扱います。
もしあなたが 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 個以上)
を行っている場合、メーリングリストへ個別に通知するのは鬱陶しいので、代わりにバグを登録した後で要約を送信してください。これによって、他の開発者らに次に来るパッケージを知らせ、説明とパッケージ名のレビューが可能になります。
新規パッケージがアーカイブへインストールされる際にバグ報告を自動的に閉じるため、Closes:
#
というエントリを新規パッケージの changelog
内に含めてください (「新規アップロードでバグがクローズされる時」 を参照)。
nnnnn
パッケージについて、NEW パッケージキューの管理者への説明が必要だろうと思う場合は、changelog に説明を含めて
<ftpmaster@debian.org>
へ送ってください。アップロード後であればメンテナとして受け取ったメールに返信してください。もしくは既に再アップロードをの最中の場合は reject
のメールに対して返信してください。
セキュリティバグを閉じる場合は、CVE 番号を Closes:
#
と同じく含めるようにしてください。これは、セキュリティチームが脆弱性を追跡するのに役立ちます。アドバイザリの ID
が分かる前にバグ修正のためのアップロードが行われた場合は、以前の changelog
エントリを次のアップロード時に修正するのが推奨されています。このような場合でも、元々の changelog
での記載に可能な限り背景情報へのポインタを全て含めてください。
nnnnn
我々がメンテナに意図しているところをアナウンスする様に求めるのには、いくつもの理由があります。
(潜在的な新たな) メンテナが、メーリングリストの人々の経験を活かすのを手助けし、もし他の誰かが既に作業を行っていた場合に知らせる。
そのパッケージについて作業することを検討している他の人へ、既に作業をしているボランティアがいることを知らせ、労力が共有される。
<debian-devel-changes@lists.debian.org>
に流される一行の説明文 (description) と通常どおりの「Intial
release」という changelog エントリよりも、残った他のメンテナがパッケージに関してより深く知ることができる。
不安定版 (unstable)
で暮らす人 (そして最前線のテスターである人) の助けになる。
メンテナや他に興味を持つ人々へ、プロジェクトで何が行われているのか、何か新しいことがあるかということ関して、告知は良い印象を与える。
新しいパッケージに対する一般的な拒否理由については http://ftp-master.debian.org/REJECT-FAQ.html を参照してください。
パッケージについて行った変更は debian/changelog
に記録されなくてはいけません。これらの変更には、何が変更されたのか、(不確かであれば)
何故なのか、そしてどのバグが閉じられたのかの簡潔な説明文を付加する必要があります。このファイルは
/usr/share/doc/
、あるいは
native パッケージの場合は
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
」 を参照してください。
「Best practices for debian/changelog
」 も参照してください。
パッケージをアップロードする前に、基本的なテストをする必要があります。最低限、以下の作業が必要です (同じ Debian パッケージの古いバージョンなどが必要になるでしょう):
パッケージをインストールしてソフトウェアが動作するのを確認する、あるいは既にそのソフトの Debian パッケージが存在している場合、パッケージを以前のバージョンから新しいバージョンにアップグレードする。
パッケージに対して lintian を実行する。以下のようにして
lintian を実行できます: lintian -v
。lintian が生成した出力を理解していない場合は、lintian
が問題の説明を非常に冗長に出力するようにする package-version
.changes-i
オプションを付けて実行してみてください。
通常、lintian がエラーを出力するようであれば、パッケージをアップロードしてはいけません (エラーは
E
で始まります)。
lintian についての詳細は、「lintian
」 を参照してください。
もし古いバージョンがあれば、それからの変更点を分析するために追加で debdiff を実行する (「debdiff」 を参照) 。
(もしあれば) 以前のバージョンにダウングレードする — これは postrm
スクリプトと
prerm
スクリプトをテストします。
パッケージを削除して、再インストールする。
ソースパッケージを違うディレクトリにコピーして展開し、再構築する。これは、パッケージが外部の既存ファイルに依っているか、.diff.gz
ファイル内に含まれているファイルで保存されている権限に依るかどうかをテストします。
Debian のソースパッケージには 2 種類あります:
いわゆる native
パッケージ。元のソースと Debian で当てられたパッチの間に差が無いもの
オリジナルのソースコードの tarball ファイルに、Debian によって作成された変更点を含む別のファイルが付随している (より一般的な) パッケージ
native パッケージの場合、ソースパッケージは Debian のソース control ファイル
(.dsc
) とソースコードの tarball
(.tar.{gz,bz2,lzma}
) を含んでいます。native ではないパッケージのソースパッケージは
Debian のソース control ファイルと、オリジナルのソースコードの tarball
(.orig.tar.{gz,bz2,lzma}
)、そして Debian での変更点 (ソース形式“1.0”は
.diff.gz
、ソース形式“3.0 (quilt)”は
.debian.tar.{gz,bz2,lzma}
) を含んでいます。
ソース形式“1.0”では、パッケージが native かどうかはビルド時に dpkg-source
によって決められていました。最近では望むソース形式を debian/source/format
に“3.0
(quilt)”または“3.0 (native)”と記述することによって明示することが推奨されています。この章の残りの部分は native
ではないパッケージについてのみ記しています。
初回には、特定の開発元のバージョン (upstream version) に該当するバージョンがアップロードされます。元のソース tar
ファイルは、アップロードされて .changes
ファイルに含まれている必要があります。その後、新しい
diff ファイルや .dsc
ファイルの生成には全く同じ tar
ファイルを使わなければならず、これを再アップロードする必要はありません。
デフォルトでは、dpkg-genchanges および
dpkg-buildpackage は前述されている changelog エントリと現在のエントリが異なった
upstream バージョンを持つ場合にのみ、オリジナルのソース tar
ファイルを含めようとします。この挙動は、-sa
を使って常に含めたり、-sd
を使うことで常に含めないようにするように変更できます。
アップロード時にオリジナルのソースが含まれていない場合、アップロードされる .dsc
と diff
ファイルを構築する際に dpkg-source が使用するオリジナルの tar
ファイルは、必ず既にアーカイブにあるものと 1 バイトも違わぬものでなくてはなりません。
注意していただきたいのですが、native ではないパッケージでは、diff
はパッチ内のファイルパーミッションを保存しないので、*.orig.tar.{gz,bz2,lzma}
内に存在しないファイルのパーミッションは保持されません。しかし、ソース形式“3.0
(quilt)”を使っている場合、debian
ディレクトリ内にあるファイルのパーミッションは tar
アーカイブで保存されるのでそのままになります。
アップロードでは、パッケージがどのディストリビューション向けになっているかを指定してあることが必要です。パッケージの構築プロセスでは、debian/changelog
ファイルの最初の行からこの情報を展開し、.changes
ファイルの
Distribution
欄に配置します。
この欄にはいくつか指定可能な値があります:
stable
、unstable
、testing-proposed-updates
、そして
experimental
です。通常、パッケージは unstable
にアップロードされます。
実際には、他に二つ指定可能なディストリビューションがあります: stable-security
と
testing-security
ですが、これらについての詳細は 「セキュリティ関連バグの取扱い」 を読んでください。
同時に複数のディストリビューションへパッケージをアップロードすることはできません。
安定版 (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/control
ファイルの セクション (Section)
フィールドと 優先度 (Priority)
フィールドは実際にアーカイブ内でどこに配置されるか、あるいはプライオリティが何かという指定ではありません。debian/control
ファイル中の値は、実際のところは単なるヒントです。
アーカイブメンテナは、override
ファイル
内でパッケージについて定められたセクションと優先度を常に確認しています。override
ファイル
と debian/control
で指定されたパッケージのフィールドに不一致がある場合、パッケージがアーカイブにインストールされる際に相違について記述されたメールを受け取ります。debian/control
ファイルを次回のアップロード時に修正することもできますし、override
ファイル
に変更を加えるように依頼するのもよいでしょう。
パッケージが現状で置かれているセクションを変更するには、まずパッケージの debian/control
ファイルが正しいことを確認する必要があります。次に、ftp.debian.org
に対し、あなたのパッケージに対するセクションあるいは優先度について古いものから新しいものへ変更する依頼のバグ登録をします。override:
PACKAGE1:section/priority, [...], PACKAGEX:section/priority
のようなサブジェクトを使い、バグ報告の本文に変更に関する根拠を記述してください。
override ファイル
についての詳細は、dpkg-scanpackages(1) と http://www.debian.org/Bugs/Developer#maintincorrect
を参照してください。
「セクション」 で書かれているように、セクション
(Section)
フィールドにはセクション同様にサブセクションも記述するのに注意ください。セクションが main
の場合は、それは書かないようにしてください。利用可能なサブセクションは http://www.debian.org/doc/debian-policy/ch-archive.html#s-subsections で検索できます。
すべての開発者は Debian バグ追跡システムを取り扱えるようでなければいけません。これはどの様にしてバグ報告を正しく登録するか (「バグ報告」 参照)、どの様に更新及び整理するか、そしてどの様にして処理をして完了するかを知っていることを含みます。
バグ追跡システムの機能は Debian BTS 開発者向け情報に記載されています。これには、バグの完了処理・追加メッセージの送信・重要度とタグを割り当てる・バグを転送済み (Forwarded) にする・その他が含まれています。
バグを他のパッケージに割り当てし直す、同じ問題についての別々のバグ報告をマージする、などの作業はいわゆる制御メールサーバと呼ばれるものを使って処理されています。このサーバで利用可能なすべてのコマンドは、BTS 制御サーバドキュメントに記載されています。
良いメンテナになりたい場合は、あなたのパッケージに関する 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 開発者から集められた経験を元にしたバグの扱い方のガイドラインを含んでいます。
他のパッケージで見つけた問題についてバグを登録するのは、メンテナとしての責務の一つです。詳細については 「バグ報告」 を参照してください。しかし、自分のパッケージのバグを管理するのはさらに重要です。
以下がバグ報告を取り扱う手順です:
報告が実際にバグに関連するものか否かを決めてください。ユーザはドキュメントを読んでいないため、誤ったプログラムの使い方をしているだけのことが時々あります。このように判断した場合は、ユーザに問題を修正するのに十分な情報を与えて (良いドキュメントへのポインタを教えるなどして) バグを閉じます。同じ報告が何度も繰り返し来る場合には、ドキュメントが十分なものかどうか、あるいは有益なエラーメッセージを与えるよう、誤った使い方を検知していないのでは、と自身に問い直してください。これは開発元の作者に伝える必要がある問題かもしれません。
バグを閉じるという貴方の判断にバグ報告者らが同意しない場合には、それをどう取り扱うかについての同意が見つかるまで、彼らは再度オープンな状態
(reopen) にするでしょう。そのバグについてもう議論することが無いという場合は、バグは存在するが修正することはないと知らせるため、バグに対して
wontfix
タグを付けることになります。この決定が受け入れがたい時には、あなた (あるいは報告者) はバグを
tech-ctte
に再指定 (reassign) して技術委員会
(technical committee) の判断を仰いでください (パッケージへ報告されたものをそのままにしておきたい場合は、BTS の clone
コマンドを使ってください)。これを行う前には推奨手順を読んでおいてください。
バグが実際にあるが、他のパッケージによって引き起こされている場合は、バグを正しいパッケージに再指定 (reassign)
します。どのパッケージに再指定するべきかが分からない場合は、IRC か
<debian-devel@lists.debian.org>
で聞いてください。再指定するパッケージのメンテナに通知をしてください。例えば
<
宛にメッセージを Cc:
してメール中に理由を説明するなどします。単に再指定しただけでは再指定された先のメンテナにはメールは送信されませんので、彼らがパッケージのバグ一覧を見るまでそれを知ることはありません。
packagename
@packages.debian.org>
バグがあなたのパッケージの動作に影響する場合は、バグを複製し (clone)、複製したバグをその挙動を実際に起こしているパッケージに再指定することを検討してください。さもなければ、あなたのパッケージのバグ一覧にバグが見つからないので、多分ユーザに同じバグを何度も繰り返し報告される羽目になる可能性があります。あなたは、再指定 (reassign) によって「自分の」バグということを防ぎ、バグの複製 (clone) によって関係があることを記載しておく必要があります。
時々、重要度の定義に合うようにバグの重要度を調整する必要もあります。これは、人々はバグ修正を確実に早くしてもらうために重要度を極端に上げようとするからです。要望された変更点が単に体裁的なものな時には、バグは要望 (wishlist) に格下げされるでしょう。
バグが確かにあるが既に他の誰かによって同じ問題が報告されている場合は、2 つの関連したバグを BTS の merge コマンドを使って 1 つにマージします。このようにすると、バグが修正された時に全ての投稿者に通知がいきます (ですが、そのバグ報告の投稿者へのメールは報告の他の投稿者には自動的には通知されないことに注意してください)。merge コマンドや類似の unmerge コマンドの技術詳細については、BTS 制御サーバドキュメントを参照してください。
バグ報告者は情報を書き漏らしている場合、必要な情報を尋ねる必要があります。その様なバグに印をつけるには
moreinfo
タグを使います。さらに、そのバグを再現できない場合には、unreproducible
タグを付けます。誰もそのバグを再現できない場合、どうやって再現するのか、さらに情報を何ヶ月経っても、この情報が誰からも送られてこない場合はバグは閉じても構いません。
バグがパッケージに起因する場合、さっさと直します。自分では直せない場合は、バグに help
タグを付けます。<debian-devel@lists.debian.org>
や <debian-qa@lists.debian.org>
で助けを求めることも出来ます。開発元
(upstream)
の問題であれば、作者に転送する必要があります。バグを転送するだけでは十分ではありません。リリースごとにバグが修正されているかどうかを確認しなければいけません。もし修正されていれば、それを閉じ、そうでなければ作者に確認を取る必要があります。必要な技能を持っていてバグを修正するパッチが用意できる場合は、同時に作者に送りましょう。パッチを
BTS に送付してバグに patch
タグを付けるのを忘れないでください。
ローカル環境でバグを修正した、あるいは VCS リポジトリに修正をコミットした場合には、バグに pending
タグを付けてバグが修正されたことと次のアップロードでバグが閉じられるであろうことを回りに知らせます
(changelog
に closes:
を追加します)。これは複数の開発者が同一のパッケージで作業している際に特に役立ちます。
一旦修正されたパッケージがアーカイブから入手可能になったら、バグはどのバージョンで修正されたかを指定して閉じられる必要があります。これは自動的に行われます。「新規アップロードでバグがクローズされる時」 を読んでください。
バグや問題があなたのパッケージで修正されたとしたら、そのバグを閉じるのはパッケージメンテナとしての責任になります。しかし、バグを修正したパッケージが 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
を使ったバグの閉じ方は必須ではない、ということは念頭に置いておいてください。行ったアップロードとは無関係に単にバグを閉じたい、という場合は、説明をメールに書いて
<
に送ってバグを閉じてください。そのバージョンのパッケージでの変更がバグに何も関係ない場合は、そのバージョンの changelog
エントリではバグを閉じないでください。
XXX
-done@bugs.debian.org>
どのように changelog のエントリを書くのか、一般的な情報については 「Best practices for debian/changelog
」 を参照してください。
機密性が高いその性質上、セキュリティ関連のバグは注意深く取り扱わねばなりません。この作業をコーディネイトし、未処理のセキュリティ問題を追い続け、セキュリティ問題についてメンテナを手助けしたり修正自体を行い、セキュリティ勧告を出し、security.debian.org
を維持するために Debian セキュリティチームが存在します。
Debian
パッケージ中のセキュリティ関連のバグに気づいたら、あなたがメンテナであるかどうかに関わらず、問題に関する正確な情報を集めて、まずは可能な限り早く
<team@security.debian.org>
宛でセキュリティチームに連絡を取ってください。チームに問い合わせること無く 安定版
(stable)
向けのパッケージをアップロードしないでください。例えば、役に立つ情報は以下を含んでいます:
バグによって、どのバージョンが影響を受けると分かっているか。サポートされている Debian のリリース、ならびに テスト版
(testing)
及び 不安定版 (unstable)
にある各バージョンをチェックしてください。
利用可能なものがあれば、修正内容 (パッチが特に望ましい)
自身で準備した修正パッケージ (まずは 「セキュリティ問題に対処するパッケージを用意する」
を読んで、.diff.gz
と .dsc
ファイルだけを送ってください)
テストについて何かしらの手助けになるもの (攻撃コード、リグレッションテストなど)
勧告に必要になる情報 (「セキュリティ勧告」 参照)
パッケージメンテナとして、あなたは安定版リリースについてもメンテナンスする責任を持ちます。あなたがパッチの評価と更新パッケージのテストを行うのに最も適任な人です。ですから、以下のセキュリティチームによって取り扱ってもらうため、どのようにしてパッケージを用意するかについての章を参照してください。
セキュリティチームは集約的なデータベース、Debian セキュリティ追跡システムをメンテナンスしています。これはセキュリティ問題として知られている全ての公開情報を含んでいます: どのパッケージ/バージョンが影響を受ける/修正されているか、つまりは安定版、テスト版、不安定版が脆弱かどうか、という情報です。まだ機密扱いの情報は追跡システムには追加されません。
特定の問題について検索することもできますし、パッケージ名でも検索できます。あなたのパッケージを探して、どの問題がまだ未解決かを確認してください。できれば追加情報を提供するか、パッケージの問題に対処するのを手伝ってください。やり方は追跡システムのウェブページにあります。
Debian 内での他の多くの活動とは違い、セキュリティ問題に関する情報については、暫くの間秘密にしておく必要がしばしばあります。これによって、ソフトウェアのディストリビュータがユーザが危険にさらされるのを最小限にするため、公開時期を合わせることができます。今回がそうであるかは、問題と対応する修正の性質や、既に既知のものとなっているかどうかによります。
開発者がセキュリティ問題を知る方法はいくつかあります:
公開フォーラム (メーリングリスト、ウェブサイトなど) で知らせる
誰かがバグ報告を登録している
誰かがプライベートなメールで教えてきた
最初の二つのケースでは、情報は公開されていて可能な限り早く修正することが重要です。しかしながら最後のケースは、公開情報ではないかもしれません。この場合は、問題に対処するのに幾つか取り得る選択肢があります:
セキュリティの影響度が小さい場合、問題を秘密にしておく必要はなく、修正を行ってリリースするのが良い場合がしばしばあります。
問題が深刻な場合、他のベンダと情報を共有してリリースをコーディネイトする方が望ましいでしょう。セキュリティチームは様々な組織/個人と連絡を取りつづけ、この問題に対応することができます。
どのような場合でも、問題を報告した人がこれを公開しないように求めているのであれば、明白な例外として Debian の安定版リリースに対する修正を作成してもらうためにセキュリティチームへ連絡すること以外、この様な要求は尊重されるべきです。機密情報をセキュリティチームに送る場合は、この点を明示しておくのを忘れないでください。
機密を要する場合は、修正を不安定版 (unstable)
(や公開 VCS リポジトリなどその他どこへも)
へ修正をアップロードしないよう、注意してください。コードその物が公開されている場合、変更の詳細を難読化するだけでは十分ではなく、皆によって解析され得る
(そしてされる) でしょう。
機密であることを要求されたにも関わらず、情報を公開するのには 2 つの理由があります: 問題が一定期間既知の状態になっている、あるいは問題や攻撃コードが公開された場合です。
セキュリティチームは、機密事項に関して通信を暗号化できる PGP 鍵を持っています。詳細については、セキュリティチーム FAQ を参照してください。
セキュリティ勧告は現在のところ、リリースされた安定版ディストリビューションについてのみ、取り扱われます。テスト版
(testing)
や 不安定版 (unstable)
についてではありません。リリースされると、セキュリティ勧告は
email-debian-security-announce; メーリングリストに送られ、セキュリティのウェブページに掲載されます。セキュリティ勧告はセキュリティチームによって記述、掲載されます。しかし、メンテナが情報を提供できたり、文章の一部を書けるのであれば、彼らは当然そんなことは気にしません。勧告にあるべき情報は以下を含んでいます:
以下のようなものを含めた問題の説明と範囲:
問題の種類 (権限の上昇、サービス拒否など)
何の権限が得られるのか、(もし分かれば) 誰が得るのか
どのようにして攻撃が可能なのか
攻撃はリモートから可能なのかそれともローカルから可能なのか
どのようにして問題が修正されたのか
この情報によって、ユーザがシステムに対する脅威を評価できるようになります。
影響を受けるパッケージのバージョン番号
修正されたパッケージのバージョン番号
どこで更新されたパッケージを得るかという情報 (通常は Debian のセキュリティアーカイブからです)
開発元のアドバイザリへの参照、CVE 番号、脆弱性の相互参照について役立つその他の情報
あなたがセキュリティチームに対し、彼らの職務に関して手助けできる方法の一つは、安定版 Debian リリース用のセキュリティ勧告に適した修正版パッケージを提供することです。
安定版について更新が作成される際、システムの挙動の変化や新しいバグの導入を避けるように注意が必要です。これを行うため、バグを修正するための変更は可能な限り少なくします。ユーザや管理者は一旦リリースされたものの厳密な挙動を当てにしている、どのような変更でも誰かのシステムを壊しかねません。これは特にライブラリについて当てはまります: API や ABI を決して変更していないことを確認してください。変更がどれほど小さいものでも関係ありません。
これは、開発元の新しいリリースバージョン (new upstream version) への移行が良い解決策ではないことを意味しています。代わりに、関連する変更を現在の Debian 安定版リリースに存在しているバージョンへバックポートするべきです。通常、開発元のメンテナは助けが必要であれば手伝おうとしてくれます。そうでない場合は、Debian セキュリティチームが手助けすることができます。
いくつかのケースでは、例えば大量のソースコードの変更や書き直しが必要など、セキュリティ修正をバックポートできないことがあります。この様な場合、新しいバージョン (new upstream version) へ移行する必要があるかもしれません。しかし、これは極端な状況の場合にのみ行われるものであり、実行する前に必ずセキュリティチームと調整をしなければなりません。
これに関してはもう一つ重要な指針があります: 必ず変更についてテストをしてください。攻撃用コード (exploit) が入手可能な場合には、それを試してみて、パッチを当てていないパッケージで成功するか、修正したパッケージでは失敗することかどうかを確かめてみてください。他の確認として、セキュリティ修正は時折表面上はそれと関係が無いような機能を壊すことがあるので、通常の動作も同様にテストしてください。
脆弱性の修正に直接関係しない変更をパッケージへ加えないようにしてください。この様な変更は元に戻さなくてはならなくなるだけで、時間を無駄にします。他に直したいバグがパッケージにある場合は、セキュリティ勧告が発行された後、通常通りに proposed-update にアップロードを行ってください。セキュリティ更新の仕組みは、それ以外の方法では安定版リリースから reject されるであろう変更をあなたのパッケージに加える方法ではありませんので、この様な事はしないでください。
変更点を可能な限り見直してください。以前のバージョンとの変更点を繰り返し確認してください (これには patchutils
パッケージの interdiff や
devscripts
の
debdiff が役立ちます。「debdiff」 を参照してください)。
以下の項目を必ず確認してください
debian/changelog
で 正しいディストリビューションを対象にする。安定版
(stable)
の場合、これは stable-security
になり、テスト版 (testing)
の場合は
testing-security
に、そして以前の安定版リリースへの場合は
oldstable-security
となります。distribution
-proposed-updates
や stable
を対象にしないでください!
アップロードは urgency=high で行う必要があります。
説明が十分にされている、意味がある changelog
エントリを書くこと。他の人は、これらを元に特定のバグが修正されているのかを見つけ出します。登録されている Debian バグ に対して closes:
行を追加すること。外部のリファレンス、できれば CVE 識別番号
を常に含めること、そうすれば相互参照が可能になります。しかし、CVE
識別番号がまだ付与されていない場合には、それを待たずに作業を進めてください。識別番号は後ほど付与することができます。
バージョン番号が正しいことを確認する。現在のパッケージより大きく、しかし以降のディストリビューションよりパッケージバージョンが小さい必要があります。分からない場合は
dpkg --compare-versions
でテストしてください。以前のアップロードで既に使っているバージョン番号を再利用しないように注意してください。そうしないと番号が binNMU
と衝突します。+
codename
1
を追加するのが通例です。例えば 1:2.4.3-4+lenny1
とします。もちろん 1
はアップロードするごとに増やします。
これまでに (以前のセキュリティ更新によって) security.debian.org
へ開発元のソースコードをアップロードしていなければ、開発元のソースコードを全て含めてアップロードするパッケージをビルドする
(dpkg-buildpackage -sa
)。以前、同じ開発元のバージョンで
security.debian.org
にアップロードしたことがある場合は、開発元のソースコード無しでアップロードしても構いません (dpkg-buildpackage
-sd
)。
通常のアーカイブで使われているのと全く同じ
*.orig.tar.{gz,bz2,lzma}
を必ず使うようにしてください。さもなくば、後ほどセキュリティ習性を
main アーカイブに移動することができません。
ビルドを行っているディストリビューションからインストールしたパッケージだけが含まれているクリーンなシステム上でパッケージをビルドしてください。その様なシステムを自分で持っていない場合は、debian.org
マシン (「Debian のマシン群」 を参照してください) を使うこともできますし、chroot
を設定することもできます (「pbuilder
」 と 「debootstrap
」
を参照してください)。
セキュリティアップロードキュー
(oldstable-security
、stable-security
等) には、セキュリティチームからの事前許可無しにパッケージをアップロードしないでください。パッケージがチームの要求に完全に合致していない場合、望まれないアップロードに対処するために多くの問題が引き起こされたり遅延が生じることになります。詳細については
「セキュリティ関連バグの取扱い」 を参照してください。
セキュリティチームと調整する事無しに proposed-updates
へ修正したものをアップロードしないようにしてください。security.debian.org
からパッケージは proposed-updates
ディレクトリに自動的にコピーされます。アーカイブに同じ、あるいはより高いバージョン番号のものが既にインストールされている場合は、セキュリティアップデートはアーカイブシステムに
reject されます。そうすると、安定版ディストリビューションはこのパッケージに対するセキュリティ更新無しで終了してしまうでしょう。
一旦、新しいパッケージを作成してテストし、セキュリティチームによって許可を受けたら、アーカイブへインストールできるようにするためにアップロードをする必要があります。セキュリティに関するアップロードの場合、アップロード先は
ftp://security-master.debian.org/pub/SecurityUploadQueue/
になります。
セキュリティキューへアップロードしたものが許可されると、パッケージは自動的にすべてのアーキテクチャに対してビルドされ、セキュリティチームによる確認の為に保存されます。
許可、あるいは確認を待っているアップロードには、セキュリティチームのみがアクセスできます。これは、まだ公開できないセキュリティ問題の修正があるかも知れないためです。
セキュリティチームのメンバーがパッケージを許可した場合は、proposed パッケージに対する
ftp-master.debian.org
上の適切な
distribution
-proposed-updates
と同様に security.debian.org
上にインストールされます。
アーカイブの変更作業のいくつかは、Debian のアップロードプロセスでは自動的なものにはなっていません。これらの手続きはメンテナによる手動での作業である必要があります。この章では、この様な場合に何をするかのガイドラインを提供します。
時折パッケージは属しているセクションが変わることがあります。例えば「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
, the program will show
details for package
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
.
以前は、incoming
からパッケージを削除することが可能でした。しかし、新しい incoming
システムが導入されたことにより、これはもはや不可能となっています。その代わりに、置き換えたいパッケージよりも高いバージョンのリビジョンの新しいパッケージをアップロードする必要があります。両方のバージョンのパッケージがアーカイブにインストールされますが、一つ前のバージョンはすぐに高いバージョンで置き換えられるため、実際にはバージョンが高い方だけが
不安定版 (unstable)
で利用可能になります。しかし、もしあなたがパッケージをきちんとテストしていれば、パッケージを置き換える必要はそんなに頻繁には無いはずです。
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:
indicating that the package is now
orphaned. The severity of the bug should be set to
package
-- short
description
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.
Debian がサポートするアーキテクチャの数は増え続けています。あなたが移植作業者ではない、あるいは別のアーキテクチャを使うことが無いという場合であっても、移植性の問題に注意を払うことはメンテナとしてのあなたの義務です。従って、あなたが移植作業者でなくても、この章の大半を読む必要があります。
Porting is the act of building Debian packages for architectures that are
different from the original architecture of the package maintainer's binary
package. It is a unique and essential activity. In fact, porters do most
of the actual compiling of Debian packages. For instance, when a maintainer
uploads a (portable) source packages with binaries for the
i386
architecture, it will be built for each of the other
architectures, amounting to 12 more builds.
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.
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 ポリシーマニュアルを参照してください。
意図がある場合以外は、アーキテクチャの値を all
または any
以外に指定しないでください。非常に多くの場合、メンテナが Debianポリシーマニュアル
の指示に従っていません。アーキテクチャを単一のものに指定する (i386
あるいは
amd64
など) は大抵誤りです。
Make sure your source package is correct. Do dpkg-source -x
to make sure your source
package unpacks properly. Then, in there, try building your package from
scratch with dpkg-buildpackage.
package
.dsc
Make sure you don't ship your source package with the
debian/files
or debian/substvars
files. They should be removed by the clean
target of
debian/rules
.
Make sure you don't rely on locally installed or hacked configurations or
programs. For instance, you should never be calling programs in
/usr/local/bin
or the like. Try not to rely on
programs being setup in a special way. Try building your package on another
machine, even if it's the same architecture.
Don't depend on the package you're building being installed already (a sub-case of the above issue). There are, of course, exceptions to this rule, but be aware that any case like this needs manual bootstrapping and cannot be done by automated package builders.
Don't rely on the compiler being a certain version, if possible. If not, then make sure your build dependencies reflect the restrictions, although you are probably asking for trouble, since different architectures sometimes standardize on different compilers.
Make sure your debian/rules
contains separate
binary-arch
and binary-indep
targets,
as the Debian Policy Manual requires. Make sure that both targets work
independently, that is, that you can call the target without having called
the other before. To test this, try to run dpkg-buildpackage
-B.
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
-m
. Of course, set
porter-email
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.
Sometimes the initial porter upload is problematic because the environment in which the package was built was not good enough (outdated or obsolete library, bad compiler, etc.). Then you may just need to recompile it in an updated environment. However, you have to bump the version number in this case, so that the old bad package can be replaced in the Debian archive (dak refuses to install new packages if they don't have a version number greater than the currently available one).
You have to make sure that your binary-only NMU doesn't render the package
uninstallable. This could happen when a source package generates
arch-dependent and arch-independent packages that have inter-dependencies
generated using dpkg's substitution variable
$(Source-Version)
.
Despite the required modification of the changelog, these are called binary-only NMUs — there is no need in this case to trigger all other architectures to consider themselves out of date or requiring recompilation.
Such recompilations require special ``magic'' version numbering, so that the archive maintenance tools recognize that, even though there is a new Debian version, there is no corresponding source update. If you get this wrong, the archive maintainers will reject your upload (due to lack of corresponding source code).
The ``magic'' for a recompilation-only NMU is triggered by using a suffix
appended to the package version number, following the form
b
. For instance, if the
latest version you are recompiling against was version
number
2.9-3
, your binary-only NMU should carry a version of
2.9-3+b1
. If the latest version was
3.4+b1
(i.e, a native package with a previous
recompilation NMU), your binary-only NMU should have a version number of
3.4+b2
.[4]
Similar to initial porter uploads, the correct way of invoking
dpkg-buildpackage is dpkg-buildpackage
-B
to only build the architecture-dependent parts of the package.
Porters doing a source NMU generally follow the guidelines found in 「Non-Maintainer Upload (NMU)」, just like non-porters. However, it is expected that the wait cycle for a porter's source NMU is smaller than for a non-porter, since porters have to cope with a large quantity of packages. Again, the situation varies depending on the distribution they are uploading to. It also varies whether the architecture is a candidate for inclusion into the next stable release; the release managers decide and announce which architectures are candidates.
If you are a porter doing an NMU for unstable
, the above
guidelines for porting should be followed, with two variations. Firstly,
the acceptable waiting period — the time between when the bug is submitted
to the BTS and when it is OK to do an NMU — is seven days for porters
working on the unstable
distribution. This period can be
shortened if the problem is critical and imposes hardship on the porting
effort, at the discretion of the porter group. (Remember, none of this is
Policy, just mutually agreed upon guidelines.) For uploads to
stable
or testing
, please coordinate
with the appropriate release team first.
Secondly, porters doing source NMUs should make sure that the bug they
submit to the BTS should be of severity serious
or
greater. This ensures that a single source package can be used to compile
every supported Debian architecture by release time. It is very important
that we have one version of the binary and source package for all
architectures in order to comply with many licenses.
Porters should try to avoid patches which simply kludge around bugs in the
current version of the compile environment, kernel, or libc. Sometimes such
kludges can't be helped. If you have to kludge around compiler bugs and the
like, make sure you #ifdef
your work properly; also,
document your kludge so that people know to remove it once the external
problems have been fixed.
Porters may also have an unofficial location where they can put the results of their work during the waiting period. This helps others running the port have the benefit of the porter's work, even during the waiting period. Of course, such locations have no official blessing or status, so buyer beware.
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.
各移植版についての状況を含んだウェブページは http://www.debian.org/ports/ から参照できます。
Debian の各移植版はメーリングリストを持っています。移植作業のメーリングリストは http://lists.debian.org/ports.html で見ることができます。これらのリストは移植作業者の作業の調整や移植版のユーザと移植作業者をつなぐために使われています。
移植用のツールの説明をいくつか 「移植用ツール」 で見ることができます。
The wanna-build
system is used as a
distributed, client-server build distribution system. It is usually used in
conjunction with build daemons running the buildd
program. Build daemons
are ``slave'' hosts which contact the central wanna-build
system to receive a list of packages
that need to be built.
wanna-build
is not yet available as
a package; however, all Debian porting efforts are using it for automated
package building. The tool used to do the actual package builds,
sbuild
is available as a package,
see its description in 「sbuild
」. Please note that the
packaged version is not the same as the one used on build daemons, but it is
close enough to reproduce problems.
Most of the data produced by wanna-build
which is generally useful to porters
is available on the web at http://buildd.debian.org/. This data
includes nightly updated statistics, queueing information and logs for build
attempts.
We are quite proud of this system, since it has so many possible uses. Independent development groups can use the system for different sub-flavors of Debian, which may or may not really be of general interest (for instance, a flavor of Debian built with gcc bounds checking). It will also enable Debian to recompile entire distributions quickly.
The wanna-build team, in charge of the buildds, can be reached at
debian-wb-team@lists.debian.org
. To determine who
(wanna-build team, release team) and how (mail, BTS) to contact, refer to
http://lists.debian.org/debian-project/2009/03/msg00096.html.
When requesting binNMUs or give-backs (retries after a failed build), please use the format described at http://release.debian.org/wanna-build.txt.
Some packages still have issues with building and/or working on some of the
architectures supported by Debian, and cannot be ported at all, or not
within a reasonable amount of time. An example is a package that is
SVGA-specific (only available for i386
and
amd64
), or uses other hardware-specific features not
supported on all architectures.
In order to prevent broken packages from being uploaded to the archive, and wasting buildd time, you need to do a few things:
First, make sure your package does fail to build on architectures that it cannot support. There are a few ways to achieve this. The preferred way is to have a small testsuite during build time that will test the functionality, and fail if it doesn't work. This is a good idea anyway, as this will prevent (some) broken uploads on all architectures, and also will allow the package to build as soon as the required functionality is available.
Additionally, if you believe the list of supported architectures is pretty
constant, you should change any
to a list of supported
architectures in debian/control
. This way, the build
will fail also, and indicate this to a human reader without actually trying.
In order to prevent autobuilders from needlessly trying to build your
package, it must be included in Packages-arch-specific
,
a list used by the wanna-build script. The current
version is available as http://buildd.debian.org/quinn-diff/Packages-arch-specific; please see the
top of the file for whom to contact for changes.
Please note that it is insufficient to only add your package to
Packages-arch-specific
without making it fail to build
on unsupported architectures: A porter or any other person trying to build
your package might accidently upload it without noticing it doesn't work.
If in the past some binary packages were uploaded on unsupported
architectures, request their removal by filing a bug against ftp.debian.org
.
Every package has one or more maintainers. Normally, these are the people who work on and upload new versions of the package. In some situations, it is useful that other developers can upload a new version as well, for example if they want to fix a bug in a package they don't maintain, when the maintainer needs help to respond to issues. Such uploads are called Non-Maintainer Uploads (NMU).
NMU を行う前に、以下の質問について考えてください:
Does your NMU really fix bugs? Fixing cosmetic issues or changing the packaging style in NMUs is discouraged.
Did you give enough time to the maintainer? When was the bug reported to the BTS? Being busy for a week or two isn't unusual. Is the bug so severe that it needs to be fixed right now, or can it wait a few more days?
How confident are you about your changes? Please remember the Hippocratic Oath: "Above all, do no harm." It is better to leave a package with an open grave bug than applying a non-functional patch, or one that hides the bug instead of resolving it. If you are not 100% sure of what you did, it might be a good idea to seek advice from others. Remember that if you break something in your NMU, many people will be very unhappy about it.
Have you clearly expressed your intention to NMU, at least in the BTS? It is also a good idea to try to contact the maintainer by other means (private email, IRC).
If the maintainer is usually active and responsive, have you tried to contact him? In general it should be considered preferable that a maintainer takes care of an issue himself and that he is given the chance to review and correct your patch, because he can be expected to be more aware of potential issues which an NMUer might miss. It is often a better use of everyone's time if the maintainer is given an opportunity to upload a fix on their own.
When doing an NMU, you must first make sure that your intention to NMU is
clear. Then, you must send a patch with the differences between the current
package and your proposed NMU to the BTS. The nmudiff
script in the devscripts
package
might be helpful.
While preparing the patch, you should better be aware of any
package-specific practices that the maintainer might be using. Taking them
into account reduces the burden of getting your changes integrated back in
the normal package workflow and thus increases the possibilities that that
will happen. A good place where to look for for possible package-specific
practices is debian/README.source
.
Unless you have an excellent reason not to do so, you must then give some
time to the maintainer to react (for example, by uploading to the
DELAYED
queue). Here are some recommended values to use
for delays:
7 日以上経っているリリースクリティカルバグのみを修正するアップロード: 2 日
リリースクリティカルバグや重要なバグの修正のみのアップロード: 5 日
他の NMU: 10 日
Those delays are only examples. In some cases, such as uploads fixing
security issues, or fixes for trivial bugs that blocking a transition, it is
desirable that the fixed package reaches unstable
sooner.
Sometimes, release managers decide to allow NMUs with shorter delays for a subset of bugs (e.g release-critical bugs older than 7 days). Also, some maintainers list themselves in the Low Threshold NMU list, and accept that NMUs are uploaded without delay. But even in those cases, it's still a good idea to give the maintainer a few days to react before you upload, especially if the patch wasn't available in the BTS before, or if you know that the maintainer is generally active.
After you upload an NMU, you are responsible for the possible problems that you might have introduced. You must keep an eye on the package (subscribing to the package on the PTS is a good way to achieve this).
This is not a license to perform NMUs thoughtlessly. If you NMU when it is clear that the maintainers are active and would have acknowledged a patch in a timely manner, or if you ignore the recommendations of this document, your upload might be a cause of conflict with the maintainer. You should always be prepared to defend the wisdom of any NMU you perform on its own merits.
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
+nmu
, where
X
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
+deb
should be used, where XY
uZ
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.
Collaborative maintenance is a term describing the sharing of Debian package
maintenance duties by several people. This collaboration is almost always a
good idea, since it generally results in higher quality and faster bug fix
turnaround times. It is strongly recommended that packages with a priority
of standard
or which are part of the base set have
co-maintainers.
Generally there is a primary maintainer and one or more co-maintainers. The
primary maintainer is the person whose name is listed in the
Maintainer
field of the
debian/control
file. Co-maintainers are all the other
maintainers, usually listed in the Uploaders
field of the
debian/control
file.
In its most basic form, the process of adding a new co-maintainer is quite easy:
Setup the co-maintainer with access to the sources you build the package
from. Generally this implies you are using a network-capable version
control system, such as CVS
or
Subversion
. Alioth (see 「Debian での FusionForge の導入例: Alioth」)
provides such tools, amongst others.
Add the co-maintainer's correct maintainer name and address to the
Uploaders
field in the first paragraph of the
debian/control
file.
Uploaders: John Buzz <jbuzz@debian.org>, Adam Rex <arex@debian.org>
Using the PTS (「パッケージ追跡システム」), the co-maintainers should subscribe themselves to the appropriate source package.
Another form of collaborative maintenance is team maintenance, which is
recommended if you maintain several packages with the same group of
developers. In that case, the Maintainer
and
Uploaders
field of each package must be managed with
care. It is recommended to choose between one of the two following schemes:
Put the team member mainly responsible for the package in the
Maintainer
field. In the Uploaders
,
put the mailing list address, and the team members who care for the package.
Put the mailing list address in the Maintainer
field. In
the Uploaders
field, put the team members who care for
the package. In this case, you must make sure the mailing list accept bug
reports without any human interaction (like moderation for non-subscribers).
In any case, it is a bad idea to automatically put all team members in the
Uploaders
field. It clutters the Developer's Package
Overview listing (see 「Developer's packages overview」) with packages one doesn't
really care for, and creates a false sense of good maintenance. For the same
reason, team members do not need to add themselves to the
Uploaders
field just because they are uploading the
package once, they can do a “Team upload” (see 「NMU vs チームアップロード」). Conversely, it is a bad idea to keep a package
with only the mailing list address as a Maintainer
and no
Uploaders
.
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:
The package must have been available in unstable
for 2, 5
or 10 days, depending on the urgency (high, medium or low). Please note
that the urgency is sticky, meaning that the highest urgency uploaded since
the previous testing
transition is taken into account.
Those delays may be doubled during a freeze, or testing
transitions may be switched off altogether;
It must not have new release-critical bugs (RC bugs affecting the version
available in unstable
, but not affecting the version in
testing
);
It must be available on all architectures on which it has previously been
built in unstable
. dak ls
may be of interest to check that information;
It must not break any dependency of a package which is already available in
testing
;
The packages on which it depends must either be available in
testing
or they must be accepted into
testing
at the same time (and they will be if they
fulfill all the necessary criteria).
To find out whether a package is progressing into testing
or not, see the testing
script output on the web page of the testing distribution, or
use the program grep-excuses which is in the devscripts
package. This utility can easily be
used in a crontab(5) to keep yourself informed of the
progression of your packages into testing
.
The update_excuses
file does not always give the
precise reason why the package is refused; you may have to find it on your
own by looking for what would break with the inclusion of the package. The
testing web page gives some more
information about the usual problems which may be causing such troubles.
Sometimes, some packages never enter testing
because the
set of inter-relationship is too complicated and cannot be sorted out by the
scripts. See below for details.
Some further dependency analysis is shown on http://release.debian.org/migration/ — but be warned, this page also shows build dependencies which are not considered by britney.
For the testing
migration script, outdated means: There
are different versions in unstable
for the release
architectures (except for the architectures in fuckedarches; fuckedarches is
a list of architectures that don't keep up (in
update_out.py
), but currently, it's empty). outdated
has nothing whatsoever to do with the architectures this package has in
testing
.
Consider this example:
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
.
However, if ftp-master removes a package in unstable
(here on arm
):
alpha | arm | hurd-i386 | |
---|---|---|---|
テスト版 | 1 | 1 | - |
不安定版 | 2 | - | 1 |
In this case, the package is up to date on all release architectures in
unstable
(and the extra hurd-i386
doesn't matter, as it's not a release architecture).
Sometimes, the question is raised if it is possible to allow packages in that are not yet built on all architectures: No. Just plainly no. (Except if you maintain glibc or so.)
Sometimes, a package is removed to allow another package in: This happens
only to allow another package to go in if it's ready in
every other sense. Suppose e.g. that a
cannot be
installed with the new version of b
; then
a
may be removed to allow b
in.
Of course, there is another reason to remove a package from
testing
: It's just too buggy (and having a single RC-bug
is enough to be in this state).
Furthermore, if a package has been removed from unstable
,
and no package in testing
depends on it any more, then it
will automatically be removed.
A situation which is not handled very well by britney is if package
a
depends on the new version of package
b
, and vice versa.
この場合の例:
テスト版 | 不安定版 | |
---|---|---|
a | 1; depends: b=1 | 2; depends: b=2 |
b | 1; depends: a=1 | 2; depends: a=2 |
Neither package a
nor package b
is
considered for update.
Currently, this requires some manual hinting from the release team. Please
contact them by sending mail to <debian-release@lists.debian.org>
if this happens to
one of your packages.
Generally, there is nothing that the status of a package in
testing
means for transition of the next version from
unstable
to testing
, with two
exceptions: If the RC-bugginess of the package goes down, it may go in even
if it is still RC-buggy. The second exception is if the version of the
package in testing
is out of sync on the different
arches: Then any arch might just upgrade to the version of the source
package; however, this can happen only if the package was previously forced
through, the arch is in fuckedarches, or there was no binary package of that
arch present in unstable
at all during the
testing
migration.
In summary this means: The only influence that a package being in
testing
has on a new version of the same package is that
the new version might go in easier.
If you are interested in details, this is how britney works:
The packages are looked at to determine whether they are valid candidates. This gives the update excuses. The most common reasons why a package is not considered are too young, RC-bugginess, and out of date on some arches. For this part of britney, the release managers have hammers of various sizes to force britney to consider a package. (Also, the base freeze is coded in that part of britney.) (There is a similar thing for binary-only updates, but this is not described here. If you're interested in that, please peruse the code.)
Now, the more complex part happens: Britney tries to update
testing
with the valid candidates. For that, britney
tries to add each valid candidate to the testing distribution. If the number
of uninstallable packages in testing
doesn't increase,
the package is accepted. From that point on, the accepted package is
considered to be part of testing
, such that all
subsequent installability tests include this package. Hints from the
release team are processed before or after this main run, depending on the
exact type.
If you want to see more details, you can look it up on
merkel:/org/ftp.debian.org/testing/update_out/
(or in
merkel:~aba/testing/update_out
to see a setup with a
smaller packages file). Via web, it's at http://ftp-master.debian.org/testing/update_out_code/.
The hints are available via http://ftp-master.debian.org/testing/hints/.
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:
Make sure that your package really needs to go through
testing-proposed-updates
, and can't go through
unstable
;
必ず最小限な量だけの変更を含めるようにする;
Make sure that you included an appropriate explanation in the changelog;
Make sure that you've written testing
or
testing-proposed-updates
into your target distribution;
Make sure that you've built and tested your package in
testing
, not in unstable
;
Make sure that your version number is higher than the version in
testing
and testing-proposed-updates
,
and lower than in unstable
;
After uploading and successful build on all platforms, contact the release
team at <debian-release@lists.debian.org>
and ask them to approve your upload.
ある重要度以上のバグすべてが通常リリースクリティカルであると見なされます。現在のところ、critical
(致命的)
、grave (重大)
、serious
(深刻)
バグがそれにあたります。
そのようなバグは、Debian の 安定版 (stable)
リリース時に、そのパッケージがリリースされる見込みに影響があるものと仮定されます:
一般的に、パッケージでオープンになっているリリースクリティカルバグがある場合、そのパッケージはテスト版
(testing)
に入らず、その結果安定版 (stable)
ではリリースされません。
不安定版 (unstable)
でのバグのカウント数は、リリース対象アーキテクチャの不安定版 (unstable)
で利用可能なパッケージ
/バージョン
の組み合わせに適用されるとマークされたすべてのリリースクリティカルバグです。テスト版
(testing)
のバグのカウント数も同様に定義します。
ディストリビューションにおけるアーカイブの構造では、一つのバージョンのパッケージだけを持つことができ、パッケージは名前によって定義されています。そのため、ソースパッケージ
acmefoo
がテスト版 (testing)
にインストールされると、付随するバイナリパッケージ
acme-foo-bin
、acme-bar-bin
、libacme-foo1
、libacme-foo-dev
の古いバージョンが削除されます。
しかし、古いバージョンではライブラリに古い soname を含んだ libacme-foo0
のようなバイナリパッケージを提供しているかもしれません。古い acmefoo
を削除するのは
libacme-foo0
を削除することになり、これに依存しているパッケージを壊してしまいます。
Evidently, this mainly affects packages which provide changing sets of binary packages in different versions (in turn, mainly libraries). However, it will also affect packages upon which versioned dependencies have been declared of the ==, <=, or << varieties.
When the set of binary packages provided by a source package change in this
way, all the packages that depended on the old binaries will have to be
updated to depend on the new binaries instead. Because installing such a
source package into testing
breaks all the packages that
depended on it in testing
, some care has to be taken now:
all the depending packages must be updated and ready to be installed
themselves so that they won't be broken, and, once everything is ready,
manual intervention by the release manager or an assistant is normally
required.
この様に複雑な組み合わせのパッケージで問題がある場合は、<debian-devel@lists.debian.org>
あるいは <debian-release@lists.debian.org>
に連絡を取って手助けを求めてください。
[3] パッケージがどのセクションに属するかのガイドラインは Debian ポリシーマニュアルを参照してください。
[4] In the past, such NMUs used the third-level number on the Debian part of the revision to denote their recompilation-only status; however, this syntax was ambiguous with native packages and did not allow proper ordering of recompile-only NMUs, source NMUs, and security NMUs on the same package, and has therefore been abandoned in favor of this new syntax.