Debian ディストリビューション用に新たなパッケージを作成しようと考えたら、
まず最初に Work-Needing and
Prospective Packages (WNPP) の一覧をチェックしてください。 WNPP
をチェックすることによって、
まだ誰もそのソフトウェアのパッケージング作業を行なっていないこと、
作業が重複していないことが確認できます。
あなたが作業を予定しているパッケージにまだ誰も手をつけていないことが
分かったら、新たなパッケージ作成に関するあなたの計画を説明するために
簡潔な電子メールを debian-devel@lists.debian.org
宛てに送ります。 その電子メールのサブジェクトは ``intent to package
foo'' とするべきです。 foo
のところには新たなパッケージの名前を当てはめてください
このような手順を踏むことを開発者にお願いするのは、 以下のようないくつかの理由のためです。
debian-devel@lists.debian.org
への ``intent to package'' メッセージは WNPP
メンテナによって収集され、その申し出は WNPP 文書の改訂版で公開されます。
Debian FTP アーカイブにパッケージをアップロードする際には、
アーカイブメンテナにその扱いを指示するための .changes
を添えなければなりません。 こちらは普通、通常のパッケージ構築プロセスの最中に
dpkg-genchanges によって生成されます。
この changes ファイルは以下のフィールドをもつ制御ファイルです。
Debian アップロードの際、これらのフィールドはすべて必須です。
これらのフィールドの内容については Debian
パッケージングマニュアル の制御フィールドの一覧をご覧ください。
また、Description フィールドを用いれば
自動的にバグをクローズすることが可能です。 こちらに関しては 新規アップロードによってバグをクローズする場合には,
Section 10.4 をご覧ください。
なお、この節ではアーカイブメンテナンスのポリシーに関わる
Distribution フィールドのみを取り上げます。
とりわけ debian/changelog ファイルから生成される
Distribution フィールドは、
そのパッケージがどのディストリビューション向けのものなのかを示します。
このフィールドの値には、`stable'、`unstable'、`frozen'、`experimental'
の四つが当てはまりえます。
またこれらの値は組み合わせて当てはめられる場合もあります。
例えば、極めて重要なセキュリティ上の修正を施したパッケージのリリースがあり、
そのパッケージが stable および unstable
ディストリビューションの双方に必要なものであったならば、 changelog
の Distribution フィールドには `stable unstable' と記入します。
あるいは、Debian がフリーズされており frozen
ディストリビューションにバグ修正リリースを収録したい場合は、
そのディストリビューションは `frozen unstable' とします。 (frozen
へアップロードする際のより詳細な情報については frozen へのアップロード,
Section 6.2.2.1 をご覧ください。)
なお注意していただきたいのですが、ディストリビューションを `stable'
に設定することは、実際に stable
ディストリビューションに収録される前に、 そのパッケージがさらなるテストのために
Debian アーカイブの proposed-updates
ディレクトリに収録されることを意味しています。 また experimental
ディストリビューションを
他のディストリビューションと組み合わせることはまったく意味がありません。
注意してください。
特定のアップストリームバージョンに対応するバージョンを 初めてアップロードする際には、 オリジナルソースの tar ファイルを .changes ファイルを添えて アップロードしなければなりません。 続いて新しい diff と .dsc ファイルを生成する際には、 これとまったく同じ tar ファイルを用いなければなりませんが、 その際にはこの tar ファイルをアップロードする必要はありません。
Debian ソースバージョン番号のリビジョン部分が 0 あるいは 1 であることは、
それが新たなアップストリームバージョンであることを示しますが、 この場合 (のみ)
dpkg-genchanges と dpkg-buildpackage
は、デフォルトでオリジナルソースの tar ファイルを収録します。
この動作は、常にこちらを収録するには -sa を、
常にそれを無視するには -sd を用いることによって
変更することができます。
ただ、オリジナルソースがそのアップロードに含まれない場合は、 アップロードする
.dsc ファイルと diff を生成する際に dpkg-source
が用いるオリジナル tar ファイルは、 すでにアーカイブにあるものと 1
バイトたりとも違わない 同一のものでなければなりません。
なお何らかの特殊な理由がある場合は、おそらく -sa フラグを用いて、
新しいバージョンのオリジナルソースをアップロードしなければなりません。
Debian フリーズは Debian にとって重要な期間です。 この期間はディストリビューション全体を調和させ安定化させる機会なのです。 それゆえ、frozen へアップロードする際には注意を要します。
最新のソフトウェアを常にリリースに収録するという試みは、 魅惑的なことです。 しかしながら、システムが全体として安定し、 期待している通りに動作することの方がより重要なことです。
frozen へのアップロードのモットーは 「新たなコードは入れない」です。 その基準を定めることは難しいことですが、 以下のようないくつかのガイドラインがあります。
新たなバグを招いてしまう可能性が、どんなバグ修正にでも 統計的に 15% はあることを心に留めておいてください。 新たなバグの混入や発見は、リリースを遅らせたり、 最終的なプロダクトの品質を低下させたりするのです。 元々のバグの重大さと新たに混入したバグの重大さとの間に、 相関関係はほとんどありません。
あなたのパッケージをアップロードする前に、 それに対して基本的なテストを行なうべきです。 必ず以下の作業を行なうようにしてください。 (現行の Debian パッケージがあれば、その古いバージョンも必要になるでしょう。)
lintian を実行してください。
lintian は、 lintian -v
package-version.changes として実行します。
こちらは、バイナリパッケージもソースパッケージもチェックします。
lintian が生成する出力が理解できない場合は、 -i
スイッチを追加してご覧ください。 こうすれば lintian は、
そのプログラムに関する大変冗長な解説を出力します。
lintian がエラーを出した場合 (その行は E
から始まります)、
通常はそのパッケージをアップロードすべきではありません。
lintian に関するより詳細な情報については lintian, Section 11.2
をご覧ください。
パッケージをアップロードするためには、 master.debian.org
に個人アカウントが必要です。
開発者はすでに全員このアカウントを持っているはずです。 こちらに関しては master サーバ, Section 4.2.1
をご覧ください。 そのファイル群を転送するには scp と
ftp のいずれも利用できます。
どちらを使う場合でも、そのファイル群は /home/Debian/ftp/private/project/Incoming/
に設置する必要があります。 匿名 FTP を利用して master 上の Incoming
にアップロードすることはできません。 --
あなたのユーザ名とパスワードを使わなければなりません。)
注意: アメリカ合衆国政府によって輸出規制されているソフトウェアを
パッケージが含む場合は、それを master や、海外にある
chiark や erlangen のアップロードキューには
アップロードしないでください。 この規制は、ほぼすべての暗号ソフトウェアや、
時にはPGP 暗号および認証をサポート電子メールリーダのような
暗号ソフトウェアを「利用する」ソフトウェアにも及びます。
このようなソフトのアップロードは non-us に行なってください。 (pandora (non-us)
へのアップロード, Section 6.2.5 をご覧ください。)
アメリカ合衆国の輸出規制があなたのパッケージに適用されるかどうか
はっきりしない場合は、debian-devel@lists.debian.org
にメッセージを投稿し質問してください。
また、パッケージをアップロードする際、 Debian package dupload
が便利なことにお気づきになるでしょう。 この便利なプログラムは、デフォルトで
ftp を経由し master や、chiark、
erlangen へのアップロードができるようになっています。 こちらは
ssh を利用するように設定することもできます。
より詳細な情報については dupload(1) と dupload(5)
をご覧ください。
前述の通り、輸出規制されているソフトウェアは master
にアップロードしてはいけません。 その代わりに 非匿名 FTP か scp
を使って、 パッケージを pandora.debian.org にコピーし、
そのファイル群を /org/non-us.debian.org/incoming/
に設置してください。 デフォルトで master
と同じアカウントが使えます。
dupload プログラムは pandora
へのアップロードをサポートしています。
詳細はプログラム付属のドキュメントを参照してください。
master へのネットワーク接続が遅い場合、
その代わりとなるものがあります。 その一つが、chiark
上にあるヨーロッパのアップロードキュー経由で Incoming
にファイル群をアップロードする方法です。 その詳細については ftp://ftp.chiark.greenend.org.uk/pub/debian/private/project/README.how-to-upload
をご覧ください。
注意:アメリカ合衆国政府によって輸出規制されている ソフトウェアを含むパッケージを chiark のキューにアップロードしないでください。 このアップロードキューは master に向けられたものですので、 master へのアップロード, Section 6.2.4 で説明した法規がここでも同様に適用されます。
dupload プログラムは chiark
へのアップロードをサポートしています。
詳細はプログラム付属のドキュメントを参照してください。
他にもドイツにあるアップロードキューが利用できます。 匿名 FTP 経由で ftp://ftp.uni-erlangen.de/pub/Linux/debian/UploadQueue/
にファイル群をアップロードしてください。
そのアップロードは、 master の Incoming へのアップロードと同じように、 完全な Debian アップロードでなければなりません。 つまり、.changes ファイルで触れている他のファイルを添えて .changes ファイルをアップロードします。 そのキューデーモンは .changes が Debian 開発者によって 正しく PGP 署名されているかどうかをチェックし、 不正なファイルはそのキュー経由では master へ転送しません。 .changes の Maintainer フィールドに、 あなたの電子メールアドレスがあるかどうかも確認してください。 そこに記述されたアドレスは master と同様あらゆるリプライに使用されます。
chiark と同様に、アップロードのあとあなたのファイルを セカンドディレクトリに移動する必要はありません。 また、どんな場合でもアップロードがどうなったかについて、 キューデーモンから返信メールを受け取るはずです。 あなた宛てにエラーが通知されない限り おそらくこちらも master へ移動されるはずです。
注意:アメリカ合衆国政府によって輸出規制されている ソフトウェアを含むパッケージを erlangen のキューにアップロードしないでください。 このアップロードキューは master に向けられたものですので、 master へのアップロード, Section 6.2.4 で説明した法規がここでも同様に適用されます。
dupload プログラムは erlangen
へのアップロードをサポートしています。
詳細はプログラム付属のドキュメントを参照してください。
アメリカ合衆国にある他のアップロードキューも利用できます。 こちらは
master に接続できない問題が発生した際の
優れたバックアップ手段です。 erlangen と同様に ftp://samosa.debian.org/pub/UploadQueue/
にファイル群をアップロードすることができます。
日本でもアップロードキューが利用できます。ftp://master.debian.or.jp/pub/Incoming/upload/
への匿名 FTP 経由でファイル群をアップロードしてください。
パッケージをアップロードしたら、 そのアナウンスを``debian-changes'' メーリングリストの一つに投稿しなければなりません。 そのアナウンスの Subject フィールドには (ソース) パッケージ名、バージョン番号、変更事項の極めて簡潔な要約を含め、 その本文には PGP で署名された .changes ファイルを含めます。 付加的な説明文は .changes ファイルの前に付け加えます。
あるパッケージが、その Distribution: フィールドに `stable'
と記述されてリリースされる場合、 そのアナウンスは debian-changes@lists.debian.org
に送ります。 一方あるパッケージが、その Distribution: フィールドに
`unstable' や、`experimental'、(もしあれば) `frozen'
などが記述されてリリースされる場合、 そのアナウンスは debian-devel-changes@lists.debian.org
に送らなければなりません。
場合によっては、stable と unstable ディストリビューションの両方にパッケージをアップロードする必要がありますが、 この場合は Distribution: フィールドに 両方のディストリビューション名を記述してください。 この場合アップロードアナウンスは、 上記のメーリングリストの両方に投稿してください。
なお、dupload プログラムは、
アナウンスをどこへ投稿すべきかを判断し
適切なメーリングリストに自動的にアナウンスを投稿してくれます。 dupload, Section 11.8
をご覧ください。
Debian アーカイブメンテナが、
アップロードされたパッケージの処理に責任を持ちます。
ほとんどの場合アップロードは、 dinstall
というアーカイブメンテナンスツールによって 基本的に毎日自動的に処理されます。
特に `unstable' ディストリビューションに存在するパッケージのアップロードは、
自動的に処理されます。 ただ、その他の場合、特に新規パッケージのような場合には、
特定のディストリビューションへのパッケージアップロードは手動で処理されます。
アップロードされたパッケージが手動で処理される場合、
アーカイブの変更には一週間ほど時間がかかります。 (辛抱強くお待ちください。)
どんな場合でも、パッケージアップロードの通知を電子メールで受け取れます。 この通知の内容は十分注意してお確かめください。 パッケージがあなたの想定していたセクションに設置されなかった場合、 そのことがこちらで通知されるでしょう。 その理由に関してはこちらをよくお読みください。
debian/control ファイルの Section および
Priority フィールドは、
そのファイルがアーカイブのどこに設置されるかや、その priority を
実際に特定するものではありません。
アーカイブ全体を整理された状態にしておくために、
これらのフィールドの管理はアーカイブメンテナが行ないます。 そのため
debian/control ファイルに設定された値は、
実際はそのヒントになるだけです。
アーカイブメンテナは、パッケージの正式なセクションやプライオリティを
override file にて管理します。 場合によっては override file
は修正が必要になります。 ただ、パッケージの control
ファイルを単に変更しても効果はありません。 その代わりに override-change@debian.org
に電子メールを送るか、 ftp.debian.org
に対するバグとして報告を行なわなければなりません
override files に関するより詳細な情報については、
dpkg-scanpackages(8) や、
/usr/doc/debian/bug-log-mailserver.txt、/usr/doc/debian/bug-maint-info.txt
をご覧ください。
aph@debian.orgschwarz@debian.orgijackson@gnu.ai.mit.edu