Debian デベロッパーズリファレンス --------------------------------- Adam Di Carlo, current maintainer Christian Schwarz Ian Jackson ver. 2.11, 2002年04月08日 ------------------------------------------------------------------------------- 著作権表示 ---------- copyright (c)1998, 1999 Adam Di Carlo copyright (c)1997, 1998 Christian Schwarz このマニュアルはフリーソフトウェアです。あなたは、Free Software Foundation が公表した GNU 一般公有使用許諾の第二版あるいはそれ以降のいずれかの版の 条件に基づいて、本文書の再配付および変更を行うことが可能です。 本文書はその有用性が期待されて配付されるものですが、 市場性や特定の目的への適合性に関する暗黙の保証も含め、 _いかなる保証も行ないません_。 詳細については GNU 一般公有使用許諾書をお読みください。 GNU 一般公有使用許諾の写しは、Debian GNU/Linux ディストリビューションの `/usr/share/common-licenses/GPL' や、WWW 上では GNU ウェブサイト (http://www.gnu.org/copyleft/gpl.html) にあります。また Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA へ手紙 (英語) で依頼し入手することもできます。 なお、この日本語訳については遠藤 美純 (1999 年) に著作権があります。 ------------------------------------------------------------------------------- 目次 ---- 1. この文書が扱う領域 2. 開発者になるための申し込み 2.1. はじめよう 2.2. Debian 開発者としての登録 2.3. Debian Mentors (指導者) 3. Debian に登録した自分の情報を管理する 3.1. 自分の公開鍵を管理する 3.2. 丁重に脱退する 4. メーリングリストや、サーバ、他のマシン 4.1. メーリングリスト 4.2. Debian サーバ群 4.2.1. master サーバ 4.2.2. WWW サーバ 4.2.3. CVS サーバ 4.2.4. Debian サーバのミラー 4.3. Debian の他のマシン 5. Debian アーカイブ 5.1. 概観 5.2. セクション 5.3. アーキテクチャ 5.4. サブセクション 5.5. パッケージ 5.6. ディストリビューションディレクトリ 5.6.1. 安定版、開発版、(時に) フリーズ版 5.6.2. 実験版 5.7. リリースコード名 6. パッケージのアップロード 6.1. 新規パッケージのアナウンス 6.2. パッケージをアップロードする 6.2.1. changes ファイルの作成 6.2.2. ディストリビューションの選択 6.2.2.1. _frozen_ へのアップロード 6.2.3. アップロードの前にパッケージをチェックする 6.2.4. `master' へのアップロード 6.2.5. `pandora' (non-us) へのアップロード 6.2.6. `chiark' 経由のアップロード 6.2.7. `erlangen' 経由のアップロード 6.2.8. 他のアップロードキュー 6.3. パッケージアップロードのアナウンス 6.4. 新規パッケージインストールの通知 6.4.1. オーバライドファイル 7. ノンメンテナアップロード (NMU) 7.1. 用語 7.2. NMU を行なうことができるのは誰か 7.3. source NMU を行なう場合には 7.4. source NMU を行なうには 7.4.1. source NMU のバージョン番号づけ 7.4.2. source NMU は新たな changelog エントリを必要とする 7.4.3. source NMU とバグ追跡システム 7.4.4. source NMU の構築 8. 移植作業と移植版 8.1. 移植作業者への配慮 8.2. 移植作業者によるアップロードに関するガイドライン 8.2.1. 移植作業者が source NMU を行なう場合には 8.3. 移植作業者用のツール群 8.3.1. `quinn-diff' 8.3.2. `buildd' 8.3.3. `dpkg-cross' 9. パッケージの移動、削除、改名、引き継ぎ、みなしご化 9.1. パッケージの移動 9.2. パッケージの削除 9.2.1. `Incoming' からのパッケージ削除 9.3. パッケージの置き換えや改名 9.4. パッケージのみなしご化 9.5. パッケージの引き継ぎ 10. バグの扱い 10.1. バグを監視する 10.2. バグを報告する 10.3. バグ報告に返信する 10.4. 新規アップロードによってバグをクローズする場合には 10.5. Lintian による報告 10.6. 一度にたくさんのバグ報告を行なう 11. Debian 開発者用ツールの概観 11.1. `dpkg-dev' 11.2. `lintian' 11.3. `debhelper' 11.4. `debmake' 11.5. `yada' 11.6. `equivs' 11.7. `cvs-buildpackage' 11.8. `dupload' 11.9. `fakeroot' 11.10. `devscripts' 11.11. `debget' ------------------------------------------------------------------------------- 1. この文書が扱う領域 --------------------- この文書の目的は、Debian 開発者に推奨される手続きと利用可能なリソースとに 関する概観を提供することにあります。 こちらで扱う諸手続きは、 開発者になる方法 (章 2, `開発者になるための申し込み') や、 新たなパッケージをアップロードする方法 (章 6, `パッケージのアップロード')、 他の開発者によるパッケージを移植したり臨時リリースするには いつどのようにしたらよいのか (章 7, `ノンメンテナアップロード (NMU)')、 パッケージを移動、削除、みなしご化 (orphan) する方法 (章 9, `パッケージの移動、削除、改名、引き継ぎ、みなしご化')、バグ報告の扱い方 (章 10, `バグの扱い') にわたります。 また、このリファレンスで触れるリソースには、 メーリングリストとサーバ (章 4, `メーリングリストや、サーバ、他のマシン')、 Debian アーカイブの構成に関する解説 (章 5, `Debian アーカイブ')、 パッケージアップロードを受け付けるさまざまなサーバの説明 (Section 6.2.4, ``master' へのアップロード')、 パッケージの品質を高めるために開発者が利用できるリソースについての解説 (章 11, `Debian 開発者用ツールの概観') などがあります。 初めに明らかにしておきたいのですが、 このリファレンスは、Debian パッケージに関する技術的な詳細や、 Debian パッケージの作成方法を説明するものではありません。 その情報については、 にて論じられています。 また、このリファレンスは Debian ソフトウェアが準拠すべき基準を詳細に解説するようなものでもありません。 その情報については、Debian ポリシーマニュアル (http://www.debian.org/doc/debian-policy/) をご覧ください。 さらに、この文書は_公式なポリシーを明らかにするものではありません_。 こちらに含まれるのは Debian システムに関する記述と、 一般的に認められている慣習に関する記述です。 ------------------------------------------------------------------------------- 2. 開発者になるための申し込み ----------------------------- 2.1. はじめよう --------------- あなたは、すでにすべての文書を読み、例題の `hello' パッケージの内容をすべて理解し、 さぁこれからお気に入りのソフトウェアを Debianize しようとしているとします。 では、Debian 開発者になって、自分で作ったパッケージを Debian プロジェクト に組み入れるためには、実際のところどうすればよいのでしょうか？ まだ を購読していないならば、 まず最初にこちらを購読しましょう。 _Subject_ に `subscribe' と書いた電子メールを に送ってください。 なにか問題があったら、メーリングリスト管理者 と連絡をとってください。 利用可能なメーリングリストについての情報は Section 4.1, `メーリングリスト' をご覧ください。 実際に行動を起こしたりコードを書いたりする前に、 まずはこちらを購読し、しばらくは様子を見て (つまり読むだけで投稿は控えて) みましょう。 そうしたら作業が重複しないように、 あなたがどんな作業を行なうかについての投稿をしてください。 を購読するのもよい考えです。 詳しくは Section 2.3, `Debian Mentors (指導者)' をご覧ください。 また Linux People IRC ネットワーク (例えば `irc.debian.org') 上の `#debian' IRC チャンネルも役に立つでしょう。 2.2. Debian 開発者としての登録 ------------------------------ Debian プロジェクトへの登録を決めるまえに、Debian の社会契約 (http://www.debian.org/social_contract)を読む必要があります。 開発者として登録するということは、 Debian の社会契約に同意し、その支持を誓約することを意味します。 Debian GNU/Linux の背景にある考え方の本質に対して、 開発者が同意をすることは極めて重要です。 また GNU 宣言 (http://www.gnu.org/gnu/manifesto.html) も読んでおくとよいでしょう。 開発者として登録するためには、 あなたの身元 (identity) とプロジェクトで何をするのか についての確認を行ないます。 Debian GNU/Linux に関わる作業を行なう人々の数は 800 人を越えるまでに増え、 私たちのシステムは極めて重要なさまざまな領域で利用されているために、 悪意を持った存在に対して慎重になる必要があります。 そのため、新メンテナにサーバのアカウントを与えパッケージのアップロードを 許可する前に、その新メンテナを確かめる必要があるのです。 登録に際しては、その手続きの一つとして、以下の情報を に送る必要があります。 * あなたの氏名 * 希望する `master' サーバのログイン名 (8 文字以下) と、 を購読する際の電子メールアドレス (一般的に、こちらはあなたが普段使っている電子メールアドレスか、 あなたの新しい `debian.org' アドレスになります。) * 連絡可能な電話番号。 注意していただきたいのですが、 新メンテナチームは長距離通話料を節約するために、通常は夜に電話をかけます。 夜に勤務先にいるのが普通でない限り、勤務先の電話番号は書かないでください。 * プロジェクト参加の意図に関する宣言。 こちらにはどんなパッケージを作成しようとしているか、 どの Debian 移植版を手伝おうとしているのか、 どのように Debian に貢献しようと考えているのかを書きます。 * Debian 社会契約 (http://www.debian.org/social_contract) を読み、 それを支持することに同意する旨の宣言 * あなたの実生活での身元を確認するための手段。 例えば以下に挙げる手段ならば問題ありません。 * 以下のものによる、私たちが確認可能な署名によってサインされた OpenPGP 鍵 * _実生活上_で会ったことがある現行の Debian 開発者 * あなたの身元を証明する (Verisign などのような) 公式な認証サービス。 電子メールアドレスに関する証明で、 あなたの身元を証明するものでないものでは、不十分です。 * また、ご自身の身元が確認できる公式証明書 (出生証明書、国民証明書、アメリカ合衆国運転免許証など) の写しをスキャン (あるいは郵送)、することによって身元を証明することもできます。 なお、こちらを電子メールで送る場合は、あなたの OpenPGP 鍵で署名してください。 もしまだ OpenPGP 鍵を持っていないならば、それを生成してください。 アップロードするパッケージに署名し、それを確認するために、 開発者には全員 OpenPGP 鍵が必要です。 お使いになるソフトウェアのマニュアル にはセキュリティに関する極めて重要な情報が書かれていますので、 そちらはよく読んでおいてください。 セキュリティ上の問題のほとんどは、 ソフトウェア上の欠陥や高度なクラック技術によるものというよりは、 人間のミスによるものなのです。 お使いになる公開鍵の管理に関するより詳細な情報については Section 3.1, `自分の公開鍵を管理する' をご覧ください。 Debian はその基準となる標準として `GNU Privacy Guard' (`gnupg' パッケージのバージョン 1 以降) を利用します。 同様に OpenPGP の他の実装を利用されても結構です。 なお、OpenPGP は RFC2440 (http://www.gnupg.org/rfc2440.html) におけるオープンな標準に基づくものです。 Debian の開発作業において用いられる公開鍵アルゴリズムとして推奨されるのは、 DSA (こちらは ``DSS'' や ``DH/ElGamal'' と呼ばれることもあります) です。 なお、他の種類の鍵をお使いになっても結構です。 しかし、お使いになる鍵の長さは、少なくとも 1024 ビットでなくてはなりません。 これより短い鍵はセキュリティが低いので、それをわざわざ使う必要はありません。 また、お使いになる鍵には、少なくともあなたのユーザ ID を用いて署名しておいてください。 こうすることによって ユーザ ID の改竄を防ぐことができます。 `gpg' はこちらを自動的に行ないます。 また お使いになる鍵上の名前の一つが、 作成したパッケージであなたが公式開発者として用いる 電子メールアドレスと一致するようにしてください。 例えば、私は `developers-reference' パッケージの開発者を ``Adam Di Carlo '' としていますが、 それゆえ、私の鍵のユーザ ID の一つは、これと同じ値 ``Adam Di Carlo '' を持っています。 まだあなたの公開鍵を `pgp5.ai.mit.edu' のような公開鍵サーバに 登録していない場合は、お手元のコンピュータで利用できる `/usr/share/doc/pgp/keyserv.doc' という文書をお読みください。 この文書には自分の鍵を公開鍵サーバに登録する方法が説明されています。 あなたの公開鍵が公開サーバに登録されていなかった場合は、 New Maintainer グループがその登録を行ないます。 アメリカ合衆国の輸出制限のために `gnupg' を含むいくつかのパッケージは、合衆国外の ftp サーバに置いてあります。 これらのパッケージが現在置かれている場所に関しては、 ftp://ftp.debian.org/debian/README.non-US をご覧ください。 国によっては、暗号ソフトウェアの利用を国民に禁じているところもあります。 しかし、(フランスの場合など) 暗号を扱う製品を、暗号の利用のためではなく認 証のために利用することは完全に合法ですから、こちらも Debian パッケージ開発 者の活動を妨げるものではありません。 Debian プロジェクトでは、暗号の生成、解読のために、 それを利用することは求められません。 なお、認証のための暗号利用が禁止されている国に住んでいる場合は、 特別な措置を講じますのでご連絡ください。 あなたに関する情報をすべて用意しおわり公開鍵が公開鍵サーバに登録されたら、 あなたのパッケージをアップロードできるよう 公式 Debian 開発者の登録を行なうために、 宛てに電子メールを送ってください。 この電子メールには、上記の情報がすべて含まれていなければなりません。 また、このメールには ftp://ftp.debian.org/debian/doc/debian-keyring.tar.gz や、 `debian-keyring' パッケージで配布される鍵データベース用に、 あなたの公開鍵を添えなければなりません。 (`gpg' の場合は `gpg --armor --export ' として鍵を取り出してください。) なお、この申請メールには自分で選んだ公開鍵で必ず署名してください。 これらの情報が受け取られて処理されれば、あなたの Debian 開発者としての新たなアカウントに関する情報が連絡されるはずです。 もし一ヶ月以内に何も連絡がなかったら、 申請メールが届いているかどうか尋ねるために、 フォローアップメッセージを送ってください。 申請メールを繰り返して送るようなことは、 New Maintainer チームが混乱するだけですので、 決して_しない_でください。 特にリリースが近づいている場合などは、 間違いも起こりやすく、担当者も時間に追われているので、 辛抱強くお待ちください。 2.3. Debian Mentors (指導者) ---------------------------- 新米開発者が初めてパッケージを作成したり、 開発に関連する他の問題を解決する際に、その手助けができるよう メーリングリスト が用意されています。 新規開発者にはこのメーリングリストの購読が進められています。 (詳細は Section 4.1, `メーリングリスト' をご覧ください。) (例えば、私的な電子メールのやりとりなど) 一対一の援助を望まれる場合も、 このメーリングリストを利用してください。 経験豊富な開発者が手助けを申し出てくれるでしょう。 ------------------------------------------------------------------------------- 3. Debian に登録した自分の情報を管理する ---------------------------------------- 3.1. 自分の公開鍵を管理する --------------------------- 各自の秘密鍵の扱いについては十分に注意してください。 それを公開サーバや `master.debian.org' のようなマルチユーザのマシンに置いたりしてはいけません。 またそのバックアップを取り、その写しをオフラインで保持しておいてください。 さらに、お使いになるソフトウェアに付属する説明書や、 PGP FAQ (http://www.cam.ac.uk.pgp.net/pgpnet/pgp-faq/) にも目を通してください。 あなたの公開鍵に署名やユーザ ID を加えたり削除した場合には 鍵サーバ上の公開鍵を更新するとともに、 あなたの公開鍵を に電子メールで送付する必要があります。 その鍵を取り出す方法については Section 2.2, `Debian 開発者としての登録' で説明してあります。 Debian における鍵管理についてのより詳細な検討については、 `debian-keyring' パッケージのドキュメントをご覧ください。 3.2. 丁重に脱退する ------------------- Debian プロジェクトから脱退を決めた場合は、 必ず以下の手続きを行なうべきです。 1. Section 9.4, `パッケージのみなしご化' の説明にしたがい、 自分のパッケージすべてをみなしご化する 2. プロジェクト脱退の理由に関する電子メールを に送る 3. 宛てに電子メールを送り、 Debian キーリング管理者にプロジェクト脱退を伝える ------------------------------------------------------------------------------- 4. メーリングリストや、サーバ、他のマシン ----------------------------------------- この章では、開発者が利用できる Debian メーリングリストおよび主な Debian サーバや他の Debian マシンに関する簡単な紹介を行ないます。 4.1. メーリングリスト --------------------- メーリングリストサーバは `lists.debian.org' にあります。 購読する場合は `subscribe' を購読を取り消す場合は `unsubscribe' と _Subject_ に書いて、 `debian--REQUEST@lists.debian.org' に電子メールを送ってください。 その際 `debian-' にはそのメーリングリストの名前を当てはめてください。 メーリングリストの購読とその購読取り消しに関するより詳細な説明については、 http://www.debian.org/MailingLists/subscribeや ftp://ftp.debian.org/debian/doc/mailing-lists.txt、また `doc-debian' パッケージをインストールしている場合は、 お手元のマシンの `/usr/share/doc/debian/mailing-lists.txt' をご覧ください。 メーリングリストのメッセージに返信をする場合、 カーボンコピー (`CC') をオリジナルの発信者に送ることは、 そうすることが明示的に求められていない限りはしないでください。 メーリングリストに投稿した人は、その返信をメーリングリスト上で読むはずです。 Debian の中核的なメーリングリストには、 や、 、、、 、 があります。 開発者は全員少なくとも と を購読することが期待されます。 特別な目的を持つ他のメーリングリストに関しては、 http://www.debian.org/MailingLists/subscribe をご覧ください。 また、クロスポスト (同じメッセージを複数のメーリングリストへ投稿すること) はなるべく避けてください。 は、Debian 開発者間の私的な議論のために 用意された特別なメーリングリストです。 こちらは、いかなる理由があったとしても、 公には公開しない投稿のために用いられるものです。 そのため、こちらは小規模なメーリングリストで、 本当に必要な場合を除いて の利用は勧められません。 さらに、このメーリングリストの電子メールを他者に転送しては _いけません_。 ネットワークにおける通例通りに、 返信する場合の記事の引用は控え目にしてください。 また、一般的にメッセージ投稿に関しては通例の慣習にしたがってください。 メーリングリストのオンラインアーカイブは http://lists.debian.org/ にて利用できます。 4.2. Debian サーバ群 -------------------- Debian サーバ群はよく知られていますが、 Debian プロジェクトにおいて極めて重要な機能を果たしています。 各開発者は各サーバがどのようなもので、何を行なっているのかを 知っておくべきでしょう。 もし Debian サーバの利用に問題があり、 その問題をシステム管理者に知らせる必要があると思われる場合は、 をご覧になって、その担当者の連絡先を確認してください。 また、サーバの利用に関するもの以外の問題 (例えばパッケージの削除や、ウェブサイトへの提案など) がある場合は、 一般的には「仮想パッケージ」に対するバグとして報告を行なってください。 バグ報告に関する情報については Section 10.2, `バグを報告する' をご覧ください。 4.2.1. master サーバ -------------------- master サーバ `master.debian.org' には、 (non-U.S. パッケージを除く) Debian アーカイブの正式な写しが保持されています。 一般的にパッケージはこのサーバにアップロードされます。 章 6, `パッケージのアップロード' をご覧ください。 また、バグ追跡システム (BTS) が正式におかれているのも、 この `master.debian.org' です。 Debian バグの統計的な分析や処理を行ないたい場合に、 それを行なうのもこちらになります。 しかしながら、そこに何かを実装する前には、 無駄な労力や時間の浪費を避けるために、 にてあなたのプランを説明してください。 Debian 開発者はすべて `master.debian.org' にアカウントを持ちます。 このマシンのパスワードの管理には注意してください。 危険を犯してインターネット越しにパスワードを送るような、 ログインやアップロードメソッドは避けるようにしてください。 `master.debian.org' でディスクフル、不審な動作などを見かけた場合は、 宛てに電子メールを送ってください。 Debian FTP アーカイブに関する問題については、通常 `ftp.debian.org' 仮想パッケージに対するバグとして報告するか、 宛てに電子メールを送る必要があります。 なお、その手続きについては 章 9, `パッケージの移動、削除、改名、引き継ぎ、みなしご化' をご覧ください。 4.2.2. WWW サーバ ----------------- メインウェブサーバである `www.debian.org' は、`va.debian.org' としても知られているものです。 開発者には全員にこのマシンのアカウントが付与されます。 ウェブ上でもっぱら Debian に関連する情報を提供したい場合は、 あなたのホームディレクトリ配下の `public_html' ディレクトリにファイルを設置すれば可能です。 こちらに関しては `va.debian.org' と `master.debian.org' のどちらで行なっても結構です。 その場所に設置したファイルは、 `http://www.debian.org/~/' か `http://master.debian.org/~/' という URL 経由でそれぞれアクセスすることができます。 場合によっては `master' 上にファイルを設置する必要があるかもしれませんが、 一般的には `www.debian.org' アドレス用に `va' をご利用になりたいでしょう。 前もって許可を得ていない限り、Debian に関係のないコンテンツを Debian サーバ上には設置しないください。 何か質問があるときには へ電子メールを送ってください。 Debian ウェブサーバに問題を見つけた場合、通常は `www.debian.org' 仮想パッケージに対するバグとして報告してください。 なお、まず初めに誰かがすでに同じ問題を報告していないかどうかを バグ追跡システム (http://www.debian.org/Bugs/db/pa/lwww.debian.org.html) で確認してください。 4.2.3. CVS サーバ ----------------- `cvs.debian.org' は前述の `va.debian.org' としても知られているものです。 開発者が複数いるパッケージの協同作業を手伝う場合など、 CVS サーバへの公開アクセスを利用したい場合は、 このサーバの CVS エリア利用を依頼することができます。 一般的に `cvs.debian.org' は、ローカル CVS アクセスや、 クライアント/サーバ式アノニマス読み込み専用アクセス、 `ssh' 経由クライアント/サーバ式フルアクセスを 組み合わせて提供します。 また、この CVS エリアには http://cvs.debian.org/ からウェブ経由で読み込み専用アクセスをすることができます。 CVS エリア利用の依頼をする場合は、 宛てに電子メールで依頼してください。 その際には、必要とする CVS エリアの名前や、CVSROOT の所有者となる `va.debian.org' 上のユーザアカウント、 こちらを必要とする理由を書き添えてください。 4.2.4. Debian サーバのミラー ---------------------------- ウェブサーバおよび FTP サーバには、利用可能なミラーサーバが複数あります。 中核となる FTP サーバやウェブサーバには高い負荷を与えないでください。 理想的には、中核となるサーバは第一陣のミラーサーバにミラーを行なうのみで、 ユーザはすべてミラーにアクセスすることが望ましいです。 こうすれば Debian は必要とするネットワーク帯域を、 複数のサーバやネットワークにより適切に分散させることができます。 なお、より新しいミラーリング送出技術によって、 ミラーが可能な限り最新であることが保証されます。 利用可能な公開 FTP (および、通常は、HTTP) サーバの一覧を掲載するメインウェブページは http://www.debian.org/distrib/ftplist にあります。 Debian ミラーに関するより詳しい情報については http://www.debian.org/mirror/ をご覧ください。 この有益なページには、内部向けアクセスや公的アクセスのどちらにおいても、 独自にミラーを設置することに関心がある場合に 役立つ情報やツールが含まれています。 普通これらのミラーは Debian への協力に関心のあるサードパーティーによって運営されています。 そのため通常、開発者はこれらのマシンにアカウントがありません。 `master.debian.org' のミラーをとることはしないでください。 このホストはすでに相当高い負荷を負っています。 その情報については上記のサイトを確認するか、 宛てに電子メールを送ってください。 4.3. Debian の他のマシン ------------------------ 開発者が利用できる Debian マシンは他にもあります。 これらのマシンは、利用者が適切であると判断する範囲内で、 Debian に関連する目的に利用できます。 なお、各システム管理者に迷惑をかけないように注意してください。 また、まず最初にローカルメンテナに了解を得ない限りは、 ディスクスペースや、ネットワーク帯域、CPU などをむやみに使わないでください。 普通これらのマシンはボランティアによって運営されています。 これらのマシンは一般的に移植作業用です。 Section 4.2, `Debian サーバ群' で触れた各サーバとは別に、 Debian 開発者が利用できるマシンの一覧が http://db.debian.org/machines.cgi にあります ------------------------------------------------------------------------------- 5. Debian アーカイブ -------------------- 5.1. 概観 --------- Debian GNU/Linux ディストリビューションは、数多くの Debian パッケージ (現在約 6800 ある `.deb' ファイル) といくつかの付加的なファイル (ドキュメントやインストールディスクイメージなど) から構成されています。 以下は完全な Debian ディストリビューションのディレクトリツリーの一例です。 dists/stable/main/ dists/stable/main/binary-all/ dists/stable/main/binary-all/admin/ dists/stable/main/binary-all/base/ dists/stable/main/binary-all/comm/ dists/stable/main/binary-all/devel/ ... dists/stable/main/binary-i386/ dists/stable/main/binary-i386/admin/ dists/stable/main/binary-i386/base/ ... dists/stable/main/binary-m68k/ dists/stable/main/binary-m68k/admin/ dists/stable/main/binary-m68k/base/ ... dists/stable/main/source/ dists/stable/main/source/admin/ dists/stable/main/source/base/ ... dists/stable/main/disks-i386/ dists/stable/main/disks-m68k/ ... dists/stable/contrib/ dists/stable/contrib/binary-all/ dists/stable/contrib/binary-i386/ dists/stable/contrib/binary-m68k/ ... dists/stable/contrib/source/ dists/stable/non-free/ dists/stable/non-free/binary-all/ dists/stable/non-free/binary-i386/ dists/stable/non-free/binary-m68k/ ... dists/stable/non-free/source/ dists/testing/ dists/testing/main/ ... dists/testing/contrib/ ... dists/testing/non-free/ ... dists/unstable dists/unstable/main/ ... dists/unstable/contrib/ ... dists/unstable/non-free/ ... pool/ pool/a/ pool/a/apt/ ... pool/b/ pool/b/bash/ ... pool/liba/ pool/liba/libalias-perl/ ... pool/m/ pool/m/mailx/ ... ご覧の通りに、ディストリビューションのトップレベルディレクトリには、 _main_、_contrib_、_non-free_ の三つのディレクトリがあります。 これらのディレクトリは _sections_ と呼ばれています。 各セクションには、ソースパッケージ用のディレクトリ (`source')、サポートされている各アーキテクチャ用のディレクトリ (`binary-i386'、`binary-m68k' など)、 アーキテクチャ非依存のパッケージ用のディレクトリ (`binary-all') があります。 _main_ セクションには、特定のアーキテクチャにおいて Debian ディスト リビューションをインストールする際に必要となるディスクイメージと、 いくつかの基本的な文書を収録するための付加的なディレクトリ (`disks-i386'、`disks-m68k' など) が含まれています。 _binary_ および _source_ ディレクトリは、 さらに _subsections_ に分かれています。 5.2. セクション --------------- _公式 Debian GNU/Linux ディストリビューション_ を構成するのが _main_ セクションです。 _main_ セクションは、 私たちのガイドラインすべてに完全に適合するがゆえに公式なものです。 他の二つのセクションは程度の違いはありますが、 このガイドラインに適合しないために、 Debian の公式な構成要素ではありません。 _main_ セクションの全パッケージは Debian フリーソフトウェアガイドライン (http://www.debian.org/social_contract#guidelines)(DFSG) と Debian ポリシーマニュアル (http://www.debian.org/doc/debian-policy/) に記載されている他のポリシー上の要件を完全に満たしています。 DEFS は「フリーソフトウェア」に関する私たちの定義です。 詳しくは Debian ポリシーマニュアルをご覧ください。 DFSG に適合しないパッケージは _non-free_ セクションに置かれます。 これらのパッケージに関しては、その利用のサポートや _non-free_ ソフトウェアパッケージのためのインフラ (バグ追跡システムや、メーリングリストなど)は提供しますが、 Debian ディストリビューションの一部とは見なされません。 _contrib_ セクションのパッケージは DFSG に適合していなければなりませんが、 他の要件を満たせないものが当てはまります。 例えば _non-free_ パッケージに依存するパッケージなどです。 この三つのセクションに関しては、 Debian ポリシーマニュアル (http://www.debian.org/doc/debian-policy/) により正確な定義が記述されています。 上記の説明は簡易的なものです。 アーカイブのトップレベルを三つのセクションに分けていることは、 インターネット上の FTP サーバや CD-ROM などを経由して Debian を配布したいと考える人々にとって重要です。 というのも、_main_ および _contrib_ セクションのみを配布するならば、 あらゆる法的な危険を避けることができるからです。 例えば _non-free_ セクションのパッケージのいくつかは 商業配布が禁じられています。 一方、CD-ROM ベンダにとっては _non-free_ パッケージの個々のライセンスをチェックし、許可を得たものを CD-ROM に収録することが容易になります。 (この扱いはベンダによってさまざまでしょうから、 この作業は Debian 開発者によっては行なわれません。) 5.3. アーキテクチャ ------------------- 当初 Linux カーネルが利用できたのは Intel i386 (およびそれ以降) プラットフォームのみで、Debian も同様でした。 しかし Linux がより普及すると、 カーネルも他のアーキテクチャへと移植されるようになりました。 Linux 2.0 カーネルは Intel x86 や、DEC Alpha、SPARC、(Atari や、 Amiga、Macintoshes といった) Motorola 680x0 、MIPS、PowerPC などをサポートしています。 Linux 2.2 カーネルはさらに、ARM や UltraSPARC を含むより多くのアーキテクチャをサポートします。 Debian は、Linux がサポートするプラットフォームを 同様にサポートすべきだとしています。 そのため Debian には作業中の移植版があり、 また実際のところ非 Linux カーネルへの移植版も作業中です。 _i386_ (Intel x86 の私たちの呼び名) は別にして、 この文書が書かれている現在、_m68k_ や、_alpha_、 _powerpc_、_sparc_、_hurd-i386_ _arm_ などが作業中です。 Debian GNU/Linux 1.3 は _i386_ 版のみが利用可能でした。 Debian 2.0 では _i386_ および _m68k_ アーキテクチャ版が提供されました。 Debian 2.1 では _i386_、_m68k_、_alpha_、および _sparc_ アーキテクチャ版が提供されました。 Debian 2.1 では _powerpc_ アーキテクチャのサポートが追加されます。 特定の移植版に関する開発者向け、あるいはユーザ向の情報は Debian 移植版ウェブページ (http://www.debian.org/ports/) をご覧ください。 5.4. サブセクション ------------------- _main_、_contrib_、_non-free_ の各セクションは、 インストールプロセスやアーカイブのメンテナンスを単純化するために _subsections_ に分割されます。 サブセクションは、`base' サブセクションを除けば、 正式には定義されていません。 サブセクションは単に、 利用可能なパッケージの整理と閲覧を容易にするために存在しています。 どのセクションが利用可能かどうかは、 現行の Debian ディストリビューションをチェックしてください。 5.5. パッケージ --------------- Debian パッケージには、_source_ パッケージと _binary_ パッケージの二種類があります。 ソースパッケージは、`.dsc' ファイルと `.tar.gz' ファイル、あるいは、`.dsc' ファイルと `.orig.tar.gz'、`.diff.gz' ファイルといった二つないし三つのファイルから構成されています。 Debian 専用に開発され Debian 以外で配布されていないパッケージでは、 プログラムのソースを含むファイルは `.tar.gz' ファイルのみです。 一方 Debian 以外でも配布されているパッケージの場合は、 `.orig.tar.gz' ファイルにいわゆる _upstream source code_ を収めます。これは _upstream maintainer_ (たいていはそのソフトウェアの作者) によって配布されているソースコードです。 この場合、Debian 開発者によって加えられた変更は `.diff.gz' ファイルに収められます。 `.dsc' ファイルには、ソースパッケージのファイル一覧や、 チェックサム (`md5sums')、パッケージに関するいくらかの追加情報 (パッケージ開発者やバージョンなど) が収められます。 5.6. ディストリビューションディレクトリ --------------------------------------- 前章で説明したディレクトリシステムは、 _distribution directories_ に含まれるものです。 全ディストリビューションは Debian アーカイブのトップレベルディレクトリ にある `dists' ディレクトリに収められています。 (トップレベルディレクトリから各ディストリビューションに張られている シンボリックリンクは、下位互換のためにあるもので、重要なものではありません。) 要約すれば、Debian アーカイブは FTP サーバにルートディレクトリを持っているといえます。 例えば、ミラーサイト ftp.us.debian.org では、 Debian アーカイブ全体は /debian に収められていますが、その位置は共通しています。 (/pub/debian にある場合もあります。) 実際の個々のディストリビューションは そのアーカイブのルートにある `dists' ディレクトリに収められています。 以下はそのレイアウトの概要です。 /dists//
/// このレイアウトから推察して、 _slink_ ディストリビューションの i386 ベースパッケージを探すには /debian/dists/slink/main/binary-i386/base/ を見ればいいことが分かるでしょう。 5.6.1. 安定版、開発版、(時に) フリーズ版 ---------------------------------------- Debian のディストリビューションには (`dists/stable' にある) _stable_ (安定版) と呼ばれるものと、 (`dists/unstable' にある) _unstable_ (開発版)と呼ばれるものの二つが常に存在します。 こちらは Debian プロジェクトの開発プロセスを反映しています。 活発な開発は、_unstable_ ディストリビューションで行なわれます。 (そのためこのディストリビューションはときに _development distribution_ とも呼ばれます。) 全 Debian 開発者はいつでも、 このディストリビューションで自分のパッケージを更新することができます。 そのため、このディストリビューションの内容は日に日に変わっていきます。 このディストリビューションは特別にテストされているものではないので、 時に「不安定」なものです。 開発期間が終了すると、_unstable_ ディストリビューションは _frozen_ と呼ばれる新たなディストリビューションディレクトリに コピーされます。 この後は、バグフィックスを除くいかなる変更も frozen ディストリビューションに対してはできません。 こちらが「フリーズ版 frozen」と呼ばれるのはそのためです。 一ヶ月あるいはもうすこし以上経つと、 _frozen_ ディストリビューションは _stable_ に名前を変えます。 古い _stable_ は上書きされ、この時点で消去されます。 この開発サイクルは _unstable_ ディストリビューションが、 _frozen_ ディストリビューションとしてのテスト期間を経て、 _stable_ ディストリビューションになるとの仮定に基づいたものです。 あるディストリビューションが安定していると見なされたとしても、 二三のバグは必ず残っているものです。 _stable_ ディストリビューションが時々更新されるのはこのためです。 しかしながら、これらの更新は極めて注意深くテストされ、 新たなバグを持ち込む危険を避けながら個々にアーカイブに導入されねばなりません。 _stable_ ディストリビューションへの追加推奨パッケージは、 `proposed-updates' ディレクトリにあります。 検査に合格した `proposed-updates' にあるこれらのパッケージは、 定期的にまとめて _stable_ ディストリビューションに移動され、 _stable_ ディストリビューションのリビジョンレベルが上げられます。 (例えば、`1.3' は `1.3r1' に、`2.0r2' は `2.0r3' となっていきます。) 古い _unstable_ ディストリビューションが _frozen_ ディストリビューションに移動されると、新たな _unstable_ ディストリビューションが作られるため、``freeze'' 期間の間も _unstable_ ディストリビューションの開発は続けられます。 また他の変更点としては、_frozen_ ディストリビューションが公式に リリースされた際、Debian アーカイブから古い _stable_ ディストリビューションが (`archive.debian.org' には残されますが) 完全に消去されることがあげられます。 要約すれば、常に _stable_ および _unstable_ ディストリビューションが利用可能で、 時々 _frozen_ ディストリビューションが一ヶ月かもしくはそれ以上の間 設置されるということです。 5.6.2. 実験版 ------------- _experimental_ ディストリビューション (実験版) は 特別なディストリビューションです。 こちらは `stable' や `unstable' とは異なり、 完全なディストリビューションではありません。 こちらはその代わりに、 お使いのシステムを破壊しかねない極めて実験的なソフトウェアのための、 一時的な設置領域であることを意味します。 _experimental_ ディストリビューションからパッケージを ダウンロードしインストールするユーザは、 このことを十分に注意すべきことが望まれます。 つまり、_experimental_ ディストリビューションに賭けることは 間違っているということです。 _experimental_ ディストリビューションの利用を選択する際、 開発者は十分に注意すべきです。 もしあるパッケージが極めて不安定なものだったとしても、 description (パッケージ解説文) に二三の警告を掲載するなどして、 _unstable_ ディストリビューションにアップロードする方がよいでしょう。 しかしながら、システムに極めて深刻な損害を与えかねないソフトウェアに関しては、 _experimental_ ディストリビューションにアップロードするほうが 適切でしょう。 例えば実験的な暗号ファイルシステムなどは、おそらく _experimental_ ディストリビューション向きでしょう。 完全に異なる設定を用いる新しいベータ版のソフトウェアなども、 開発者の裁量によりますが _experimental_ ディストリビューション向きでしょう。 新しくてもシステムに損害を与えるようなことがないソフトウェアは、 _unstable_ ディストリビューションにアップロード可能です。 お使いのシステムのアップグレードが不完全な場合やその状況が複雑な場合は、 テスタたちが用意にアクセスできるように _experimental_ ディストリビューションを 一時的な領域として利用することもできます。 しかしながら、_experimental_ ディストリビューションを 個人的な一時領域として利用することは、常によい考えであるとは限りません。 そこに設置したファイルを自分で置き換えたり更新したりできないからです。 (`dinstall' や Debian アーカイブメンテナがそれを行ないます。) さらに、そのパッケージを _unstable_ ディストリビューションにアップロードした場合には、 _experimental_ ディストリビューション上からそれを削除するよう アーカイブメンテナに依頼することを覚えておかなくてはいけないでしょう。 Debian アーカイブメンテナの負担を減らすためにも、 こちらに関しては一般的に `va.debian.org' 上にある個人用ウェブスペースを利用することがより適切です。 5.7. リリースコード名 --------------------- リリースされた各 Debian ディストリビューションには _code name_ が付けられます。 Debian 1.1 には `buzz'、Debian 1.2 には `rex'、Debian 1.3 には `bo'、 Debian 2.0 には `hamm'、Debian 2.1には `slink'、そして Debian 2.2 には `potato' という _code name_ が付けられています。 また、`sid' と名づけられた「仮想ディストリビューション」もあります。 こちらには、Debian によって公式にはサポートおよびリリースされていない アーキテクチャのパッケージが収録されます。 これらのアーキテクチャは、 将来的にはメインディストリビューションに統合される計画にあります。 Debian はオープンな開発モデルを取っているので、 _unstable_ ディストリビューションでさえも Debian FTP、HTTP サーバネットワークからインターネット経由で 配布されています。 そのため、開発バージョンを収録したディレクトリの名前を `unstable' としたならば、そのバージョンをリリースする際にはその名前を `stable' に変更しなければなりませんが、 このことによって FTP ミラーはディストリビューション全体 (すでに極めて巨大です!) を再取得しなければならなくなります。 一方初めからディストリビューションディレクトリを _Debian-x.y_ としたならば、Debian リリース _x.y_ が利用可能だと受け止められてしまうでしょう。 (過去にある CD-ROM ベンダが、pre-1.0 開発バージョンをベースに Debian 1.0 CD-ROM を作成したことがありました。 Debian 最初の公式リリースが 1.0 ではなく 1.1 だったのはこのためでした。) そのため、アーカイブ中のディストリビューションディレクトリの名前は、 そのリリース状態ではなく (`slink' のような) コード名によって定められています。 これらの名前は、開発期間中もリリースの後も同じものになっており、 変更可能なシンボリックリンクが、 現行のリリース済み安定ディストリビューションを指し示します。 ディストリビューションディレクトリの実体に _code names_ を用い、 適切なリリースディレクトリを指すために _stable_、_unstable_、 _frozen_ へのシンボリックリンクを用いるのはこのためです。 ------------------------------------------------------------------------------- 6. パッケージのアップロード --------------------------- 6.1. 新規パッケージのアナウンス ------------------------------- Debian ディストリビューション用に新たなパッケージを作成しようと考えたら、 まず最初に Work-Needing and Prospective Packages (WNPP) (http://www.debian.org/devel/wnpp/) の一覧をチェックしてください。 WNPP をチェックすることによって、 まだ誰もそのソフトウェアのパッケージング作業を行なっていないこと、 作業が重複していないことが確認できます。 あなたが作業を予定しているパッケージにまだ誰も手をつけていないことが 分かったら、新たなパッケージ作成に関するあなたの計画を説明するために 簡潔な電子メールを 宛てに送ります。 その電子メールのサブジェクトは ``intent to package '' とするべきです。 のところには新たなパッケージの名前を当てはめてください このような手順を踏むことを開発者にお願いするのは、 以下のようないくつかの理由のためです。 * この手順は (潜在的な新) 開発者がメーリングリストの人々の経験に与る助けになり、 また既に誰かが作業していた場合その人に連絡することにもなります。 * そのパッケージの作業を考えていた他の人々に、 その作業の志願者がいることやまたその作業を協同して行なえることを 知らしめることができます。 への ``intent to package'' メッセージは WNPP メンテナによって収集され、その申し出は WNPP 文書の改訂版で公開されます。 * 他の開発者に、パッケージ一行解説文や、 普通デフォルトで `debian-devel-changes' に投稿される ``Initial version'' の changelog エントリ よりも詳しいパッケージ情報を伝えることができます。 * このことは (テスタの第一陣を形成している) 開発版を常時使っている人々に 役立ちます。私たちはこのような人々を鼓舞すべきです。 * このアナウンスは、開発者や関心の高い他のグループに対して、 当プロジェクトで行なわれていること、新しく起こっていることについての よりよい好感をもたらします。 6.2. パッケージをアップロードする --------------------------------- 6.2.1. changes ファイルの作成 ----------------------------- Debian FTP アーカイブにパッケージをアップロードする際には、 アーカイブメンテナにその扱いを指示するための `.changes' を添えなければなりません。 こちらは普通、通常のパッケージ構築プロセスの最中に `dpkg-genchanges' によって生成されます。 この changes ファイルは以下のフィールドをもつ制御ファイルです。 * `Format' * `Date' * `Source' * `Binary' * `Architecture' * `Version' * `Distribution' * `Urgency' * `Maintainer' * `Description' * `Changes' * `Files' Debian アップロードの際、これらのフィールドはすべて必須です。 これらのフィールドの内容については の制御フィールドの一覧をご覧ください。 また、`Description' フィールドを用いれば 自動的にバグをクローズすることが可能です。 こちらに関しては Section 10.4, `新規アップロードによってバグをクローズする場合には' をご覧ください。 なお、この節ではアーカイブメンテナンスのポリシーに関わる `Distribution' フィールドのみを取り上げます。 6.2.2. ディストリビューションの選択 ----------------------------------- とりわけ `debian/changelog' ファイルから生成される `Distribution' フィールドは、 そのパッケージがどのディストリビューション向けのものなのかを示します。 このフィールドの値には、`stable'、`unstable'、`frozen'、`experimental' の四つが当てはまりえます。 またこれらの値は組み合わせて当てはめられる場合もあります。 例えば、極めて重要なセキュリティ上の修正を施したパッケージのリリースがあり、 そのパッケージが _stable_ および _unstable_ ディストリビューションの双方に必要なものであったならば、 `changelog' の `Distribution' フィールドには `stable unstable' と記入します。 あるいは、Debian がフリーズされており _frozen_ ディストリビューションにバグ修正リリースを収録したい場合は、 そのディストリビューションは `frozen unstable' とします。 (_frozen_ へアップロードする際のより詳細な情報については Section 6.2.2.1, `_frozen_ へのアップロード' をご覧ください。) なお注意していただきたいのですが、ディストリビューションを `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' フラグを用いて、 新しいバージョンのオリジナルソースをアップロードしなければなりません。 6.2.2.1. _frozen_ へのアップロード ---------------------------------- Debian フリーズは Debian にとって重要な期間です。 この期間はディストリビューション全体を調和させ安定化させる機会なのです。 それゆえ、_frozen_ へアップロードする際には注意を要します。 最新のソフトウェアを常にリリースに収録するという試みは、 魅惑的なことです。 しかしながら、システムが全体として安定し、 期待している通りに動作することの方がより重要なことです。 _frozen_ へのアップロードのモットーは 「_新たなコードは入れない_」です。 その基準を定めることは難しいことですが、 以下のようないくつかのガイドラインがあります。 * _critical_、_grave_ といった深刻なバグや、 重要な _important_ バグなどの修正は、最終リリース時に 収録しなければならないパッケージに対しては常に可能です。 * 必ずしも収録の必要のないパッケージに対しては、 _critical_ や、_grave_、_important_ なバグの修正は、新たな機能を一切追加しない場合のみ可能です。 * _normal_ バグの修正は (推奨はされませんが) 新たな機能を追加しない場合 (のみ) 可能です。 * _wishlist_ に関する修正はできません。 (それは結局のところバグではないからです。) * 文書が優れていることは重要ですから、文書に関するバグ修正は可能です。 新たなバグを招いてしまう可能性が、どんなバグ修正にでも 統計的に 15% はあることを心に留めておいてください。 新たなバグの混入や発見は、リリースを遅らせたり、 最終的なプロダクトの品質を低下させたりするのです。 元々のバグの重大さと新たに混入したバグの重大さとの間に、 相関関係はほとんどありません。 6.2.3. アップロードの前にパッケージをチェックする ------------------------------------------------- あなたのパッケージをアップロードする前に、 それに対して基本的なテストを行なうべきです。 必ず以下の作業を行なうようにしてください。 (現行の Debian パッケージがあれば、その古いバージョンも必要になるでしょう。) * パッケージをインストールし、 そのソフトウェアが動作するかどうかを確認してください。 また、すでにその Debian パッケージが存在する場合は、 そのパッケージを古いバージョンから作成した新しいバージョンに アップグレードしてみてください。 * そのパッケージに対して `lintian' を実行してください。 `lintian' は、 `lintian -v .changes' として実行します。 こちらは、バイナリパッケージもソースパッケージもチェックします。 `lintian' が生成する出力が理解できない場合は、 `-i' スイッチを追加してご覧ください。 こうすれば `lintian' は、 そのプログラムに関する大変冗長な解説を出力します。 `lintian' がエラーを出した場合 (その行は `E' から始まります)、 通常はそのパッケージをアップロードすべきでは_ありません_。 `lintian' に関するより詳細な情報については Section 11.2, ``lintian'' をご覧ください。 * そのパッケージを (もし存在すれば) 以前のバージョンにダウングレードしてみてください。 -- こちらは `postrm' および `prerm' スクリプトのテストになります。 * そのパッケージを削除し、それを再インストールしてみてください。 6.2.4. `master' へのアップロード -------------------------------- パッケージをアップロードするためには、 master.debian.org に個人アカウントが必要です。 開発者はすでに全員このアカウントを持っているはずです。 こちらに関しては Section 4.2.1, `master サーバ' をご覧ください。 そのファイル群を転送するには `scp' と `ftp' のいずれも利用できます。 どちらを使う場合でも、そのファイル群は ftp://samosa.debian.org/pub/UploadQueue/ に設置する必要があります。 匿名 FTP を利用して master 上の Incoming にアップロードすることはできません。 -- あなたのユーザ名とパスワードを使わなければなりません。) _注意:_ アメリカ合衆国政府によって輸出規制されているソフトウェアを パッケージが含む場合は、それを `master' や、海外にある `chiark' や `erlangen' のアップロードキューには アップロードしないでください。 この規制は、ほぼすべての暗号ソフトウェアや、 時にはPGP 暗号および認証をサポート電子メールリーダのような 暗号ソフトウェアを「利用する」ソフトウェアにも及びます。 このようなソフトのアップロードは `non-us' に行なってください。 (Section 6.2.5, ``pandora' (non-us) へのアップロード' をご覧ください。) アメリカ合衆国の輸出規制があなたのパッケージに適用されるかどうか はっきりしない場合は、 にメッセージを投稿し質問してください。 また、パッケージをアップロードする際、 Debian package `dupload' が便利なことにお気づきになるでしょう。 この便利なプログラムは、デフォルトで `ftp' を経由し `master' や、`chiark'、 `erlangen' へのアップロードができるようになっています。 こちらは `ssh' を利用するように設定することもできます。 より詳細な情報については dupload(1) と dupload(5) をご覧ください。 6.2.5. `pandora' (non-us) へのアップロード ------------------------------------------ 前述の通り、輸出規制されているソフトウェアは `master' にアップロードしてはいけません。 その代わりに 非匿名 FTP か `scp' を使って、 パッケージを pandora.debian.org にコピーし、 そのファイル群を /org/non-us.debian.org/incoming/ に設置してください。 デフォルトで `master' と同じアカウントが使えます。 `dupload' プログラムは `pandora' へのアップロードをサポートしています。 詳細はプログラム付属のドキュメントを参照してください。 6.2.6. `chiark' 経由のアップロード ---------------------------------- `master' へのネットワーク接続が遅い場合、 その代わりとなるものがあります。 その一つが、`chiark' 上にあるヨーロッパのアップロードキュー経由で `Incoming' にファイル群をアップロードする方法です。 その詳細については ftp://ftp.chiark.greenend.org.uk/pub/debian/private/project/README.how-to-upload をご覧ください。 _注意:_アメリカ合衆国政府によって輸出規制されている ソフトウェアを含むパッケージを `chiark' のキューにアップロードしないでください。 このアップロードキューは `master' に向けられたものですので、 Section 6.2.4, ``master' へのアップロード' で説明した法規がここでも同様に適用されます。 `dupload' プログラムは `chiark' へのアップロードをサポートしています。 詳細はプログラム付属のドキュメントを参照してください。 6.2.7. `erlangen' 経由のアップロード ------------------------------------ 他にもドイツにあるアップロードキューが利用できます。 匿名 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' に向けられたものですので、 Section 6.2.4, ``master' へのアップロード' で説明した法規がここでも同様に適用されます。 `dupload' プログラムは `erlangen' へのアップロードをサポートしています。 詳細はプログラム付属のドキュメントを参照してください。 6.2.8. 他のアップロードキュー ----------------------------- アメリカ合衆国にある他のアップロードキューも利用できます。 こちらは `master' に接続できない問題が発生した際の 優れたバックアップ手段です。 `erlangen' と同様に ftp://samosa.debian.org/pub/UploadQueue/ にファイル群をアップロードすることができます。 日本でもアップロードキューが利用できます。ftp://master.debian.or.jp/pub/Incoming/upload/ への匿名 FTP 経由でファイル群をアップロードしてください。 6.3. パッケージアップロードのアナウンス --------------------------------------- パッケージをアップロードしたら、 そのアナウンスを``debian-changes'' メーリングリストの一つに投稿しなければなりません。 そのアナウンスの _Subject_ フィールドには (ソース) パッケージ名、バージョン番号、変更事項の極めて簡潔な要約を含め、 その本文には PGP で署名された `.changes' ファイルを含めます。 付加的な説明文は `.changes' ファイルの前に付け加えます。 あるパッケージが、その `Distribution:' フィールドに `stable' と記述されてリリースされる場合、 そのアナウンスは に送ります。 一方あるパッケージが、その `Distribution:' フィールドに `unstable' や、`experimental'、(もしあれば) `frozen' などが記述されてリリースされる場合、 そのアナウンスは に送らなければなりません。 場合によっては、_stable_ と _unstable_ ディストリビューションの両方にパッケージをアップロードする必要がありますが、 この場合は `Distribution:' フィールドに 両方のディストリビューション名を記述してください。 この場合アップロードアナウンスは、 上記のメーリングリストの両方に投稿してください。 なお、`dupload' プログラムは、 アナウンスをどこへ投稿すべきかを判断し 適切なメーリングリストに自動的にアナウンスを投稿してくれます。 Section 11.8, ``dupload'' をご覧ください。 6.4. 新規パッケージインストールの通知 ------------------------------------- Debian アーカイブメンテナが、 アップロードされたパッケージの処理に責任を持ちます。 ほとんどの場合アップロードは、 `dinstall' というアーカイブメンテナンスツールによって 基本的に毎日自動的に処理されます。 特に `unstable' ディストリビューションに存在するパッケージのアップロードは、 自動的に処理されます。 ただ、その他の場合、特に新規パッケージのような場合には、 特定のディストリビューションへのパッケージアップロードは手動で処理されます。 アップロードされたパッケージが手動で処理される場合、 アーカイブの変更には一週間ほど時間がかかります。 (辛抱強くお待ちください。) どんな場合でも、パッケージアップロードの通知を電子メールで受け取れます。 この通知の内容は十分注意してお確かめください。 パッケージがあなたの想定していたセクションに設置されなかった場合、 そのことがこちらで通知されるでしょう。 その理由に関してはこちらをよくお読みください。 6.4.1. オーバライドファイル --------------------------- `debian/control' ファイルの `Section' および `Priority' フィールドは、 そのファイルがアーカイブのどこに設置されるかや、その priority を 実際に特定するものではありません。 アーカイブ全体を整理された状態にしておくために、 これらのフィールドの管理はアーカイブメンテナが行ないます。 そのため `debian/control' ファイルに設定された値は、 実際はそのヒントになるだけです。 アーカイブメンテナは、パッケージの正式なセクションやプライオリティを _override file_ にて管理します。 場合によっては _override file_ は修正が必要になります。 ただ、パッケージの `control' ファイルを単に変更しても効果はありません。 その代わりに に電子メールを送るか、 `ftp.debian.org' に対するバグとして報告を行なわなければなりません _override files_ に関するより詳細な情報については、 dpkg-scanpackages(8) や、 `/usr/share/doc/debian/bug-log-mailserver.txt'、`/usr/share/doc/debian/bug-maint-info.txt' をご覧ください。 ------------------------------------------------------------------------------- 7. ノンメンテナアップロード (NMU) --------------------------------- 状況によっては、あるパッケージをその公式な開発者以外の誰かが リリースしなければならないことがあります。 このことはノンメンテナアップロード、すなわち NMU と呼ばれています。 異なるアーキテクチャ向けのパッケージを作成するという Debian の移植作業に携わる人にとっては、 この NMU は正規の移植作業の一環にあります。 (章 8, `移植作業と移植版' をご覧ください。) 他にも、特にフリーズ期間などに、 セキュリティや機能に関する深刻な問題を処理するために、 Debian 開発者が他の開発者のパッケージを修正する必要がある場合、 つまり、パッケージ開発者が修正版を即座にリリースできない場合には NMU が行なわれます。 この章では、NMU がいつどのように行なわれるべきかについての ガイドラインを扱います。 なお次節で説明しますが、この NMU には source NMU と binary NMU の二つがあります。 7.1. 用語 --------- この節の全体にわたって二つの新たな用語、``binary NMU'' と ``source NMU'' を用います。 これらの用語は、この文書の中では技術上の特別な意味を示すものとして用います。 binary NMU と source NMU は、あるパッケージが公式な開発者以外の開発者 によってアップロードされる点では同じです。 _ノンメンテナ_アップロードと呼ばれるのはこのためです。 source NMU とは、あるパッケージがそのバグ修正のために、 公式開発者以外の開発者によってアップロードされることを指します。 source NMU は、(`debian/changelog' の改変のみかもしれませんが、) 常にソースの改変を伴います。 この改変はアップストリームソースと、 Debian で加えられたソースのどちらに対して行なうことができます。 binary NMU は、新たなアーキテクチャ向けにバイナリパッケージを 再コンパイルしアップロードすることを指します。 そのため、こちらは移植に関する正規の作業一環にあるものです。 つまり binary NMU とは、ソース改変を必要としない、 (普通は他アーキテクチャ用) パッケージのバイナリバージョンが ノンメンテナアップロードされたものです。 ただ、ターゲットとするアーキテクチャでコンパイルを通すために、 移植作業者がソース上の問題を修正することはよくあることです。 そのため、こちらは binary NMU というよりもむしろ source NMU とみなされるものです。 このように、私たちは、移植作業者による NMU と非移植作業者による NMU を用語の上では区別していません。 source および binary の両 NMU は、``NMU'' という用語で一括りされえます。 しかしながら、``NMU'' という用語が使われる際に多くの人々は ``source NMU''を想定するために、このことはしばしば混乱をもたらしがちです。 そのためこの区別については注意を払っておくべきでしょう。 この章で私が不特定に ``NMU'' という用語を使う場合、 それは source および binary の両 NMU を指すものとします。 7.2. NMU を行なうことができるのは誰か ------------------------------------- Debian 開発者として正式に登録された者のみが binary NMU あるいは source NMU を行なうことができます。 公式な開発者とは、Debian キーリングに自分の鍵が登録されている者のことです。 もちろん、非開発者の場合もソースパッケージをダウンロードして、 問題を修正するためにそのハックを始めることは奨励されています。 ただその際には、NMU を行なう代わりに バグ追跡システムへ適切なパッチを登録するべきです。 開発者は質の高いパッチやバグ報告に対して普通いつでも感謝しています。 7.3. source NMU を行なう場合には -------------------------------- source NMU を行なう場合のガイドラインは、 ターゲットとするディストリビューション (つまり stable や、unstable あるいは frozen) によって異なります。 なお、移植作業者が従うルールは、その特別な状況 (Section 8.2.1, `移植作業者が source NMU を行なう場合には' をご覧ください) のために、非移植作業者の場合とは若干異なります。 stable 版に対して行なえるものは、critical なバグの修正や、 セキュリティ上のバグに関する修正のみです。 セキュリティ上のバグが発覚した場合、 修正版パッケージは可能な限り早くアップロードされるべきです。 この場合、Debian セキュリティマネージャは、 修正版パッケージを適切な期限内 (48 時間以内) に確実にアップロードできるよう該当パッケージの開発者と連絡をとるべきです。 パッケージ開発者が修正版パッケージを十分に早くは提供できない場合や、 その開発者にすぐに連絡の取れない場合には、 セキュリティマネージャが修正版パッケージ (つまり source NMU ) をアップロードすることができます。 リリースのフリーズ期間 (Section 6.2.2.1, `_frozen_ へのアップロード' をご覧ください) には、 important バグや重要度の高いバグの修正は奨励されており認められます。 しかし、この期間においても、 そのパッケージの現行開発者と連絡をとるよう努めなければなりません。 現行開発者がその問題の修正をちょうどアップロードしようとしているところ なのかもしれないからです。 また、いかなる source NMU を行なう場合でも、Section 7.4, `source NMU を行なうには' にて掲げられているガイドラインには従う必要があります。 非開発者による unstable 版へのバグ修正も、 最終手段として行なわれる場合や許可がある場合のみ 認められています。 以下の各ステップを踏んでみて、 その結果それが上手くいかない場合には、 おそらく NMU を行なうに問題はないでしょう。 * そのパッケージのバグが Debian バグ追跡システム (BTS) に登録されているかどうかを確認します。 もし登録されていない場合は、バグ登録を行なってください。 * その開発者に電子メールを送り、 そのパッケージのバグ修正を援助する旨申し出ます。 返信をもらうまでに二三日は待ってください。 * 作業を開始しバグを修正します。 BTS に登録された適切なバグに対してパッチを登録してください。 そのパッケージを Section 6.2.3, `アップロードの前にパッケージをチェックする' の説明にしたがって構築およびテストします。 こちらはローカルで行なってください。 * 開発者の対応を二三週間待ちます。 * NMU を行なってよいかどうか尋ねるために、 開発者に電子メールを送ります。 * あなたのパッチが予期しない副作用を持っていないかどうかを 重ねてチェックします。 その際あなたのパッチができるだけ小さなものとなるように、 また元のソースをなるべく改変しないものとなるよう確認してください。 * 開発者の対応をもう一週間待ちます。 * 作業を進め、Section 7.4, `source NMU を行なうには' の説明にしたがい source NMU を行ないます。 7.4. source NMU を行なうには ---------------------------- 以下の記述は、移植作業者が パッケージのバグ修正ならびにパッケージの移植の両方の役割を果たす場合のみ 当てはまります。 移植作業者が Debian ソースアーカイブに変更を加える必要がある場合、 そのアップロードはすなわち source NMU であり、 その際には source NMU に関するルールにしたがわなければなりません。 単に再コンパイルしたバイナリパッケージをアップロードする場合、 適用されるルールは異なってきます。 こちらに関しては Section 8.2, `移植作業者によるアップロードに関するガイドライン' をご覧ください。 まず第一に、ソースに対する NMU パッチは、 元のソースをなるべく改変しないものであることが重要です。 あれこれとソースを整理したりしないでください。 モジュール名やファイル名は変更しないでください。 ディレクトリは移動しないでください。 つまり、一般的には問題のない箇所に変更を加えないでください。 パッチはなるべく小さなものとなるようにしてください。 あなたの審美的な観点から何とかしたいことがあるならば、 Debian 開発者やアップストリーム開発者に連絡を取るか、 バグ報告を行なってください。 ともあれ、審美的な観点からの変更は ノンメンテナアップロードで行なうべきでは_ありません_。 7.4.1. source NMU のバージョン番号づけ -------------------------------------- パッケージに変更を加える際には常に、 それがどんなに些細なものであろうとも、 バージョン番号を変更しなければなりません。 そうしなければ、パッケージングシステムが正しく機能しません。 ノンメンテナアップロード (NMU) を行なう場合、 バージョン番号の 部分 (最後のハイフン以降の部分) に新たなマイナーバージョン番号を追加しなければなりません この拡張マイナー番号は `1' から始められます。 例えば、1.1-3 というバージョンの `foo' というパッケージの場合を考えてみましょう。 Debian アーカイブにおいては、そのソースパッケージの制御ファイルは、 `foo_1.1-3.dsc' になります。 つまり、アップストリームバージョンは `1.1' で、 Debian バージョンは `3' です。 そして、次の NMU では新たなマイナー番号 `.1' を Debian リビジョンに追加することになります。 つまり、新たなソース制御ファイルは `foo_1.1-3.1.dsc' になります。 Debian リビジョンマイナー番号は、パッケージ開発者のバージョン番号の いずれかと衝突しないようにするために必要になるものです。 これがなければパッケージ開発者の作業が混乱してしまいます。 また、こうすることには、 Debian アーカイブ中のあるパッケージが公式な開発者によるもの でないことが見てすぐわかるという利点もあります。 もしバージョン番号に 部分がない場合は、 `0.1' で始まるように追加しなければなりません。 正規の開発者以外の誰かが、新たなアップストリームバージョンベースのリリース をどうしても行なう必要がある場合は、`0.1' という を付けてリリースを行なってください。 正規のパッケージ開発者の場合は、 を `1' から始めてください。 ただこちらを行なう場合、 構築システムに新たなソースパッケージを強制的に選択させるために、 `-sa' スイッチを付けて `dpkg-buildpackage' を起動する必要があるでしょう。 (普通このプログラムは、Debian リビジョン が '0' あるいは '1' かどうかのみを確認します。 -- `0.1' という数字を認識するほどにはまだ賢くないのです。) 注意していただきたいのですが、移植作業者が異なるアーキテクチャ向けに パッケージを単に再コンパイルする場合は、 バージョン番号を付け直す必要はありません。 移植作業者は、何らかの方法でソースパッケージに変更を加えた場合、 つまり、binary NMU ではなく source NMU を行なう場合 (のみ)、 新たなバージョン番号を用いるべきです。 7.4.2. source NMU は新たな changelog エントリを必要とする --------------------------------------------------------- source NMU を行なう非公式開発者は、 NMU によってどのバグが修正されたのか、 また通常は NMU がなぜ必要でどこを修正したのかを説明する changelog エントリを作成しなければなりません。 changelog エントリの log エントリには、 その非公式開発者の電子メールアドレスと NMU バージョン番号が含められます。 慣例によって、source NMU の changelog エントリは次の行で始められます。 * Non-maintainer upload 7.4.3. source NMU とバグ追跡システム ------------------------------------ 公式なパッケージ開発者以外の開発者がパッケージに変更を加える場合、 その変更はなるべく小さなものに留めるべきです。 また、変更箇所を詳しく説明するために必ず、 そのパッチを unified context diff (`diff -u') の形でバグ追跡システムに送るべきです。 単にパッケージを再コンパイルする場合はどうするのでしょうか？ この場合、すでに述べたように移植作業者の場合と非移植作業者の場合では その手順が異なります。 移植作業者ではない開発者が単に再コンパイルが必要なだけの NMU を行なう場合、 (つまり、新たな共有ライブラリが利用できるようになった場合や `debhelper' でバグ修正が行なわれた場合) やはり changelog エントリが必要になり、 それゆえパッチが存在することになります。 一方、移植作業者の場合は、おそらく単に binary NMU を行なうことになります。 (注意: このことは、本来再コンパイルをしなければならない移植作業者が それを行なわないことに関しては考慮していません。 -- こちらは、私たちのアーカイブ管理に関する問題点の一つでしょう。) source NMU (ノンメンテナアップロード) によって バグ追跡システムに登録されている既存のバグを修正した場合、 非公式開発者はそのバグを_クローズ_するのではなく、 その旨を_通知_しなければなりません。 規則の上では、バグをクローズすることができるのは、 公式パッケージ開発者か元のバグ報告者のみです。 しかしながら、ノンメンテナリリースを行なった者は、適切なバグに対して、 そのバグが NMU によって修正されたことを説明する 手短なメッセージを送付しなければなりません。 また、 を利用する場合、 NMU を行なった当事者は NMU で修正したバグの重要度を `fixed' に設定しなければなりません。 こうすることによって、そのバグが NMU によって修正されたことを、 確実に皆に知らせることができるわけです。 ただ、NMU で加えられた変更が、公式なパッケージ開発者によって正式に採用され るまで、そのバグは開かれたままです。 また、その問題を修正するために必要となるパッチを添えてバグをオープンするか、 (すでにオープンされている) 他のバグ報告のいずれかにそのパッチを追加してください。 正規の開発者は、そのパッチを採用するか、 あるいはその問題を修正する他の方途を用いることになります。 時にはバグがアップストリームで独自に修正されることもあります。 このことは NMU によるパッチが退けられる十分な理由のひとつです。 新たなバージョンをリリースする際に、 正規の開発者が NMU によるパッチを採用しない場合、 その開発者はノンメンテナリリースで修正された問題のそれぞれが 新たなアップストリームバージョンで確実に修正されていること を保証しなければなりません。 さらに正規の開発者は、changelog ファイルのエントリに ノンメンテナアップロードに関する記述を _常に_残すようにしておかなければなりません。 7.4.4. source NMU の構築 ------------------------ source NMU パッケージは、通常どおりに構築されます。 ディストリビューションの選択には、 Section 6.2.2, `ディストリビューションの選択' で説明したものと同じルールが適用されます。 また Section 6.2, `パッケージをアップロードする' で説明したとおり、 通常の changes ファイルなどが構築されます。 実際、章 6, `パッケージのアップロード' で説明したルールは、 適切なメーリングリストへの NMU のアナウンスの必要性も含めて すべて適用されます。 `debian/control' ファイルにある開発者の名前は、 変更し_ない_ように気をつけてください。 なお、`debian/changelog' ファイルの NMU エントリにある あなたの名前は、changes ファイルに署名する際に用いられます。 ------------------------------------------------------------------------------- 8. 移植作業と移植版 ------------------- Debian がサポートするアーキテクチャは今なお増加しています。 移植作業者でない場合や、特定のアーキテクチャ以外を利用しない場合でも、 開発者としてポータビリティの問題を意識しておくことは必要でしょう。 そのため、移植作業者でない方も、こちらの章はあらかた読んでおくべきです。 移植作業とは、パッケージ開発者のバイナリパッケージが構築された 元のアーキテクチャとは異なるアーキテクチャ向けに Debian パッケージを構築することを指します。 こちらは独自の必要な活動です。 事実、大半の Debian パッケージを実際にコンパイルしているのは移植作業者です。 例えば、_i386_ 用にコンパイルされたバイナリパッケージを 各アーキテクチャ用に再コンパイルする必要がありますし、 そのためにはおよそ五回以上構築を行なわなければなりません。 8.1. 移植作業者への配慮 ----------------------- 移植作業者は、膨大な数のパッケージを処理しなければならないために、 困難な独自の作業を行ないます。 理想としては、全ソースパッケージがさまざまなアーキテクチャで 適切に構築されるべきなのですが、残念ながらそううまくは行きません。 この節では、Debian 開発者らによってしばしば指摘される「既知」の確認項目 -- 移植作業者を困らせたり、 その作業を不必要に困難にさせる共通の問題を取り上げます。 まず第一に上げられる最も重要なモットーは、 移植作業者によって指摘されたバグや問題には素早く対応するということです。 移植作業者に対しては、 あなたのパッケージの実際の協同開発者に対するのと同じように、 丁重に対応してください。(ある意味では彼らは協同開発者です。) 実際、移植作業者が出くわす問題の大半は、 ソースパッケージにおける_パッケージング上のバグ_なのです。 以下が確認し注意すべき事柄の確認項目です。 1. ``all'' や ``any'' 以外の値をアーキテクチャとして設定することは、 そのことを本当に意図していない限り、行なわないでください。 大変多くのケースで、開発者が Debian パッケージングマニュアル (http://www.debian.org/doc/packaging-manuals/packaging.html/) の説明にしたがっていません。 アーキテクチャを ``i386'' に設定することは、たいていのところ間違いです。 2. 作成したソースパッケージが正しいものであることを確認してください。 `dpkg-source -x .dsc' を実行して、 あなたのソースパッケージが適切に展開できることを確認してください。 それから、そこで `dpkg-buildpackage' を用い、 一からあなたのパッケージを構築してみてください。 3. `debian/files' ファイルや `debian/substvars' ファイルを残したまま、ソースパッケージをアップロードしないでください。 これらのファイルは、`debian/rules' の `clean' ターゲットによって消去されていなければなりません。 4. ローカルにインストールされたり手を加えられた 設定やプログラムに依存していないことを確かめてください。 例えば、`/usr/local/bin' やそれに類するディレクトリにあるプログラムを呼び出してはいけません。 プログラムが特殊な方法でセットアップされることを 当てにしないでください。 また、あなたのパッケージを、 同一アーキテクチャでもかまいませんので、他のマシンで構築してみてください。 5. (上記のことにも含まれることですが、) あなたで構築されたパッケージをすでにインストールされているものと 仮定してはいけません。 6. `egcc' が利用できるものと仮定してはいけません。 また、特定のバージョンの `gcc' に依存してはいけません。 7. Debian パッケージングマニュアルで要求されている通りに、 ``binary-arch'' ターゲットと ``binary-indep'' ターゲットは debian/rules に別々に収録しなければなりません。 この両ターゲットがそれぞれ独立して動作すること、 つまり、あるターゲットを呼び出す際に 他のターゲットを前もって呼び出していないことを確認してください。 こちらをテストするには、`dpkg-buildpackage -b' を実行してみてください。 8.2. 移植作業者によるアップロードに関するガイドライン ----------------------------------------------------- 移植先のアーキテクチャ用のバイナリを取り出したときのままで構築できるなら、 作業もはかどるでしょう。 この節で扱うのはこのような場合で、言葉を変えれば、 適切にアーカイブにインストールできるように、 バイナリを構築し binary NMU をアップロードする方法を説明します。 他のアーキテクチャ向けにコンパイルを通すために、 パッケージにパッチを当てなくてはならない場合は、 source NMU を行なわなければなりません。 こちらに関しては Section 7.4, `source NMU を行なうには' をご参照ください。 binary NMU を行なう場合、そのソースに対しては一切変更を行ないません。 ソースパッケージ中のいかなるファイルに対しても手をつける必要はありません。 `debian/changelog' も然りです。 場合によっては、ライブラリなどの更新済みの他パッケージに対して、 あるパッケージを再コンパイルする必要があるでしょう。 この場合は、アップグレードシステムが適切に動作するように、 バージョン番号を上げなければなりません。 しかしながら、たとえそうでも、これらは binary のみの NMU とみなされます。 -- この場合、全アーキテクチャで再コンパイルする必要はないからです。 NMU の場合と同様にバージョン番号を設定しなければなりませんが、 この場合は NMU バージョンの前に ``.0.'' を付け加えます。 例えば、``foo_1.3-1'' というソースパッケージを単に再コンパイルして NMU する場合、その番号は ``foo_1.3-1.0.1'' になります。 `dpkg-buildpackage' を起動するには、 `dpkg-buildpackage -B -m' としてください。 もちろん の箇所には あなたの電子メールアドレスを当てはめてください。 こうすれば、`debian/rules' の `binary-arch' ターゲットを用いて、該当パッケージの特定アーキテクチャ依存部分に限った バイナリ構築のみが行なわれます。 8.2.1. 移植作業者が source NMU を行なう場合には ----------------------------------------------- 移植作業者が source NMU を行なう場合、 非移植作業者の場合と同様に、一般的には 章 7, `ノンメンテナアップロード (NMU)' にて触れたガイドラインに従います。 しかしながら、移植作業者の場合、 相当な量のパッケージを処理しなければならないことから、 source NMU をする際に他の開発者の対応を待つ時間は、 非移植作業者の場合よりも短いことが望まれています。 さらに、その状況は アップロード先のディストリビューションによっても異なってきます。 `frozen' ディストリビューションへの重要な修正 (すなわち、リリースが予定されているアーキテクチャで ソースパッケージのコンパイルを通すために必要となる修正) は、 待ち時間を_置かず_にアップロードすることができます。 移植作業者が `unstable' ディストリビューションへの NMU を行なう場合も、 上記の移植作業に関するガイドラインに従わなければなりませんが、 二点ほど異なる点もあります。 まず一点目は、十分とされる待ち時間 -- BTS にバグが報告されてから、NMU が認められるまでの時間 -- が、`unstable' ディストリビューションに関する作業を行なう移植作業者の場合、7 日間であるということです。 なお、この期間も、 致命的な問題や移植作業の負担となる問題がある場合は、 移植作業グループの裁量で短くされることもありえます。 (これはポリシーではなく、 あくまでもガイドラインに沿って相互に了承されているものです。 ご注意ください。) 二点目は、source NMU を行なう移植作業者が BTS に報告する際、 そのバグの重要度を `important' 以上にしなければならないということです。 こうすることによって、リリース時に Debian でサポートされる全アーキテクチャ用のバイナリが、 確実に単一のソースパッケージから構築されることが保証されます。 さまざまなライセンスに準拠するためにも、 全アーキテクチャにわたるバイナリおよびソースパッケージを 単一のバージョンで管理することは、極めて重要です。 移植作業者は、現行バージョンのコンパイル環境や、カーネル、libc においてのみバグが回避できるようなパッチを、 避けるように努めなければなりません。 ただ、このような応急処置が必要になる場合もあるでしょう。 コンパイラのバグやその類いを回避しなければならない場合、 そのために追加したコードには適切に `#ifdef' を用いてください。 また、その外的な問題が修正された際に誰もがその箇所を除去できるように、 あなたが行なった応急処置を文書に残しておいてください。 他の開発者の対応を待つ間に、移植作業者は 自身の作業結果を公開するために非公式な場所を構えることもあります。 このことは、他の開発者の対応を待つ間においても、 その移植作業の利益を、同じ作業に携わる他の開発者が 受け取れる利点があります。 もちろん、このような場所は公式に推奨されるものでも 公式な地位を与えられたものでもありませんので、 こちらを利用される場合はご注意ください。 8.3. 移植作業者用のツール群 --------------------------- 移植作業に有用なツールがいくつか用意されています。 この節ではこれらツール群の簡単な紹介を行ないます。 なお、これらに関する完全な情報については、 各パッケージの文書やリファレンスをご覧ください。 8.3.1. `quinn-diff' ------------------- `quinn-diff' は、 異なるアーキテクチャ間の差異を locate するために用いられます。 例えば、アーキテクチャ からアーキテクチャ へ、 どのパッケージを移植する必要があるのかを教えてくれます。 8.3.2. `buildd' --------------- `buildd' システムは、分散配置される クライアント/サーバ式の構築およびディストリビューションシステム として用いられます。 こちらは通常 _auto-builders_ と共に利用されます。 この _auto-builders_ は、単に移植の必要なパッケージのチェックアウトと 自動構築を行なう「スレーブ」ホストです。 このシステムには、 移植作業者がソースパッケージを「チェックアウト」して作業を行なうための 電子メールインターフェイスもあります。 `buildd' はまだパッケージとしては利用できませんが、 移植作業の多くにおいて現に利用されており、 また近い将来利用されることが計画されています。 こちらには、現に極めて有用で頻繁に利用されている `andrea' や、`sbuild'、 `wanna-build' といったパッケージ化されていない数々のコンポーネントが含まれています。 `buildd' によって生成された 移植作業者にとって一般的に有益なデータのいくつかは、 ウェブ上の http://buildd.debian.org/ で利用できます。 こちらのデータには、毎晩 `andrea' (ソースの依存関係) と `quinn-diff' (再コンパイルの必要なパッケージ) から更新される情報も収録されています。 さまざまな用途に役立つ可能性を秘めているこのシステムに、 私たちは大きな期待を寄せています。 一般的的な関心を呼ぶかどうかは別ですが、独立した各開発グループが、 Debian の異なるサブ flavor 用のシステム (例えば、gcc バウンズチェック付きで構築された Debian のある flavor など) を利用することもできます。 また、こちらは Debian がディストリビューション全体を素早く再コンパイル することも可能にするのです。 8.3.3. `dpkg-cross' ------------------- `dpkg-cross' は、 `dpkg' に似た方法で、 クロスコンパイル用のライブラリやヘッダをインストールするツールです。 さらに、クロスコンパイルをサポートするために `dpkg-buildpackage' や `dpkg-shlibdeps' の機能性も高められています。 ------------------------------------------------------------------------------- 9. パッケージの移動、削除、改名、引き継ぎ、みなしご化 ----------------------------------------------------- Debian のアップロード手続きにおいて、 アーカイブ操作の作業のすべてが自動化されているわけではありません。 自動化されていない作業に関しては、開発者が手動で行なわなければなりません。 この章ではそのような作業の際に従うべきガイドラインを扱います。 9.1. パッケージの移動 --------------------- パッケージはそのセクションが変更されることもあります。 例えば `non-free' セクションのパッケージが後のバージョンで GPL 準拠となった場合、そのパッケージは `main' あるいは `contrib' に移動されなければなりません [1]。 あなたのパッケージのセクションを変更しなければならない場合、 変更先のセクションにパッケージを設置するために、 パッケージの制御情報を変更し、 そのパッケージを再アップロードしてください。 パッケージがアーカイブにインストールされる際に送られてくる インストレーションログを十分に確認してください。 もし何らかの理由でパッケージが変更前の場所にも残っていた場合は、 `ftp.debian.org' に対してバグ報告を行ない、 変更前の場所にあるパッケージを削除するよう依頼してください。 もしかすると `dinstall' のバグかもしれないので、 その際にはあなたで行なったことの詳細を添えてください。 一方、パッケージの _subsection_ (例えば ``devel'' や ``admin'' など) を変更する必要がある場合、その手続きは若干異なります。 この場合は、そのパッケージの制御ファイルにある subsection を修正し、 再アップロードしてください。 また、Section 6.4.1, `オーバライドファイル' で説明したように、 オーバライドファイルを更新する必要もあります。 [1] あるパッケージをどのセクションに収めるべきかに関す るガイドラインについては Debian ポリシーマニュアル (http://www.debian.org/doc/debian-policy/) をご覧ください。 9.2. パッケージの削除 --------------------- あるパッケージ (例えば、もはや不要になった古い互換ライブラリなどを) を何らかの理由のために完全に削除したい場合は、`ftp.debian.org' に対してバグ報告を行ない、 そのパッケージを削除するよう依頼しなければなりません。 その際、そのパッケージをどのディストリビューションから 削除するのかを必ず明記してください。 なお、そのパッケージが不要なものかどうかはっきりしない場合は、 に電子メールを送り意見を求めてください。 また、こちらに関しては `apt' パッケージの `apt-cache' プログラムを利用して確認してみてもよいでしょう。 `apt-cache showpkg ' とすれば、reverse depends 情報を含む 詳細が表示されます。 9.2.1. `Incoming' からのパッケージ削除 -------------------------------------- あるパッケージを `Incoming' から削除したい場合は、 義務ではありませんが、適切なアナウンス用メーリングリスト ( か ) にその旨を通知しておくとよいでしょう。 9.3. パッケージの置き換えや改名 ------------------------------- パッケージの名前を間違えて付けてしまい、 それを改名しなければならないことがあるかもしれません。 この場合、次の二つの手順を踏む必要があります。 まず初めに、そのパッケージの古い名前に対して replace および conflict となるよう `debian/control' ファイルに設定を行ないます。 をご覧ください。) そして、このパッケージをアップロードし、それをアーカイブに移動したら、 `ftp.debian.org' に対するバグ報告を行ない、 古い名前のパッケージを削除するよう依頼してください。 9.4. パッケージのみなしご化 --------------------------- あるパッケージのメンテナンスができなくなった場合は、そのパッケージ開発者を `Debian QA Group ' に設定し直し、 宛てにそのパッケージをみなしご化する旨を 電子メールで通知しなければなりません。 ただ、そのパッケージが Debian にとって極めて重要なものである場合は、 代わりに 宛てに電子メールを送り、 新開発者を募集すべきでしょう。 9.5. パッケージの引き継ぎ ------------------------- 新開発者が必要なパッケージの一覧が、定期的に メーリングリストに流されます。 この一覧は http://www.debian.org/devel/wnpp/ にある Work-Needing and Prospective Packages document (WNPP) からも入手できます。 WNPP の一覧にあるパッケージのメンテナンスを引き継ぎたい場合や、 あなたのパッケージのメンテナンスを放棄する場合、 新規パッケージの作業を誰が行なっているかどうか単に確認した場合は、 に電子メールを送ってください。 このことをおろそかにして、あるパッケージを単に引き継ぐだけではいけません。 -- これではパッケージハイジャックです。 もちろん、現行の開発者に連絡を取り、 そのパッケージの引き継ぎを依頼することは可能です。 しかしながら、その際に同意を得られなければ、 そのパッケージを引き継ぐことはできません。 たとえあなたの申し出が無視されたとしても、 それはパッケージ引き継ぎの理由とはなりません。 現行開発者が音沙汰もなくその作業を放棄していると確信できる場合は、 その旨を にて尋ねてみてください。 なお、古いパッケージを引き継いだ場合は、 あなたをそのパッケージの公式開発者として バグ追跡システムに登録なさりたいでしょう。 `Maintainer:' フィールドを更新した新バージョンをアップロードすれば、 二週間ほど時間がかかりますが、その処理は自動的に行なわれます。 ただ、しばらくの間、新バージョンをアップロードできない場合は、 バグ報告があなたの元へ正しく送付されるようにするために、 に電子メールを送ってください。 ------------------------------------------------------------------------------- 10. バグの扱い -------------- 10.1. バグを監視する -------------------- 優れた開発者であるためには、定期的に Debian バグ追跡システム (BTS) (http://www.debian.org/Bugs/) で自分のパッケージに関するものをチェックすると良いでしょう。 BTS には、あなたのパッケージに対してオープンされた 全バグ報告が登録されています。 開発者は、`bugs.debian.org' 宛てに 電子メールを出すことによって BTS を利用することもできます。 その際に利用できるコマンドに関するドキュメントは http://www.debian.org/Bugs/ にあります。 また `debian-doc' パッケージがインストール済みならば、 ローカルにある `/usr/share/doc/debian/bug-*' ファイルをご覧になることもできます。 また、オープンされたバグ報告を定期的に取り込むことも有益です。 また、あなたのパッケージに対してオープンされたバグ報告の概略を 毎週電子メールで受け取りたいならば、 cron ジョブに以下の行を追加してもよいでしょう。 # 毎週自分のパッケージに対するバグ報告を調べる 0 17 * * fri echo "index maint
" | mail request@bugs.debian.org の箇所には、あなたの Debian 公式開発者としての電子メールアドレスを当てはめてください。 10.2. バグを報告する -------------------- パッケージ開発者として、他のパッケージのバグを発見することや、 あなたのパッケージに対して報告されてはいるが、その対象パッケージを変更 (reassign) すべきバグ報告を受けることもあるでしょう。 これらのバグは登録しておく必要があります。 こちらをどのように行なうかについての説明は、 バグコントロールメールサーバ入門 (http://www.debian.org/Bugs/server-control.html) にあります。 問題があった場合、そのバグを登録することが奨励されています。 電子メールを受け取るときに用いている通常のユーザアカウントから、 バグを報告してください。 root アカウントからバグを報告してはいけません。 当該パッケージに関する問題のバグが、 まだ報告されていないことを確認してください。 その上で、そのバグを適切なところへ報告してください。 特別に許可を得ている場合、他のパッケージに対しても、 何度も報告を受けているバグをマージし、その修正が完了した際、 そのバグの重要度を `fixed' に設定することもできます。 なお、バグ報告者かそのパッケージの開発者でなければ、 (開発者から権限を付与されていない限り、) そのバグを実際にクローズすることはできません。 10.3. バグ報告に返信する ------------------------ バグ報告に対する返信は、必ずそのバグの元の報告者と、 バグ報告そのもの (例えば <123@bugs.debian.org>) の両者に送付されなければなりません。 バグサーバ経由で に `close' コマンドを送って バグをクローズすることは_決して_しないでください。 そうしてしまうと、元の報告者は、そのバグがクローズされた理由に関して 何のフィードバックも得ることができません。 10.4. 新規アップロードによってバグをクローズする場合には -------------------------------------------------------- あなたのパッケージのバグを修正する場合、 その修正が完了した際にバグをクローズすることは、 パッケージ開発者としての責任です。 しかしながら、修正されたパッケージが Debian アーカイブに収められるまでは、 そのバグをクローズしてはいけません。 そのため、アップロードしたパッケージがアーカイブにインストールされたとの 通知を受けてから、BTS に登録されているバグをクローズしてください。 `dpkg-dev' の新しいバージョンを利用し、 changelog エントリを適切に設定していれば、 `dinstall' は自動的にそのバグをクローズします。 そのためには、以下のように `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 manpage. closes: #98725. 技術的な観点からいえば、以下の Perl 正規表現が用いられます。 /closes:\s*(bug)?\#\d+(,\s*(bug)?\#\d+)*/gi このパッケージの開発者は、他の changelog エントリと区別しやすいことから、 `(closes: Bug#)' という文法を好んで使っているようです。 バグのクローズを手動という古い流儀で行ないたい場合は、 `.changes' ファイルを 宛てに送れば結構です。 その際こちらの の箇所にはバグ番号を当てはめてください。 10.5. Lintian による報告 ------------------------ パッケージ開発者は、定期的に最新の `lintian' を `unstable' ディストリビューションから入手し、 自らのパッケージすべてをチェックすべきです。 あるいは、オンライン lintian 報告 (http://lintian.debian.org/)上で、 自分が開発者として登録している電子メールアドレスの箇所を チェックしてもよいでしょう。 こちらの報告は自動的に更新されますが、 最新の `lintian' を利用して、 ディストリビューションの最新バージョン (通常は 'unstable') に対する `lintian' 報告を収録しています。 10.6. 一度にたくさんのバグ報告を行なう -------------------------------------- たくさんの異なるパッケージ上にある同一の問題に対して、 たくさんのバグ報告を -- つまり 10 以上も -- 行なうことは、勘弁願いたい作業です。 ただ、ともあれ一度にたくさんのバグ報告をしなくて済むように、 できうることは行なってください。 例えば、その問題のチェックが自動化できるものならば、 エラーや警告を発行するように `lintian' に新たなチェックを付け加えてください。 同じ問題に関する 10 個以上のバグを一度に報告する場合は、 そのバグを報告する前に、その意図するところを添えて 宛てにメッセージを送ることが推奨されています。 このことによって、他の開発者はそのバグが本当に問題のあるものなのかどうかを 確かめることができます。 さらに、このことは、 複数の開発者が同じバグを同時に報告するという事態も防ぎます。 なお、たくさんのバグを同一のサブジェクトで報告する際には、 バグ報告が配送されるメーリングリストに転送されないよう、 そのバグ報告は へ送ってください。 ------------------------------------------------------------------------------- 11. Debian 開発者用ツールの概観 ------------------------------- この章では、開発者が利用できるツール群を大まかに説明します。 これらのツール群は、開発者の便宜を図り、 これらを使うことによって空いた時間をより重要な 作業にまわせるよう用意されています。 高レベルのパッケージ開発ツールの利用を好む人もいれば、好まない人もいます。 Debian では、この問題に関して公式な取り決めはありません。 つまり、どのツールを用いても作業を行なうことができるならば問題ありません。 そのため、この章は、どのツールを使うべきなのか、 開発に伴う作業にどのように取り組むべきなのか、 について規定するものではありません。 また、競合するツールの排除を避けるために、 特定のツールを推奨することもしません。 これらパッケージの説明文の大半は、 実際のパッケージ説明文そのものを参考にしたものです。 より詳細な情報は各パッケージのドキュメントをご覧ください。 11.1. `dpkg-dev' ---------------- `dpkg-dev' には、Debian ソースパッケージの展開、 構築、アップロードに必要となる (`dpkg-source' を含む) ツール群が収録されています。 これらのユーティリティ群は、パッケージの作成および操作に必要となる 基本的で低レベルな機能を提供します。 そのため、こちらはいずれの Debian 開発者にも必要となるものです。 11.2. `lintian' --------------- `lintian' は Debian パッケージを精査し、 バグやポリシー違反を報告します。 `lintian' は、一般的なエラーのチェックとともに、 Debian ポリシーの多角的な自動チェックも行ないます。 `lintian' の使い方については、 Section 6.2.3, `アップロードの前にパッケージをチェックする' および Section 10.5, `Lintian による報告' ですでに説明してあります。 11.3. `debhelper' ----------------- `debhelper'は、 バイナリ Debian パッケージの構築に関連する 一般的な作業を自動化するために、 `debian/rules' で利用できるプログラム集です。 このプログラム集には、作成するパッケージへのさまざまなファイルのインストールや、 ファイルの圧縮、ファイルパーミッションの修正、作成するパッケージの Debian menu システムへの統合を行なうプログラム群が含まれています。 `debmake' とは異なり、`debhelper' は、 一貫した流儀で動作しながらも、小さく、 独立している多数のコマンド群から構成されています。 そのため、`debhelper' は `debmake' より細かな管理を行なうことができます。 11.4. `debmake' --------------- `debmake' は、`debhelper' に先行して開発されたもので、より大まかなコマンドで `debian/rules' の補助を行なうものです `debmake' には主に二つのプログラムが含まれています。 一つは `deb-make' で、 こちらは、開発者が通常の (Debian 的ではない) ソースアーカイブを Debian ソースパッケージへ変換する補助をします。 もう一つは `debstd' で、 こちらは `debhelper' においては複数のコマンドによって 実現されている自動化された機能を一つにまとめたものです。 今では `debhelper' の利用が好まれ、 `debmake' の利用は避けようとの合意があります。 しかし、これは `debmake' のバグが問題であるから、というわけではありません。 11.5. `yada' ------------ `yada' は若干異なる思想を持つ、 新たなパッケージング補助ツールです。 `debian/packages' ファイルを用いて、 `debian/' サブディレクトリ以下に設置される 他の必要なファイルを自動生成します。 なお `yada' はまだまだ新しいものですので、 他のシステムに比べれば問題が残っている可能性があります。 11.6. `equivs' -------------- `equivs' は、パッケージ作成用に 用意されているパッケージです。 `equivs' は、 単に依存関係を満たすためにパッケージを作成しなければならない場合などの、 ローカルな利用にしばしば推奨されているものです。 また、他パッケージに依存することのみを目的としたパッケージ ``meta-packages'' を作成する場合などにも利用されます。 11.7. `cvs-buildpackage' ------------------------ `cvs-buildpackage' は、 Debian ソースパッケージの CVS リポジトリへの導入やインポート、 CVS リポジトリからの Debian パッケージの構築、 アップストリームにおける変更のリポジトリへの統合の補助 といった機能を提供します。 これらのユーティリティは、Debian 開発者による CVS の利用を容易にするインフラを提供します。 `cvs-buildpackage' を利用すれば、 _stable_ や、_unstable_、場合によっては _experimental_ といったディストリビューション向けに、 あるパッケージを独立した複数の CVS ブランチにて管理したり、 そのほかのバージョンコントロールシステムの恩恵を受けることができます 11.8. `dupload' --------------- `dupload' は、 Debian パッケージを Debian アーカイブに自動アップロードしたり、 アップロードのログをとったり、 アップロードに関する電子メールを送信したりする、 スクリプトおよびパッケージです。 `dupload' では、新規アップロードを行なう先の場所や、 その方法を設定することも可能です。 11.9. `fakeroot' ---------------- `fakeroot' は root 権限をシミュレートします。 `fakeroot' を利用すれば、root にならずにパッケージを構築できます。 (各パッケージでは、通常 root の所有権でファイルがインストールされている必要があります。) `fakeroot' がインストールされていれば、 一般ユーザで、例えば `dpkg-buildpackage -rfakeroot' とすることができます。 11.10. `devscripts' ------------------- `devscripts' は、Debian パッケージ開発に役立つ ラッパーやツールを収録したパッケージです。 例えば、`debian/changelog' ファイルをコマンドラインから操作するための `debchange' や、`dpkg-buildpackage' のラッパーである `debuild' といったスクリプトが含まれています。 11.11. `debget' --------------- `debget' は、Debian アーカイブからファイルをダウンロードする際に役立つ 便利なスクリプトを収録したパッケージです。 例えば、ソースパッケージのダウンロードにこちらを利用することができます。 ------------------------------------------------------------------------------- Debian デベロッパーズリファレンス Adam Di Carlo, current maintainer Christian Schwarz Ian Jackson ver. 2.11, 2002年04月08日