目次
この章では、パッケージの作成、アップロード、メンテナンス、移植についての情報を扱います。
もしあなたが 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)
で暮らす人 (そして最前線のテスターである人)
の助けになる。我々はそのような人々を推奨すべきである。
メンテナや他に興味を持つ人々へ、プロジェクトで何が行われているのか、何か新しいことがあるかということ関して、告知は良い印象を与える。
新しいパッケージに対するよくある拒否理由については https://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」 を参照) 。
パッケージを削除して、再インストールする。
ソースパッケージを違うディレクトリにコピーして展開し、再構築する。これは、パッケージが外部の既存ファイルに依っているか、.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
ではないパッケージについてのみ記しています。
The first time a version is uploaded that corresponds to a particular
upstream version, the original source tar file must be uploaded and included
in the .changes
file. Subsequently, this very same tar
file should be used to build the new diffs and .dsc
files, and will not need to be re-uploaded.
デフォルトでは、dpkg-genchanges および
dpkg-buildpackage は前述されている changelog エントリと現在のエントリが異なった
upstream バージョンを持つ場合にのみ、オリジナルのソース tar
ファイルを含めようとします。この挙動は、-sa
を使って常に含めたり、-sd
を使うことで常に含めないようにするように変更できます。
アップロード時にオリジナルのソースが含まれていない場合、アップロードされる .dsc
と diff
ファイルを構築する際に dpkg-source が使用するオリジナルの tar
ファイルは、必ず既にアーカイブにあるものと 1 バイトも違わぬものでなくてはなりません。
Please notice that, in non-native packages, permissions on files that are
not present in the *.orig.tar.{gz,bz2,xz}
will not be
preserved, as diff does not store file permissions in the patch. However,
when using source format “3.0 (quilt)”, permissions of files inside the
debian
directory are preserved since they are stored in
a tar archive.
アップロードでは、パッケージがどのディストリビューション向けになっているかを指定してあることが必要です。パッケージの構築プロセスでは、debian/changelog
ファイルの最初の行からこの情報を展開し、.changes
ファイルの
Distribution
欄に配置します。
パッケージは、通常 unstable
へアップロードされます。unstable
あるいは experimental
へのアップロードはこれらの suite を changelog のエントリに記します。サポートされている他の suite
へのアップロードは、曖昧さを避けるために suite のコードネームを使う必要があります。
実際には、他にも指定可能なディストリビューションがあります: codename-security
ですが、その詳細については 「セキュリティ関連バグの取扱い」 を読んでください。
同時に複数のディストリビューションへ、パッケージをアップロードすることはできません。
安定版 (stable)
へのアップロードは、安定版リリースマネージャによるレビューのため、パッケージは
proposed-updates-new
キューに転送され、許可された場合は Debian アーカイブの
stable-proposed-updates
ディレクトリにインストールされます。ここから、ここから、安定版 (stable)
の次期ポイントリリースに含まれることになります。
アップロードが許可されるのを確実にするには、アップロードの前に変更点について安定版リリースチームと協議する必要があります。そのためには、reportbug
コマンドを使って、現在の安定版 (stable)
へ適用したいパッチを含めて release.debian.org
擬似パッケージへバグを登録してください。パッチは、安定版
にある現在のバージョンに対する source
debdiff である必要があります。changelog エントリは、安定版
ディストリビューションに対するものである必要があり (例:
`buster')、くどいほど詳細で、アップロードで修正されるバグに対する Closes
宣言を含んでいなければなりません。
安定版 (stable)
へのアップロード時には特に注意を払うことが必要です。基本的に、以下のいずれかが起こった際にのみ 安定版
(stable)
へパッケージはアップロードされます:
本当に致命的な機能の問題がある
パッケージがインストールできなくなる
リリースされたアーキテクチャにパッケージが無い
In the past, uploads to stable
were used to address
security problems as well. However, this practice is deprecated, as uploads
used for Debian security advisories (DSAs) are automatically copied to the
appropriate proposed-updates
archive when the advisory
is released. See 「セキュリティ関連バグの取扱い」 for detailed information on
handling security problems. If the security team deems the problem to be too
benign to be fixed through a DSA
, the stable release
managers are usually willing to include your fix nonetheless in a regular
upload to stable
.
些細な修正でも後ほどバグを引き起こすことがあるので、重要でないものは何であろうと変更するのは推奨されません。
安定版 (stable)
にアップロードされるパッケージは安定版
(stable)
を動作しているシステム上でコンパイルされていなければならず、ライブラリ (やその他のパッケージ)
への依存は安定版 (stable)
で入手可能なものに限られます。例えば、安定版
(stable)
にアップロードされたパッケージが不安定版 (unstable)
にのみ存在するライブラリパッケージに依存していると reject されます。他のパッケージへの依存を (提供
(Provides)
や shlibs
をいじることで)
変更するのは、他のパッケージをインストールできないようにする可能性があるので認められません。
旧安定版 (oldstable)
ディストリビューションへのアップロードはアーカイブされてない限り可能です。安定版
(stable)
と同じルールが適用されます。
詳細については、testing section にある情報を参照してください。
To upload a package, you should upload the files (including the signed
changes and dsc file) with anonymous ftp to
ftp.upload.debian.org
in the directory /pub/UploadQueue/. To get
the files processed there, they need to be signed with a key in the Debian
Developers keyring or the Debian Maintainers keyring (see https://wiki.debian.org/DebianMaintainer).
changes ファイルは最後に転送する必要があることに注意してください。そうしないとアーカイブのメンテナンスを行っているソフトが changes ファイルをパースして全てのファイルがアップロードされていないと判断して、アップロードは reject されるかもしれません。
パッケージのアップロードを行う際には dupload や dput が便利なことにも気づくことでしょう。これらの便利なプログラムは、パッケージを Debian にアップロードする作業を自動化するのに役立ちます。
パッケージを削除するには ftp://ftp.upload.debian.org/pub/UploadQueue/README と dcut Debian パッケージを参照してください。
パッケージを直ちにアップロードするのが良い時もありますが、パッケージがアーカイブに入るのが数日後であるのが良いと思う時もあります。例えば、Non-Maintainer アップロードの準備をする際は、メンテナに対して猶予期間を数日間与えたいと思うでしょう。
delayed ディレクトリにアップロードされると、パッケージは the deferred uploads
queue に保存されます。指定した待ち時間が終わると、パッケージは処理のため通常の incoming
ディレクトリに移動されます。この作業は ftp.upload.debian.org
の
DELAYED/
ディレクトリへのアップロードを通じて自動的に処理されます (X
-dayX
は 0 から 15
の間です)。0-day は一日に複数回 ftp.upload.debian.org
へアップロードするのに使われます。
dput を使うと、パッケージを遅延キューに入れるのに --delayed
パラメータを使えます。
DELAY
Do NOT upload a package to the security
upload queue (on *.security.upload.debian.org
) without
prior authorization from the security team. If the package does not exactly
meet the team's requirements, it will cause many problems and delays in
dealing with the unwanted upload. For details, please see 「セキュリティ関連バグの取扱い」.
ヨーロッパにはもう一つのアップロードキューが 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)
に存在しているパッケージの更新は自動的に処理されます。それ以外の場合、特に新規パッケージの場合は、アップロードされたパッケージをディストリビューションに含めるのは手動で行われます。アップロードが手動で処理される場合は、アーカイブへの変更は実施されるまでに一ヶ月ほどかかります。お待ちください。
どの場合であっても、パッケージがアーカイブに追加されたことや、バグがアップロードで閉じられたことを告げるメールでの通知を受け取ることになります。あなたが閉じようとしたバグが処理されてない場合は、この通知を注意深く確認してください。
インストール通知は、パッケージがどのセクションに入ったかを示す情報を含んでいます。不一致がある場合は、それを示す別のメール通知を受け取ります。以下も参照ください。
キュー経由でアップロードした場合は、キューデーモンソフトウェアもメールで通知を行うことに留意してください。
Also note that new uploads are announced on the IRC channel
#debian-devel-changes
. If your upload fails silently, it
could be that your package is improperly signed, in which case you can find
more explanations on
ssh.upload.debian.org:/srv/upload.debian.org/queued/run/log
.
debian/control
ファイルの セクション (Section)
フィールドと 優先度 (Priority)
フィールドは実際にアーカイブ内でどこに配置されるか、あるいはプライオリティが何かという指定ではありません。debian/control
ファイル中の値は、実際のところは単なるヒントです。
アーカイブメンテナは、override
ファイル
内でパッケージについて定められたセクションと優先度を常に確認しています。override
ファイル
と debian/control
で指定されたパッケージのフィールドに不一致がある場合、パッケージがアーカイブにインストールされる際に相違について記述されたメールを受け取ります。debian/control
ファイルを次回のアップロード時に修正することもできますし、override
ファイル
に変更を加えるように依頼するのもよいでしょう。
パッケージが現状で置かれているセクションを変更するには、まずパッケージの debian/control
ファイルが正しいことを確認する必要があります。次に、ftp.debian.org
に対し、あなたのパッケージに対するセクションあるいは優先度について古いものから新しいものへ変更する依頼のバグ登録をします。override:
PACKAGE1:section/priority, [...], PACKAGEX:section/priority
のようなサブジェクトを使い、バグ報告の本文に変更に関する根拠を記述してください。
override ファイル
についての詳細は、dpkg-scanpackages(1) と https://www.debian.org/Bugs/Developer#maintincorrect
を参照してください。
「セクション」 で書かれているように、セクション
(Section)
フィールドにはセクション同様にサブセクションも記述するのに注意ください。セクションが main
の場合は、それは書かないようにしてください。利用可能なサブセクションは https://www.debian.org/doc/debian-policy/ch-archive.html#s-subsections で検索できます。
すべての開発者は Debian バグ追跡システムを取り扱えるようでなければいけません。これは、どの様にしてバグ報告を正しく登録するか (「バグ報告」 参照)、どの様に更新及び整理するか、そしてどの様にして処理をして完了するかを知っていることを含みます。
バグ追跡システムの機能は、Debian BTS 開発者向け情報に記載されています。これには、バグの完了処理・追加メッセージの送信・重要度とタグを割り当てる・バグを転送済み (Forwarded) にする・その他が含まれています。
バグを他のパッケージに割り当てし直す、同じ問題についての別々のバグ報告をマージする、早まってクローズされたバグの再オープンなどの作業は、いわゆる制御メールサーバと呼ばれるものを使って処理されています。このサーバで利用可能なすべてのコマンドは、BTS 制御サーバドキュメントに記載されています。
良いメンテナになりたい場合は、あなたのパッケージに関する Debian バグ追跡システム
(BTS) のページを定期的にチェックする必要があります。BTS
には、あなたのパッケージに対して登録されている全てのバグが含まれています。登録されているバグについては、以下のページを参照することで確認できます:
https://bugs.debian.org/
yourlogin
@debian.org
メンテナは、bugs.debian.org
のメールアドレス経由で BTS
に対応します。利用可能なコマンドについてのドキュメントは https://www.debian.org/Bugs/ で参照可能ですし、もし
doc-debian
パッケージをインストールしてあれば、ローカルファイル /usr/share/doc/debian/bug-*
で見ることも可能です。
定期的にオープンになっているバグについてのレポートを受け取るのも良いでしょう。あなたのパッケージでオープンになっているバグの全一覧を毎週受け取りたい場合、以下のような cron ジョブを追加します:
# 自分のパッケージにあるバグのレポートを毎週取得する
0 17 * * fri echo "index maint address
" | mail request@bugs.debian.org
address
は、あなたの公式な Debian
パッケージメンテナとしてのメールアドレスに置き換えてください。
When responding to bugs, make sure that any discussion you have about bugs
is sent to the original submitter of the bug, the bug itself and (if you are
not the maintainer of the package) the maintainer. Sending an email to
<
will send the mail
to the maintainer of the package and record your email with the bug log. If
you don't remember the submitter email address, you can use
123
@bugs.debian.org><
to also
contact the submitter of the bug. The latter address also records the email
with the bug log, so if you are the maintainer of the package in question,
it is enough to send the reply to
123
-submitter@bugs.debian.org><
.
Otherwise you should include
123
-submitter@bugs.debian.org><
so that you also
reach the package maintainer.
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:
を追加します)。これは複数の開発者が同一のパッケージで作業している際に特に役立ちます。
Once a corrected package is available in the archive, the bug should be closed indicating the version in which it was fixed. This can be done automatically; read 「新規アップロードでバグがクローズされる時」.
バグや問題があなたのパッケージで修正されたとしたら、そのバグを閉じるのはパッケージメンテナとしての責任になります。しかし、バグを修正したパッケージが Debian アーカイブに受け入れられるまではバグを閉じてはいけません。従って、一旦更新したパッケージがアーカイブにインストールされたという通知を受け取った場合は、BTS でバグを閉じることができますし、そうしなければいけません。もちろん、バグは正しいバージョンで閉じなくてはいけません。
ですが、アップロード後に手動でバグをクローズしなくても済む方法があります — debian/changelog
に以下の特定の書き方にて修正したバグを列挙すれば、それだけで後はアーカイブのメンテナンスソフトがバグをクローズしてくれます。例:
acme-cannon (3.1415) unstable; urgency=low * Frobbed with options (closes: Bug#98339) * Added safety to prevent operator dismemberment, closes: bug#98765, bug#98713, #98714. * Added man page. Closes: #98725.
技術的に言うと、どの様にしてバグを閉じる changelog が判別されているかを以下の Perl の正規表現にて記述しています:
/closes:\s*(?:bug)?\#\s*\d+(?:,\s*(?:bug)?\#\s*\d+)*/ig
We prefer the closes: #
syntax, as it is the most concise entry and the easiest to integrate with
the text of the XXX
changelog
. Unless specified
differently by the -v
-switch to
dpkg-buildpackage, only the bugs closed in the most
recent changelog entry are closed (basically, exactly the bugs mentioned in
the changelog-part in the .changes
file are closed).
歴史的に、non-maintainer upload (NMU) と判別されるアップロードは
closed ではなく fixed
とタグがされてきましたが、この習慣はバージョントラッキングの進化によって廃れています。同じことが
fixed-in-experimental
タグにも言えます。
もしバグ場号を間違って入力したり、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 パッケージ中のセキュリティ関連のバグに気づいたら、あなたがメンテナであるかどうかに関わらず、問題に関する正確な情報を集め、まずは
<team@security.debian.org>
宛にメールを出してセキュリティチームへ連絡を取ってください。お望みであれば、Debian
セキュリティ担当窓口の鍵を使ってメールを暗号化できます。詳細は https://www.debian.org/security/faq#contact を参照してください。チームに問い合わせること無く
安定版 (stable)
向けのパッケージをアップロードしないでください。例として、役に立つ情報は以下のようなものになります:
バグが既に公開されているか否か
バグによって、どのバージョンが影響を受けると分かっているか。サポートされている Debian のリリース、ならびに テスト版
(testing)
及び 不安定版 (unstable)
にある各バージョンをチェックしてください。
利用可能なものがあれば、修正内容 (パッチが特に望ましい)
自身で準備した修正パッケージ (まずは 「セキュリティ問題に対処するパッケージを用意する」 を読んで、debdiff
の結果、あるいは .diff.gz
と .dsc
ファイルだけを送ってください)
テストについて何かしらの手助けになるもの (攻撃コード、リグレッションテストなど)
勧告に必要になる情報 (「セキュリティ勧告」 参照)
パッケージメンテナとして、あなたは安定版リリースについてもメンテナンスする責任を持ちます。あなたがパッチの評価と更新パッケージのテストを行うのに最も適任な人です。ですから、以下のセキュリティチームによって取り扱ってもらうため、どのようにしてパッケージを用意するかについての章を参照してください。
セキュリティチームは集約的なデータベース、Debian セキュリティ追跡システム (Debian Security Tracker)をメンテナンスしています。これはセキュリティ問題として知られている全ての公開情報を含んでいます: どのパッケージ/バージョンが影響を受ける/修正されているか、つまりは安定版、テスト版、不安定版が脆弱かどうか、という情報です。まだ機密扱いの情報は追跡システムには追加されません。
特定の問題について検索することもできますし、パッケージ名でも検索できます。あなたのパッケージを探して、どの問題がまだ未解決かを確認してください。できれば追加情報を提供するか、パッケージの問題に対処するのを手伝ってください。やり方は追跡システムのウェブページにあります。
Debian 内での他の多くの活動とは違い、セキュリティ問題に関する情報については、暫くの間秘密にしておく必要がしばしばあります。これによって、ソフトウェアのディストリビュータがユーザが危険にさらされるのを最小限にするため、公開時期を合わせることができます。今回がそうであるかは、問題と対応する修正の性質や、既に既知のものとなっているかどうかによります。
開発者がセキュリティ問題を知る方法はいくつかあります:
公開フォーラム (メーリングリスト、ウェブサイトなど) で知らせる
誰かがバグ報告を登録している
誰かがプライベートなメールで教えてきた
最初の二つのケースでは、情報は公開されていて可能な限り早く修正することが重要です。しかしながら最後のケースは、公開情報ではないかもしれません。この場合は、問題に対処するのに幾つか取り得る選択肢があります:
セキュリティの影響度が小さい場合、問題を秘密にしておく必要はなく、修正を行ってリリースするのが良い場合がしばしばあります。
問題が深刻な場合、他のベンダと情報を共有してリリースをコーディネイトする方が望ましいでしょう。セキュリティチームは様々な組織/個人と連絡を取りつづけ、この問題に対応することができます。
どのような場合でも、問題を報告した人がこれを公開しないように求めているのであれば、明白な例外として Debian の安定版リリースに対する修正を作成してもらうためにセキュリティチームへ連絡すること以外、この様な要求は尊重されるべきです。機密情報をセキュリティチームに送る場合は、この点を明示しておくのを忘れないでください。
機密を要する場合は、修正を不安定版 (unstable)
(や公開 VCS リポジトリなどその他どこへも)
へ修正をアップロードしないよう、注意してください。コードその物が公開されている場合、変更の詳細を難読化するだけでは十分ではなく、皆によって解析され得る
(そしてされる) でしょう。
機密であることを要求されたにも関わらず、情報を公開するのには 2 つの理由があります: 問題が一定期間既知の状態になっている、あるいは問題や攻撃コードが公開された場合です。
セキュリティチームは、機密事項に関して通信を暗号化できる PGP 鍵を持っています。詳細については、セキュリティチーム FAQ を参照してください。
セキュリティ勧告は現在のところ、リリースされた安定版ディストリビューションについてのみ、取り扱われます。テスト版
(testing)
や 不安定版 (unstable)
についてではありません。リリースされると、セキュリティ勧告は
email-debian-security-announce; メーリングリストに送られ、セキュリティのウェブページに掲載されます。セキュリティ勧告はセキュリティチームによって記述、掲載されます。しかし、メンテナが情報を提供できたり、文章の一部を書けるのであれば、彼らは当然そんなことは気にしません。勧告にあるべき情報は以下を含んでいます:
以下のようなものを含めた問題の説明と範囲:
問題の種類 (権限の上昇、サービス拒否など)
何の権限が得られるのか、(もし分かれば) 誰が得るのか
どのようにして攻撃が可能なのか
攻撃はリモートから可能なのかそれともローカルから可能なのか
どのようにして問題が修正されたのか
この情報によって、ユーザがシステムに対する脅威を評価できるようになります。
影響を受けるパッケージのバージョン番号
修正されたパッケージのバージョン番号
どこで更新されたパッケージを得るかという情報 (通常は Debian のセキュリティアーカイブからです)
開発元のアドバイザリへの参照、CVE 番号、脆弱性の相互参照について役立つその他の情報
あなたがセキュリティチームに対し、彼らの職務に関して手助けできる方法の一つは、安定版 Debian リリース用のセキュリティ勧告に適した修正版パッケージを提供することです。
When an update is made to the stable release, care must be taken to avoid changing system behavior or introducing new bugs. In order to do this, make as few changes as possible to fix the bug. Users and administrators rely on the exact behavior of a release once it is made, so any change that is made might break someone's system. This is especially true of libraries: make sure you never change the API (Application Program Interface) or ABI (Application Binary Interface), no matter how small the change.
これは、開発元の新しいリリースバージョン (new upstream version) への移行が良い解決策ではないことを意味しています。代わりに、関連する変更を現在の Debian 安定版リリースに存在しているバージョンへバックポートするべきです。通常、開発元のメンテナは助けが必要であれば手伝おうとしてくれます。そうでない場合は、Debian セキュリティチームが手助けすることができます。
いくつかのケースでは、例えば大量のソースコードの変更や書き直しが必要など、セキュリティ修正をバックポートできないことがあります。この様な場合、新しいバージョン (new upstream version) へ移行する必要があるかもしれません。しかし、これは極端な状況の場合にのみ行われるものであり、実行する前に必ずセキュリティチームと調整をしなければなりません。
これに関してはもう一つ重要な指針があります: 必ず変更についてテストをしてください。攻撃用コード (exploit) が入手可能な場合には、それを試してみて、パッチを当てていないパッケージで成功するか、修正したパッケージでは失敗することかどうかを確かめてみてください。他の確認として、セキュリティ修正は時折表面上はそれと関係が無いような機能を壊すことがあるので、通常の動作も同様にテストしてください。
脆弱性の修正に直接関係しない変更をパッケージへ加えないようにしてください。この様な変更は元に戻さなくてはならなくなるだけで、時間を無駄にします。他に直したいバグがパッケージにある場合は、セキュリティ勧告が発行された後、通常通りに proposed-update にアップロードを行ってください。セキュリティ更新の仕組みは、それ以外の方法では安定版リリースから reject されるであろう変更をあなたのパッケージに加える方法ではありませんので、この様な事はしないでください。
変更点を可能な限り見直してください。以前のバージョンとの変更点を繰り返し確認してください (これには patchutils
パッケージの interdiff や
devscripts
の
debdiff が役立ちます。「debdiff」 を参照してください)。
以下の項目を必ず確認してください
debian/changelog
で 正しいディストリビューションを対象にする:
codename
-security
(例えば
buster-security
)。distribution
-proposed-updates
や stable
を対象にしないでください!
アップロードは urgency=high で行う必要があります。
説明が十分にされている、意味がある changelog
エントリを書くこと。他の人は、これらを元に特定のバグが修正されているのかを見つけ出します。登録されている Debian バグ に対して closes:
行を追加すること。外部のリファレンス、できれば CVE 識別番号
を常に含めること、そうすれば相互参照が可能になります。しかし、CVE
識別番号がまだ付与されていない場合には、それを待たずに作業を進めてください。識別番号は後ほど付与することができます。
バージョン番号が正しいことを確認する。現在のパッケージより大きく、しかし以降のディストリビューションよりパッケージバージョンが小さい必要があります。分からない場合は
dpkg --compare-versions
でテストしてください。以前のアップロードで既に使っているバージョン番号を再利用しないように注意してください。そうしないと番号が binNMU
と衝突します。+deb
X
u1
(X
はメジャーリリース番号) を追加するのが通例です。例えば
1:2.4.3-4+deb10u1
とします。もちろん 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
」
を参照してください)。
Do NOT upload a package to the security
upload queue (on *.security.upload.debian.org
) without
prior authorization from the security team. If the package does not exactly
meet the team's requirements, it will cause many problems and delays in
dealing with the unwanted upload.
セキュリティチームと調整する事無しに proposed-updates
へ修正したものをアップロードしないようにしてください。security.debian.org
からパッケージは proposed-updates
ディレクトリに自動的にコピーされます。アーカイブに同じ、あるいはより高いバージョン番号のものが既にインストールされている場合は、セキュリティアップデートはアーカイブシステムに
reject されます。そうすると、安定版ディストリビューションはこのパッケージに対するセキュリティ更新無しで終了してしまうでしょう。
Once you have created and tested the new package and it has been approved by
the security team, it needs to be uploaded so that it can be installed in
the archives. For security uploads, the place to upload to is
ftp://ftp.security.upload.debian.org/pub/SecurityUploadQueue/
.
セキュリティキューへアップロードしたものが許可されると、パッケージは自動的にすべてのアーキテクチャに対してビルドされ、セキュリティチームによる確認の為に保存されます。
Uploads that are waiting for acceptance or verification are only accessible by the security team. This is necessary since there might be fixes for security problems that cannot be disclosed yet.
セキュリティチームのメンバーがパッケージを許可した場合は、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 ファイルを更新する必要が出てくるでしょう。
If for some reason you want to completely remove a package (say, if it is an
old compatibility library which is no longer required), you need to file a
bug against ftp.debian.org
asking
that the package be removed; as with all bugs, this bug should normally have
normal severity. The bug title should be in the form RM:
, where
package
[architecture
list]
-- reason
package
is the package to be removed and
reason
is a short summary of the reason for the
removal request. [architecture list]
is optional
and only needed if the removal request only applies to some architectures,
not all. Note that the reportbug will create a title
conforming to these rules when you use it to report a bug against the
ftp.debian.org
pseudo-package.
If you want to remove a package you maintain, you should note this in the
bug title by prepending ROM
(Request Of Maintainer).
There are several other standard acronyms used in the reasoning for a
package removal; see https://ftp-master.debian.org/removals.html for a complete
list. That page also provides a convenient overview of pending removal
requests.
Note that removals can only be done for the unstable
,
experimental
and stable
distributions. Packages are not removed from testing
directly. Rather, they will be removed automatically after the package has
been removed from unstable
and no package in
testing
depends on it. (Removals from
testing
are possible though by filing a removal bug
report against the release.debian.org
pseudo-package. See 「テスト版からの削除」.)
例外として、明示的な削除依頼が必要ない場合が一つあります: (ソース、あるいはバイナリ) パッケージがソースからビルドされなくなった場合、半自動的に削除されます。バイナリパッケージの場合、これはこのバイナリパッケージを生成するソースパッケージがもはや存在しないということを意味します。バイナリパッケージがいくつかのアーキテクチャで生成されなくなったという場合には、削除依頼は必要です。ソースパッケージの場合は、関連の全バイナリパッケージが別のソースパッケージによって上書きされるのを意味しています。
削除依頼では、依頼を判断する理由を詳細に書く必要があります。これは不必要な削除を避け、何故パッケージが削除されたのかを追跡できるようにするためです。例えば、削除されるパッケージにとって代わるパッケージの名前を記述します。
通常は自分がメンテナンスしているパッケージの削除のみを依頼します。その他のパッケージを削除したい場合は、メンテナの許可を取る必要があります。パッケージが放棄されたのでメンテナがいない場合は、まず
<debian-qa@lists.debian.org>
で削除依頼について議論をしてください。パッケージの削除についての合意ができたら、削除依頼の新規バグを登録するのではなく、wnpp
パッケージに対して登録されているバグを reassign して O:
に題名を変更するべきです。
この件、あるいはパッケージ削除に関するその他のトピックについて、さらなる情報を https://wiki.debian.org/ftpmaster_Removals や https://qa.debian.org/howto-remove.html で参照できます。
パッケージを破棄しても構わないか迷う場合には、意見を聞きに <debian-devel@lists.debian.org>
へメールしてください。apt
の apt-cache
プログラムも重要です。apt-cache showpkg
として起動した際、プログラムはパッケージ名
パッケージ名
の非依存関係を含む詳細を表示します。他にも
apt-cache
rdepends、apt-rdepends、build-rdeps
(devscripts
パッケージに含まれる)、grep-dctrl
などの有用なプログラムが非依存関係を含む情報を表示します。みなしご化されたパッケージの削除は、<debian-qa@lists.debian.org>
で話し合われます。
一旦パッケージが削除されたら、パッケージのバグを処理する必要があります。実際のコードが別のパッケージに含まれるようになったので、別のパッケージへバグを付け替える
(例えば、libfoo13
が上書きするので、libfoo12
が削除される) か、あるいはソフトウェアがもう Debian の一部では無くなった場合にはバグを閉じるかする必要があります。バグを閉じる場合、過去の
Debian のリリースにあるパッケージバージョンで修正されたとマークするのを避けてください。バージョン
<most-recent-version-ever-in-Debian>+rm
で修正されたとマークしなければなりません。
以前は、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 でリストに挙がっているパッケージのどれかに対するメンテナンスを引き継ぎたい場合には、情報と手続きについては前述のページを確認してください。
It is not OK to simply take over a package without assent of the current maintainer — that would be package hijacking. You can, of course, contact the current maintainer and ask them for permission to take over the package.
However, when a package has been neglected by the maintainer, you might be able to take over package maintainership by following the package salvaging process as described in 「Package Salvaging」. If you have reason to believe a maintainer is no longer active at all, see 「活動的でない、あるいは連絡が取れないメンテナに対応する」.
Complaints about maintainers should be brought up on the developers' mailing list. If the discussion doesn't end with a positive conclusion, and the issue is of a technical nature, consider bringing it to the attention of the technical committee (see the technical committee web page for more information).
古いパッケージを引き継いだ場合は、おそらくバグ追跡システムでパッケージの公式メンテナとして表示されるようにしたいことでしょう。これは、一旦
Maintainer
欄を更新した新しいバージョンをアップロードすれば自動的に行われますが、アップロードが完了してから数時間はかかります。しばらくは新しいバージョンをアップロードする予定が無い場合は、「Debian パッケージトラッカー」
を使ってバグ報告を受け取ることができます。しかし、以前のメンテナにしばらくの間はバグ報告が届き続けても問題無いことを確認してください。
パッケージは、リリースクリティカルのバグやメンテナ不在、不人気あるいは全体的な品質の低さ等により削除されることがよくあります。再導入プロセスはパッケージ化の開始時と似ていますが、あらかじめその歴史的経緯を調べておくことにより、落し穴にはまるのをいくらか避けることができます。
まず初めに、パッケージが削除された理由を確認しましょう。この情報はそのパッケージの PTS ページのニュースから削除の項目か削除ログを探すことにより見つけられます。削除のバグにはそのパッケージが削除された理由や、そのパッケージの再導入にあたって必要なことがいくらか提示されているでしょう。パッケージの再導入ではなくどこか他のソフトウェアの一部への乗り替えが最適であるということが提示されているかもしれません。
以前のメンテナに連絡を取り、パッケージの再導入のために作業していないか、パッケージ共同保守に関心はないか、必要になったときにパッケージのスポンサーをしてくれないか、等を確認しておくと良いでしょう。
新しいパッケージ (「新規パッケージ」) の導入前に必要なことは全てやりましょう。
利用できる中で適切な最新のパッケージをベースに作業しましょう。これはunstable
の最新版かもしれません。また、snapshot
アーカイブにはまだ存在するでしょう。
前のメンテナにより利用されていたバージョン管理システムに有用な変更が記録されているかもしれないので、確認してみるのは良いことです。以前のパッケージの
control
ファイルにそのパッケージのバージョン管理システムにリンクしているヘッダが無いか、それがまだ存在するか確認してください。
(testing
や
stable
、oldstable
ではなく)
unstable
からパッケージが削除されると、そのパッケージに関連するバグは全て閉じられます。閉じられたバグを全て (アーカイブされているバグを含めて)
確認し、+rm
で終わるバージョンで閉じられていて現在でも有効なものを全て unarchive および
reopen してください。有効ではなくなっているものは修正されているバージョンがわかればすべて修正済みとしてください。
Package removals from unstable also trigger marking the package as removed in the security tracker. Debian members should mark removed issues as unfixed in the security tracker repository and all others should contact the security team to report reintroduced packages.
Debian がサポートするアーキテクチャの数は増え続けています。あなたが移植作業者ではない、あるいは別のアーキテクチャを使うことが無いという場合であっても、移植性の問題に注意を払うことはメンテナとしてのあなたの義務です。従って、あなたが移植作業者でなくても、この章の大半を読む必要があります。
Porting is the act of building Debian packages for architectures that are
different from the original architecture of the package maintainer's binary
package. It is a unique and essential activity. In fact, porters do most
of the actual compiling of Debian packages. For instance, when a maintainer
uploads a (portable) source package with binaries for the
i386
architecture, it will be built for each of the other
architectures, amounting to 10 more builds.
移植作業者は、難解かつ他には無いタスクを抱えています。それは、彼らは膨大な量のパッケージに対処する必要があるからです。理想を言えば、すべてのソースパッケージは変更を加えないできちんとビルドできるべきです。残念なことに、その様な場合はほとんどありません。この章は Debian メンテナによってよくコミットされる「潜在的な問題」のチェックリストを含んでいます — よく移植作業者を困らせ、彼らの作業を不必要に難解にする共通の問題です。
The first and most important thing is to respond quickly to bugs or issues raised by porters. Please treat porters with courtesy, as if they were in fact co-maintainers of your package (which, in a way, they are). Please be tolerant of succinct or even unclear bug reports; do your best to hunt down whatever the problem is.
移植作業者が遭遇する問題のほとんどは、何といっても、ソースパッケージ内でのパッケージ作成のバグによって引き起こされます。以下は、確認あるいは注意すべき項目のリストです。
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
など) は大抵誤りです。
ソースパッケージが正しいことを確かめてください。ソースパッケージが正しく展開されたのを確認するため、dpkg-source -x
を実行してください。そして、ここでは、一からパッケージを dpkg-buildpackage
でビルドするのに挑戦してみてください。
package
.dsc
debian/files
や debian/substvars
を含んだソースパッケージを出していないかを確かめてください。これらは、debian/rules
の
clean
ターゲットによって削除されるべきです。
Make sure you don't rely on locally installed or hacked configurations or
programs. For instance, you should never be calling programs in
/usr/local/bin
or the like. Try not to rely on
programs being set up in a special way. Try building your package on
another machine, even if it's the same architecture.
構築中の既にインストールしてあるパッケージに依存しないでください (上記の話の一例です)。もちろん、このルールには例外はありますが、そのような場合には手動で一から環境を構築する必要があり、パッケージ作成マシンで自動的に構築することはできません。
可能であれば、特定のバージョンのコンパイラに依存しないでください。もし無理であれば、その制約をビルドの依存関係に反映されているのを確認してください。だとしても異なったアーキテクチャでは時折異なったバージョンのコンパイラで統一されているので、それでも恐らく問題を引き起こすことになるでしょう。
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
で作業したものが動作することを確認してください。また、力業についてドキュメントに載せてください。一旦外部の問題が修正されたら、それを削除するのを皆が知ることができます。
移植作業者は、待ち期間の間、作業結果を置いておける非公式の置き場所を持つこともあります。移植版を動作させている人が、待ち期間の間であっても、これによって移植作業者による作業の恩恵を受けられるようになります。もちろん、この様な場所は、公式な恩恵や状況の確認を受けることはできませんので、利用者は注意してください。
パッケージの自動移植に役立つインフラストラクチャと複数のツールがあります。この章には、この自動化とこれらのツールへの移植の概要が含まれています。全体の情報に付いてはパッケージのドキュメントかリファレンスを参照してください。
各移植版についての状況を含んだウェブページは https://www.debian.org/ports/ から参照できます。
Debian の各移植版はメーリングリストを持っています。移植作業のメーリングリストは https://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
that is generally useful to porters
is available on the web at https://buildd.debian.org/. This data
includes nightly updated statistics, queueing information and logs for build
attempts.
我々はこのシステムを極めて誇りに思っています。何故ならば、様々な利用方法の可能性があるからです。独立した開発グループは、実際に一般的な用途に合うかどうか分からない異なった別アプローチの Debian にシステムを使うことができます (例えば、gcc の配列境界チェック付きでビルドした Debian など)。そして、Debian がディストリビューション全体を素早く再コンパイルできるようにもなります。
buildd の担当である wanna-build
チームには、debian-wb-team@lists.debian.org
で連絡が取れます。誰
(wanna-build チーム、リリースチーム) に連絡を取るのか、どうやって (メール、BTS) 連絡するのかを決めるには、https://lists.debian.org/debian-project/2009/03/msg00096.html を参照してください。
binNMU や give-back (ビルド失敗後のやり直し) を依頼する時には、https://release.debian.org/wanna-build.txt で記述されている形式を使ってください。
いくつかのパッケージでは、Debian
でサポートされているアーキテクチャのうちの幾つかで、構築や動作に問題を抱えており、全く移植できない、あるいは十分な時間内では移植ができないものがあります。例としては、SVGA
に特化したパッケージ (i386
と amd64
のみで利用可能)や、すべてのアーキテクチャではサポートされていないようなハードウェア固有の機能があります。
壊れたパッケージがアーカイブにアップロードされたり buildd の時間が無駄に費やされたりするのを防ぐため、幾つかしなければならないことがあります:
まず、サポートできないアーキテクチャ上ではパッケージがビルドに失敗するのを確認しておく必要があります。これを行うには幾つかやり方があります。お勧めの方法は構築時に機能をテストする小さなテストスイートを用意して、動かない場合に失敗するようにすることです。これは、全てのアーキテクチャ上で、壊れたものをアップロードするのを防ぎ、必要な機能が動作するようになればパッケージがビルドできるようになる、良い考えです。
さらに、サポートしているアーキテクチャ一覧が一定量であると信ずるのであれば、debian/control
内で
any
からサポートしているアーキテクチャの一覧に変更するべきです。この方法であれば、ビルドが同様に失敗するようになるのに加え、実際に試すことなく人間である読み手にサポートしているアーキテクチャが分かるようにできます。
autobuilder が必要もなくパッケージをビルドしようとしないように、wanna-build
スクリプトが使うリストである Packages-arch-specific
に追加しておく必要があります。現在のバージョンは https://wiki.debian.org/PackagesArchSpecific から入手できます:
変更依頼をする相手はファイルの一番上を参照してください。
Please note that it is insufficient to only add your package to
Packages-arch-specific
without making it fail to build
on unsupported architectures: A porter or any other person trying to build
your package might accidentally upload it without noticing it doesn't work.
If in the past some binary packages were uploaded on unsupported
architectures, request their removal by filing a bug against ftp.debian.org
.
By default packages from the non-free
section are not
built by the autobuilder network (mostly because the license of the packages
could disapprove). To enable a package to be built, you need to perform the
following steps:
法的に許可されているか、技術的にパッケージが auto-build 可能かどうかを確認する;
debian/control
のヘッダ部分に XS-Autobuild:
yes
を追加する;
メールを <nonfree@release.debian.org>
に送り、何故パッケージが合法的、かつ技術的に auto-build できるものなのかを説明する
すべてのパッケージには最低一人のメンテナがいます。通常、この人達がパッケージに対して作業をし、新しいバージョンをアップロードします。時折、他の開発者らが新しいバージョンをアップロードできると便利な場合があります。例えば、彼らがメンテナンスしていないパッケージにあるバグを修正したいが、メンテナが問題に対応するのには助けが必要な場合です。このようなアップロードは Non-Maintainer Upload (NMU) と呼ばれます。
NMU を行う前に、以下の質問について考えてください:
NMU がメンテナを援助するような形にしましたか? メンテナが実際に助けを必要としているかどうか、意見に不一致があるかもしれないため、DELAYED キューが存在しています。DELAYED キューは、メンテナに対処する時間を与えるために存在しており、NMU diff の個別レビューが可能になるという有益な影響があります。
NMU がバグを本当に修正しますか? ("バグ" はあらゆる種類のバグを意味しています。例えば新しいバージョンをパッケージにしてほしいという wishlist バグもそうですが、メンテナへの影響を最小化するよう注意を払う必要があります)。NMU において、些細な表面的な問題やパッケージングスタイルの変更 (例えば cdbs から dh への変更) を行うのは推奨されていません。
メンテナに十分な時間を与えましたか? BTS にバグが報告されたのは何時ですか? 一、二週間忙しいことはあり得ないことでは無いです。そのバグはすぐに修正しなければならないほど重大ですか? それとも、あと数日待てるものですか?
その変更にどれくらい自信がありますか? ヒポクラテスの誓いを思い出してください: 「何よりも、害を及ぼすことなかれ」 動かないパッチを当てるよりもパッケージの重大なバグをそのままオープンな状態にしておく方が良いですし、パッチによってバグを解決するのではなく隠してしまうかもしれません。自分が 100% 何をしたのか分かっていないのであれば、他の人からアドバイスをもらうのも良い考えでしょう。NMU で何かを壊したのであれば、多くの人がとても不幸になるであろうことを覚えておいてください。
少なくとも BTS で、NMU するのを明確に表明しましたか? 何も反応が得られなかった場合、他の手段 (プライベートなメール、IRC) でメンテナに連絡をとるのも良い考えです。
メンテナがいつも活動的で応答してくれる場合、彼に連絡を取ろうとしましたか? 大概の場合、メンテナ自身が問題に対応して、あなたのパッチをレビューする機会が与えられる方が好ましいと思われます。これは、NMU をする人が見落としているだろう潜在的な問題にメンテナは気付くことができるからです。大抵、メンテナが自分でアップロードする機会が与えられる方が、皆の時間を使うよりも良いやり方です。
NMU をする際には、まず NMU をする意図を明確にしておかねばなりません。それから、BTS へ現在のパッケージと提案する NMU
との差分をパッチとして送付する必要があります。devscripts
パッケージにある nmudiff スクリプトが役に立つでしょう。
While preparing the patch, you had better be aware of any package-specific
practices that the maintainer might be using. Taking them into account
reduces the burden of integrating your changes into the normal package
workflow and thus increases the chances that integration will happen. A good
place to look for possible package-specific practices is debian/README.source
.
そうするべき十二分な理由が無い限り、メンテナに対応する時間を与えるべきです (例えば DELAYED
キューにアップロードすることによってこれを行います)。以下が delayed キューを使う際のお勧めの値です:
7 日以上経っているリリースクリティカルバグのみを修正するアップロードで、バグに対するメンテナの活動が 7 日間見られなく、修正が行われている形跡が無い: 0 日
7 日以上経っているリリースクリティカルバグのみを修正するアップロード: 2 日
リリースクリティカルバグや重要なバグの修正のみのアップロード: 5 日
他の NMU: 10 日
この値は例に過ぎません。セキュリティ問題を修正するアップロードや、移行を阻む些細なバグを修正するなど、いくつかのケースでは修正されたパッケージが
不安定版 (unstable)
にすぐ入るようになるのは望ましいことです。
時々、リリースマネージャが特定のバグに対して短い delay 日数の NMU を許可を認めることがあります (7 日より古いリリースクリティカルバグなど)。また、一部のメンテナは Low Threshold NMU list に自身を挙げており、遅延なしの NMU アップロードを許可しています。しかしどのような場合であっても、特にパッチが BTS で以前手に入らなかったり、メンテナが大抵アクティブであるのを知っている場合など、アップロードの前にメンテナに対して数日与えるのは良い考えです。
NMU アップロード後、あなたは自分が導入したであろう問題に責任を持つことになります。パッケージを見張らなければなりません (これを行うには PTS 上のパッケージを購読するのが良い方法です)。
これは、軽率な NMU を行うための許可証ではありません。明らかにメンテナがアクティブで時期を逃さずパッチについて対応している場合や、このドキュメントに書かれている推奨を無視している場合など、あなたによるアップロードはメンテナと衝突を起こすでしょう。NMU のメリットについて、自分が行ったことの賢明さを常に弁護できるようにしておく必要があります。
Just like any other (source) upload, NMUs must add an entry to
debian/changelog
, telling what has changed with this
upload. The first line of this entry must explicitly mention that this
upload is an NMU, e.g.:
* Non-maintainer upload.
NMU のバージョンのつけ方は、ネイティブなパッケージとネイティブではないパッケージでは異なります。
パッケージがネイティブパッケージの場合 (バージョン番号に Debian リビジョンが付かない)、バージョンはメンテナの最後のアップロードのバージョン
+ +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 にあるパッケージともぶつかる可能性があります。これには、アーカイブのパッケージが公式メンテナによるものではない、と視覚的に明らかにする利点もあります。
パッケージをテスト版や安定版にアップロードする場合、バージョン番号を「分岐」する必要が時々あります。これは例えばセキュリティアップロードが該当します。そのため、+deb
形式のバージョン番号を使うようにしてください。X
uY
X
はメジャーリリース番号で
Y
は 1
から始まるカウンターです。例えば、buster (Debian 10) が安定版の間は安定版バージョン
1.5-3
のパッケージへのセキュリティ NMU ならバージョン
1.5-3+deb10u1
となりますが、bullseye
へのセキュリティ NMU ではバージョン 1.5-3+deb11u1
となります。
NMU の許可を求めた後で待っているのは効率的ではありません。NMU
した人が作業にもどるために頭を切り替えるのに手間がかかるからです。DELAYED
キュー (「遅延アップロード」 参照) は、開発者が NMU
をするのに必要な作業を同時にできるようになります。例えば、メンテナに対して更新したパッケージを 7
日後にアップロードするのを伝えるのではなく、パッケージを DELAYED/7
にアップロードしてメンテナに対して対応するのに 7
日間あることを伝えるべきです。この間、メンテナはもっとアップロードを遅らせるかアップロードをキャンセルするかを尋ねることができます。
DELAYED
キューは、無用のプレッシャーをメンテナに与えるために使われるべきではありません。特に、メンテナはアップロードを自身ではキャンセルできないので、delay
が完了する前にアップロードをキャンセルあるいは遅らせることができるのはあなただ、という点が重要です。
DELAYED
を使った NMU を行って delay
が完了する前にメンテナがパッケージを更新した場合には、アーカイブに既により新しいバージョンがあるので、あなたのアップロードは拒否されます。理想的なのは、メンテナがそのアップロードであなたが提案した変更
(あるいは少なくとも対応した問題の解決方法) を含めるのを取り仕切ることです。
誰かがあなたのパッケージを NMU した場合、これは彼らがパッケージを良い形に保つのを助けたいと思っているということです。これによって、ユーザへ修正したパッケージをより早く届けます。NMU した人に、パッケージの副メンテナになることを尋ねるのを考えてみるのも良いでしょう。パッケージに対して NMU を受け取るのは悪いことではありません。それは、単にそのパッケージが他の人が作業する価値があるという意味です。
NMU を承認するには、変更と changelog のエントリを次のメンテナアップロードに含めます。バグは BTS で close されたままになりますが、パッケージのメンテナバージョンに影響していると表示されます。
Note that if you ever need to revert a NMU that packages a new upstream
version, it is recommended to use a fake upstream version like
until one can upload the latest version again. More information can be found
in https://www.debian.org/doc/debian-policy/ch-controlfields.html#epochs-should-be-used-sparingly.
CURRENT
+reallyFORMER
NMU のフルネームはソース NMU です。もう一つ別の種類があって、バイナリのみの NMU (binary-only NMU) あるいは binNMU と名付けられています。binNMU も、パッケージメンテナ以外の誰かによるパッケージのアップロードです。しかし、これはバイナリのみのアップロードです。
ライブラリ (や他の依存関係) が更新された時、それを使っているパッケージを再ビルドする必要があるかもしれません。ソースへの変更は必要ないので、同じソースパッケージが利用されます。
binNMU は、通常 wanna-build によって buildd
上で引き起こされます。debian/changelog
にエントリが追加され、なぜアップロードが必要だったのか、という説明と 「再コンパイル、あるいは binary-only NMU」
で記述されているようにバージョン番号を増やします。このエントリは、その次のアップロードに含めるべきではありません。
buildd は、アーカイブするために、バイナリのみのアップロードとして、そのアーキテクチャに対してパッケージをアップロードします。厳密に言えば、これは
binNMU です。しかし、これは通常 NMU とは呼ばれず、debian/changelog
にエントリを追加しません。
NMUs are uploads of packages by somebody other than their assigned maintainer. There is another type of upload where the uploaded package is not yours: QA uploads. QA uploads are uploads of orphaned packages.
QA アップロードは、ほとんど通常のメンテナによるアップロードと同じです: 些細な問題であっても、なんでも修正します。バージョン番号の付け方は通常のものですし、delay アップロードをする必要もありません。違いは、パッケージのメンテナあるいはアップローダとして記載されていない点です。また、QA アップロードの changelog のエントリは以下のように最初の一行が特別になっています:
* QA upload.
あなたが NMU をしたいと思い、かつ、メンテナが活動的ではない場合、パッケージが放棄されてないかどうかを確認するのが賢明です
(この情報はパッケージ追跡システム (PTS) のページで表示されています)。放棄されたパッケージに対して最初の QA
アップロードを行うときは、メンテナは Debian QA Group
<packages@qa.debian.org>
に設定する必要があります。まだ QA
アップロードがされていない放棄されたパッケージには、以前のメンテナが設定されています。この一覧は https://qa.debian.org/orphaned.html で手に入ります。
Instead of doing a QA upload, you can also consider adopting the package by making yourself the maintainer. You don't need permission from anybody to adopt an orphaned package; you can just set yourself as maintainer and upload the new version (see 「パッケージを引き取る」).
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.
Package salvaging is the process by which one attempts to save a package that, while not officially orphaned, appears poorly maintained or completely unmaintained. This is a weaker and faster procedure than orphaning a package officially through the powers of the MIA team. Salvaging a package is not meant to replace MIA handling, and differs in that it does not imply anything about the overall activity of a maintainer. Instead, it handles a package maintainership transition for a single package only, leaving any other package or Debian membership or upload rights (when applicable) untouched.
Note that the process is only intended for actively taking over maintainership. Do not start a package salvaging process when you do not intend to maintain the package for a prolonged time. If you only want to fix certain things, but not take over the package, you must use the NMU process, even if the package would be eligible for salvaging. The NMU process is explained in 「Non-Maintainer Upload (NMU)」.
Another important thing to remember: It is not acceptable to hijack others' packages. If followed, this salvaging process will help you to ensure that your endeavour is not a hijack but a (legal) salvaging procedure, and you can counter any allegations of hijacking with a reference to this process. Thanks to this process, new contributors should no longer be afraid to take over packages that have been neglected or entirely forgotten.
The process is split into two phases: In the first phase you determine whether the package in question is eligible for the salvaging process. Only when the eligibility has been determined you may enter the second phase, the actual package salvaging.
For additional information, rationales and FAQs on package salvaging, please visit the Salvaging Packages page on the Debian wiki.
A package becomes eligible for salvaging when it has been neglected by the current maintainer. To determine that a package has really been neglected by the maintainer, the following indicators give a rough idea what to look for:
NMUs, especially if there has been more than one NMU in a row.
Bugs filed against the package do not have answers from the maintainer.
Upstream has released several versions, but despite there being a bug entry asking for it, it has not been packaged.
There are QA issues with the package.
You will have to use your judgement as to whether a given combination factors constitutes neglect; in case the maintainer disagrees they have only to say so (see below). If you're not sure about your judgement or simply want to be on the safe side, there is a more precise (and conservative) set of conditions in the Package Salvaging wiki page. These conditions represent a current Debian consensus on salvaging criteria. In any case you should explain your reasons for thinking the package is neglected when you file an Intent to Salvage bug later.
If and only if a package has been determined to be eligible for package salvaging, any prospective maintainer may start the following package salvaging procedure.
Open a bug with the severity "important" against the package in question,
expressing the intent to take over maintainership of the package. For this,
the title of the bug should start with ITS:
package-name
[5]. You may
alternatively offer to only take co-maintenance of the package. When you
file the bug, you must inform all maintainers, uploaders and if applicable
the packaging team explicitly by adding them to
X-Debbugs-CC
. Additionally, if the maintainer(s) seem(s)
to be generally inactive, please inform the MIA team by adding
mia@qa.debian.org
to X-Debbugs-CC
as
well. As well as the explicit expression of the intent to salvage, please
also take the time to document your assessment of the eligibility in the bug
report, for example by listing the criteria you've applied and adding some
data to make it easier for others to assess the situation.
In this step you need to wait in case any objections to the salvaging are
raised; the maintainer, any current uploader or any member of the associated
packaging team of the package in question may object publicly in response to
the bug you've filed within 21 days
, and this terminates
the salvaging process.
The current maintainers may also agree to your intent to salvage by filing a
(signed) public response to the the bug. They might propose that you become
a co-maintainer instead of the sole maintainer. On team maintained
packages, a member of the associated team can accept your salvaging proposal
by sending out a signed agreement notice to the ITS bug, alternatively
inviting you to become a new co-maintainer of the package. The team may
require you to keep the package under the team's umbrella, but then may ask
or invite you to join the team. In any of these cases where you have
received the OK to proceed, you can upload the new package immediately as
the new (co-)maintainer, without the need to utilise the
DELAYED
queue as described in the next step.
After the 21 days delay, if no answer has been sent to the bug from the
maintainer, one of the uploaders or team, you may upload the new release of
the package into the DELAYED
queue with a minimum delay
of seven days
. You should close the salvage bug in the
changelog and you must also send an nmudiff to the bug ensuring that copies
are sent to the maintainer and any uploaders (including teams) of the
package by CC'ing
them in the mail to the BTS.
During the waiting time of the DELAYED
queue, the
maintainer can accept the salvaging, do an upload themselves or (ask to)
cancel the upload. The latter two of these will also stop the salvaging
process, but the maintainer must reply to the salvaging bug with more
information about their action.
共同メンテナンス (collaborative maintenance) は、Debian
パッケージのメンテナンス責任を数人でシェアすることを指す用語です。この共同作業は、通常はより上質で短いバグ修正時間をもたらすので、大抵の場合は常に良い考えです。優先度が標準
(standard
) あるいは基本セット (base) の一部であるパッケージは、共同メンテナ
(co-maintainer) を持つことを強くお勧めします。
大抵の場合、主メンテナに加えて一人か二人の共同メンテナが居ます。主メンテナは debian/control
ファイルの Maintainer
欄に名前が記載されている人です。共同メンテナは他のすべてのメンテナで、通常
debian/control
ファイルの Uploaders
に記載されています。
もっとも基本的なやり方では、新しい副メンテナの追加は大変簡単です:
Set up the co-maintainer with access to the sources you build the package
from. Generally this implies you are using a network-capable version
control system, such as Git
. Salsa (see 「salsa.debian.org: Git repositories and collaborative development platform」) provides Git repositories, amongst other
collaborative tools.
共同メンテナの正確なメンテナ名とアドレスを debian/control
ファイルの最初の段落の
Uploaders
欄に追加します。
Uploaders: John Buzz <jbuzz@debian.org>, Adam Rex <arex@debian.org>
PTS (「Debian パッケージトラッカー」) を使う場合、共同メンテナは適切なソースパッケージの購読をする必要があります。
共同メンテナンスのもう一つの形態はチームメンテナンスです。これは、複数のパッケージを同じ開発者グループでメンテナンスする場合にお勧めです。その場合、各パッケージの
Maintainer
欄と Uploaders
欄は注意して扱わねばいけません。以下の二つの案からいずれかを選ぶのがお勧めです:
パッケージの主に担当をするチームメンバーを Maintainer
欄に追加します。Uploaders
欄には、メーリングリストのアドレスとパッケージの面倒をみるチームメンバーを追加します。
Put the mailing list address in the Maintainer
field. In
the Uploaders
field, put the team members who care for
the package. In this case, you must make sure the mailing list accepts bug
reports without any human interaction (like moderation for non-subscribers).
どのような場合でも、すべてのチームメンバーを Uploaders
欄に入れるのは良くない考えです。これは、Developer's Package Overview の一覧 (「Developer's packages overview」
参照)
を実際には対応していないパッケージで散らかしてしまい、偽りの良いメンテナンス状態を作り出します。同じ理由から、パッケージを一回アップロードするのであれば、「チームアップロード
(Team Upload)」ができるので、チームメンバーは Uploaders
欄へ自分を追加する必要はありません
(「NMU とチームアップロード」 参照)。逆にいえば、Maintainer
欄にメーリングリストのアドレスのみで Uploaders
欄に誰も追加していないままにしておくのは良くない考えです。
パッケージは通常、不安定版 (unstable)
におけるテスト版への移行基準を満たした後でテスト版 (testing)
ディストリビューションへとインストールされます。
これらは、すべてのアーキテクチャ上で同期していなければならず、インストールできなくなるような依存関係を持ってはいけません。また、テスト版
(testing)
にインストールされる際に既知のリリースクリティカルバグを持っていない必要があります。このようにして、テスト版
(testing)
は常にリリース候補に近いものである必要があります。詳細は以下を参照してください。
テスト版 (testing)
ディストリビューションを更新するスクリプトは、日に二回、更新されたパッケージのインストール直後に動作します。これらのスクリプトは
britney
と呼ばれます。これは、テスト版 (testing)
ディストリビューションに対して Packages
ファイルを生成しますが、不整合を避けてバグが無いパッケージのみを利用しようとする気の利いたやり方で行います。
不安定版 (unstable)
からのパッケージの取り込みは以下の条件です:
パッケージは、urgency に応じて (high、medium、low)、2日、5日、10日の間、不安定版
(unstable)
で利用可能になっていなければいけません。urgency は貼り付くことに注意してください。つまり、前回の
テスト版 (testing)
への移行を考慮に入れてから最大の urgency
でアップロードされるということです;
新たなリリースクリティカルバグを持っていないこと (不安定版 (unstable)
で利用可能なバージョンに影響する
RC バグであって、テスト版 (testing)
にあるバージョンに影響するものではない);
あらかじめ unstable
でビルドされた際に、全アーキテクチャで利用可能になっていなくてはいけません。この情報をチェックするのに dak ls に興味を持つかもしれません;
既にテスト版 (testing)
で利用可能になっているパッケージの依存関係を壊さないこと;
パッケージが依存するものは、テスト版 (testing)
で利用可能なものか、テスト版
(testing)
に同時に受け入れられるものでなくてはいけない
(そして、それらは必要な条件をすべて満たしていれば、テスト版 (testing)
) に入る);
プロジェクトの状況。つまり、テスト版 (testing)
ディストリビューションのフリーズ中は、自動的な移行がオフになります。
パッケージがテスト版 (testing)
に入る処理がされるかどうかは、テスト版ディストリビューションのウェブページのテスト版
(testing)
スクリプトの出力を参照するか、devscripts
パッケージ中の
grep-excuses プログラムを使ってください。このユーティリティは、パッケージがテスト版
(testing)
への進行の通知をし続けるのに、crontab(5) で手軽に使うことができます。
update_excuses
は、なぜパッケージが拒否されたのか正確な理由を必ずしも表示しません。自分自身で何がパッケージが含まれるのを妨げているのか、探す必要があるかもしれません。テスト版のウェブページが、そのような問題を引き起こす良くある問題についての情報を与えてくれるでしょう。
時折、相互依存関係の組み合わせが非常に難解なのでスクリプトが解決できないことがあるため、パッケージがテスト版
(testing)
に決して入らないことがあります。詳細は下記を参照してください。
Some further dependency analysis is shown on https://release.debian.org/migration/ — but be warned: this page also shows build dependencies that are not considered by britney.
For the testing
migration script, outdated means: There
are different versions in unstable
for the release
architectures (except for the architectures in outofsync_arches;
outofsync_arches is a list of architectures that don't keep up (in
britney.py
), but currently, it's empty). Outdated has
nothing whatsoever to do with the architectures this package has in
testing
.
以下の例を考えてみましょう:
alpha | arm | |
---|---|---|
テスト版 | 1 | - |
不安定版 | 1 | 2 |
The package is out of date on alpha
in
unstable
, and will not go to
testing
. Removing the package would not help at all; the
package is still out of date on alpha
, and will not
propagate to testing
.
ですが、もしも ftp-master が不安定版 (unstable)
のパッケージ (ここでは
arm
の) を削除した場合:
alpha | arm | hurd-i386 | |
---|---|---|---|
テスト版 | 1 | 1 | - |
不安定版 | 2 | - | 1 |
この場合、パッケージは不安定版 (unstable)
ですべてのリリースアーキテクチャで最新になります
(それから、もう一つの hurd-i386
は、リリースアーキテクチャではないので問題になりません)。
時折、すべてのアーキテクチャでまだビルドされていていないパッケージを入れられるか、という質問がでてきます: いいえ。 単純にいいえ、です (glibc などをメンテしている場合を除きます)。
時折、パッケージは他のパッケージがテスト版へ入るために削除されます:
これは、他のパッケージが他のすべての面で準備ができている場合にテスト版に入るようにする場合のみ発生します。例えば、a
が新しいバージョンの b
とはインストールできない場合を考えてみましょう。その場合、a
は b
が入るために削除されるかもしれません。
Of course, there is another reason to remove a package from
testing
: it's just too buggy (and having a single RC-bug
is enough to be in this state).
さらに、パッケージが 不安定版 (unstable)
から削除され、テスト版
(testing)
にはこれに依存するパッケージがもうなくなった場合、パッケージは自動的に削除されます。
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>
にメールを送って連絡を取ってください。
Generally, there is nothing that the status of a package in
testing
means for transition of the next version from
unstable
to testing
, with two
exceptions: If the RC-bugginess of the package goes down, it may go in even
if it is still RC-buggy. The second exception is if the version of the
package in testing
is out of sync on the different
arches: Then any arch might just upgrade to the version of the source
package; however, this can happen only if the package was previously forced
through, the arch is in outofsync_arches, or there was no binary package of
that arch present in unstable
at all during the
testing
migration.
この要旨: 影響は、テスト版 (testing)
にあるパッケージが、同じパッケージの新しいバージョンになるのは、新しいバージョンの方が楽にできそうだから、ということです。
詳細について知りたい場合ですが、britney の動作は以下のようになります:
パッケージが、適切な候補であるかどうかを決めるために確認が行われます。これによって、更新が実行されます。パッケージが候補とみなされない理由でもっともよくあるのは、まだ日数が経過していない (too young)、RC バグがある、いくつかのアーキテクチャで古くなりすぎている、というものです。britney のこの部分では、リリースマネージャーが britney がパッケージを検討できるように、hints と呼ばれる様々なサイズのハンマーを使います (下記を参照してください)。
さて、より複雑な部分に差し掛かります: Britney が適正候補を使ってテスト版 (testing)
を更新しようとします。このため、britney はテスト版ディストリビューションに個々の適正な候補を追加しようとします。テスト版
(testing)
でインストール不可能なパッケージの数が増えないのであれば、パッケージは受け入れられます。その時から、受け入れられたパッケージはテスト版
(testing)
の一部として取り扱われ、このパッケージを含めるためのインストールチェックテストが引き続き行われます。リリースチームからの hints
は、実際の内容に応じて、このメインの処理の前後に処理されます。
より詳細を見たい場合は、https://ftp-master.debian.org/testing/update_output/ で探すことができます。
hints は、説明からも探せますが、https://ftp-master.debian.org/testing/hints/ にあります。hints
によって、Debian リリースチームはパッケージを block あるいは unblock することや、パッケージをテスト版
(testing)
へ移動する手間を減らしたり強制的に移動させたり、あるいはテスト版
(testing)
からパッケージを削除したり、testing-proposed-updates へアップロードを許可したり、urgency
を上書きすることが可能になります。
テスト版 (testing)
ディストリビューションは、上記で説明したルールに従って 不安定版
(unstable)
からのパッケージで作られています。しかし、時折、テスト版
(testing)
の為だけに構築したパッケージをアップロードする必要があるという場合があります。そのためには、testing-proposed-updates
にアップロードするのが良いでしょう。
Keep in mind that packages uploaded there are not automatically processed;
they have to go through the hands of the release manager. So you'd better
have a good reason to upload there. In order to know what a good reason is
in the release managers' eyes, you should read the instructions that they
regularly give on <debian-devel-announce@lists.debian.org>
.
不安定版 (unstable)
でパッケージを更新できるのであれば、testing-proposed-updates
にアップロードすべきではありません。更新できない場合 (例えば、不安定版 (unstable)
に新しい開発版がある場合)、この機能を使うことができますが、まずはリリースマネージャから許可を得るのが良いでしょう。パッケージがフリーズされていても、不安定版
(unstable)
経由のアップロードが新たな依存関係を何も引き起こさない場合、不安定版
(unstable)
での更新は可能です。
バージョン番号は、通常
+deb
X
uY
を付加することで指定されます。X
は Debian のメジャーリリース番号で
Y
は 1
から始まる数です。例:
1:2.4.3-4+deb10u1
アップロードでは、以下の項目のいずれも見落とさないように必ずしてください:
本当に testing-proposed-updates
を通す必要があり、unstable
ではダメなことを確認する;
必ず、最小限な量だけの変更を含めるようにする;
必ず changelog 中に適切な説明を含める;
必ず、対象とするディストリビューションとして testing code name
(e.g. bullseye
) を記述している;
必ず 不安定版 (unstable)
ではなく テスト版 (testing)
でパッケージを構築・テストしている;
バージョン番号が testing
および
testing-proposed-updates
のものよりも大きく、unstable
のものよりも小さいのを確認する;
アップロードしてすべてのプラットフォームで構築が成功したら、<debian-release@lists.debian.org>
宛でリリースチームに連絡を取って、アップロードを承認してくれるように依頼しましょう。
ある重要度以上のバグすべてが通常リリースクリティカルであると見なされます。現在のところ、critical
(致命的)
、grave (重大)
、serious
(深刻)
バグがそれにあたります。
そのようなバグは、Debian の 安定版 (stable)
リリース時に、そのパッケージがリリースされる見込みに影響があるものと仮定されます:
一般的に、パッケージでオープンになっているリリースクリティカルバグがある場合、そのパッケージはテスト版
(testing)
に入らず、その結果安定版 (stable)
ではリリースされません。
The unstable
bug count comprises all release-critical
bugs that are marked to apply to
package
/version
combinations available in unstable
for a release
architecture. The testing
bug count is defined
analogously.
ディストリビューションにおけるアーカイブの構造では、一つのバージョンのパッケージだけを持つことができ、パッケージは名前によって定義されています。そのため、ソースパッケージ
acmefoo
がテスト版 (testing)
にインストールされると、付随するバイナリパッケージ
acme-foo-bin
、acme-bar-bin
、libacme-foo1
、libacme-foo-dev
の古いバージョンが削除されます。
However, the old version may have provided a binary package with an old
soname of a library, such as libacme-foo0
. Removing the
old acmefoo
will remove libacme-foo0
,
which will break any packages that depend on it.
Evidently, this mainly affects packages that provide changing sets of binary packages in different versions (in turn, mainly libraries). However, it will also affect packages upon which versioned dependencies have been declared of the ==, <=, or << varieties.
When the set of binary packages provided by a source package changes in this
way, all the packages that depended on the old binaries will have to be
updated to depend on the new binaries instead. Because installing such a
source package into testing
breaks all the packages that
depended on it in testing
, some care has to be taken now:
all the depending packages must be updated and ready to be installed
themselves so that they won't be broken, and, once everything is ready,
manual intervention by the release manager or an assistant is normally
required.
この様に複雑な組み合わせのパッケージで問題がある場合は、<debian-devel@lists.debian.org>
あるいは <debian-release@lists.debian.org>
に連絡を取って手助けを求めてください。
[3] パッケージがどのセクションに属するかのガイドラインは Debian ポリシーマニュアルを参照してください。
[4] 過去においては、再コンパイルのみの状態を意味するために、このような NMU はリビジョンの Debian 部分の三つ目の番号を使っていました。しかし、この記法はネイティブパッケージの場合に曖昧で、同一パッケージでの再コンパイルのみの NMU と、ソース NMU と、セキュリティ NMU の正しい順序が付けられなかったため、この新しい記法で置き換えられました。
[5] ITS is shorthand for "Intend to Salvage"