目次
この章では、パッケージの作成、アップロード、メンテナンス、移植についての情報を扱います。
もしあなたが Debian ディストリビューションに対して新たなパッケージを作成したいという場合、まず 作業が望まれるパッケージ (Work-Needing and Prospective Packages (WNPP)) の一覧をチェックする必要があります。WNPP 一覧をチェックすることで、まだ誰もそのソフトをパッケージ化していないことや、作業が重複していないことを確認します。詳細については WNPP のページ を読んでください。
パッケージ化しようとしているソフトについて、誰もまだ作業していないようであれば、まずは wnpp
擬似パッケージ (pseudo-package)
に対してバグ報告を投稿する必要があります (「バグ報告」)。このバグ報告には、パッケージの説明、作業しようとしているパッケージのライセンス、ダウンロードが可能な現在の
URL を含めた新規パッケージの作成予定 (自分自身が分かるだけではないもの) を記述します。
サブジェクトを ITP:
に設定する必要があります。ここでは
foo
-- short
description
foo
は新規パッケージの名前に置き換えます。バグ報告の重要度は
wishlist
に設定しなければなりません。X-Debbugs-CC ヘッダを使ってコピーを
<debian-devel@lists.debian.org>
に送信してください (CC: は使わないでください。CC:
を使った場合はメールのサブジェクトにバグ番号が付与されないためです)。大量の新規パッケージの作成 (11 個以上)
を行っている場合、メーリングリストへ個別に通知するのは鬱陶しいので、代わりにバグを登録した後で debian-devel
メーリングリストへ要約を送信してください。これによって、他の開発者らに次に来るパッケージを知らせ、説明とパッケージ名のレビューが可能になります。
新規パッケージがアーカイブへインストールされる際にバグ報告を自動的に閉じるため、Closes:
#
というエントリを新規パッケージの 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/
、あるいはネイティブパッケージの場合は
package
/changelog.Debian.gz/usr/share/doc/
にインストールされます。
package
/changelog.gz
debian/changelog
ファイルは、幾つもの異なった項目からなる特定の構造に従っています。一点を取り上げてみると、distribution
については「ディストリビューションを選ぶ」に記述されています。このファイルの構造について、より詳細な情報は Debian
ポリシーの debian/changelog
という章で確認できます。
changelog への記載は、パッケージがアーカイブにインストールされる際、自動的に Debian バグを閉じるのに利用できます。「新規アップロードでバグがクローズされる時」 を参照してください。
ソフトウェアの新しい開発元のバージョン (new upstream version) を含むパッケージの changelog エントリは、以下のようにするのが慣習です:
* New upstream release.
changelog
エントリの作成と仕上げ処理に使えるツールがあります。「devscripts
」 と 「dpkg-dev-el
」 を参照してください。
「debian/changelog
のベストプラクティス」 も参照してください。
パッケージをアップロードする前に、基本的なテストをする必要があります。最低限、以下の作業が必要です (同じ 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 によって作成された変更点を含む別のファイルが付随している (より一般的な) パッケージ
ネイティブパッケージの場合、ソースパッケージは Debian のソース control ファイル (.dsc
)
とソースコードの tarball (.tar.{gz,bz2,xz}
)
を含んでいます。ネイティブではないパッケージのソースパッケージは Debian のソース control ファイルと、オリジナルのソースコードの
tarball (.orig.tar.{gz,bz2,xz}
)、そして Debian での変更点
(ソース形式“1.0”は .diff.gz
、ソース形式“3.0 (quilt)”は
.debian.tar.{gz,bz2,xz}
) を含んでいます。
ソース形式“1.0”では、パッケージが native かどうかはビルド時に dpkg-source
によって決められていました。最近では望むソース形式を debian/source/format
に“3.0
(quilt)”または“3.0 (native)”と記述することによって明示することが推奨されています。この章の残りの部分は native
ではないパッケージについてのみ記しています。
初回には、特定の開発元のバージョン (upstream version) に該当するバージョンがアップロードされます。元のソース tar
ファイルは、アップロードされて .changes
ファイルに含まれている必要があります。その後、新しい
diff ファイルや .dsc
ファイルの生成には全く同じ tar
ファイルを使わなければならず、これを再アップロードする必要はありません。
デフォルトでは、dpkg-genchanges および
dpkg-buildpackage は前述されている changelog エントリと現在のエントリが異なった
upstream バージョンを持つ場合にのみ、オリジナルのソース tar
ファイルを含めようとします。この挙動は、-sa
を使って常に含めたり、-sd
を使うことで常に含めないようにするように変更できます。
アップロード時にオリジナルのソースが含まれていない場合、アップロードされる .dsc
と diff
ファイルを構築する際に dpkg-source が使用するオリジナルの tar
ファイルは、必ず既にアーカイブにあるものと 1 バイトも違わぬものでなくてはなりません。
注意していただきたいのですが、native ではないパッケージでは、diff
はパッチ内のファイルパーミッションを保存しないので、*.orig.tar.{gz,bz2,xz}
内に存在しないファイルのパーミッションは保持されません。しかし、ソース形式“3.0
(quilt)”を使っている場合、debian
ディレクトリ内にあるファイルのパーミッションは tar
アーカイブで保存されるのでそのままになります。
アップロードでは、パッケージがどのディストリビューション向けになっているかを指定してあることが必要です。パッケージの構築プロセスでは、debian/changelog
ファイルの最初の行からこの情報を展開し、.changes
ファイルの
Distribution
欄に配置します。
この欄にはいくつか指定可能な値があります:
stable
、unstable
、testing-proposed-updates
、そして
experimental
です。通常、パッケージは unstable
にアップロードされます。
実際には、他に二つ指定可能なディストリビューションがあります: stable-security
と
testing-security
ですが、これらについての詳細は 「セキュリティ関連バグの取扱い」 を読んでください。
同時に複数のディストリビューションへ、パッケージをアップロードすることはできません。
安定版 (stable)
へのアップロードは、安定版リリースマネージャによるレビューのため、パッケージは
proposed-updates-new
キューに転送され、許可された場合は Debian アーカイブの
stable-proposed-updates
ディレクトリにインストールされます。ここから、ここから、安定版 (stable)
の次期ポイントリリースに含まれることになります。
To ensure that your upload will be accepted, you should discuss the changes
with the stable release team before you upload. For that, file a bug against
the release.debian.org
pseudo-package using reportbug, including the patch you
want to apply to the package version currently in
stable
. Always be verbose and detailed in your changelog
entries for uploads to the stable
distribution.
安定版 (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 アップロードの準備をする際は、メンテナに対して猶予期間を数日間与えたいと思うでしょう。
An upload to the delayed directory keeps the package in the deferred uploads
queue. When the specified waiting time is over, the package is
moved into the regular incoming directory for processing. This is done
through automatic uploading to ftp.upload.debian.org
in
upload-directory DELAYED/
(X
-dayX
between 0 and 15). 0-day is uploaded multiple
times per day to 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 アーカイブメンテナはパッケージのアップロードに関して責任を持っています。多くの部分は、アップロードはアーカイブ用のメンテナンスツール
dak process-upload によって日々自動的に行われています。特に、不安定版
(unstable)
に存在しているパッケージの更新は自動的に処理されます。それ以外の場合、特に新規パッケージの場合は、アップロードされたパッケージをディストリビューションに含めるのは手動で行われます。アップロードが手動で処理される場合は、アーカイブへの変更は実施されるまでに一ヶ月ほどかかります。お待ちください。
どの場合であっても、パッケージがアーカイブに追加されたことや、バグがアップロードで閉じられたことを告げるメールでの通知を受け取ることになります。あなたが閉じようとしたバグが処理されてない場合は、この通知を注意深く確認してください。
インストール通知は、パッケージがどのセクションに入ったかを示す情報を含んでいます。不一致がある場合は、それを示す別のメール通知を受け取ります。以下も参照ください。
キュー経由でアップロードした場合は、キューデーモンソフトウェアもメールで通知を行うことに留意してください。
debian/control
ファイルの セクション (Section)
フィールドと 優先度 (Priority)
フィールドは実際にアーカイブ内でどこに配置されるか、あるいはプライオリティが何かという指定ではありません。debian/control
ファイル中の値は、実際のところは単なるヒントです。
アーカイブメンテナは、override
ファイル
内でパッケージについて定められたセクションと優先度を常に確認しています。override
ファイル
と debian/control
で指定されたパッケージのフィールドに不一致がある場合、パッケージがアーカイブにインストールされる際に相違について記述されたメールを受け取ります。debian/control
ファイルを次回のアップロード時に修正することもできますし、override
ファイル
に変更を加えるように依頼するのもよいでしょう。
パッケージが現状で置かれているセクションを変更するには、まずパッケージの debian/control
ファイルが正しいことを確認する必要があります。次に、ftp.debian.org
に対し、あなたのパッケージに対するセクションあるいは優先度について古いものから新しいものへ変更する依頼のバグ登録をします。override:
PACKAGE1:section/priority, [...], PACKAGEX:section/priority
のようなサブジェクトを使い、バグ報告の本文に変更に関する根拠を記述してください。
override ファイル
についての詳細は、dpkg-scanpackages(1) と 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 のエントリを書くのか、一般的な情報については 「debian/changelog
のベストプラクティス」 を参照してください。
機密性が高いその性質上、セキュリティ関連のバグは注意深く取り扱わねばなりません。この作業をコーディネイトし、未処理のセキュリティ問題を追い続け、セキュリティ問題についてメンテナを手助けしたり修正自体を行い、セキュリティ勧告を出し、security.debian.org
を維持するために Debian セキュリティチームが存在します。
Debian
パッケージ中のセキュリティ関連のバグに気づいたら、あなたがメンテナであるかどうかに関わらず、問題に関する正確な情報を集めて、まずはセキュリティチームに連絡を取ってください。この場合、リクエストトラッカーにチケットを登録するのが好ましいです。http://wiki.debian.org/rt.debian.org#Security_Team
を参照してください。あるいは <team@security.debian.org>
にメールすることもできます。チームに問い合わせること無く
安定版 (stable)
向けのパッケージをアップロードしないでください。例えば、役に立つ情報は以下を含んでいます:
バグが既に公開されているか否か
バグによって、どのバージョンが影響を受けると分かっているか。サポートされている Debian のリリース、ならびに テスト版
(testing)
及び 不安定版 (unstable)
にある各バージョンをチェックしてください。
利用可能なものがあれば、修正内容 (パッチが特に望ましい)
自身で準備した修正パッケージ (まずは 「セキュリティ問題に対処するパッケージを用意する」
を読んで、.diff.gz
と .dsc
ファイルだけを送ってください)
テストについて何かしらの手助けになるもの (攻撃コード、リグレッションテストなど)
勧告に必要になる情報 (「セキュリティ勧告」 参照)
パッケージメンテナとして、あなたは安定版リリースについてもメンテナンスする責任を持ちます。あなたがパッチの評価と更新パッケージのテストを行うのに最も適任な人です。ですから、以下のセキュリティチームによって取り扱ってもらうため、どのようにしてパッケージを用意するかについての章を参照してください。
セキュリティチームは集約的なデータベース、Debian セキュリティ追跡システム (Debian Security Tracker)をメンテナンスしています。これはセキュリティ問題として知られている全ての公開情報を含んでいます: どのパッケージ/バージョンが影響を受ける/修正されているか、つまりは安定版、テスト版、不安定版が脆弱かどうか、という情報です。まだ機密扱いの情報は追跡システムには追加されません。
特定の問題について検索することもできますし、パッケージ名でも検索できます。あなたのパッケージを探して、どの問題がまだ未解決かを確認してください。できれば追加情報を提供するか、パッケージの問題に対処するのを手伝ってください。やり方は追跡システムのウェブページにあります。
Debian 内での他の多くの活動とは違い、セキュリティ問題に関する情報については、暫くの間秘密にしておく必要がしばしばあります。これによって、ソフトウェアのディストリビュータがユーザが危険にさらされるのを最小限にするため、公開時期を合わせることができます。今回がそうであるかは、問題と対応する修正の性質や、既に既知のものとなっているかどうかによります。
開発者がセキュリティ問題を知る方法はいくつかあります:
公開フォーラム (メーリングリスト、ウェブサイトなど) で知らせる
誰かがバグ報告を登録している
誰かがプライベートなメールで教えてきた
最初の二つのケースでは、情報は公開されていて可能な限り早く修正することが重要です。しかしながら最後のケースは、公開情報ではないかもしれません。この場合は、問題に対処するのに幾つか取り得る選択肢があります:
セキュリティの影響度が小さい場合、問題を秘密にしておく必要はなく、修正を行ってリリースするのが良い場合がしばしばあります。
問題が深刻な場合、他のベンダと情報を共有してリリースをコーディネイトする方が望ましいでしょう。セキュリティチームは様々な組織/個人と連絡を取りつづけ、この問題に対応することができます。
どのような場合でも、問題を報告した人がこれを公開しないように求めているのであれば、明白な例外として Debian の安定版リリースに対する修正を作成してもらうためにセキュリティチームへ連絡すること以外、この様な要求は尊重されるべきです。機密情報をセキュリティチームに送る場合は、この点を明示しておくのを忘れないでください。
機密を要する場合は、修正を不安定版 (unstable)
(や公開 VCS リポジトリなどその他どこへも)
へ修正をアップロードしないよう、注意してください。コードその物が公開されている場合、変更の詳細を難読化するだけでは十分ではなく、皆によって解析され得る
(そしてされる) でしょう。
機密であることを要求されたにも関わらず、情報を公開するのには 2 つの理由があります: 問題が一定期間既知の状態になっている、あるいは問題や攻撃コードが公開された場合です。
セキュリティチームは、機密事項に関して通信を暗号化できる PGP 鍵を持っています。詳細については、セキュリティチーム FAQ を参照してください。
セキュリティ勧告は現在のところ、リリースされた安定版ディストリビューションについてのみ、取り扱われます。テスト版
(testing)
や 不安定版 (unstable)
についてではありません。リリースされると、セキュリティ勧告は
email-debian-security-announce; メーリングリストに送られ、セキュリティのウェブページに掲載されます。セキュリティ勧告はセキュリティチームによって記述、掲載されます。しかし、メンテナが情報を提供できたり、文章の一部を書けるのであれば、彼らは当然そんなことは気にしません。勧告にあるべき情報は以下を含んでいます:
以下のようなものを含めた問題の説明と範囲:
問題の種類 (権限の上昇、サービス拒否など)
何の権限が得られるのか、(もし分かれば) 誰が得るのか
どのようにして攻撃が可能なのか
攻撃はリモートから可能なのかそれともローカルから可能なのか
どのようにして問題が修正されたのか
この情報によって、ユーザがシステムに対する脅威を評価できるようになります。
影響を受けるパッケージのバージョン番号
修正されたパッケージのバージョン番号
どこで更新されたパッケージを得るかという情報 (通常は Debian のセキュリティアーカイブからです)
開発元のアドバイザリへの参照、CVE 番号、脆弱性の相互参照について役立つその他の情報
あなたがセキュリティチームに対し、彼らの職務に関して手助けできる方法の一つは、安定版 Debian リリース用のセキュリティ勧告に適した修正版パッケージを提供することです。
安定版について更新が作成される際、システムの挙動の変化や新しいバグの導入を避けるように注意が必要です。これを行うため、バグを修正するための変更は可能な限り少なくします。ユーザや管理者は一旦リリースされたものの厳密な挙動を当てにしているので、どのような変更でも誰かのシステムを壊しかねません。これは特にライブラリについて当てはまります: API や ABI を決して変更していないことを確認してください。変更がどれほど小さいものでも関係ありません。
これは、開発元の新しいリリースバージョン (new upstream version) への移行が良い解決策ではないことを意味しています。代わりに、関連する変更を現在の Debian 安定版リリースに存在しているバージョンへバックポートするべきです。通常、開発元のメンテナは助けが必要であれば手伝おうとしてくれます。そうでない場合は、Debian セキュリティチームが手助けすることができます。
いくつかのケースでは、例えば大量のソースコードの変更や書き直しが必要など、セキュリティ修正をバックポートできないことがあります。この様な場合、新しいバージョン (new upstream version) へ移行する必要があるかもしれません。しかし、これは極端な状況の場合にのみ行われるものであり、実行する前に必ずセキュリティチームと調整をしなければなりません。
これに関してはもう一つ重要な指針があります: 必ず変更についてテストをしてください。攻撃用コード (exploit) が入手可能な場合には、それを試してみて、パッチを当てていないパッケージで成功するか、修正したパッケージでは失敗することかどうかを確かめてみてください。他の確認として、セキュリティ修正は時折表面上はそれと関係が無いような機能を壊すことがあるので、通常の動作も同様にテストしてください。
脆弱性の修正に直接関係しない変更をパッケージへ加えないようにしてください。この様な変更は元に戻さなくてはならなくなるだけで、時間を無駄にします。他に直したいバグがパッケージにある場合は、セキュリティ勧告が発行された後、通常通りに proposed-update にアップロードを行ってください。セキュリティ更新の仕組みは、それ以外の方法では安定版リリースから reject されるであろう変更をあなたのパッケージに加える方法ではありませんので、この様な事はしないでください。
変更点を可能な限り見直してください。以前のバージョンとの変更点を繰り返し確認してください (これには patchutils
パッケージの 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,xz}
を必ず使うようにしてください。さもなくば、後ほどセキュリティ修正を
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,xz}
を
(開発元のバージョンが新しいものになったのではなくても)
アップロードに含める必要があります。新しいセクションが正しい場合は、自動的に移動されます。移動されない場合には、何が起こったのかを理解するために
ftpmaster に連絡を取ります。
一方で、もしパッケージの一つのサブセクション
(例:「devel」「admin」)
を変更する必要がある、という場合には、手順は全く異なります。パッケージの control
ファイルにあるサブセクションを修正して、再アップロードします。また、「パッケージのセクション、サブセクション、優先度を指定する」 に記述してあるように
override ファイルを更新する必要が出てくるでしょう。
何らかの理由でパッケージを完全に削除したくなった場合 (もう必要がなくなった古い互換用ライブラリの場合、など)、パッケージを削除するよう
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)
にあるパッケージは削除されたパッケージに依存しなくなります。
例外として、明示的な削除依頼が必要ない場合が一つあります: (ソース、あるいはバイナリ) パッケージがソースからビルドされなくなった場合、半自動的に削除されます。バイナリパッケージの場合、これはこのバイナリパッケージを生成するソースパッケージがもはや存在しないということを意味します。バイナリパッケージがいくつかのアーキテクチャで生成されなくなったという場合には、削除依頼は必要です。ソースパッケージの場合は、関連の全バイナリパッケージが別のソースパッケージによって上書きされるのを意味しています。
削除依頼では、依頼を判断する理由を詳細に書く必要があります。これは不必要な削除を避け、何故パッケージが削除されたのかを追跡できるようにするためです。例えば、削除されるパッケージにとって代わるパッケージの名前を記述します。
通常は自分がメンテナンスしているパッケージの削除のみを依頼します。その他のパッケージを削除したい場合は、メンテナの許可を取る必要があります。パッケージがみなしご化されたのでメンテナがいない場合は、まず
<debian-qa@lists.debian.org>
で削除依頼について議論をしてください。パッケージの削除についての合意ができたら、削除依頼の新規バグを登録するのではなく、wnpp
パッケージに対して登録されているバグを reassign して O:
に題名を変更するべきです。
この件、あるいはパッケージ削除に関するその他のトピックについて、さらなる情報を http://wiki.debian.org/ftpmaster_Removals や http://qa.debian.org/howto-remove.html で参照できます。
パッケージを破棄しても構わないか迷う場合には、意見を聞きに <debian-devel@lists.debian.org>
へメールしてください。apt
の apt-cache
プログラムも重要です。apt-cache showpkg
として起動した際、プログラムはパッケージ名
パッケージ名
の非依存関係を含む詳細を表示します。他にも
apt-cache
rdepends、apt-rdepends、build-rdeps
(devscripts
パッケージに含まれる)、grep-dctrl
などの有用なプログラムが非依存関係を含む情報を表示します。みなしご化されたパッケージの削除は、<debian-qa@lists.debian.org>
で話し合われます。
一旦パッケージが削除されたら、パッケージのバグを処理する必要があります。実際のコードが別のパッケージに含まれるようになったので、別のパッケージへバグを付け替える
(例えば、libfoo13
が上書きするので、libfoo12
が削除される) か、あるいはソフトウェアがもう Debian の一部では無くなった場合にはバグを閉じるかする必要があります。バグを閉じる場合、過去の
Debian のリリースにあるパッケージバージョンで修正されたとマークするのを避けてください。バージョン
<most-recent-version-ever-in-Debian>+rm
で修正されたとマークしなければなりません。
以前は、incoming
からパッケージを削除することが可能でした。しかし、新しい incoming
システムが導入されたことにより、これはもはや不可能となっています。その代わりに、置き換えたいパッケージよりも高いバージョンのリビジョンの新しいパッケージをアップロードする必要があります。両方のバージョンのパッケージがアーカイブにインストールされますが、一つ前のバージョンはすぐに高いバージョンで置き換えられるため、実際にはバージョンが高い方だけが
不安定版 (unstable)
で利用可能になります。しかし、もしあなたがパッケージをきちんとテストしていれば、パッケージを置き換える必要はそんなに頻繁には無いはずです。
あなたのパッケージのどれかの開発元のメンテナらが、ソフトウェアをリネームするのを決めた時
(あるいはパッケージを間違えて名前を付けた時)、以下の二段階のリネーム手続きに従う必要があります。最初の段階では、debian/control
ファイルに新しい名前を反映し、利用しなくなるパッケージ名に対して Replace、Provides、Conflicts を設定する変更をします
(詳細に関しては Debian ポリシーマニュアルl
を参照)。注意してほしいのは、利用しなくなるパッケージ名がリネーム後も動作する場合のみ、Provides
を付け加えるべきだということです。一旦パッケージをアップロードがアップロードされてアーカイブに移動したら、ftp.debian.org
に対してバグを報告してください (「パッケージの削除」 参照)。同時にパッケージのバグを正しく付け替えするのを忘れないでください。
他に、パッケージの作成でミスを犯したので置き換えたいという場合があるかもしれません。これを行う方法は唯一つ、バージョン番号を上げて新しいバージョンをアップロードすることです。通常、古いバージョンは無効になります。これはソースを含めた各パッケージ部分に適用されることに注意してください:
パッケージの開発元のソース tarball を入れ替えたい場合には、別のバージョンをつけてアップロードする必要があります。よくある例は
foo_1.00.orig.tar.gz
を
foo_1.00+0.orig.tar.gz
、あるいは
foo_1.00.orig.tar.bz2
で置き換えるというものです。この制約によって、ftp
サイト上で各ファイルが一意の名前を持つことになり、ミラーネットワークをまたがった一貫性を保障するのに役立ちます。
パッケージをもうメンテナンスできなくなってしまった場合、ほかの人に知らせて、パッケージがみなしご化 (orphaned)
とマークされたのが分かるようにする必要があります。パッケージメンテナを Debian QA Group
<packages@qa.debian.org>
に設定し、疑似パッケージwnpp
に対してバグ報告を送信しなければなりません。バグ報告は、パッケージが今みなしご化されていることを示すように O:
というタイトルにする必要があります。バグの重要度は
パッケージ名
--
短い要約
通常 (normal)
に設定しなければなりません; パッケージの重要 (priority) が standard
より高い場合には重要 (important) に設定する必要があります。必要だと思うのならば、メッセージの X-Debbugs-CC:
ヘッダのアドレスに <debian-devel@lists.debian.org>
を入れてコピーを送ってください (そう、CC: を使わないでください。その理由は、CC:
を使うと、メッセージの題名がバグ番号を含まないからです)。
パッケージを手放したいが、しばらくの間はメンテナンスを継続できる場合には、代わりに wnpp
へ RFA:
という題名でバグ報告を送信する必要があります。パッケージ名
--
短い要約
RFA
は Request For
Adoption (引き取り依頼)
を意味しています。
より詳細な情報は WNPP ウェブページにあります。
新たなメンテナが必要なパッケージの一覧は 作業が望まれるパッケージ (WNPP、Work-Needing and Prospective Packages list) で入手できます。WNPP でリストに挙がっているパッケージのどれかに対するメンテナンスを引き継ぎたい場合には、情報と手続きについては前述のページを確認してください。
メンテナンスされていないと思うパッケージを単純に持っていっても構いませんか? —それはパッケージの乗っ取り (hijacking) です。できますが、もちろんのこと、現在のメンテナに確認をとってパッケージを持って行って良いか尋ねましょう。メンテナが AWOL (absent without leave、無届け欠席状態) であると信ずる理由があれば、「活動的でない、あるいは連絡が取れないメンテナに対応する」 を参照してください。
一般的に、現在のメンテナの同意なしでパッケージを引き取るべきではありません。彼らがあなたのことを無視したのだとしても、それはパッケージを引き取る理由とはなりません。メンテナへの不満は開発者のメーリングリストへ送られるべきです。議論が良い結論に至らない、かつ問題が技術的なものなのであれば、技術委員会に相談することを検討してください (より詳細については、Debian 技術委員会のページ を参照してください)。
古いパッケージを引き継いだ場合は、おそらくバグ追跡システムでパッケージの公式メンテナとして表示されるようにしたいことでしょう。これは、一旦
Maintainer
欄を更新した新しいバージョンをアップロードすれば自動的に行われますが、アップロードが完了してから数時間はかかります。しばらくは新しいバージョンをアップロードする予定が無い場合は、「パッケージ追跡システム」
を使ってバグ報告を受け取ることができます。しかし、以前のメンテナにしばらくの間はバグ報告が届き続けても問題無いことを確認してください。
Debian がサポートするアーキテクチャの数は増え続けています。あなたが移植作業者ではない、あるいは別のアーキテクチャを使うことが無いという場合であっても、移植性の問題に注意を払うことはメンテナとしてのあなたの義務です。従って、あなたが移植作業者でなくても、この章の大半を読む必要があります。
移植作業 (Porting) とは、パッケージメンテナが生成したバイナリパッケージの元々のアーキテクチャとは違うアーキテクチャの Debian
パッケージをビルドする作業です。これは非常にユニークかつ極めて重要な活動です。事実、移植作業者は実際の Debian
パッケージのコンパイルの大半を行っています。例えば、メンテナが (移植可能な) ソースパッケージと i386
のバイナリをアップロードすると、他の各アーキテクチャ、11 以上の数のビルドが生成されます。
移植作業者は、難解かつ他には無いタスクを抱えています。それは、彼らは膨大な量のパッケージに対処する必要があるからです。理想を言えば、すべてのソースパッケージは変更を加えないできちんとビルドできるべきです。残念なことに、その様な場合はほとんどありません。この章は Debian メンテナによってよくコミットされる「潜在的な問題」のチェックリストを含んでいます — よく移植作業者を困らせ、彼らの作業を不必要に難解にする共通の問題です。
まず初めの、そして最も重要な点は、バグや移植作業者から投げかけられた問題に素早く回答することです。移植作業者をパッケージの副メンテナ (co-maintainer) であるように丁重に扱ってください (ある意味、その通りではあります)。簡潔、あるいは不明瞭なバグ報告に対して寛容になってください。問題が何であれ、原因を捉えることに最善を尽くしてください。
移植作業者が遭遇する問題のほとんどは、何といっても、ソースパッケージ内でのパッケージ作成のバグによって引き起こされます。以下は、確認あるいは注意すべき項目のリストです。
debian/control
中の Build-Depends
と
Build-Depends-Indep
の設定が正しいことを確認してください。これを検証するのに最も良い方法は
debootstrap
パッケージを使って 不安定版
(unstable)
の chroot 環境を作成することです (「debootstrap
」
参照)。chroot 環境内では、build-essential
パッケージと、Build-Depends
または
Build-Depends-Indep
に記載されている依存パッケージをインストールしてください。最後に、chroot 環境でパッケージの生成を試してください。これらの手順は
pbuilder パッケージで提供される同名のプログラムの利用によって自動化することができます (「pbuilder
」 参照)。
chroot を正しく設定できない場合は、dpkg-depcheck が手助けになることでしょう (「dpkg-depcheck」 参照)。
ビルドの依存情報の指定方法については、Debian ポリシーマニュアルを参照してください。
意図がある場合以外は、アーキテクチャの値を all
または any
以外に指定しないでください。非常に多くの場合、メンテナが Debianポリシーマニュアルの指示に従っていません。アーキテクチャを単一のものに指定する
(i386
あるいは amd64
など) は大抵誤りです。
ソースパッケージが正しいことを確かめてください。ソースパッケージが正しく展開されたのを確認するため、dpkg-source -x
を実行してください。そして、ここでは、一からパッケージを dpkg-buildpackage
でビルドするのに挑戦してみてください。
package
.dsc
debian/files
や debian/substvars
を含んだソースパッケージを出していないかを確かめてください。これらは、debian/rules
の
clean
ターゲットによって削除されるべきです。
ローカル環境にインストールされていたり、弄くられている設定やプログラムに依存していないことを確かめてください。例えば、/usr/local/bin
やその類のプログラムは決して呼び出してはいけません。特殊なやり方で設定されたプログラムには依存しないようにしてください。別のマシンでパッケージをビルドしてください。それが同じアーキテクチャであっても、です。
構築中の既にインストールしてあるパッケージに依存しないでください (上記の話の一例です)。もちろん、このルールには例外はありますが、そのような場合には手動で一から環境を構築する必要があり、パッケージ作成マシンで自動的に構築することはできません。
可能であれば、特定のバージョンのコンパイラに依存しないでください。もし無理であれば、その制約をビルドの依存関係に反映されているのを確認してください。だとしても異なったアーキテクチャでは時折異なったバージョンのコンパイラで統一されているので、それでも恐らく問題を引き起こすことになるでしょう。
debian/rules
で、Debian
ポリシーマニュアルが定めるように、binary-arch
及び
binary-indep
ターゲットに分かれて含まれていることを確かめてください。両方のターゲットが独立して動作するのを確かめてください。つまり、他のターゲットを事前に呼び出さなくても、ターゲットを呼び出せるのを確かめるということです。これをテストするには、dpkg-buildpackage
-B を実行してください。
パッケージが移植作業を行うアーキテクチャで手を入れずに構築できるのであれば、あなたは幸運で作業は簡単です。この章は、その様な場合に当てはめられます: きちんとアーカイブにインストールされるために、どうやってバイナリパッケージを構築・アップロードするかを記述しています。他のアーキテクチャでコンパイルできるようにするため、パッケージにパッチを当てる必要がある場合は、実際のところ、ソース NMU を行なうので、代わりに 「いつ、どうやって NMU を行うか」 を参照してください。
移植作業者のアップロード (porter upload) は、ソースに何も変更を加えません。ソースパッケージ中のファイルには触る必要はありません。これは
debian/changelog
を含みます。
dpkg-buildpackage を dpkg-buildpackage -B
-m
として起動してください。もちろん、porter-email
porter-email
にはあなたのメールアドレスを設定します。これはdebian/rules
の binary-arch
を使ってパッケージのバイナリ依存部分のみのビルドを行います。
移植作業のために Debian
マシン上で作業をしていて、アーカイブに入れてもらうためにアップロードするパッケージにローカルでサインする必要がある場合は、.changes
に対して debsign を手軽に実行するのもできますし、dpkg-sig
のリモート署名モードを使うこともできます。
時折、最初の移植作業者のアップロード作業は困難なものになります。パッケージが構築された環境があまり良くないからです (古すぎる、使われていないライブラリがある、コンパイラの問題、などなど…)。その場合には、更新した環境で再コンパイルする必要があるでしょう。しかし、この場合にはバージョンを上げる必要があり、古いおかしなパッケージは Debian アーカイブ中で入れ替えられることになります (現在利用可能なものよりバージョン番号が大きくない場合、dak は新しいパッケージのインストールを拒否します)。
binary-only NMU がパッケージをインストール不可能にしてしまっていないことを確認する必要があります。ソースパッケージが、dpkg の
substitution 変数 $(Source-Version)
を使って内部依存関係を生成しているアーキテクチャ依存パッケージとアーキテクチャ非依存パッケージを生成した場合に起こる可能性があります。
changelog の変更が必要かどうかに関わらず、これらは binary-only NMU と呼ばれます — この場合には、他の全アーキテクチャで古すぎるかどうかや再コンパイルが必要かなどを考える必要はありません。
このような再コンパイルは、特別な「magic」バージョン番号を付けるのを必要とするので、アーカイブのメンテナンスツールは、これを理解してくれます。新しい Debian バージョンで、対応するソースアップデートが無くても、です。これを間違えた場合、アーカイブメンテナは (対応するソースコードが欠落しているので) アップロードを拒否します。
再コンパイルのみの NMU への「magic」は、b
という形式に従った、パッケージのバージョン番号に対するサフィックスを追加することで引き起こされます。例えば、再コンパイル対象の最新バージョンが
番号
2.9-3
の場合、バイナリのみの NMU は 2.9-3+b1
というバージョンになる必要があります。最新のバージョンが 3.4+b1
(つまり、ネイティブパッケージで、前回が再コンパイルの NMU) の場合、バイナリのみの NMU は 3.4+b2
というバージョン番号にならねばいけません。[4]
最初の移植作業者のアップロード (porter upload) と同様に、パッケージのアーキテクチャ依存部分をビルドするための
dpkg-buildpackage の正しい実行の仕方は dpkg-buildpackage
-B
です。
移植作業者は、通常は非移植作業者同様に 「Non-Maintainer Upload (NMU)」 にあるガイドラインに沿ってソース NMU を行います。しかし、移植作業者のソース NMU に対する待ち時間は非移植作業者より小さくなります。これは、移植作業は大量のパッケージに対応する必要があるからです。さらに、状況はパッケージがアップロードされるディストリビューションに依って変わります。これは、アーキテクチャが次の安定版リリースに含められるかどうかによっても変わります。リリースマネージャはどのアーキテクチャが候補なのかを決定してアナウンスします。
あなたが不安定版 (unstable)
へ NMU
を行う移植作業者の場合、移植作業についての上記のガイドライン、そして 2 つの相違点に従う必要があります。まず、適切な待ち時間です — バグが BTS
へ投稿されてから NMU を行って OK になるまでの間 — 移植作業者が 不安定版 (unstable)
ディストリビューションに対して行う場合は 7 日間になります。問題が致命的で移植作業に困難を強いるような場合には、この期間は短くできます
(注意してください。この何れもがポリシーではなく、単にガイドラインに沿って相互に了解されているだけです)。安定版
(stable)
や テスト版 (testing)
へのアップロードについては、まず適切なリリースチームと調整をしてください。
次に、ソース NMU を行う移植作業者は BTS へ登録したバグの重要度が serious
かそれ以上であることを確認してください。これは単一のソースパッケージが、すべての Debian
でサポートされているアーキテクチャでコンパイルされたことをリリース時に保証します。数多くのライセンスに従うため、すべてのアーキテクチャについて、単一のバージョンのバイナリパッケージとソースパッケージを持つことがとても重要です。
移植作業者は、現在のバージョンのコンパイル環境やカーネル、libc
にあるバグのために作られた単なる力業のパッチを極力回避すべきです。この様なでっち上げの代物があるのは、仕方がないことが時折あります。コンパイラのバグやその他の為にでっち上げを行う必要がある場合には、#ifdef
で作業したものが動作することを確認してください。また、力業についてドキュメントに載せてください。一旦外部の問題が修正されたら、それを削除するのを皆が知ることができます。
移植作業者は、待ち期間の間、作業結果を置いておける非公式の置き場所を持つこともあります。移植版を動作させている人が、待ち期間の間であっても、これによって移植作業者による作業の恩恵を受けられるようになります。もちろん、この様な場所は、公式な恩恵や状況の確認を受けることはできませんので、利用者は注意してください。
パッケージの自動移植に役立つインフラストラクチャと複数のツールがあります。この章には、この自動化とこれらのツールへの移植の概要が含まれています。全体の情報に付いてはパッケージのドキュメントかリファレンスを参照してください。
各移植版についての状況を含んだウェブページは http://www.debian.org/ports/ から参照できます。
Debian の各移植版はメーリングリストを持っています。移植作業のメーリングリストは http://lists.debian.org/ports.html で見ることができます。これらのリストは移植作業者の作業の調整や移植版のユーザと移植作業者をつなぐために使われています。
移植用のツールの説明をいくつか 「移植用ツール」 で見ることができます。
wanna-build
システムは、分散型の、クライアント・サーバでの構築配布システムとして利用されています。通常、これは buildd
プログラムが動作しているビルドデーモンと連携して使われます。ビルドデーモン
は、ビルドが必要なパッケージの一覧を受け取るために中央の
wanna-build
システムと通信する「slave」ホストです。
wanna-build
は、まだパッケージとしては入手可能になっていません。ですが、すべての Debian
の移植作業ではパッケージ構築作業の自動化にこれが使われています。実際のパッケージ構築に使われるツール、sbuild
はパッケージとして利用可能です。「sbuild
」
で説明を参照してください。パッケージ化されたバージョンは、ビルドデーモンで使われているものとは同じではありませんが、問題を再現するには十分なものである点に注意ください。
wanna-build
によって生成される移植作業者にとって大抵有用であるデータの多くは、ウェブ上の http://buildd.debian.org/
で入手可能です。このデータには、毎晩更新される統計情報や、queue 情報、ビルド失敗のログが含まれています。
我々はこのシステムを極めて誇りに思っています。何故ならば、様々な利用方法の可能性があるからです。独立した開発グループは、実際に一般的な用途に合うかどうか分からない異なった別アプローチの Debian にシステムを使うことができます (例えば、gcc の配列境界チェック付きでビルドした Debian など)。そして、Debian がディストリビューション全体を素早く再コンパイルできるようにもなります。
buildd の担当である wanna-build
チームには、debian-wb-team@lists.debian.org
で連絡が取れます。誰
(wanna-build チーム、リリースチーム) に連絡を取るのか、どうやって (メール、BTS) 連絡するのかを決めるには、http://lists.debian.org/debian-project/2009/03/msg00096.html を参照してください。
binNMU や give-back (ビルド失敗後のやり直し) を依頼する時には、http://release.debian.org/wanna-build.txt で記述されている形式を使ってください。
いくつかのパッケージでは、Debian
でサポートされているアーキテクチャのうちの幾つかで、構築や動作に問題を抱えており、全く移植できない、あるいは十分な時間内では移植ができないものがあります。例としては、SVGA
に特化したパッケージ (i386
と amd64
のみで利用可能)や、すべてのアーキテクチャではサポートされていないようなハードウェア固有の機能があります。
壊れたパッケージがアーカイブにアップロードされたり buildd の時間が無駄に費やされたりするのを防ぐため、幾つかしなければならないことがあります:
まず、サポートできないアーキテクチャ上ではパッケージがビルドに失敗するのを確認しておく必要があります。これを行うには幾つかやり方があります。お勧めの方法は構築時に機能をテストする小さなテストスイートを用意して、動かない場合に失敗するようにすることです。これは、全てのアーキテクチャ上で、壊れたものをアップロードするのを防ぎ、必要な機能が動作するようになればパッケージがビルドできるようになる、良い考えです。
さらに、サポートしているアーキテクチャ一覧が一定量であると信ずるのであれば、debian/control
内で
any
からサポートしているアーキテクチャの一覧に変更するべきです。この方法であれば、ビルドが同様に失敗するようになるのに加え、実際に試すことなく人間である読み手にサポートしているアーキテクチャが分かるようにできます。
autobuilder が必要もなくパッケージをビルドしようとしないように、wanna-build
スクリプトが使うリストである Packages-arch-specific
に追加しておく必要があります。現在のバージョンは http://buildd.debian.org/quinn-diff/Packages-arch-specific から入手できます:
変更依頼をする相手はファイルの一番上を参照してください。
サポートしていないアーキテクチャ上でビルドが失敗するようにせずに、パッケージを単に
Packages-arch-specific
に付け加えるだけでは不十分であることに注意してください:
移植作業者、あるいはあなたのパッケージをビルドしようとしている他の人は、それが動かないのに気づかないで誤ってアップロードするかもしれません。過去に、サポートされてないアーキテクチャ上にバイナリパッケージがアップロードされてしまった場合、削除依頼は
ftp.debian.org
に対するバグを登録することによって行われました。
non-free
セクションのパッケージは、デフォルトでは autobuilder
ネットワークではビルドされません
(多くの場合は、パッケージのライセンスによって許可されていないためです)。パッケージをビルドできるようにするには、以下の手順を踏む必要があります:
法的に許可されているか、技術的にパッケージが auto-build 可能かどうかを確認する;
debian/control
のヘッダ部分に XS-Autobuild:
yes
を追加する;
メールを <nonfree@release.debian.org>
に送り、何故パッケージが合法的、かつ技術的に auto-build できるものなのかを説明する
すべてのパッケージには最低一人のメンテナがいます。通常、この人達がパッケージに対して作業をし、新しいバージョンをアップロードします。時折、他の開発者らが新しいバージョンをアップロードできると便利な場合があります。例えば、彼らがメンテナンスしていないパッケージにあるバグを修正したいが、メンテナが問題に対応するのには助けが必要な場合です。このようなアップロードは Non-Maintainer Upload (NMU) と呼ばれます。
NMU を行う前に、以下の質問について考えてください:
NMU は本当にバグを修正しますか? NMU では、些細な問題の修正やパッケージ方式の変更は推奨されません。
メンテナに十分な時間を与えましたか? BTS にバグが報告されたのは何時ですか? 一、二週間忙しいことはあり得ないことでは無いです。そのバグはすぐに修正しなければならないほど重大ですか? それとも、あと数日待てるものですか?
その変更にどれくらい自信がありますか? ヒポクラテスの誓いを思い出してください: 「何よりも、害を及ぼすことなかれ」 動かないパッチを当てるよりもパッケージの重大なバグをそのままオープンな状態にしておく方が良いですし、パッチによってバグを解決するのではなく隠してしまうかもしれません。自分が 100% 何をしたのか分かっていないのであれば、他の人からアドバイスをもらうのも良い考えでしょう。NMU で何かを壊したのであれば、多くの人がとても不幸になるであろうことを覚えておいてください。
少なくとも BTS で、NMU するのを明確に表明しましたか? 他の手段 (プライベートなメール、IRC) でメンテナに連絡をとるのも良い考えです。
メンテナがいつも活動的で応答してくれる場合、彼に連絡を取ろうとしましたか? 大概の場合、メンテナ自身が問題に対応して、あなたのパッチをレビューする機会が与えられる方が好ましいと思われます。これは、NMU をする人が見落としているだろう潜在的な問題にメンテナは気付くことができるからです。大抵、メンテナが自分でアップロードする機会が与えられる方が、皆の時間を使うよりも良いやり方です。
NMU をする際には、まず NMU をする意図を明確にしておかねばなりません。それから、BTS へ現在のパッケージと提案する NMU
との差分をパッチとして送付する必要があります。devscripts
パッケージにある nmudiff スクリプトが役に立つでしょう。
パッチを準備している間、メンテナが利用しているであろうパッケージ固有の慣例に注意を向けた方がいいでしょう。これを考慮に入れることは、通常のパッケージの作業工程に対してあなたの変更が入る負担を減らし、それに従って変更が入る可能性を高めます。パッケージ固有の慣例がある可能性があるので探すと良い場所は、debian/README.source
です。
そうするべき十二分な理由が無い限り、メンテナに対応する時間を与えるべきです (例えば DELAYED
キューにアップロードすることによってこれを行います)。以下が delayed キューを使う際のお勧めの値です:
7 日以上経っているリリースクリティカルバグのみを修正するアップロードで、バグに対するメンテナの活動が 7 日間見られなく、修正が行われている形跡が無い: 0 日
7 日以上経っているリリースクリティカルバグのみを修正するアップロード: 2 日
リリースクリティカルバグや重要なバグの修正のみのアップロード: 5 日
他の NMU: 10 日
この値は例に過ぎません。セキュリティ問題を修正するアップロードや、移行を阻む些細なバグを修正するなど、いくつかのケースでは修正されたパッケージが
不安定版 (unstable)
にすぐ入るようになるのは望ましいことです。
時々、リリースマネージャが特定のバグに対して短い delay 日数の NMU を許可を認めることがあります (7 日より古いリリースクリティカルバグなど)。また、一部のメンテナは Low Threshold NMU list に自身を挙げており、遅延なしの NMU アップロードを許可しています。しかしどのような場合であっても、特にパッチが BTS で以前手に入らなかったり、メンテナが大抵アクティブであるのを知っている場合など、アップロードの前にメンテナに対して数日与えるのは良い考えです。
NMU アップロード後、あなたは自分が導入したであろう問題に責任を持つことになります。パッケージを見張らなければなりません (これを行うには PTS 上のパッケージを購読するのが良い方法です)。
これは、軽率な NMU を行うための許可証ではありません。明らかにメンテナがアクティブで時期を逃さずパッチについて対応している場合や、このドキュメントに書かれている推奨を無視している場合など、あなたによるアップロードはメンテナと衝突を起こすでしょう。NMU のメリットについて、自分が行ったことの賢明さを常に弁護できるようにしておく必要があります。
他の (ソース) アップロード同様、NMU は debian/changelog
にそのアップロードで何を変更したのかを示すエントリを追加せねばなりません。エントリの最初の行は、このアップロードが NMU
であることを明白に示す必要があります。例えばこうです:
* Non-maintainer upload.
NMU のバージョンのつけ方は、ネイティブなパッケージとネイティブではないパッケージでは異なります。
パッケージがネイティブパッケージの場合 (バージョン番号に Debian リビジョンが付かない)、バージョンはメンテナの最後のアップロードのバージョン
+ +nmu
となり、X
X
は 1
から始まる数字になります。最後のアップロードが同様に NMU の場合は、数字を増やします。例えば、現在のバージョンが
1.5
だとすると、NMU はバージョンが 1.5+nmu1
になります。
パッケージがネイティブパッケージではない場合は、バージョン番号の Debian リビジョン部分 (最後のハイフン以下の部分)
にマイナーバージョン番号を追加します。例えば、現在のバージョンが 1.5-2
であれば、NMU は
1.5-2.1
というバージョンになります。開発元のバージョンが新しくなったものが NMU
でパッケージになった場合は、Debian リビジョンは 0
に設定されます。例えば
1.6-0.1
です。
どちらの場合でも、最後のアップロードも NMU だった場合には数字が増えます。例えば、現在のバージョンが
1.5+nmu3
(既に NMU されたネイティブパッケージ) の場合、NMU は
1.5+nmu4
というバージョンになります。
特別なバージョン付け方法が必要とされるのは、メンテナの作業を混乱させるのを避けるためです。何故ならば、Debian リビジョンのために整数を使っていると、NMU の際に既に準備されていたメンテナによるアップロードや、さらには ftp NEW queue にあるパッケージともぶつかる可能性があります。これには、アーカイブのパッケージが公式メンテナによるものではない、と視覚的に明らかにする利点もあります。
テスト版 (testing) あるいは 不安定版 (unstable) にパッケージをアップロードした場合、バージョン番号のツリーを「分岐
(fork)」させねばならない時がしばしばあります。例えばセキュリティアップロードの場合です。この場合、+deb
というバージョン形式が使われる必要があり、XY
uZ
X
と
Y
はメジャーリリース番号とマイナーリリース番号で、Z
は 1
から始まる数字です。リリース番号がまだ分からない場合 (リリースサイクルの初期に テスト版 (testing)
に良くあることです)、最後の安定版リリース番号よりは大きい、最も小さなリリース番号を使います。例えば、Lenny (Debian 5.0)
が安定版の間は、バージョンが 1.5-3+deb50u1
であるパッケージの安定版へのセキュリティ NMU
はバージョン 1.5-3+deb50u1
になり、同様に Squeeze へのセキュリティ NMU はバージョン
1.5-3+deb60u1
になります。リリースのリリース後、テスト版
(testing)
ディストリビューションへのセキュリティアップロードは、リリースが Debian 6.1 なのか Debian
7.0 なのかが分かるまで +deb61uZ
とバージョンが付けられます (バージョンが Debian 7.0
になった場合は、アップロードは +deb70uZ
とバージョンが付けられます)。
NMU の許可を求めた後で待っているのは効率的ではありません。NMU
した人が作業にもどるために頭を切り替えるのに手間がかかるからです。DELAYED
キュー (「遅延アップロード」 参照) は、開発者が NMU
をするのに必要な作業を同時にできるようになります。例えば、メンテナに対して更新したパッケージを 7
日後にアップロードするのを伝えるのではなく、パッケージを DELAYED/7
にアップロードしてメンテナに対して対応するのに 7
日間あることを伝えるべきです。この間、メンテナはもっとアップロードを遅らせるかアップロードをキャンセルするかを尋ねることができます。
DELAYED
キューは、無用のプレッシャーをメンテナに与えるために使われるべきではありません。特に、メンテナはアップロードを自身ではキャンセルできないので、delay
が完了する前にアップロードをキャンセルあるいは遅らせることができるのはあなただ、という点が重要です。
DELAYED
を使った NMU を行って delay
が完了する前にメンテナがパッケージを更新した場合には、アーカイブに既により新しいバージョンがあるので、あなたのアップロードは拒否されます。理想的なのは、メンテナがそのアップロードであなたが提案した変更
(あるいは少なくとも対応した問題の解決方法) を含めるのを取り仕切ることです。
誰かがあなたのパッケージを NMU した場合、これは彼らがパッケージを良い形に保つのを助けたいと思っているということです。これによって、ユーザへ修正したパッケージをより早く届けます。NMU した人に、パッケージの副メンテナになることを尋ねるのを考えてみるのも良いでしょう。パッケージに対して NMU を受け取るのは悪いことではありません。それは、単にそのパッケージが他の人が作業する価値があるという意味です。
NMU を承認するには、変更と changelog のエントリを次のメンテナアップロードに含めます。バグは BTS で close されたままになりますが、パッケージのメンテナバージョンに影響していると表示されます。
NMU のフルネームはソース NMU です。もう一つ別の種類があって、バイナリのみの NMU (binary-only NMU) あるいは binNMU と名付けられています。binNMU も、パッケージメンテナ以外の誰かによるパッケージのアップロードです。しかし、これはバイナリのみのアップロードです。
ライブラリ (や他の依存関係) が更新された時、それを使っているパッケージを再ビルドする必要があるかもしれません。ソースへの変更は必要ないので、同じソースパッケージが利用されます。
binNMU は、通常 wanna-build によって buildd
上で引き起こされます。debian/changelog
にエントリが追加され、なぜアップロードが必要だったのか、という説明と 「再コンパイル、あるいは binary-only NMU」
で記述されているようにバージョン番号を増やします。このエントリは、その次のアップロードに含めるべきではありません。
buildd は、アーカイブするために、バイナリのみのアップロードとして、そのアーキテクチャに対してパッケージをアップロードします。厳密に言えば、これは
binNMU です。しかし、これは通常 NMU とは呼ばれず、debian/changelog
にエントリを追加しません。
NMU は、割り当てられているメンテナ以外の誰かによるパッケージのアップロードです。自分のものではないパッケージのアップロードについては、もう一つ、別の種類のアップロードがあります: QA アップロードです。QAアップロードは、みなしご化されたパッケージのアップロードです。
QA アップロードは、ほとんど通常のメンテナによるアップロードと同じです: 些細な問題であっても、なんでも修正します。バージョン番号の付け方は通常のものですし、delay アップロードをする必要もありません。違いは、パッケージのメンテナあるいはアップローダとして記載されていない点です。また、QA アップロードの changelog のエントリは以下のように最初の一行が特別になっています:
* QA upload.
あなたが NMU をしたいと思い、かつ、メンテナが活動的ではない場合、パッケージがみなしご化されてないかどうかを確認するのが賢明です
(この情報はパッケージ追跡システム (PTS) のページで表示されています)。みなしご化されたパッケージに対して最初の QA
アップロードを行うときは、メンテナは Debian QA Group
<packages@qa.debian.org>
に設定する必要があります。まだ QA
アップロードがされていないみなしご化されたパッケージには、以前のメンテナが設定されています。この一覧は http://qa.debian.org/orphaned.html で手に入ります。
QA アップロードをする代わりに、メンテナをあなた自身に変更してパッケージを引き取ることも考えられます。みなしご化されたパッケージを引き取るのには、誰からの許可も必要としません。メンテナをあなた自身に設定して新しいバージョンをアップロードするだけです (「パッケージに変更を加える」 を参照)。
パッケージングチーム (Maintainer
あるいは Uploader
としてメーリングリストを使う。「共同メンテナンス」 参照)
の一員であるため、時々パッケージを修正あるいは更新しているが、常にこの特定パッケージに貢献する予定は無いので自分を
Uploaders
には加えたくはない、という時があります。これがあなたのチームの方針に沿っているなら、直接
Maintainer
欄や Uploader
欄に記載せずとも通常のアップロードが可能です。この場合、changelog のエントリを以下の行で始める必要があります:
* Team upload.
共同メンテナンス (collaborative maintenance) は、Debian
パッケージのメンテナンス責任を数人でシェアすることを指す用語です。この共同作業は、通常はより上質で短いバグ修正時間をもたらすので、大抵の場合は常に良い考えです。優先度が標準
(standard
) あるいは基本セット (base) の一部であるパッケージは、副メンテナ
(co-maintainer) を持つことを強くお勧めします。
大抵の場合、主メンテナに加えて一人か二人の副メンテナが居ます。主メンテナは debian/control
ファイルの Maintainer
欄に名前が記載されている人です。副メンテナは他のすべてのメンテナで、通常
debian/control
ファイルの Uploaders
に記載されています。
もっとも基本的なやり方では、新しい副メンテナの追加は大変簡単です:
副メンテナが、あなたがビルドしたパッケージのソースにアクセスできるように設定します。一般に、これはあなたが CVS
や Subversion
のようなネットワークを利用するバージョン管理システムを利用しているということを意味しています。Alioth (「Debian での FusionForge の導入例: Alioth」 参照) はこの様なツールを提供しており、他でも同様です。
副メンテナの正確なメンテナ名とアドレスを debian/control
ファイルの最初の段落の
Uploaders
欄に追加します。
Uploaders: John Buzz <jbuzz@debian.org>, Adam Rex <arex@debian.org>
PTS (「パッケージ追跡システム」) を使う場合、副メンテナは適切なソースパッケージの購読をする必要があります。
共同メンテナンスのもう一つの形態はチームメンテナンスです。これは、複数のパッケージを同じ開発者グループでメンテナンスする場合にお勧めです。その場合、各パッケージの
Maintainer
欄と Uploaders
欄は注意して扱わねばいけません。以下の二つの案からいずれかを選ぶのがお勧めです:
パッケージの主に担当をするチームメンバーを Maintainer
欄に追加します。Uploaders
欄には、メーリングリストのアドレスとパッケージの面倒をみるチームメンバーを追加します。
メーリングリストのアドレスを Maintainer
欄に追加します。Uploaders
欄には、パッケージの面倒をみるチームメンバーを追加します。この場合、メーリングリストは (購読者以外に対するモデレーションなどの)
人手を介さずにバグ報告を受け取ることを確認する必要があります。
どのような場合でも、すべてのチームメンバーを Uploaders
欄に入れるのは良くない考えです。これは、Developer's Package Overview の一覧 (「Developer's packages overview」
参照)
を実際には対応していないパッケージで散らかしてしまい、偽りの良いメンテナンス状態を作り出します。同じ理由から、パッケージを一回アップロードするのであれば、「チームアップロード
(Team Upload)」ができるので、チームメンバーは Uploaders
欄へ自分を追加する必要はありません
(「NMU vs チームアップロード」 参照)。逆にいえば、Maintainer
欄にメーリングリストのアドレスのみで Uploaders
欄に誰も追加していないままにしておくのは良くない考えです。
通常、パッケージは不安定版 (unstable)
での必要ないくつかのテストを潜り抜けた後で、テスト版ディストリビューション(testing)
にインストールされます。
これらは、すべてのアーキテクチャ上で同期していなければならず、インストールできなくなるような依存関係を持ってはいけません。また、テスト版
(testing)
にインストールされる際に既知のリリースクリティカルバグを持っていない必要があります。このようにして、テスト版
(testing)
は常にリリース候補に近いものである必要があります。詳細は以下を参照してください。
テスト版 (testing)
ディストリビューションを更新するスクリプトは、日に二回、更新されたパッケージのインストール直後に動作します。これらのスクリプトは
britney
と呼ばれます。これは、テスト版 (testing)
ディストリビューションに対して Packages
ファイルを生成しますが、不整合を避けてバグが無いパッケージのみを利用しようとする気の利いたやり方で行います。
不安定版 (unstable)
からのパッケージの取り込みは以下の条件です:
パッケージは、urgency に応じて (high、medium、low)、2日、5日、10日の間、不安定版
(unstable)
で利用可能になっていなければいけません。urgency は貼り付くことに注意してください。つまり、前回の
テスト版 (testing)
への移行を考慮に入れてから最大の urgency
でアップロードされるということです。この遅延は、フリーズ期間の間は倍になるか、テスト版 (testing)
への移行が完全に無効にされます;
新たなリリースクリティカルバグを持っていないこと (不安定版 (unstable)
で利用可能なバージョンに影響する
RC バグであって、テスト版 (testing)
にあるバージョンに影響するものではない);
あらかじめ unstable
でビルドされた際に、全アーキテクチャで利用可能になっていなくてはいけません。この情報をチェックするのに dak ls に興味を持つかもしれません;
既にテスト版 (testing)
で利用可能になっているパッケージの依存関係を壊さないこと;
パッケージが依存するものは、テスト版 (testing)
で利用可能なものか、テスト版
(testing)
に同時に受け入れられるものでなくてはいけない
(そして、それらは必要な条件をすべて満たしていれば、テスト版 (testing)
) に入る)。
パッケージがテスト版 (testing)
に入る処理がされるかどうかは、テスト版ディストリビューションのウェブページのテスト版
(testing)
スクリプトの出力を参照するか、devscripts
パッケージ中の
grep-excuses プログラムを使ってください。このユーティリティは、パッケージがテスト版
(testing)
への進行の通知をし続けるのに、crontab(5) で手軽に使うことができます。
update_excuses
は、なぜパッケージが拒否されたのか正確な理由を必ずしも表示しません。自分自身で何がパッケージが含まれるのを妨げているのか、探す必要があるかもしれません。テスト版のウェブページが、そのような問題を引き起こす良くある問題についての情報を与えてくれるでしょう。
時折、相互依存関係の組み合わせが非常に難解なのでスクリプトが解決できないことがあるため、パッケージがテスト版
(testing)
に決して入らないことがあります。詳細は下記を参照してください。
依存性についてのさらなる分析は、http://release.debian.org/migration/ で表示されています — ですが、このページが britney が処理した依存性ではないものも表示しているのに注意してください。
テスト版 (testing)
への移行スクリプトの場合、時代遅れ (outdated)
というのが意味しているのは: リリースアーキテクチャに対して、複数の異なったバージョンが不安定版
(unstable)
にある (fuckedarches にあるアーキテクチャを除く。fuckedarches は
(update_out.py
中で)
更新を行わないアーキテクチャの一覧ですが、現在のところは空になっています)。時代遅れ (outdated) の場合、テスト版
(testing)
でこのパッケージが存在しているアーキテクチャに対して全く何もしません。
以下の例を考えてみましょう:
alpha | arm | |
---|---|---|
テスト版 | 1 | - |
不安定版 | 1 | 2 |
不安定版 (unstable)
での alpha
のパッケージは時代遅れになっているので、テスト版 (testing)
に入りません。パッケージの削除は全く役に立たず、alpha
ではパッケージは時代遅れのままで、テスト版 (testing)
には移行しません。
ですが、もしも ftp-master が不安定版 (unstable)
のパッケージ (ここでは
arm
の) を削除した場合:
alpha | arm | hurd-i386 | |
---|---|---|---|
テスト版 | 1 | 1 | - |
不安定版 | 2 | - | 1 |
この場合、パッケージは不安定版 (unstable)
ですべてのリリースアーキテクチャで最新になります
(それから、もう一つの hurd-i386
は、リリースアーキテクチャではないので問題になりません)。
時折、すべてのアーキテクチャでまだビルドされていていないパッケージを入れられるか、という質問がでてきます: いいえ。 単純にいいえ、です (glibc などをメンテしている場合を除きます)。
時折、パッケージは他のパッケージがテスト版へ入るために削除されます:
これは、他のパッケージが他のすべての面で準備ができている場合にテスト版に入るようにする場合のみ発生します。例えば、a
が新しいバージョンの b
とはインストールできない場合を考えてみましょう。その場合、a
は b
が入るために削除されるかもしれません。
もちろん、他にも テスト版 (testing)
からパッケージが削除される理由があります: バグが多すぎる場合です
(そして RC バグが1個だけあるのもこの状態とみなすのには十分です)。
さらに、パッケージが 不安定版 (unstable)
から削除され、テスト版
(testing)
にはこれに依存するパッケージがもうなくなった場合、パッケージは自動的に削除されます。
britney によってうまく取扱われない状況は、パッケージ a
がパッケージ
b
の新しいバージョンに依存していて、そしてその逆も、というものです。
この場合の例:
テスト版 | 不安定版 | |
---|---|---|
a | 1; depends: b=1 | 2; depends: b=2 |
b | 1; depends: a=1 | 2; depends: a=2 |
パッケージ a
あるいはパッケージ b
が更新対象と見做されない。
現状、このような場合はリリースチームによる手動でのヒントが必要になります。あなたのパッケージのどれかにこのような状況が起きた場合は、<debian-release@lists.debian.org>
にメールを送って連絡を取ってください。
一般的に言って、不安定版 (unstable)
にあるパッケージのステータスが意味するのは、不安定版 (unstable)
から テスト版
(testing)
へ移行する次のバージョン2 つの例外があります: パッケージの RC バグ数が減っている場合、RC
バグが残っていてもテスト版に入る可能性があります。2 つ目の例外は、テスト版 (testing)
のパッケージのバージョンが異なったアーキテクチャで同期していない場合です:
その場合、すべてのアーキテクチャがソースパッケージのバージョンへとアップグレードされることがあります。ですが、これはパッケージが以前にアーキテクチャが、テスト版
(testing)
への移行の際、不安定版 (unstable)
にそのアーキテクチャのバイナリパッケージが全くないという場合だけです
この要旨: 影響は、テスト版 (testing)
にあるパッケージが、同じパッケージの新しいバージョンになるのは、新しいバージョンの方が楽にできそうだから、ということです。
詳細について知りたい場合ですが、britney の動作は以下のようになります:
パッケージが、適切な候補であるかどうかを決めるために確認が行われます。これによって、更新が実行されます。パッケージが候補とみなされない理由でもっともよくあるのは、まだ日数が経過していない (too young)、RC バグがある、いくつかのアーキテクチャで古くなりすぎている、というものです。britney のこの部分では、リリースマネージャーが britney がパッケージを検討できるように様々なサイズのハンマーを使います (それから、base freeze が britney のこの部分のコードに記述されています)。(バイナリのみの更新 (binary-only update) についても同様ですが、ここでは記述しません。興味がある場合はコードを解析してください)。
さて、より複雑な部分に差し掛かります: Britney が適正候補を使ってテスト版 (testing)
を更新しようとします。このため、britney はテスト版ディストリビューションに個々の適正な候補を追加しようとします。テスト版
(testing)
でインストール不可能なパッケージの数が増えないのであれば、パッケージは受け入れられます。その時から、受け入れられたパッケージはテスト版
(testing)
の一部として取り扱われ、このパッケージを含めるためのインストールチェックテストが引き続き行われます。リリースチームからのヒントは、実際の内容に応じて、このメインの処理の前後に処理されます。
より詳細を見たい場合は、http://ftp-master.debian.org/testing/update_output/ で探すことができます。
hints は http://ftp-master.debian.org/testing/hints/ 経由で入手可能です。
テスト版 (testing)
ディストリビューションは、上記で説明したルールに従って 不安定版
(unstable)
からのパッケージで作られています。しかし、時折、テスト版
(testing)
の為だけに構築したパッケージをアップロードする必要があるという場合があります。そのためには、testing-proposed-updates
にアップロードするのが良いでしょう。
アップロードされたパッケージは自動的に処理されず、リリースマネージャの手によって処理される必要があることに注意してください。ですので、アップロードするのに十分な理由があるのが望ましいでしょう。何が十分な理由かを知るには、リリースマネージャの視点で、彼らが定期的に
<debian-devel-announce@lists.debian.org>
に流している指示を読む必要があります。
不安定版 (unstable)
でパッケージを更新できるのであれば、testing-proposed-updates
にアップロードすべきではありません。更新できない場合 (例えば、不安定版 (unstable)
に新しい開発版がある場合)、この機能を使うことができますが、まずはリリースマネージャから許可を得るのが良いでしょう。パッケージがフリーズされていても、不安定版
(unstable)
経由のアップロードが新たな依存関係を何も引き起こさない場合、不安定版
(unstable)
での更新は可能です。
バージョン番号は、通常テスト版 (testing)
ディストリビューションのコードネームと動作している番号を追加するなどして決定されます。例えば、1.2squeeze1
はパッケージバージョン 1.2
の
testing-proposed-updates
への最初のアップロードです。
アップロードで、以下の項目のいずれも見落とさないように必ずしてください:
本当に testing-proposed-updates
を通す必要があり、unstable
ではダメなことを確認する;
必ず、最小限な量だけの変更を含めるようにする;
必ず changelog 中に適切な説明を含める;
必ず、対象とするディストリビューションとして testing
か
testing-proposed-updates
を記述している;
必ず 不安定版 (unstable)
ではなく テスト版 (testing)
でパッケージを構築・テストしている;
バージョン番号が testing
および
testing-proposed-updates
のものよりも大きく、unstable
のものよりも小さいのを確認する;
アップロードしてすべてのプラットフォームで構築が成功したら、<debian-release@lists.debian.org>
宛でリリースチームに連絡を取って、アップロードを承認してくれるように依頼しましょう。
ある重要度以上のバグすべてが通常リリースクリティカルであると見なされます。現在のところ、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
を削除することになり、これに依存しているパッケージを壊してしまいます。
おそらく、これが主に影響するのは、一群のバイナリパッケージを変更したのを別バージョンで提供しているパッケージ (つまり、主にライブラリ) でしょう。しかし、バージョン付きの依存関係が ==、<=、<< などで宣言されているパッケージにも影響は及ぼします。
一つのソースパッケージによって提供されている一群のバイナリパッケージがこのようにして変更された場合、古いバイナリに依存しているすべてのパッケージは新しいバイナリに依存するように更新する必要があります。このようなソースパッケージをテスト版
(testing)
にインストールするとテスト版 (testing)
で依存しているすべてのパッケージを壊すことになるので、ここで注意をする必要があります:
すべての依存しているパッケージを更新し、インストールできるように準備しておくことで壊されないようにしておき、そして、すべての準備ができたら、通常はリリースマネージャあるいはリリースアシスタントによる手動作業が必要になります。
この様に複雑な組み合わせのパッケージで問題がある場合は、<debian-devel@lists.debian.org>
あるいは <debian-release@lists.debian.org>
に連絡を取って手助けを求めてください。
[3] パッケージがどのセクションに属するかのガイドラインは Debian ポリシーマニュアルを参照してください。
[4] 過去においては、再コンパイルのみの状態を意味するために、このような NMU はリビジョンの Debian 部分の三つ目の番号を使っていました。しかし、この記法はネイティブパッケージの場合に曖昧で、同一パッケージでの再コンパイルのみの NMU と、ソース NMU と、セキュリティ NMU の正しい順序が付けられなかったため、この新しい記法で置き換えられました。