Debian 新メンテナーガイド --------------------------------------------------------------------- Josip Rodin 初期の内容  Osamu Aoki 更新された内容  倉澤望 日本語訳  八津尾雄介 日本語訳  佐々木洋平 日本語訳  倉敷悟 日本語訳  青木修 日本語訳  バージョン 1.2.53 --------------------------------------------------------------------- 製作著作 © 1998-2002 Josip Rodin 製作著作 © 2005-2015 Osamu Aoki 製作著作 © 2010 Craig Small 製作著作 © 2010 Raphaël Hertzog     この文書は GNU 一般公有使用許諾書、バージョン 2 もしくはそれ以降 により規定される条件の下で使用できます。     この文書は以下の二つの文書を参考にして書かれました: * Debian パッケージの作り方 (別名 Debmake マニュアル)、 Copyright © 1997 Jaldhar Vyas. * 新メンテナー向け Debian パッケージング法、copyright © 1997     Will Lowe. The rewrite of this tutorial document with updated contents and more practical examples is available as "Guide for Debian Maintainers". Please use this new tutorial as the primary tutorial document. 2022-10-08 03:52:48 UTC --------------------------------------------------------------------- 目次 1. まずは正攻法で始めよう 1.1. Debianにおける社会ダイナミクス 1.2. 開発に必要なプログラム 1.3. 開発に必要な文書 1.4. 相談するには 2. はじめの一歩 2.1. Debian パッケージビルドのワークフロー 2.2. プログラムの選定 2.3. プログラムの入手と検証 2.4. 単純なビルドシステム 2.5. ポピュラーなポータブルなビルドシステム 2.6. パッケージ名とバージョン 2.7. dh_make のセットアップ 2.8. 最初のノンネイティブ Debian パッケージ 3. ソースコードの変更 3.1. quilt のセットアップ 3.2. アップストリームのバグを修正する 3.3. 指定場所へのファイルのインストール 3.4. ライブラリーの相違 4. debian/ ディレクトリー以下に無くてはならないファイル 4.1. control 4.2. copyright 4.3. changelog 4.4. rules 4.4.1. rules ファイルのターゲット 4.4.2. デフォルトのrulesファイル 4.4.3. rules ファイルのカスタマイズ 5. debianディレクトリーにあるその他のファイル 5.1. README.Debian 5.2. compat 5.3. conffiles 5.4. package.cron.* 5.5. dirs 5.6. package.doc-base 5.7. docs 5.8. emacsen-* 5.9. package.examples 5.10. package.init と package.default 5.11. install 5.12. package.info 5.13. package.links 5.14. {package.,source/}lintian-overrides 5.15. manpage.* 5.15.1. manpage.1.ex 5.15.2. manpage.sgml.ex 5.15.3. manpage.xml.ex 5.16. package.manpages 5.17. NEWS 5.18. {pre,post}{inst,rm} 5.19. package.symbols 5.20. TODO 5.21. watch 5.22. source/format 5.23. source/local-options 5.24. source/options 5.25. patches/* 6. パッケージのビルド 6.1. 完全な（再）ビルド 6.2. オートビルダー 6.3. debuildコマンド 6.4. pbuilderパッケージ 6.5. git-buildpackageコマンドとその仲間 6.6. 部分的な再ビルド 6.7. コマンド階層 7. パッケージのエラーの検証 7.1. 怪しげな変更 7.2. インストールに対するパッケージの検証 7.3. パッケージのメンテナースクリプトの検証 7.4. Using lintian 7.5. debc コマンド 7.6. debdiff コマンド 7.7. interdiff コマンド 7.8. mc コマンド 8. パッケージの更新 8.1. Debian リビジョンの更新 8.2. 新規のアップストリームリリースの検査 8.3. アップストリームソフトウェアの新版更新 8.4. パッケージ化スタイルの更新 8.5. UTF-8 変換 8.6. パッケージをアップグレードする際の注意点 9. パッケージをアップロードする 9.1. Debian アーカイブへアップロードする 9.2. アップロード用orig.tar.gzの内容 9.3. スキップされたアップロード A. 上級パッケージング A.1. 共有ライブラリー A.2. debian/package.symbols の管理 A.3. マルチアーチ A.4. 共有ライブラリーパッケージのビルド A.5. ネイティブ Debian パッケージ 第1章まずは正攻法で始めよう 最新の内容とより実用的な例でこの入門書を書き換えたものが Guide     for Debian Maintainers として入手できます。この新しい入門書を第一 次的な入門書として使ってください。 この文書では、一般の Debian ユーザーやデベロッパーを目指している 人を対象に Debian パッケージのビルド方法の解説を試みます。技術用     語はできるだけ避けて、実用的な例示を多用しています。古いラテンの 諺にもあるように、Longum iter est per praecepta, breve et efficax per exempla (百聞は一見にしかず) です。 本文書は多くの翻訳があるため Debian Buster リリースでは提供されま     す。本文書はこれに続くリリースでは内容が陳腐化しているため提供さ れなくなります。^[1] Debian を最高峰の Linux ディストリビューションたらしめている理由 のひとつが、そのパッケージ管理システムです。すでに膨大な数のソフ トウェアが Debian 形式で配布されていますが、まだパッケージ化され ていないソフトウェアをインストールしなければならないことがあるで     しょう。どうやったら自分でパッケージが作れるんだろうとか、それは とても難しいことなんじゃないかなどと考えたことがありませんか。確 かに、もしあなたが本当に駆け出しの Linux ユーザーなら難しいでしょ うが、それなら今ごろこんな文書を読んでませんよね :-) Unix のプロ グラミングについて少々知っている必要がありますが、神様みたいに精 通している必要は全くありません。 ^[2] ただ、確かなことがひとつあります。Debian パッケージをきちんと作成     し保守していくには時間がかかるということです。間違えないでくださ い、Debian のシステムが機能するには、メンテナーは技術的に有能であ るだけでなく、勤勉であることも必要なのです。     パッケージ作成において手助けが必要な際には、「相談するには」を読 んでください。 この文書の最新版は常に以下の場所からネットワーク経由で入手できま す。http://www.debian.org/doc/maint-guide/ また、maint-guideパッ     ケージにも含まれています。日本語訳はmaint-guide-jaパッケージに含 まれています。本文書の内容が少々古くなっているかもしれない事に注 意して下さい。 本書は入門書ですので、一部の重要なトピックスは詳細なステップを個     々説明するようにしました。あなたには不要と思われる部分があるかも しれません。我慢して下さい。本文書を簡潔にするように一部のコーナ ーケースを意識的に省略したり参照を提供するだけに止めています。 1.1. Debianにおける社会ダイナミクス     あなたがDebian と関わる際の準備となることを望み、Debianの社会ダイ ナミクスの観察結果を記します: * 我々全員はボランティアです。 + 他人に何をするかを押し付けてはいけません。 + 自分自身で行う意欲を持つべきです。 * 友好的な協力が推進力です。 + あなたの寄与は他人にストレスを掛けすぎてはいけません。 + あなたの寄与は他人に評価されて初めて価値があります。     * Debian は教師の注意が自動的にあなたに注がれるあなたの学校とは 違います。 + 多様な案件の独学能力を持つべきです。 + 他ボランティアに注意を払ってもらうことは貴重なリソースで す。 * Debian は常に改良されています。 + あなたには高品質パッケージを作成することが期待されていま す。 + あなたは変化に自らを適合させる必要があります。     Debian 界隈では異なる役割で色々なタイプの人が交流しています: * upstream author (アップストリームの作者): 元のプログラムを作 った人です。 * upstream maintainer (アップストリームのメンテナー): 現在プロ グラムをメンテナンスしている人です。 * maintainer (メンテナー): プログラムの Debian パッケージを作成 している人です。 * sponsor (スポンサー): メンテナーのパッケージを、(内容をチェッ     クした後で)公式 Debian パッケージアーカイブにアップロードする のを手伝う人です。 * mentor (指導役): 新米メンテナーをパッケージを作成等で手助けす る人です。 * Debian Developer (Debian デベロッパー) (DD): 公式 Debian パッ ケージアーカイブへの全面的アップロード権限を持っているDebian プロジェクトのメンバーです。 * Debian Maintainer (Debian メンテナー) (DM): 公式 Debian パッ ケージアーカイブへの限定的アップロード権限持っている人です。 技術的なスキル以外の要件があるので、一夜にして正式な Debian デベ ロッパー (DD) になることはできません。これでがっかりしないでくだ     さい。あなたのパッケージが他の人にとっても有用ならば、あなたはそ れをメンテナーとしてスポンサーを通して、あるいは Debian メンテナ ーとして、アップロードすることが可能です。 正式な Debian デベロッパーになるのに新しいパッケージの作成は必須 ではないことに注意してください。既存のパッケージに対して貢献して     いくことでも正式な Debian デベロッパーへの道は開かれます。多くの パッケージがよいメンテナーを待っています (「プログラムの選定」を 参照)。 本書ではパッケージングの技術面にのみフォーカスするので、Debian が     如何にして機能し、あなたが如何にすれば関与できるのかは以下を参照 下さい: * Debian: フリーソフトウェアと、"do-ocracy" (実行による支配)と 、democracy (多数決による支配)の17年間 (紹介スライド、英語) * Debian に協力するには? (正規) * The Debian GNU/Linux FAQ, Chapter 13 - "Contributing to the     Debian Project" (準正規) * Debian Wiki, HelpDebian (補足) * Debian New Member サイト (正規) * Debian Mentors FAQ (補足) 1.2. 開発に必要なプログラム 何はさておき、開発に必要なパッケージがきちんとインストールされて いることを確認するべきです。以下のリストには essential または     required なパッケージが含まれていないことに注意してください。これ らのパッケージは既にインストールされていることを前提としています 。 以下のパッケージは Debian の標準 (standard) インストール構成に含     まれており、すでに (それらが依存する他のパッケージとともに) シス テムに含まれているはずです。しかし、念のために aptitude show package もしくは dpkg -s package を用いて確認しておきましょう。 開発用システムにインストールする一番重要なパッケージは、     build-essential です。これをインストールしようとすると、基本的な ビルド環境で必要な他のパッケージを引き込むでしょう。 パッケージの種類によっては、必要になるのはこれが全てかもしれませ     ん。ただ、すべてのパッケージのビルドに必須ではないにせよ、インス トールしておくと便利だったり、パッケージによっては必要になったり するパッケージ群があります: * autoconf と automake と autotools-dev - 多くの新しいプログラ ムが、これらのプログラムを使って前処理される設定スクリプトや Makefile を利用しています。 (詳しくは info autoconf, info automake を参照)。 autotools-dev には、特定の auto ファイルを 最新版に保ち、そのようなファイルを使う最善の方法についてのド キュメントが含まれています。 * debhelper と dh-make - dh-make は例示に用いられたパッケージの ひな型を用意するのに必要となり、またそれはパッケージの生成を するために debhelper ツールをいくつか使います。これらを使わな くてもパッケージ作成は可能ですが、初めてパッケージを作る方に は利用を強くお勧めします。こうすると、取り付きやすく、以後パ ッケージを管理するのもずっと簡単です。 (詳しくは dh_make(8)、 debhelper(1) を参照。) ^[3] 標準的な dh-make の代わりに、新しいdebmake が使えます。機能が 多く種々のパッケージング例が debmake-doc 中の文書に含まれます 。 * devscripts - このパッケージはメンテナーにとって便利であると思 われる有用で優れたスクリプトを含んでいますが、だからといって パッケージをビルドするために必須というわけではありません。こ のパッケージが推奨 (Recommends)、あるいは提案 (Suggests) して いるパッケージは、一見の価値があります。(詳しくは /usr/share/ doc/devscripts/README.gz を参照。) * fakeroot - このユーティリティを使うと、ビルドの過程で何度か必 要となる root 権限をエミュレートすることができます。(詳しくは fakeroot(1) を参照。) * file - この便利なプログラムを使うと、そのファイルがどういう形 式のものか判定することができます。(詳しくは file(1) を参照。) * gfortran - GNU Fortran 95 コンパイラ。あなたのプログラムが Fortran 言語で書かれている場合に必要です。(詳しくは gfortran (1) 参照。) * git - このパッケージは人気のあるバージョン管理システムで、大 規模なプロジェクトを素早く、効率的に扱えるように設計されてい ます。知名度の高い多数のオープンソースプロジェクトで使われて おり、特に有名なものとして Linux カーネルがあります。(詳しく は git(1)、git Manual (/usr/share/doc/git-doc/index.html) 参 照。) * gnupg - このツールを使うと、パッケージに「デジタル署名」を付 けることができます。もしあなたが自分の作成したパッケージを他 の人々に配布したいのなら、これは特に重要です。また、Debian デ     ィストリビューションにあなたの作成したパッケージが含まれるよ うになった時には、確実にこのデジタル署名をすることになります 。(詳しくは gpg(1) 参照。) * gpc - GNU Pascal コンパイラ。あなたのプログラムが Pascal 言語 で書かれている場合に必要です。ここで注目に値するのは fp-compiler Free Pascal コンパイラで、こちらもまたこの作業に 適しています。(詳しくは gpc(1)、 ppc386(1) 参照。) * lintian - これは Debian パッケージチェッカで、あなたがビルド したパッケージを調べて、その中にありがちなミスが見つかったら それを指摘し、その問題について説明してくれます。(詳しくは lintian(1)、 Lintian User's Manual 参照。) * patch - このとても有用なユーティリティは、(diff プログラムに よって生成された) オリジナルとの差分が列挙されたファイルを読 み込んでオリジナルのファイルに適用し、パッチが当てられたバー ジョンを作成します。 (詳しくは patch(1) を参照。) * patchutils - このパッケージには、lsdiff、 interdiff や filterdiff といったパッチを扱うユーティリティが含まれています 。 * pbuilder - このパッケージには chroot 環境の作成や保守に使用さ れるプログラムが含まれます。この chroot 環境下で Debian パッ ケージをビルドすることで適切なビルド依存を確認して FTBFS (Fails To Build From Source) バグを回避することができます。 (詳しくは pbuilder(8) と pdebuild(1) 参照) * perl - Perl は今日の UNIX 系システムにおいてもっとも使われて いるインタープリタ型スクリプト言語のひとつで、その強力さはし ばしば「Unix のスイス軍用チェーンソー」と形容されるほどです。 (詳しくは perl(1) を参照。) * python - Python は Debian システムにおいてもっとも使われてい るもう一つのインタープリタ型スクリプト言語で、並外れたパワー と非常に明快な書式を兼ねそなえています。 (詳しくは python(1) を参照。) * quilt - このパッケージは、一連のパッチそれぞれの変更点を追跡 して、その管理を補助するものです。パッチは簡単に当てたり、外 したり、刷新したり色々することができます。(詳しくは quilt(1) 、 /usr/share/doc/quilt/quilt.pdf.gz 参照。) * xutils-dev - ある種のプログラム (通常 X11のために開発されたも の) は、これらのプログラムを利用して、マクロ関数の組み合わせ から Makefile 群を生成します。(詳しくは imake(1)、 xmkmf(1) 参照。) 上記の簡単な説明は、それぞれのパッケージが何をするのか紹介するだ けのものです。先に進む前にmake等のようにパッケージ依存関係でイン ストールされたプログラムを含むパッケージングに関連する各プログラ     ムに付属の文書を読み、標準的な使い方だけでも理解しておいてくださ い。いまはきついと思われるかも知れませんが、あとになればきっと読 んでてよかったなあと思うことでしょう。もし後日特定の疑問を持った 場合は上記で触れた文書を読み返すことをお勧めします。 1.3. 開発に必要な文書     以下は、この文書と合わせて読むべきとても重要な文書です: * debian-policy - Debian Policy Manual (Debian ポリシーマニュア ル)は、Debian アーカイブの構造と内容、OS の設計に関するいくつ かの案件、Filesystem Hierarchy Standard (FHS、個々のファイル やディレクトリーがどこにあるべきかを規定した文書) が含まれて います。さしあたって重要なのは、ディストリビューションに含ま れるためにそれぞれのパッケージが満たすべき必要条件の説明です (ローカルコピーのpolicy.pdf と /usr/share/doc/debian-policy/ fhs/fhs-3.0.pdf.gz を参照。)     * developers-reference - Debian Developer's Reference (Debian デベロッパーリファレンス)には、例えばアーカイブの構造、パッケ ージ名の変更方法、パッケージの選び方、メンテナーを降りるには どうしたらよいか、どうやって NMU をするか、バグとのつき合い方 、パッケージ作成のベストプラクティス、いつどこにアップロード すればよいかなどなど、特に技術的な事柄以外のパッケージ化につ いてのありとあらゆる情報がここにあります。(ローカルコピーの / usr/share/doc/developers-reference/developers-reference.pdf を参照。)     以下は、この文書と合わせて読むべきとても重要な文書です: * Autotools Tutorial は、Autoconf、Automake、Libtool や gettext を最も重要な構成要素としてもつ GNU Autotools として知られる GNU ビルドシステムの非常に好適な入門書です。     * gnu-standards - このパッケージには、GNU プロジェクトからの文 書が 2 つ含まれています。GNU コーディング標準と、GNU ソフトウ ェアのメンテナー向け情報です。Debian ではこれらに従うことは求 められませんが、ガイドラインまたは常識としても有用です(ローカ ルコピーの /usr/share/doc/gnu-standards/standards.pdf.gz と / usr/share/doc/gnu-standards/maintain.pdf.gz を参照。) この文書が、上記文書の記述と矛盾している場合は、そちらが正解です     。reportbug を使ってmaint-guide パッケージにバグレポートをしてく ださい。     以下は、この文書と合わせて読める同様の入門書です:     * Debian Packaging Tutorial 1.4. 相談するには     公開の場で質問をすると決心する前に、以下に示す良くできた文書を読 みましょう: * 全ての関与するパッケージの /usr/share/doc/package 中のファイ ル * 全ての関与するコマンドの man command の内容     * 全ての関与するコマンドの info command の内容 * debian-mentors@lists.debian.org メーリングリストのアーカイブ の内容 * debian-devel@lists.debian.org メーリングリストのアーカイブの 内容 site:lists.debian.org のような検索文字列を含めてドメインを制約す     るようなことでウェブ検索エンジンをより効率的に利用することを考え ましょう。 小さなテストパッケージを作ることは、パッケージ作成の詳細を学ぶよ     い方法です。他の人がどのようにパッケージを作成しているか学ぶには 、既存のよく保守されているパッケージを調べるのが一番です。     入手可能な文書やウェブのリソースからは答えを見つけられない疑問が 残った場合には、インタラクティブに疑問を聞く事が出来ます: * debian-mentors@lists.debian.org メーリングリスト。 (初心者向 けメーリングリストです。) * debian-devel@lists.debian.org メーリングリスト。 (上級者向け メーリングリストです。) * #debian-mentors の様な IRC。     * 特定群のパッケージにフォーカスしたチーム (全リストはhttps:// wiki.debian.org/Teamsを参照下さい) * debian-devel-{french,italian,portuguese,spanish} @lists.debian.org や debian-devel@debian.or.jp 等の特定言語の メーリングリスト(全リストは https://lists.debian.org/ devel.html と https://lists.debian.org/users.html を参照下さ い)     あなたがするべき努力をした後に適切に質問すれば、より経験を持った Debian デベロッパーは喜んで助けてくれるでしょう。 バグレポート (そう、本物のバグレポートです！) を受けとったら、レ ポートを効率的に処理するために、Debian バグ追跡システムに入り込み     、その説明文書を読む時だということがわかるでしょう。Debian デベロ ッパーリファレンスの 5.8. 'Handling bugs' を読むよう、強くおすす めします。 すべてうまくやったとしても、これからはお祈りの時間です。なぜか？ それは、ほんの数時間 (あるいは数日) で、世界中のユーザーがそのパ     ッケージを使いはじめるからです。もし何か致命的なエラーをやらかし ていたら、膨大な数の怒った Debian ユーザーからメール爆弾を受けと ることになります……なんて冗談ですが :-) リラックスしてバグ報告に備えてください。なにしろ、そのパッケージ     が Debian ポリシーやそのベストプラクティスに完全に沿うようになる までには、やらなくてはいけないことは沢山あるのですから (繰り返し ますが、詳細は正式の文書を読んでください)。頑張ってください！ --------------------------------------------------------------------- ^[1] 文中では、jessie より新しいシステムを使っていると想定してい     ます。古いシステム (古い Ubuntu システム等を含む)を使ってこの文書 についていきたいのであれば、少なくともバックポートされた dpkg お よび debhelper パッケージをインストールする必要があります。 ^[2] Debian システムの基本的な操作は Debian Reference から学べま     す。Unix プログラミングに関しても学べるいくつかのポインターも含ま れています。     ^[3] dh-make-perl、dh-make-php等のように、同様の内容で特化したパ ッケージもいくつかあります。 第2章はじめの一歩 最新の内容とより実用的な例でこの入門書を書き換えたものが Guide     for Debian Maintainers として入手できます。この新しい入門書を第一 次的な入門書として使ってください。     (できれば既存パッケージを引き取り) 自分のパッケージを作成しましょ う。 2.1. Debian パッケージビルドのワークフロー アップストリームのプログラムを使って Debian パッケージを作成する     場合、Debian パッケージビルドは以下の各ステップでいくつかの特定の 命名をされたファイルを生成することからなります: * 通常圧縮された tar フォーマットのアップストリームソフトウェア のコピーを入手します。 + package-version.tar.gz * debian ディレクトリー下へ Debian 固有のパッケージ用の変更をア ップストリームプログラムへ追加し、3.0 (quilt) フォーマットで ノンネイティブのソースパッケージを作成します。(ソースパッケー ジとは、Debian パッケージビルドのために用いる入力ファイルセッ トのこと。)     + package_version.orig.tar.gz + package_version-revision.debian.tar.gz^[4] + package_version-revision.dsc * Debian ソースパッケージから .deb フォーマット (または Debian のインストーラーが使う .udeb フォーマット)で提供される通常の インストール可能な Debian のバイナリーパッケージをビルドしま す。 + package_version-revision_arch.deb package と version の間の文字が tar アーカイブの名前の - (ハイフ     ン)が Debian パッケージファイルの名前では _ (下線)に変更されてい ることに注目して下さい。 Debian Policy Manual に従い、上記のファイル名中の、package 部分は     パッケージ名に置き換え、version 部分はアップストリームバージョン に置き換え、revision 部分は Debian リビジョンに置き換え、arch 部 分はパッケージアーキテクチャーに置き換えます。^[5]     以下で、このアウトラインの各ステップは後述のセクションで詳細に説 明します。 2.2. プログラムの選定 おそらく、作成したいパッケージを選んだことと思います。まず最初に     しなければならないことは、ディストリビューションのアーカイブにそ のパッケージがすでにあるかどうかを以下を使って確認することです: * aptitude コマンド     * Debian パッケージウェブページ * Debian Package Tracker ウェブページ もしパッケージが既に存在していたら、インストールしましょう! :-) もしそのパッケージがみなし子状態 (メンテナーが Debian QA Group に     設定されていること)なら、そのパッケージを他人にとられていなければ 、そのパッケージを引き取ることができるかもしれません。パッケージ のメンテナーが引き取り依頼 (RFA) を出しているパッケージも引きとれ ます。^[6]     パッケージの所有状態の情報源がいくつかあります: * devscripts パッケージ中にある wnpp-alert コマンド * Work-Needing and Prospective Packages     * Debian Bug report logs: Bugs in pseudo-package wnpp in unstable * Debian Packages that Need Lovin' * Browse wnpp bugs based on debtags 注釈ですが、Debian にはすでにほとんどの種類のプログラムが含まれて いることと、Debian アーカイブにすでに含まれているパッケージの数は アップロード権限をもつユーザーの数よりもはるかに多いことに注意し     ておくのは重要です。従って、すでにアーカイブに含まれているパッケ ージへの作業は、他のデベロッパーからはるかに喜ばれ (よりスポンサ ーしてもらえる見込みがあり)ます^[7]。貢献の仕方はいろいろありま す: * まだよく使われている、みなしごのパッケージを引き取る * パッケージ化チームに参加する     * よく使われているパッケージのバグに対処する * QA もしくは NMU アップロードを準備する もしパッケージを引き取ることができるなら、(apt-get source packagename などの方法で) ソースを入手して、調べてみてください。 残念ながらこの文書では、パッケージを引き取ることについて、わかり     やすく説明してはいません。ありがたいことに、既に誰かがあなたのた めにパッケージを準備してくれたわけですから、そのパッケージがどの ように動作するのか理解することは、それほど難しくはないでしょう。 とはいえ、そうした場合でもこの文書に書かれた多くのアドバイスはそ のまま通用しますから、このまま読み進めていってください。 もしあなたの選んだプログラムがまだパッケージ化されていないもので     、それを Debian に入れたいと決めたなら、以下のチェック項目につい て確認してください: * まず、そのプログラムが機能することを理解し、ある程度の期間使 用してその有用性について確認するべきです。 * 作業中のパッケージサイトを確認し、他の誰も同じパッケージに関 して作業していないことを確かめてください。誰も作業していなけ れば、reportbug を使って ITP (Intent To Package) のバグレポー トを、wnpp 疑似パッケージに送ってください。もし既に誰かが作業 していたら、連絡を取りたいならそうしてください。もしその気が 無いなら、まだ誰も手をつけていない他の面白いプログラムを探し ましょう。 * プログラムには、ライセンスが必須です。 + main セクションは、Debian ポリシーにより Debian フリーソ フトウェアガイドライン (DFSG) に完全に準拠しなければなり ませんし、またコンパイル・実行時に main 以外のパッケージ に依存してはなりません。これが望ましいケースです。 + contrib セクションは、DFSG に完全に準拠していなければなり ませんが、コンパイル・実行時に main にあるもの以外のパッ ケージに依存していても構いません。 + non-free セクションは、DFSG に準拠していない部分があるか     もしれませんが、配布可能でなければなりません。 + どうするべきかよくわからなければ、 debian-legal@lists.debian.org にライセンス文を送り、アド バイスを求めてください。 * プログラムは、Debian システムにセキュリティーやメンテナンス上 の懸念を招いてはいけません。 + ちゃんとした説明書きのあるプログラムで、ソースコードが理 解可能なもの (つまり、難読化されていないこと)。 + プログラムの作者に連絡をとって、パッケージ化の承諾と Debian に友好的かどうかを確認しておきましょう。何かプログ ラムそのものに起因する問題が発生した際に、作者にいろいろ 聞けるということは重要なので、メンテナンスされていないソ フトウェアをパッケージ化するのはやめておきましょう。 + プログラムは root に setuid で実行されるべきではありませ ん。もっと言えば、どのユーザーへの setuid や setgid もす るべきではありません。 + デーモンとして動作するプログラムや、*/sbin ディレクトリー に配置するプログラム、また root 特権を使ってポートを開く プログラムで無いほうが良いでしょう。 もちろんこの最後の件は単なる安全策で、setuid デーモン等で何かミス     して怒り狂ったユーザーから抗議殺到という事態を招くことを回避する ためです。パッケージ化についてもっと経験を積めば、こうしたパッケ ージも作れるようになるでしょう。 新規メンテナーであるあなたには、比較的簡単なパッケージで経験を積     むことをお勧めし、複雑なパッケージを作成することお勧めはできませ ん。 * 単純なパッケージ、 + 単一のバイナリーパッケージ、arch = all (壁紙グラフィクス のようなデータのコレクション) + 単一のバイナリーパッケージ、arch = all (POSIX のようなイ ンタープリタ言語で書かれた実行可能プログラム) * ほどほど複雑なパッケージ + 単一のバイナリーパッケージ、arch = all (C や C++ のような 言語からコンパイルされた ELF バイナリーの実行可能プログラ ム) + 複数のバイナリーパッケージ、arch = all + any (ELF バイナ リーの実行可能プログラム + 文書のパッケージ) + ソースファイルの形式が、tar.gz. や tar.bz2 でないもの     + 配布できない内容が含まれるアップストリームソース * 高度に複雑なパッケージ + 他のパッケージにより利用される、インタープリタのモジュー ルパッケージ + 他のパッケージにより利用される汎用 ELF ライブラリーパッケ ージ + ELF ライブラリーパッケージを含む複数バイナリーパッケージ + 複数のアップストリームソースからなるソースパッケージ + カーネルモジュールパッケージ + カーネルパッチパッケージ + 非自明なメンテナースクリプトを含むあらゆるパッケージ 高度に複雑なパッケージをパッケージすることはそれほど難しいことで     はありませんが、少々知識が必要です。それぞれの複雑な特徴には固有 のガイダンスを探すべきです。例えば、いくつかの言語にはそれぞれの サブポリシー文書があります: * Perl policy     * Python policy * Java policy もう一つの古いラテンの諺にもあるように、fabricando fit faber (習 うより慣れろ)です。本入門書を読みながら単純なパッケージを用いて     Debian パッケージングの全ステップを練習したり色々試したりすること を非常に推薦します。以下のようにして作った hello-sh-1.0.tar.gz と いう他愛ないアップストリームは良好なスタートポイントとなるでしょ う。^[8] $ mkdir -p hello-sh/hello-sh-1.0; cd hello-sh/hello-sh-1.0 $ cat > hello < autoreconf -+-> configure Makefile.am -----+ | +-> Makefile.in src/Makefile.am -+ | +-> src/Makefile.in     | +-> config.h.in automake aclocal aclocal.m4 autoheader configure.ac や Makefile.am ファイルを編集するには、autoconf と     automake についての知識が少々必要になります。info autoconf と info automake を参照してください。 Autotools のワークフローの通常の次のステップは、この配布されてい     るソースをユーザーが入手し、ソースディレクトリーで ./configure && make を実行することで、プログラムを binary という実行可能コマンド にコンパイルします。 Makefile.in -----+ +-> Makefile -----+-> make -> binary src/Makefile.in -+-> ./configure -+-> src/Makefile -+     config.h.in -----+ +-> config.h -----+ | config.status -+ config.guess --+ Makefile ファイルにある内容の多くは変更することができます。例えば     デフォルトでファイルがインストールされる場所などは、./configure --prefix=/usr とコマンドオプションを使って変更することができます 。 必須ではありませんが、autoreconf -i -f をユーザーとして実行するこ     とで configure や他のファイルを更新すると、ソースの互換性が改善さ れる場合があります。^[13]     CMake は代替のビルドシステムです。CMakeLists.txt ファイルがあれば 、そういうソースだとわかります。 2.6. パッケージ名とバージョン gentoo-0.9.12.tar.gz としてアップストリームソースが提供される場合     、パッケージ名は gentoo でアップストリームバージョンは 0.9.12 と なります。「changelog」で後述する debian/changelog ファイル中でも 使われます。 この単純なアプローチは大体うまくいくのですが、Debian Policy や従     来の慣習に従うようにアップストリームソースをリネームすることでパ ッケージ名とアップストリームバージョンを調整する必要があるかもし れません。 パッケージ名は、英小文字 (a-z)と数字 (0-9) と、プラス (+) やマイ ナス (-) 記号と、ピリオド (.) だけからなるように選ばなければいけ     ません。少なくとも 2 文字以上で、英数字で始まり、既存のパッケージ と同じではいけません。30 文字以内の長さにするのが望ましいです。^ [14] アップストリームのソースが test-suite のような一般的な単語をその     名称として使う場合は、その内容を明示するようにリネームしネームス ペース汚染を引き起こさないのが良い考えです。^[15] アップストリームバージョンは、英数字 (0-9A-Za-z) とプラス (+) と     波線 (~) とピリオド (.) からのみから選びます。それは数字 (0-9) で 始まらなければいけません。^[16] できることならその長さを 8 文字以 内とするのがいいです。^[17] アップストリームが 2.30.32 のような通常のバージョンスキームを使わ ずに、11Apr29 等のような日時の類や、ランダムなコードネーム文字列 や、バージョンの一部にVCS のハッシュ値等を使う場合、アップストリ ームバージョンから削除するようにしましょう。そのような情報は、 debian/changelog ファイルに記録できます。バージョン文字列を作り上     げる必要のある際には、20110429 等のような YYYYMMDD フォーマットを アップストリームバージョンとして使用します。こうすると後のバージ ョンが正しくアップグレードと dpkg により解釈されます。将来、0.1 等の通常のバージョンスキームへスムーズに移行する必要のある際には 、0~110429 等のような 0~YYMMDD フォーマットをアップストリームバー ジョンとしてこの代わりに使用します。     バージョン文字列^[18]は dpkg(1) コマンドを以下のように使うことで 比較できます:     $ dpkg --compare-versions ver1 op ver2     バージョンの比較ルールは以下のようにまとめられます: * 文字列は頭から尾へと比較されます。 * 英文字は数字よりも大きいです。 * 数字は整数として比較されます。     * 英文字は ASCII コード順で比較されます。 * ピリオド (.) と、プラス (+) と波線 (~) には以下のような特殊な ルールがあります: 0.0 < 0.5 < 0.10 < 0.99 < 1 < 1.0~rc1 < 1.0 < 1.0+b1 < 1.0+nmu1 < 1.1 < 2.0 アップストリームが gentoo-0.9.12.tar.gz のプリリリースとして gentoo-0.9.12-ReleaseCandidate-99.tar.gz をリリースする時には要注     意です。アップストリームソースを gentoo-0.9.12~rc99.tar.gz と名称 変更してアップグレードがうまく機能するように確実にする必要があり ます。 2.7. dh_make のセットアップ 次のようにして、シェルの環境変数 $DEBEMAIL と $DEBFULLNAME を設定     して、パッケージに使うあなたの email アドレスと名前を、多くの Debian メンテナンスツールに認識させましょう。^[19] $ cat >>~/.bashrc < 5 Build-Depends: debhelper (>=10) 6 Standards-Version: 4.0.0     7 Homepage: 8 9 Package: gentoo 10 Architecture: any 11 Depends: ${shlibs:Depends}, ${misc:Depends} 12 Description: 13     (行番号は筆者による)     1–7 行目は、ソースパッケージの管理情報です。9–13 行目は、バイナリ ーパッケージの管理情報です。     1 行目は、ソースパッケージ名です。     2 行目は、パッケージが所属するディストリビューション内のセクショ ンです。 ご存知のように、Debianアーカイブは main (完全にフリーなソフトウェ ア)、non-free (本当にフリーではないソフトウェア)、contrib (フリー だが non-free ソフトウェアに依存するソフトウェア)という複数エリア に分かれています。さらにそれらは、大まかなカテゴリー毎のセクショ     ンに分類されています。例えば、管理者専用のプログラムはadmin 、プ ログラムツールは devel、文書作成関連は doc、ライブラリーは libs、 メールリーダやメールデーモンは mail、ネットワーク関連のアプリケー ションやデーモンは net、分類ができないX11用のプログラムは x11に分 類され、他にも様々なセクションがあります。^[28]     ここではx11に変更してみましょう。(省略時はmain/がデフォルトとして 設定されます)     3行目は、ユーザーが当パッケージをインストールする重要度を示してい ます。^[29]     * required、 important、standardのパッケージと競合しない新規の パッケージの場合は、optionalで問題ないでしょう。 セクション (Section) と優先度 (Priority) はaptitudeのようなフロン トエンドがパッケージをソートする際と、デフォルトを選択する際に利     用されます。Debian にアップロードしたパッケージのこれらの値は、ア ーカイブメンテナーによってオーバーライドされることがありますが、 その場合は電子メールによって通知されます。     このパッケージは通常の優先度で、競合もないので、 optionalにしまし ょう。 4行目は、メンテナーの名前と電子メールアドレスです。バグ追跡システ ムは、このフィールドに記載された宛先へユーザーからのバグ報告を送     信するので、このフィールドは有効な電子メールの To ヘッダーを含む ようにしましょう。コンマ「,」、アンド記号「&」、丸括弧「()」は使 用しないでください。 5行目のBuild-Dependsフィールドは、新規パッケージのビルドに必要な パッケージのリストです。必要であれば、Build-Depends-Indepフィール ドをここに追加できます。^[30] gccやmakeのようなbuild-essentialに     含まれるパッケージは明示無くとも含まれています。他のツールがパッ ケージをビルドするのに必要な場合は、このフィールドに追加しましょ う。複数記載する場合は、コンマで区切ります。このフィールドの書式 については、後述のバイナリーパッケージ依存関係でこれらの行のシン タクスに関してもう少し詳しく説明します。 * debian/rulesを使用し、dhコマンドでパッケージングされたパッケ ージは、cleanターゲットに関するDebian ポリシーを満たすために 、Build-Dependsフィールドにdebhelper (>=9) を記載しなければな りません。 * Architecture: any のバイナリーパッケージを含むソースパッケー ジはオートビルダーによってリビルトされます。オートビルダーは debian/rules build を実行します。その際に、Build-Depends フィ     ールド (「オートビルダー」を参照)に列挙されたパッケージしかイ ンストールしないので、Build-Depends フィールドには事実上必要 なパッケージ全てを列挙しなければなりません。 Build-Depends-indep はあまり使われません。 * バイナリーパッケージが全て Architecture: all のソースパッケー ジでは、clean ターゲットに関する Debian ポリシーを満たすため に Build-Depends フィールドにすでに記載したパッケージ以外で必 要なパッケージは、Build-Depends-Indepフィールドに記載すること もできます。     どちらのフィールドを使えうべきかわからなければ、Build-Dependsにし ておきましょう。^[31]     以下のコマンドを使えば、新規のパッケージをビルドするためにどのパ ッケージが必要かを調べることができます:     $ dpkg-depcheck -d ./configure     /usr/bin/fooの正確なビルド依存パッケージを手動でみつけるには、     $ objdump -p /usr/bin/foo | grep NEEDED     を実行し、表示された各ライブラリー（例えばlibfoo.so.6の場合）につ いて、     $ dpkg -S libfoo.so.6 を実行します。Build-Depends の項目に、各ライブラリーの-devバージ     ョンを採用します。このために ldd を使用すると、間接的な依存も報告 し、過度のビルド依存問題を引き起こします。     gentooパッケージをビルドするにはxlibs-dev、libgtk1.2-dev、 libglib1.2-devが必要なので、debhelperの後に記述しましょう。 6行目は、パッケージが準拠するDebian Policy Manual のバージョンで     す。これは、あなたがパッケージ作成の際に参照したポリシーマニュア ルのバージョンです。     7行目にはソフトウェアのアップストリームホームページ URL を記載で きます。     9行目はバイナリーパッケージの名前です。ソースパッケージと同名にす るのが通例ですが、そうでなくてもかまいません。 10 行目にはバイナリーパッケージがコンパイルされる対象のアーキテク     チャーを記載します。この値はバイナリーパッケージのタイプによって 通常以下の 2 つのどちらかです: ^[32] * Architecture: any + 生成されるバイナリーパッケージが通常コンパイルされたマシ ンコードからなるアーキテクチャー依存パッケージである。     * Architecture: all + 生成されたバイナリーパッケージは、通常テキストやイメージ やインタープリター言語のスクリプトからなる、アーキテクチ ャー依存の無いパッケージである。 10行目はこれが C で書かれているのでこのままにしておきます。     dpkg-gencontrol(1) がソースパッケージがコンパイルされたマシンに合 わせた適正なアーキテクチャーの値で埋めてくれます。 特定のアーキテクチャーに依存しない(例えば、シェルやPerlスクリプト     、文書)パッケージであれば、パッケージをビルドする際に、これを all に変更し、binary-arch に代え binary-indep を使って後述の「rules」 を読んでください。 11行目からはDebianのパッケージシステムが強力なことがわかります。     パッケージは様々な形で相互に関係することができます。Dependsの他に は、Recommends、 Suggests、Pre-Depends、Breaks、 Conflicts、 Provides、Replacesなどがあります。 パッケージ管理ツールは通常このような関係を処理するとき同様の動作     をします。そうでない場合については、後から説明します。(dpkg(8)、 dselect(8)、apt(8)、aptitude(1) 等を参照してください。)     パッケージの依存関係を単純化し以下に説明します: ^[33] * Depends (依存) 依存しているパッケージがインストールされない限り、パッケージ はインストールされません。あなたのプログラムが特定のパッケー ジ無しでは動かない(または深刻な破損を引き起こす)場合はこれを 使います。 * Recommends (推奨) 厳密には必須ではないけれど通常一緒に使われるようなパッケージ の指定にこれを用います。あなたのプログラムをユーザーがインス トールする時、全てのフロントエンドは推奨パッケージも一緒にイ ンストールするかをきっと確認します。aptitude や apt-get の場 合は、推奨パッケージもデフォルトで一緒にインストールします。 (ユーザーはこの挙動を無効化できます。) dpkgはこのフィールドを 無視します。 * Suggests (提案) 必須ではないが、一緒に使用すると便利なパッケージの指定にこれ を用います。あなたのプログラムをユーザーがインストールする時 、フロントエンドが提案パッケージも一緒にインストールするかき っと確認します。aptitude は提案パッケージを一緒にインストール するように変更することが可能ですが、デフォルトではありません 。dpkg と apt-get はこのフィールドを無視します。 * Pre-Depends (事前依存) これは Depends よりも強い関係を示します。パッケージは先行依存 のパッケージがあらかじめインストールされ、かつ適切に設定され ていない限りインストールされません。これは、メーリングリスト     debian-devel@lists.debian.orgで議論を尽くした上で、とても慎重 に扱うべきです。つまり、使わないでください。:-) * Conflicts (競合) 競合しているパッケージが削除されない限り、パッケージはインス トールされません。あなたのプログラムが特定のパッケージと一緒 だと動かない（または深刻な破壊の原因になる恐れがある）場合は これを使います。 * Breaks (破壊) パッケージがインストールされると、全てのリストされたパッケー ジを破壊します。通常、Breaks の項目は特定の値より旧いバージョ ンに対して規定します。通常、上位パッケージマネジメントツール を用い、記載されたパッケージをアップグレードし解決します。 * Provides (提供) パッケージによっては、選択の余地があるために、仮想パッケージ 名が定義されています。仮想パッケージ名の一覧は virtual-package-names-list.txt.gz にあります。あなたのプログ ラムが既存の仮想パッケージの機能を提供する場合には、これを使 います。 * Replaces (置換) あなたのプログラムが別パッケージのファイルを置き換えたり、パ ッケージ全体を完全に置き換えてしまう場合（この場合は Conflicts も一緒に指定してください）この指定を使います。ここ で指定されたパッケージに含まれるファイルはあなたのパッケージ のファイルによって上書きされます。 これらのフィールドは共通の書式で記述します。指定したいパッケージ     名をコンマで区切って並べます。もし選択肢があれば、それらのパッケ ージ名を縦棒| (パイプ記号)で区切って並べます。 これらフィールドは、各指定パッケージの特定バージョン番号に適用対 象を制限できます。各個別パッケージへの制約はパッケージ名の後に丸 カッコの中に以下の関係式に続けバージョン番号を指定しリストします     。使用できる関係式は、<< と <= と = と >= と >> で、それぞれ「指 定されたものより古いバージョンのみ」、「指定されたバージョン以前 」(指定のバージョンも当然含まれます)、「指定のバージョンのみ」、 「指定されたバージョン以降」(指定のバージョンも当然含まれます)、 「指定されたものより新しいバージョンのみ」を意味します。例えば、 Depends: foo (>= 1.2), libbar1 (= 1.3.4) Conflicts: baz     Recommends: libbaz4 (>> 4.0.7) Suggests: quux Replaces: quux (<< 5), quux-foo (<= 7.6)     知っておくべき最後の特徴は ${shlibs:Depends} や ${perl:Depends} や ${misc:Depends} 等です。 dh_shlibdeps(1)は、バイナリーパッケージのライブラリー依存関係を計     算します。それは各バイナリーパッケージ毎に、ELF 実行可能ファイル や共有ライブラリーのリストを生成します。このようなリストは $ {shlibs:Depends} の置換に利用されます。 dh_perl(1)は、Perl依存関係を計算します。それは各バイナリーパッケ     ージ毎に、perl や perlapi の依存関係リストを生成します。このよう なリストは ${perl:Depends} の置換に利用されます。 一部の debhelper コマンドは、生成するパッケージが他追加パッケージ     に依存するようにパッケージを生成します。このようなコマンド全ては 、各バイナリーパッケージが必要とするパッケージのリストを生成しま す。このようなリストは ${misc:Depends} の置換に利用されます。 dh_gencontrol(1) が ${shlibs:Depends}、${perl:Depends}、$     {misc:Depends} 等を置換しながら各バイナリーパッケージ毎に DEBIAN/ control を生成します。 とは言っても、今のところ Depends フィールドはそのままにして、その     下に Suggests: file という新たな行を追加しましょう。gentoo は file パッケージによって提供される機能を利用することができるからで す。     9 行目はホームページの URLです。これが http://www.obsession.se/ gentoo/ と仮定しましょう。 12行目は手短な説明です。従来ターミナルは 1 行（半角）80 文字幅な     ので、(半角)60字以上にならないようにしましょう。fully GUI-configurable, two-pane X file manager に変更します。 13行目は詳細な説明です。これはパッケージについてより詳しく説明す る1つの段落であるべきです。各行の先頭は空白（スペース文字）で始め     ます。空白行を入れてはいけませんが、 . (半角ピリオド) を1つ書くこ とで、空白行のように見せることができます。説明文の後にも１行以上 の空白行を入れてはいけません。^[34] 6行目と7行目の間に Vcs-*フィールドを追加しバージョン管理システム     (VCS) の場所を記録しましょう。^[35] gentooパッケージがその VCS ア ーカイブを git://git.debian.org/git/collab-maint/gentoo.git の Debian Alioth Git Service に置いていると仮定しましょう。     以下が修正後のcontrol ファイルです: 1 Source: gentoo 2 Section: x11 3 Priority: optional 4 Maintainer: Josip Rodin 5 Build-Depends: debhelper (>=10), xlibs-dev, libgtk1.2-dev, libglib1.2-dev 6 Standards-Version: 4.0.0 7 Vcs-Git: https://anonscm.debian.org/git/collab-maint/gentoo.git 8 Vcs-browser: https://anonscm.debian.org/git/collab-maint/gentoo.git 9 Homepage: http://www.obsession.se/gentoo/ 10 11 Package: gentoo 12 Architecture: any 13 Depends: ${shlibs:Depends}, ${misc:Depends}     14 Suggests: file 15 Description: fully GUI-configurable, two-pane X file manager 16 gentoo is a two-pane file manager for the X Window System. gentoo lets the 17 user do (almost) all of the configuration and customizing from within the 18 program itself. If you still prefer to hand-edit configuration files, 19 they're fairly easy to work with since they are written in an XML format. 20 . 21 gentoo features a fairly complex and powerful file identification system, 22 coupled to an object-oriented style system, which together give you a lot 23 of control over how files of different types are displayed and acted upon. 24 Additionally, over a hundred pixmap images are available for use in file 25 type descriptions. 26 . 29 gentoo was written from scratch in ANSI C, and it utilizes the GTK+ toolkit 30 for its interface.     (行番号は筆者による) 4.2. copyright このファイルにパッケージのアップストリームソースに関する著作権や ライセンスなどの情報を記載します。その内容は Debian Policy     Manual, 12.5 "Copyright information" に規定され、DEP-5: Machine-parseable debian/copyright がそのフォーマットのガイドライ ンを提供しています。 dh_makeはcopyrightファイルのテンプレートを作成します。GPL-2でリリ     ースされたgentooパッケージのテンプレートを入手するには、 --copyright gpl2オプションを使用します。 You must fill in missing information to complete this file, such as the place you got the package from, the actual copyright notice, and the license. For certain common free software licenses (GNU GPL-1, GNU GPL-2, GNU GPL-3, LGPL-2, LGPL-2.1,     LGPL-3, GNU FDL-1.2, GNU FDL-1.3, Apache-2.0, 3-Clause BSD, CC0-1.0, MPL-1.1, MPL-2.0 or the Artistic license), you can just refer to the appropriate file in the /usr/share/common-licenses/ directory that exists on every Debian system. Otherwise, you must include the complete license.     つまり、gentoo パッケージの copyright ファイルは以下のようになり ます: 1 Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ 2 Upstream-Name: gentoo 3 Upstream-Contact: Emil Brink 4 Source: http://sourceforge.net/projects/gentoo/files/ 5 6 Files: * 7 Copyright: 1998-2010 Emil Brink 8 License: GPL-2+ 9 10 Files: icons/* 11 Copyright: 1998 Johan Hanson 12 License: GPL-2+ 13 14 Files: debian/* 15 Copyright: 1998-2010 Josip Rodin 16 License: GPL-2+ 17     18 License: GPL-2+ 19 This program is free software; you can redistribute it and/or modify 20 it under the terms of the GNU General Public License as published by 21 the Free Software Foundation; either version 2 of the License, or 22 (at your option) any later version. 23 . 24 This program is distributed in the hope that it will be useful, 25 but WITHOUT ANY WARRANTY; without even the implied warranty of 26 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the 27 GNU General Public License for more details. 28 . 29 You should have received a copy of the GNU General Public License along 30 with this program; if not, write to the Free Software Foundation, Inc., 31 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. 32 . 33 On Debian systems, the full text of the GNU General Public 34 License version 2 can be found in the file 35 '/usr/share/common-licenses/GPL-2'.     (行番号は筆者による) ftpmasterにより提供され debian-devel-announce に投稿された手順書     http://lists.debian.org/debian-devel-announce/2006/03/ msg00023.html に従って下さい。 4.3. changelog これは必須のファイルで、Debian Policy Manual, 4.4 "debian/ changelog"で既定された特別な書式となっています。この書式は、dpkg     やその他のプログラムが、パッケージのバージョン番号、リビジョン、 ディストリビューション、緊急度 (urgency) を識別するために利用しま す。 あなたが行なったすべての変更をきちんと記載しておくことは良いこと であり、その意味でこのファイルはまた、パッケージメンテナーである あなたにとっても重要なものです。パッケージをダウンロードした人は     、このファイルを見ることで、このパッケージに関する未解決の問題が あるかどうかを知ることができます。このファイルはバイナリーパッケ ージ中に/usr/share/doc/gentoo/changelog.Debian.gzとして保存されま す。     dh_makeがデフォルトを生成し、以下のようになっています: 1 gentoo (0.9.12-1) unstable; urgency=medium 2     3 * Initial release. (Closes: #nnnn) 4 5 -- Josip Rodin Mon, 22 Mar 2010 00:37:31 +0100 6     (行番号は筆者による) 1 行目はパッケージ名、バージョン、ディストリビューション、そして     緊急度です。ここに書くパッケージ名はソースパッケージの名前と一致 していなければなりません。またディストリビューションは unstable で、緊急度はlowより高くしてはいけません。:-) 3-5 行目はログ項目で、このパッケージのリビジョンで行われた変更を 記述します (アップストリームプログラムそのものの変更点ではありま せん - その目的のためには、アップストリーム作者によって作成され、     /usr/share/doc/gentoo/changelog.gzとしてインストールされる専用の ファイルが存在しています)。ITP (Intent To Package) バグレポート番 号を 12345 と仮定しましょう。新しい行は * (アスタリスク)で始まる 最初の行の直前に挿入します。この操作は dch(1) を使うと便利ですが 、テキストエディタを使って実行してももちろん構いません。 パッケージの完成前にパッケージが間違ってアップロードされることを     防ぐために、ディストリビューションの値を無効な値 UNRELEASED に変 更するよう推奨します。     最終的にこんなふうになります: 1 gentoo (0.9.12-1) UNRELEASED; urgency=low 2 3 * Initial Release. Closes: #12345     4 * This is my first Debian package. 5 * Adjusted the Makefile to fix $(DESTDIR) problems. 6 7 -- Josip Rodin Mon, 22 Mar 2010 00:37:31 +0100 8     (行番号は筆者による) すべての変更に満足しそれらを changelog 記録した時点で、ディストリ     ビューションの値を UNRELEASED からターゲットディストリビューショ ンの値 unstable (もしくは場合に依っては experimental) へと変更す べきです。^[36]     changelogの更新については、8章パッケージの更新で詳しく説明します 。 4.4. rules さて、今度は dpkg-buildpackage(1) が実際にパッケージを作成するた めに使うルールについて見ていきましょう。このファイルは、もうひと     つの Makefile といった存在ですが、アップストリームソースに含まれ るそれとは違います。debian ディレクトリーに含まれる他のファイルと は異なり、このファイルには実行可能属性が付与されています。 4.4.1. rules ファイルのターゲット 他の Makefile 同様、全ての rules ファイルはいくつかのルールから成 り立っていて、そのそれぞれにターゲットと実行方法が規定されます。^     [37] 新規のルールは最初のカラムにそのターゲット宣言をすることで始 まります。それに続く TAB コード (ASCII 9) で始まる数行はそのレシ ピを規定します。空行と # (ハッシュ) で始まる行はコメント行として 扱われ無視されます。^[38] 実行したいルールは、そのターゲット名をコマンドラインの引数として     実行します。例えば、 debian/rules build や fakeroot make -f debian/rules binary は、それぞれ build や binary ターゲットのルー ルを実行します。     ターゲットについて簡単に説明します: * clean ターゲット: ビルドツリー内にある、生成されたりコンパイ ルされたり役に立たなかったりする全てのファイルをクリーンしま す。(必須) * build ターゲット: ソースをビルドして、ビルドツリー内にコンパ イルしたプログラムと書式に落とし込んだドキュメントをビルドし ます。(必須) * build-arch ターゲット: ソースをビルドして、ビルドツリー内にア ーキテクチャーに依存したコンパイルしたプログラムをビルドしま す。(必須) * build-indep ターゲット: ソースをビルドして、ビルドツリー内に アーキテクチャーに依存しない書式に落とし込んだドキュメントを ビルドします。(必須) * install ターゲット: debianディレクトリー以下にある各バイナリ     ーパッケージのファイルツリーにファイルをインストールします。 定義されている場合は、binary*ターゲットは実質的にこのターゲッ トに依存します。(任意) * binary ターゲット: 全てのバイナリーパッケージを作ります。(実 質的には binary-arch と binary-indep の組み合わせ)(必須)^[39] * binary-arch ターゲット: 親ディレクトリーにアーキテクチャーに 依存したバイナリーパッケージ (Architecture: any)を作ります。 (必須)^[40] * binary-indep ターゲット: 親ディレクトリーにアーキテクチャーに 依存しないパッケージ (Architecture: all) を作ります。(必須)^ [41] * get-orig-source ターゲット: アップストリームアーカイブのサイ トから最新のバージョンのオリジナルソースパッケージを取得しま す。(任意)     今は少々圧倒されているかもしれませんが、dh_make がデフォルトとし て作成する rules ファイルを調べると、状況はとても簡単です。 4.4.2. デフォルトのrulesファイル     最新のdh_makeはdh コマンドでシンプルかつパワフルなrulesファイルを 作ってくれます: 1 #!/usr/bin/make -f 2 # See debhelper(7) (uncomment to enable) 3 # output every command that modifies files on the build system. 4 #DH_VERBOSE = 1 5 6 # see FEATURE AREAS in dpkg-buildflags(1) 7 #export DEB_BUILD_MAINT_OPTIONS = hardening=+all 8     9 # see ENVIRONMENT in dpkg-buildflags(1) 10 # package maintainers to append CFLAGS 11 #export DEB_CFLAGS_MAINT_APPEND = -Wall -pedantic 12 # package maintainers to append LDFLAGS 13 #export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed 14 15 16 %: 17 dh $@     (筆者が行番号を追加しコメントは一部削除した。実際のrulesファイル では、行頭の空白はTABコードです。)     1行目はシェルやパールスクリプトでお馴染みの表現です。オペレーティ ングシステムに/usr/bin/makeで処理するように指示しています。 4 行目のコメントを外し　DH_VERBOSE 変数を 1 に設定すれば、dh コマ ンドがどの dh_* コマンドを実行しているかを出力するようにできます 。必要であればここに、export DH_OPTIONS=-vという行を追加すれば、     dh_*コマンドが、dh_*によって実行されたコマンドを出力します。この 単純な rules ファイルが影で何をしているのかを理解し、その問題デバ ッグの際の助けとなるでしょう。この新しい dh がdebhelper ツールの 中核から設計され、あなたに対して一切隠し事をしません。 16 と 17 行目は、パターンルールを用いて非明示的ルールで全てが行わ れる場所です。パーセント記号「%」は「いかなるターゲット」を意味し     、ターゲットの名前を引数に dh という単一プログラムを実行します。^ [42] dh コマンドは、引数によって、適切なシーケンスで dh_* プログ ラムを走らせるラッパースクリプトです。^[43] * debian/rules clean は dh cleanを実行し、そしてそれは以下を実 行します: dh_testdir dh_auto_clean dh_clean * debian/rules build は dh build を実行します。実行する順番は以 下の通りです: dh_testdir dh_auto_configure dh_auto_build dh_auto_test * fakeroot debian/rules binary は^[44]、fakeroot dh binaryを実 行します。実行する順番は以下の通りです: dh_testroot dh_prep dh_installdirs dh_auto_install dh_install dh_installdocs dh_installchangelogs dh_installexamples dh_installman dh_installcatalogs dh_installcron dh_installdebconf dh_installemacsen dh_installifupdown dh_installinfo dh_installinit     dh_installmenu dh_installmime dh_installmodules dh_installlogcheck dh_installlogrotate dh_installpam dh_installppp dh_installudev dh_installwm dh_installxfonts dh_bugfiles dh_lintian dh_gconf dh_icons dh_perl dh_usrlocal dh_link dh_compress dh_fixperms dh_strip dh_makeshlibs dh_shlibdeps dh_installdeb dh_gencontrol dh_md5sums dh_builddeb * fakeroot debian/rules binary-arch は fakeroot dh binary-arch を実行します。fakeroot dh binary の全てのコマンドに -a オプシ ョンをつけた場合と同じことを行います。 * fakeroot debian/rules binary-indep は fakeroot dh binary-indep を実行します。同様のコマンドはfakeroot dh binary ですが、dh_strip、dh_makeshlibs、dh_shlibdeps は実行せず、残 りのコマンドには-i オプションを付加して実行します。 dh_*は、名前からその機能がわかるようなものばかりです。^[45]　ここ     では、Makefileをもとに作られたビルド環境を前提にして、(超)簡単な 説明を行う価値がある特筆すべき項目いくつかについて述べます: ^[46] * dh_auto_cleanは、Makefile に distclean ターゲットがあれば以下のコ マンドを通常実行します。^[47] make distclean * dh_auto_configureは、./configureがあれば以下のコマンドを通常実行 します。 (読みやすくするために引数は省略しました) ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var ... * dh_auto_buildは、 Makefileがあれば、その最初のターゲットをビルド するために、以下のコマンドを通常実行します。     make * dh_auto_test は、Makefile 中に test ターゲットがあれば、以下を通 常実行します。^[48] make test * dh_auto_install は、Makefile 中に install ターゲットがあれば、以 下のコマンドを通常実行します。 (読みやすくするために畳み込みまし た)。 make install \ DESTDIR=/path/to/package_version-revision/debian/package     fakeroot コマンドを必要とするターゲットは dh_testroot を含みます 。このコマンドは、ルートのふりをしなければエラーで終了します。 dh_make によって作成された rules ファイルについて理解すべきことは     、これは単なる提案ということです。もっと複雑なパッケージ以外のほ ぼ全てに有効ですが、必要に応じてカスタマイズをすることを遠慮して はいけません。 install は、必須ターゲットではありませんがサポートはされています     。fakeroot dh install は fakeroot dh binary のように振る舞います が、dh_fixperms の後で停止します。 4.4.3. rules ファイルのカスタマイズ     新しいdhコマンドで作成されたrulesファイルをカスタマイズする方法は 何通りもあります。     dh $@ コマンドは以下の方法でカスタマイズできます: ^[49] * dh_python2 コマンドのサポートを追加します。(Pythonに最適の選 択。)^[50] + python パッケージを Build-Depends に含めます。 + dh $@ --with python2を使用します。 + これは pythonフレームワークを使用してPythonモジュールを取 り扱います。 * dh_pysupport コマンドのサポートを追加します。(非推奨) + python-support を Build-Depends に含めます。 + dh $@ --with pysupportを使用します。 + これでpython-supportフレームワークを使用してPythonモジュ ールを利用できます。 * dh_pycentral コマンドのサポートを追加します。(非推奨) + Build-Depends に、python-central パッケージを含めます。 + 代わりにdh $@ --with python-centralを使用します。 + これでdh_pysupportコマンドも無効化されます。 + これでpython-centralフレームワークを使用してPythonモジュ ールを利用できます。 * dh_installtex コマンドのサポートを追加します。 + Build-Depends に、tex-commonパッケージを含めます。 + 代わりにdh $@ --with texを使用します。 + これで、TeXによるType1フォント、ハイフネーションパターン 、またはフォーマットが登録されます。 * dh_quilt_patch と dh_quilt_unpatch コマンドのサポートを追加し ます。 + Build-Depends に、quilt パッケージを含めます。 + 代わりにdh $@ --with quiltを使用します。 + 1.0 フォーマットのソースパッケージの debian/patches ディ レクトリー内にあるファイルを用いて、アップストリームソー スにパッチを当てたり外したりできます。 + もし新規の 3.0 (quilt) ソースパッケージフォーマットを使用     している場合、これは不要です。 * dh_dkms コマンドのサポートを追加します。 + Build-Depends に、dkms パッケージを含めます。 + 代わりにdh $@ --with dkmsを使用します。 + カーネルモジュールパッケージによる DKMS の使用を正しく処 理します。 * dh_autotools-dev_updateconfig と dh_autotools-dev_restoreconfig コマンドのサポートを追加します 。 + Build-Depends に、autotools-dev パッケージを含めます。 + 代わりに dh $@ --with autotools-dev を使用します。 + これでconfig.subとconfig.guessをアップデートおよびレスト アします。 * dh_autoreconf と dh_autoreconf_clean コマンドのサポートを追加 します。 + Build-Depends に、dh-autoreconf パッケージを含めます。 + 代わりにdh $@ --with autoreconfを使用します。 + これは、ビルド後にGNUビルドシステムのファイルのアップデー トおよびレストアを行います。 * dh_girepository コマンドのサポートを追加します。 + Build-Depends に、gobject-introspection パッケージを含め ます。 + 代わりにdh $@ --with girを使用します。 + これは GObject イントロスペクションデータを提供しているパ ッケージの依存関係を計算し、パッケージ依存関係用に $ {gir:Depends} 代替変数を生成します。 * bash 補完機能のサポートを追加します。 + Build-Depends に、bash-completion パッケージを含めます。 + 代わりにdh $@ --with bash-completionを使用します。 + このコマンドを使用すると、bash 補完機能から、 debian/ package.bash-completion の設定を使うことができるようにな ります。 新しい dh コマンドにより起動される多くの dh_* コマンドは、debian ディレクトリー内にある対応する設定ファイルによりカスタマイズする     ことが可能です。そのような機能のカスタマイズ方法については、 5章 debianディレクトリーにあるその他のファイルとコマンドごとの manpage を参照してください。 dhコマンドによって呼び出されるdh_*コマンドの中には、特定の引数で 実行したり、それらを追加のコマンドとともに実行したり、スキップし     たりする必要があることがあります。そのような場合は、変更したいdh_ fooコマンドについて、override_dh_foo ターゲットを rules ファイル に追記してください。簡単に説明すると、このターゲットはかわりにこ のコマンドを使用するという意味です。^[51] ここでは簡単に説明を行いましたが、通常以外のケースを処理するため 、dh_auto_*コマンドは、もっと複雑なことを実行することを覚えておい     てください。そのため、override_dh_auto_cleanターゲット以外は、 override_dh_* ターゲットを使用して、簡素化された別のコマンドで代 用するのは感心しません。debhelper の賢い機能を骨抜きにしてしまう からです。 例えば、最近の Autotools を用いた gentooパッケージに関して、その 設定情報を通常の /etc ディレクトリーではなく、/etc/gentoo ディレ     クトリーに置きたい場合には、dh_auto_configure コマンドが ./ configure コマンドに与えるデフォルトの引数 --sysconfig=/etc を以 下のようにしてオーバーライドできます:     override_dh_auto_configure: dh_auto_configure -- --sysconfig=/etc/gentoo --以下の引数は、自動実行されるプログラムの引数に付け足されます。     dh_auto_configure コマンドは、引数--sysconfigのみをオーバーライド しその他の良く配慮された ./configure 引数には触れないため、./ configure コマンドをここに使うより優れています。 もしも gentoo のソースをビルドするためにその Makefile に build タ     ーゲットを指定する必要がある場合、これを有効とするため、^[52] override_dh_auto_build ターゲットを作らなければなりません。     override_dh_auto_build: dh_auto_build -- build     dh_auto_buildコマンドのデフォルトで与えられた引数すべてに build 引数を加えたものとともに、$(MAKE) を確実に実行します。 もし、Debianパッケージのためにソースをクリーンするのに gentoo の     ソースの Makefile が、Makefile 中の distclean や clean ターゲット の代わりに packageclean ターゲットを指定する必要がある場合には、 override_dh_auto_clean ターゲットを作るとそれが可能になります。     override_dh_auto_clean: $(MAKE) packageclean もし、gentooのソースのMakefileが、testターゲットを含み、Debianパ     ッケージをビルドする過程で実行されたくない場合は、空の override_dh_auto_testターゲットを作ることで、スキップできます。     override_dh_auto_test: もし、gentooパッケージに、普通ではないFIXESというアップストリーム のチェンジログファイルがある場合、 dh_installchangelogsはデフォル     トではそのファイルをインストールしません。このファイルをインスト ールするには、FIXESを引数として、dh_installchangelogsに渡してやる 必要があります。^[53]     override_dh_installchangelogs: dh_installchangelogs FIXES この新しい dh コマンドを使う際には、get-orig-source ターゲットを 除き、「rules ファイルのターゲット」にあるような明示ターゲット指     定の正確な影響が把握するのが難しいかもしれません。明示ターゲット は、override_dh_* ターゲットおよび完全に独立したターゲットに限定 して下さい。 ---------------------------------------------------------------------     ^[27] 自明な場合、本章では debian ディレクトリー中のファイルは、 前に付く debian/ を省略し簡明に表記しています。     ^[28] Debian Policy Manual, 2.4 "Sections" と List of sections in sid を参照下さい。     ^[29] Debian Policy Manual, 2.5 "Priorities" を参照下さい。 ^[30] Debian Policy Manual, 7.7 "Relationships between source and     binary packages - Build-Depends, Build-Depends-Indep, Build-Conflicts, Build-Conflicts-Indep" を参照下さい。 ^[31] この少し変な状況はDebian Policy Manual, Footnotes 55で詳し     く説明されている特徴です。これは、debian/rules ファイル内の dh コ マンドではなく、dpkg-buildpackage に起因します。同様の状況は auto build system for Ubuntu にも当てはまります。     ^[32] 詳細は Debian Policy Manual, 5.6.8 "Architecture" を参照下 さい。     ^[33] Debian Policy Manual, 7 "Declaring relationships between packages" を参照下さい。     ^[34] これらの説明は英語です。これらの説明の翻訳は The Debian Description Translation Project - DDTP によって提供されています。     ^[35] Developer's Reference, 6.2.5. "Version Control System location" を参照下さい。     ^[36] もし dch -r コマンドを使ってこの最終変更をする場合には、エ ディターにより changelog ファイルを明示的に保存して下さい。 ^[37] Debian Reference, 12.2 "Make" から Makefile の書き方を学び     始められます。http://www.gnu.org/software/make/manual/html_node/ index.html もしくは non-free のアーカイブエリアにある make-doc パ ッケージに完全な説明書があります。     ^[38] Debian Policy Manual, 4.9 "Main building script: debian/ rules" に詳細に説明されています。     ^[39] このターゲットは例えば、「完全な（再）ビルド」などで、 dpkg-buildpackageが使用します。     ^[40] このターゲットは例えば、「オートビルダー」などで、 dpkg-buildpackage -Bが使用します。     ^[41] このターゲットは、 dpkg-buildpackage -Aが使用します。 ^[42] これは新しい debhelper v7+ の機能です。このデザインコンセプ トはDebConf9で debhelper アップストリームによって Not Your Grandpa's Debhelper として提示されました。lenny の dh_make は、必 須となる明示されたターゲットごとに、もっと複雑な rules ファイルと dh_* スクリプトを量産し、最初にパッケージ化した際の状態に凍結して     いました。新しい dh コマンドは、もっとシンプルで、旧来の「手動」 の雑用から開放してくれます。その上、override_dh_* ターゲットがあ るのでカスタマイズする利便性は失われていません。詳しくは「rules ファイルのカスタマイズ」を参照してください。これは、debhelper パ ッケージがもとになっており、cdbs のようにパッケージのビルドプロセ スを難読化することはありません。 ^[43] You can verify the actual sequences of dh_* programs     invoked for a given target without really running them by invoking dh target --no-act or debian/rules -- 'target --no-act'. ^[44] 以下の例は、自動的に python サポートコマンドが起動するのを     避けるために、あなたの debian/compat には 9 以下の値が入っている と仮定しています。 ^[45] dh_*スクリプトが、実際に何をして、どのようなオプションがあ     るのかを知りたい場合は、debhelper のマニュアルにある該当ページを 参照してください。     ^[46] これらのコマンドは、dh_auto_build --listを実行するとリスト される setup.py のような他のビルド環境もサポートします。     ^[47] 実際には、Makefile 中の distclean、realclean、 clean のうち 、最初に利用可能なものを探し実行します。     ^[48] Makefile 中の test か check のうち、最初に利用可能なものを 見つけ実行します。 ^[49] もし、パッケージが /usr/share/perl5/Debian/Debhelper/     Sequence/custom_name.pmファイルをインストールする場合、そのカスタ マイズの機能を dh $@ --with custom-nameで有効にしなければなりませ ん。     ^[50] dh_pysupport や dh_pycentral コマンドよりもdh_python2コマン ドが好まれます。dh_pythonコマンドは使用しないでください。     ^[51] lennyでは、dh_*スクリプトの挙動を変えたい場合、rulesファイ ル内の該当する行を見つけ出し、調整していました。     ^[52] 引数なしの dh_auto_buildは、Makefile の最初のターゲットを実 行します。 ^[53] debian/changelog と debian/NEWS は常に自動でインストールさ     れます。アップストリームの変更履歴は、ファイル名を小文字に変換し 、changelog、changes、changelog.txt、changes.txtのいずれかと一致 するものを見つけます。 第5章 debianディレクトリーにあるその他のファイル The dh_make command had major updates since this old document was     written. So some parts of this document aren't applicable any more. 最新の内容とより実用的な例でこの入門書を書き換えたものが Guide     for Debian Maintainers として入手できます。この新しい入門書を第一 次的な入門書として使ってください。     The debmake command is used in place of the dh_make command in my new Guide for Debian Maintainers. debhelperがパッケージのビルド中に行うことは、オプションの設定ファ イルを debian ディレクトリーに置けばコントロールできます。この章     では、設定ファイルの機能と書式を概説します。パッケージングのガイ ドラインについての詳細は Debian Policy Manual と Debian Developer's Reference を参照してください。     The dh_make command will create some template configuration files under the debian directory. Take a look at all of them.     自明な場合、本章では debian ディレクトリー中のファイルは、前に付 く debian/ を省略し簡明に表記しています。 dh_makeコマンドは、一部の debhelper用の設定テンプレートファイルを     作らないことがあります。その場合、自分でエディターを使いそれらを 作成しなければなりません。     設定ファイルを有効にしたい際は、以下を実行して下さい: * packageの代わりに、実際のバイナリーパッケージの名前に設定ファ イルをリネームしてください。 * 必要に応じて、テンプレートファイルの中身を書き換えます。     * 不要なテンプレートファイルは削除してください。 * 必要であれば、control ファイル(参照「control」)を変更します。 * 必要ならrulesファイル(参照「rules」)を編集してください。 package をプリフィックスとして持たない、例えば install のような debhelper の設定ファイルは、最初のバイナリーパッケージへ適用され     ます。バイナリーパッケージが多数ある場合、package-1.install、 package-2.install、等のように、パッケージ名を設定ファイルのプリフ ィックスとすることで指定できます。 5.1. README.Debian パッケージに関して、何か特別にユーザーに知らせなければならない情     報や、オリジナルのソフトウェアと作成したDebianパッケージとの相違 点があればここに記述します。     以下はdh_makeがデフォルトとして生成するものです: gentoo for Debian     ----------------- -- Josip Rodin , Wed, 11 Nov 1998 21:02:14 +0100     もし、ドキュメントがなければこのファイルを削除してください。詳し くは dh_installdocs(1)を参照してください。 5.2. compat     compat ファイルは、debhelper の互換性レベルを規定します。現段階で は、以下のように debhelper v10 に設定しましょう:     $ echo 10 > debian/compat 一定の環境下では旧システムとのコンパチビリティーのためにcompat レ     ベル v9 を使ってよろしい。しかし、v9 以下の如何なるレベルを使うこ とは勧められないし、新規パッケージに用いることは避けるべきです。 5.3. conffiles 大変な時間と労力を費やしてプログラムをカスタマイズしても、一回の アップグレードであなたの変更をあちこち上書きされてしまうとうんざ     りします。このような設定ファイルを conffile と記録しておくことで 、Debianはこの問題を解決しました。^[54] パッケージをアップグレー ドする際に、あなたは古い設定ファイルをキープしたいかかどうかを尋 ねられます。 dh_installdeb(1) は自動的に /etc ディレクトリー以下のファイルを全 て conffiles とみなすので、あなたのプログラムが他のディレクトリー     に conffiles を持たない場合は特に指定する必要はありません。ほとん どのパッケージの場合、/etc 以下にのみ conffiles がある（そうある べきです）ので、このファイルの存在は不要です。 あなたのプログラムが設定ファイルを利用する場合であっても、その設 定ファイルがプログラム自身によって頻繁に上書きされるような場合に     は、パッケージをアップグレードするたびに dpkg によって設定ファイ ルの変更について確認を求められることになるので、その設定ファイル を conffiles に登録しないほうが良いでしょう。 あなたのパッケージングするプログラムが、ユーザーに /etc ディレク     トリーの中にある設定ファイルを編集することを要求する場合、dpkg を 黙らせるために conffiles として登録しない良く使われる方法が 2 つ あります: * /etc ディレクトリー中に、メンテナースクリプトによって生成され た /var ディレクトリー以下のファイルにシンボリックリンクを張     る。 * /etc ディレクトリーの中にメンテナースクリプトによってファイル を生成する。     メンテナースクリプトについての詳細は、「{pre,post}{inst,rm}」を参 照してください。 5.4. package.cron.* パッケージが正しく動作するために、定期的にあるタスクを実行する必     要がある場合は、これらのファイルで設定します。毎時間、毎日、毎週 、または指定した時間に定期的タスクを実行するように指定することが できます。ファイル名は以下です: * cron.hourly - /etc/cron.hourly/packageとしてインストール: 1時 間ごとに実行する。 * cron.daily - /etc/cron.daily/packageとしてインストール: 1日に 1度実行。     * cron.weekly - /etc/cron.weekly/packageとしてインストール: 1週 間に1度実行。 * package.cron.monthly - /etc/cron.monthly/package:としてインス トール: 1ヶ月に1度実行。 * package.cron.d - /etc/cron.d/packageとしてインストール: どの 時間でも指定可能。     上記のファイルの書式はシェルスクリプトです。package.cron.d は違い 、crontab(5)の書式になります。 ログローテーションの設定には明示的な cron.* は必要ありません。こ     れについてはdh_installlogrotate(1) および logrotate(8)を参照して ください。 5.5. dirs このファイルにはパッケージが必要としているのに、なぜか通常のイン     ストール手順 (dh_auto_install によって呼び出される make install DESTDIR=...) では作成されないディレクトリーを指定します。通常、こ れは Makefile に問題があることを示唆しています。     installファイルに書かれてるファイルは最初にディレクトリーを作成す る必要はありません。「install」を参照してください。 まずは試しにインストールしてみて、なにか問題が起きた場合にのみ使     うべきでしょう。 dirs ファイル中のディレクトリー名の頭にスラッシ ュが付かない事に注意してください。 5.6. package.doc-base もしあなたのパッケージがマニュアルページや info 形式の文書以外に     付属文書を含む場合、 doc-base ファイルを使ってそれらを登録し、ユ ーザーがそれらの付属文書を、例えばdhelp(1) や dwww(1)、あるいは doccentral(1) コマンドなどで参照できるようにしましょう。     これには通常、/usr/share/doc/packagename/の中に収められるような HTML、PS、およびPDFなどの形式の付属文書が含まれます。     例えば、gentoo の gentoo.doc-base ファイルは次のようになります: Document: gentoo Title: Gentoo Manual Author: Emil Brink     Abstract: This manual describes what Gentoo is, and how it can be used. Section: File Management Format: HTML Index: /usr/share/doc/gentoo/html/index.html Files: /usr/share/doc/gentoo/html/*.html このファイルの書式についてはinstall-docs(8)および doc-base パッケ     ージが提供するローカルコピー　/usr/share/doc/doc-base/ doc-base.html/index.html にある doc-base のマニュアルを参照してく ださい。     追加ドキュメントのインストールについて、詳細は「指定場所へのファ イルのインストール」を見てください。 5.7. docs このファイルには、dh_installdocs(1)を使ってパッケージ生成用の一時     的なディレクトリーにインストールするために、パッケージに付属する 資料のファイル名を指定してください。     デフォルトでは、ソースディレクトリーのトップレベルに存在する BUGS 、 README*、 TODO などの名前を持つファイル全てを含みます。     gentoo に関していくつか他のファイルが含まれます: BUGS CONFIG-CHANGES CREDITS     NEWS README README.gtkrc TODO 5.8. emacsen-* パッケージをインストールする際にバイトコンパイル可能な Emacs ファ     イルがあなたのパッケージに含まれている場合、これらの emacsen-* フ ァイルを利用してそれを設定することができます。     これらのファイルはdh_installemacsen(1)によってパッケージ作成用の 一時的なディレクトリーにインストールされます。     不要ならこのファイルを削除してください。 5.9. package.examples     dh_installexamples(1)コマンドはこのディレクトリーに列挙されたファ イルを例としてインストールします。 5.10. package.init と package.default もしあなたのパッケージがデーモンであり、システムの起動時に自動的     に動作させる必要があるとしたら、私が最初に勧めたことをあなたはま るっきり無視してしまったわけですよね。そうでしょ ?:-)     Please read dh_installinit(1) dh_installsystemd(1) to provide startup script. The package.default file will be installed as /etc/default/ package. This file sets defaults that are sourced by the init     script. This package.default file is most often used to set some default flags or timeouts. If your init script has certain configurable features, you can set them in the package.default file, instead of in the init script itself. アップストリームプログラムが init スクリプト用ファイルを提供する 場合、それを使用するかしないかは自由です。もしアップストリームか らの init スクリプトを使わないのであれば package.init に新しいの     を作成しましょう。アップストリームのinit スクリプトが問題なく正し い場所にインストールされるとしても、rc* シンボリックリンクの設定 は必要です。そのためには、rules ファイルに以下を追加して、 dh_installinit をオーバーライドしましょう:     override_dh_installinit: dh_installinit --onlyscripts     不要なら、このファイルを削除してください。 5.11. install パッケージにとってインストールが必要なファイルがあるにも関わらず 、 make install ではインストールされない場合、そのファイル名とフ ァイルを置く目的地を install ファイルに記述します。そうすると、     dh_install(1) によってそれらのファイルがインストールされます。^ [55] まずは使えそうな別のツールがないかどうかを調べましょう。例え ば、ドキュメントはこのファイルではなくdocsファイルにあるべきです 。 install ファイルはインストールされるファイルごとに 1 行必要としま す。ファイル名（ビルドディレクトリーのトップを基点とした相対パス     ）、スペース、インストールするディレクトリー名（インストールディ レクトリーを基点とした相対パス）という書式です。例えば、バイナリ ー src/bar のインストールを忘れた場合などに、 install ファイルの 項目は以下のように記述します:     src/bar usr/bin     上記によって、パッケージがインストールされたときに、/usr/bin/bar というバイナリーファイルが存在することになります。 また、この install ファイルは相対パスが変わらない場合、インストー ルディレクトリーの指定を省略することもできます。この書式はビルド     した結果を、package-1.install, package-2.install などを使用し、複 数のバイナリーパッケージに分割するような、大規模なパッケージで使 われます。 dh_install コマンドはもし、カレントディレクトリーでファイルが見つ     からなかった場合は、(または、--sourcedir で探すように指示したディ レクトリー内で見つからなかった場合は)フォールバックして debian/ tmp内を検索します。 5.12. package.info     パッケージにinfoページがある場合、package.info にそれらを挙げて、 dh_installinfo(1) を使用してインストールします。 5.13. package.links パッケージメンテナーとしてパッケージビルドディレクトリー中に追加     のシンボリックリンクを作成する必要がある場合、リンク元とリンク先 の両方のフルパスを package.links ファイル中にリストすることで dh_link(1) コマンドでそれらをインストールするべきです。 5.14. {package.,source/}lintian-overrides ポリシーが例外を認めているにも関わらず、lintian が誤診断を報告し てきた場合、package.lintian-overridesかsource/lintian-overrides     を使って黙らせることができます。Lintian User's Manual (https:// lintian.debian.org/manual/index.html) を読み、濫用は控えてくださ い。 package.lintian-overrides は package と名づけられたパッケージのた     めのファイルで、dh_lintian コマンドによって usr/share/lintian/ overrides/package にインストールされます。     source/lintian-overridesはソースパッケージのためのファイルです。 これはインストールされません。 5.15. manpage.* プログラムはマニュアルページが必ず必要です。もし無いなら作らなけ ればなりません。dh_make コマンドはマニュアルページのテンプレート     を作成します。マニュアルページがないコマンドのために、コピー、編 集する必要があります。不要なテンプレートファイルを削除するのを忘 れないようにしてください。 5.15.1. manpage.1.ex マニュアルページは通常、nroff(1)で書かれています。manpage.1.exの     テンプレートもnroffで書かれています。これらのファイルをどう編集す るのかについて、簡単な説明がman(7)にあります。 最終的なマニュアルページのファイル名は、解説されているプログラム 名を含めなければなりません。ここでは、ファイル名を manpage から     gentoo に変更しましょう。ファイル名は、.1 というサフィックスも含 みます。これは、このマニュアルページはユーザーコマンドのものだ、 という意味です。この部分を間違わないように気をつけてください。以 下はマニュアルページのリストです: +---------------------------------------------------------------+ |セクショ| 内容 | ノート | | ン | | | |--------+-----------------+------------------------------------| |1 |ユーザーコマンド |実行可能なコマンドやスクリプト | |--------+-----------------+------------------------------------| |2 |システムコール |カーネルが提供するファンクション | |--------+-----------------+------------------------------------| |3 |ライブラリーコー |システムライブラリーが提供するファン| | |ル |クション | |--------+-----------------+------------------------------------|     |4 |特殊ファイル |通常 /dev にある | |--------+-----------------+------------------------------------| |5 |ファイルフォーマ |例えば、/etc/passwdのフォーマット | | |ット | | |--------+-----------------+------------------------------------| |6 |ゲーム |ゲームや他の他愛ないプログラム | |--------+-----------------+------------------------------------| |7 |マクロパッケージ |manのマクロ等 | |--------+-----------------+------------------------------------| |8 |システム管理 |普通rootが実行するプログラム | |--------+-----------------+------------------------------------| |9 |カーネルルーチン |非標準のコールや内部コール | +---------------------------------------------------------------+ つまり、gentoo のマニュアルページは gentoo.1 となります。オリジナ ルのソースファイルに gentoo.1 というマニュアルページがなければ、     アップストリームのドキュメントと例を元にして、manpage.1.ex という テンプレートファイルを編集し gentoo.1 というマニュアルページを作 らなければなりません。     各コマンドの --helpと--version 出力から help2manコマンドを用いて マニュアルページを作成することも可能です。^[56] 5.15.2. manpage.sgml.ex もし、nroffよりSGMLのほうが好みであれば、manpage.sgml.ex のほうを     ひな型として使うこともできます。こちらの場合には、以下の手順が必 要です: * ファイル名をgentoo.sgmlのような名前に変更します。 * docbook-to-man パッケージのインストール * control ファイルの Build-Depends 行へ docbook-to-man を追加     * rules ファイルに override_dh_auto_build ターゲットを追加しま す: override_dh_auto_build: docbook-to-man debian/gentoo.sgml > debian/gentoo.1 dh_auto_build 5.15.3. manpage.xml.ex     SGMLよりもXMLが好みであれば、manpage.xml.exをひな形として使うこと もできます。こちらの場合には、以下の手順が必要です: * ソースファイルの名前を、gentoo.1.xmlのような名前に変更します。 * docbook-xsl パッケージと xsltproc のような XSLT プロセッサのイン ストール (推奨) * control ファイルの Build-Depends 行へ、docbook-xsl、docbook-xml、 xsltproc の各パッケージを追加します。 * rules ファイルに override_dh_auto_build ターゲットを追加します:     override_dh_auto_build: xsltproc --nonet \ --param make.year.ranges 1 \ --param make.single.year.ranges 1 \ --param man.charmap.use.subset 0 \ -o debian/ \ http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl\ debian/gentoo.1.xml dh_auto_build 5.16. package.manpages パッケージにマニュアルページがある場合、package.manpages ファイル     にそれらをリストして、dh_installman(1) を使用してインストールしま す。 gentoo パッケージのマニュアルページとして docs/gentoo.1 をインス     トールするには、以下のように gentoo.manpages ファイルを作成しま す:     docs/gentoo.1 5.17. NEWS     dh_installchangelogs(1)コマンドでインストールします。 5.18. {pre,post}{inst,rm} postinst や preinst や postrm や prerm ファイルは^[57]メンテナー     スクリプトと呼ばれています。これらのスクリプトは、パッケージを管 理するエリアに置かれ、インストール、アップグレード、削除される際 にdpkgによって実行されます。 新米メンテナーのうちは、問題になることが多いのでメンテナースクリ プトを直接編集しないようにしましょう。詳しくは Debian Policy     Manual, 6 "Package maintainer scripts and installation procedure" を参照し、dh_make によって生成されるサンプルファイルに目を通して ください。 もし私の忠告を無視して、メンテナースクリプトを直接編集した場合は     、インストール、アップグレードだけでなく、削除とパージのテストも しっかり行ってください。 新バージョンへのアップグレードは静かであるべきで、押し付けがまし     くてはいけません。（現行ユーザーは、バグが直されたことや新機能が 追加されたことで気づかない限りアップグレードに気づかないのが理想 です。) アップグレードが出しゃばる必要がある場合 (例えば、構造がまったく 異なる設定ファイルがホームディレクトリーに散在する場合など)、パッ ケージのデフォルトを(例えばサービスを停止する等の)安全側に設定し     たり、最後の手段としてはポリシーに要求されるきちんとしたドキュメ ント (README.DebianとNEWS.Debian) を提供するなどの対策を考えるべ きです。アップグレード際にメンテナースクリプトで debconf ノートを 呼び出したりしてユーザーに迷惑を掛けないでください。 ucf パッケージは、メンテナースクリプトによって管理されているよう な conffiles とラベルされていないファイルに関して、ユーザーによっ     て変更されたファイルを保存する conffileのような処理をする仕組みを 提供します。この仕組みを使うとこれらに関する問題を最小化できます 。 これら、メンテナースクリプトはなぜ Debian を選ぶのかという理由の     1 つでもあります。これらの仕組みで、ユーザーが迷惑がる原因となら ないよう細心の注意をはらいましょう。 5.19. package.symbols 新米メンテナーにとってはライブラリーのパッケージは容易ではないし     、避けるべき行為です。このように言いましたが、もしあなたのパッケ ージがライブラリーを含む場合には、debian/package.symbols ファイル を作成すべきです。「debian/package.symbols の管理」を参照下さい。 5.20. TODO     dh_installdocs(1)コマンドでインストールします。 5.21. watch watch ファイルの書式は uscan(1) を参照してください。watch ファイ     ルは、uscan ( devscriptsパッケージに含まれます) を設定し、最初ソ ースを入手したサイトを監視します。これは Debian パッケージトラッ カーサービスによっても使用されています。     以下がその内容です: # watch control file for uscan     version=3 http://sf.net/gentoo/gentoo-(.+)\.tar\.gz debian uupdate 通常、このwatchファイルでは、http://sf.net/gentoo の URL がダウン ロードされ、 フォームへのリンクを検索します。リンクさ れた URL のベースネーム(最後の / から後の部分のみ)は Perl の正規     表現 (perlre(1) 参照)パターン gentoo-(.+)\.tar\.gz に照らし合わさ れます。一致したファイルの中から、バージョンの番号が一番大きいも のがダウンロードされ、その後アップデートされたソースツリーを作成 するために uupdate プログラムを実行します。 他のサイトでは上記の通りですが、http://sf.net の SourceForge のダ ウンロードサービスは例外です。watchファイルが Perl の正規表現 ^ http://sf\.net/ に一致する URL を含む場合、uscan プログラムが代わ     りにhttp://qa.debian.org/watch/sf.php/ を使い、このルールを当ては めます。http://qa.debian.org/ の URL リダイレクトは http://sf.net /project/tar-name-(.+)\.tar\.gzを含むwatch ファイルを対象に安定し たリダイレクトを提供するよう設計されています。これにより、そこで 周期的に変化する URL に関する問題を解決しています。 ターボールの公開鍵電子署名をアップストリームが提供している際には     、 uscan(1) 中に記載された pgpsigurlmangle オプションを用いてその 正統性を検証することが望ましい。 5.22. source/format debian/source/formatファイルでは、ソースパッケージのための理想の     書式を示すための行があります。 (完全なリストは、dpkg-source(1)を 参照してください。)squeeze以降は、以下のどちらかになっているべき です: * 3.0 (native)：ネイティブ Debian パッケージ     * 3.0 (quilt)：　それ以外の全て。 新しい3.0 (quilt)の書式はquiltパッチによる変更を debian/patchesに 記録します。そして、その変更は自動的にソースパッケージを展開する ときに適用されます。^[58]Debianの変更は、debianディレクトリー以下     のファイル全てを含め、debian.tar.gzアーカイブに保存されています。 この新しい書式は、特殊な方法を用いることなく、PGNアイコンなどのパ ッケージメンテナーによるバイナリーファイルを含めることが可能です 。^[59] dpkg-sourceが3.0 (quilt)の書式でソースパッケージを展開する際、     debian/patches/seriesに列挙されたパッチを自動的に適用します。 --skip-patchesオプションで、展開時にパッチを適用しないようにでき ます。 5.23. source/local-options Debianをパッケージングする活動をVCSで管理したい場合、アップストリ ームのソースをトラックするためのブランチ(例: upstream)とDebianパ     ッケージをトラックするための別のブランチ(Gitでの典型例: master)を 作成します。後者の場合、新しいアップストリームのソースとマージす るのを簡単にするために、通常パッチの当てていないアップストリーム のソースをdebian/*ファイルと一緒に持っておきます。 パッケージをビルドした後は、ソースのパッチは通常当てたままにされ ます。masterブランチにコミットする前に手動で quilt pop -a を実行 してパッチを外す必要があります。debian/source/local-optionsファイ     ルにunapply-patchesを書いておけば、自動的にパッチを外せます。この ファイルは生成されたソースパッケージには含まれず、ローカルビルド での挙動のみを変更します。このファイルはabort-on-upstream-changes も含むかもしれません (dpkg-source(1) 参照)。     unapply-patches abort-on-upstream-changes 5.24. source/options ソースツリーの中の自動生成されるファイルはパッケージングする際に     無意味で大きなパッチファイルを生成するのでとても厄介です。「rules ファイルのカスタマイズ」で説明したようにdh_autoreconf のようなカ スタムモジュールが本問題を解消するために存在します。 dpkg-source(1) の --extend-diff-ignore オプション引数に Perl 正規     表現を提供すると、ソースパッケージ生成時に自動生成ファイルへの変 更を無視できます。 この自動生成ファイルの問題の一般的解決策としてソースパッケージの     source/options ファイル中に dpkg-source オプション引数を保存する 事が出来ます。以下の例では、config.sub と config.guess と Makefile に関してパッチファイルの生成をスキップします。     extend-diff-ignore = "(^|/)(config\.sub|config\.guess|Makefile)$" 5.25. patches/* 古い　1.0　のソースフォーマットは、debian　内にパッケージメンテナ ンスファイルと、パッチファイルを含む単一の大きな　diff.gz　ファイ     ルを作っていました。そのようなファイルは、ソースツリーの変更を後 から調べたり、理解するのが非常に厄介でした。これはあまりいただけ ません。 新しい 3.0 (quilt) は、quilt コマンドを使って、パッチを debian/ patches/* に置きます。debian ディレクトリー以下に含まれているパッ     チやその他のパッケージデータは、debian.tar.gz ファイルとしてパッ ケージングされます。dpkg-source コマンドは、quilt 形式のパッチデ ータを quilt パッケージなしで 3.0 (quilt) として扱えるので、quilt パッケージを Build-Depends に記載する必要はありません。^[60] quilt コマンドについてはquilt(1) で説明されています。ソースへの変 更は、debian/patches ディレクトリー内 -p1 パッチファイルのスタッ     クとして記録され、debian ディレクトリーの外のソースツリーには触れ ません。それらのパッチの順番は debian/patches/series ファイルに記 録されます。パッチの適用 (=push)も、外す (=pop)のも、更新(= refresh)も、簡単にできます。 ^[61]     3章ソースコードの変更では、debian/patchesに 3 つのパッチを作りま した。     Debian のパッチは debian/patches にあるので、「quilt のセットアッ プ」の説明に従い、dquilt コマンドを正しく設定してください。     誰かが(あなた自身も含みます) foo.patch というパッチを後から提供し た際の、3.0 (quilt) ソースパッケージの変更はとてもシンプルです: $ dpkg-source -x gentoo_0.9.12.dsc $ cd gentoo-0.9.12 $ dquilt import ../foo.patch     $ dquilt push $ dquilt refresh $ dquilt header -e ... describe patch 新しい 3.0 (quilt) 形式で保存されるパッチには曖昧さがあってはいけ     ません。それを保証するために、dquilt pop -a; while dquilt push; do dquilt refresh; done としてください。 ---------------------------------------------------------------------     ^[54] dpkg(1) and Debian Policy Manual, "D.2.5 Conffiles" を参照 下さい。     ^[55] filesファイルによって、dh_movefiles(1)コマンドが設定され、 置換されます。 ^[56] help2man が作成する仮のマニュアルページに、詳細なドキュメン     トが info システムにあると記載されることに注意して下さい。info ペ ージ中にコマンドが無い場合は、help2man コマンドが生成したページを 手動で修正するべきです。 ^[57] {pre,post}{inst,rm} という bash 独自の短縮形をこれらのファ     イル名の表記としていますが、システムシェルである dash との互換性 のために、これらのメンテナースクリプトでは純粋な POSIX シンタック スを使うべきです。     ^[58] ソースの書式を 3.0 (quilt) や 3.0 (native) に移行する際の注 意点などは、DebSrc3.0 を参照下さい。 ^[59] この新しいフォーマットは、複数のアップストリームの tar アー     カイブやこの他の圧縮方法もサポートしています。詳細は本稿の範疇を 超えるため割愛します。 ^[60] パッチセットをメンテナンスするためのいくつかの方法が提案さ     れ、Debian パッケージで使われていますが、quilt が推奨されています 。他には、dpatch、dbs、cdbs、などがあります。これらの方法は、大抵 debian/patches/* ファイルでパッチを管理しています。 ^[61] スポンサーにパッケージのアップロードを頼む時にも、あなたが     加えた変更に対するこのような明確な分離とドキュメントは、スポンサ ーによるパッケージのレビューを促進させるためにも、非常に重要です 。 第6章パッケージのビルド 最新の内容とより実用的な例でこの入門書を書き換えたものが Guide     for Debian Maintainers として入手できます。この新しい入門書を第一 次的な入門書として使ってください。     これでパッケージをビルドする準備が整いました。 6.1. 完全な（再）ビルド     完全なパッケージの（再）ビルドを行うには、以下を確実にインストー ルして下さい。 * build-essentialパッケージ     * Build-Dependsに挙げられているパッケージ(参照「control」) * Build-Depends-indepに挙げられているパッケージ(参照「control」 )     ソースディレクトリーで以下のコマンドを実行してください:     $ dpkg-buildpackage -us -uc     このコマンドはバイナリーパッケージとソースパッケージをビルドする 作業をすべて行ってくれます。これには以下の作業が含まれます: * ソースツリーのクリーン (debian/rules clean) * ソースパッケージのビルド (dpkg-source -b) * プログラムのビルド (debian/rules build)     * バイナリーパッケージのビルド (fakeroot debian/rules binary) * .dsc ファイルの作成 * dpkg-genchanges を使用し .changesファイルを作成 満足なビルド結果の場合には、debsign コマンドを用いてあなたの秘密     GPG 鍵で .dsc と .changes ファイルを署名します。秘密フレーズを２ 回入力する必要があります。 ^[62]     ノンネイティブパッケージの場合、パッケージビルド後の親ディレクト リー (~/gentoo) に以下のファイルが生成されているはずです: * gentoo_0.9.12.orig.tar.gz これは単に Debian 標準に合わせるために名前を変更しただけで、 中身はオリジナルなソースコードの tar アーカイブです。これは元 来、dh_make -f ../gentoo-0.9.12.tar.gz で作成されたということ を覚えておいてください。 * gentoo_0.9.12-1.dsc これはソースコードの内容の概要です。このファイルはあなたの controlファイルから生成され、dpkg-source(1)によってソースを展 開する際に使われます。 * gentoo_0.9.12-1.debian.tar.gz この圧縮された tar アーカイブには、あなたのdebianディレクトリ ーの中身が含まれています。オリジナルのソースコードに行った変 更や追加などの情報は全て debian/patches 内に、quilt パッチと して保存されます。 上記 3 つのファイルを使えば誰でも簡単にあなたのパッケージをス クラッチからビルドすることができます。3 つのファイルを任意の     場所にコピーし、dpkg-source -x gentoo_0.9.12-1.dscを実行する だけです。^[63] * gentoo_0.9.12-1_i386.deb これは、あなたが生成した完全なバイナリーパッケージです。他の 全てのパッケージと同じく、dpkgを使ってインストールしたり削除 したりできます。 * gentoo_0.9.12-1_i386.changes このファイルは現在のリビジョンパッケージにおける変更点をすべ て記載したもので、Debian FTP アーカイブ管理プログラムによって 、バイナリーおよびソースパッケージを FTP アーカイブにインスト ールするために利用されます。このファイルの一部は、changelog ファイルと .dsc をもとに生成されます。 パッケージの保守管理を続けていくと、挙動の変更や新機能の追加 をすることがあります。あなたのパッケージをダウンロードする人 は、このファイルを見れば何が変わったのか、一目でわかります。 また、このファイルの中身は Debian アーカイブ管理プログラムに よって、debian-devel-changes@lists.debian.org メーリングリス トへ流されます。 Debain FTP アーカイブにアップロードする前に、~/.gnupg/ ディレクト     リー中にあるあなたの秘密 GPG 鍵で debsign コマンドを用いて gentoo_0.9.12-1.dsc と gentoo_0.9.12-1_i386.changes ファイルを署 名しなければいけません。 以下の ~/.devscripts ファイルを用いると、debsign コマンドはあなた     が指定した秘密 GPG キー ID (パッケージをスポンサーする際に便利) で署名できます:     DEBSIGN_KEYID=Your_GPG_keyID .dsc と .changes ファイルに記載されている長い数字の羅列は各ファイ ルの MD5/SHA1/SHA256 チェックサムです。パッケージをダウンロードし     た人は、sha1sum(1)、sha256sum(1)を使って整合性をテストすることが できます。もし、数字が一致しない場合には、ファイルが壊れているか 、あるいは何者かによって改ざんされていると分かるわけです。 6.2. オートビルダー Debian は、様々なアーキテクチャー上で buildd デーモンを走らせてい るオートビルダーネットワークによって、色々な移植版をサポートして     います。あなたがそれらを明示的に使う必要はありませんが、パッケー ジがどうなるのかを知っておくと良いでしょう。それでは、あなたのパ ッケージがどのように異なるアーキテクチャー向けに再ビルドされるの かを見ていきましょう。^[64]     Architecture: any のパッケージは、オートビルダーシステムによって 再ビルドされます。それは、以下を確実にインストールします。 * build-essentialパッケージ     * Build-Dependsに挙げられているパッケージ (参照「control」)     そして、ソースディレクトリーで次のコマンドを実行します:     $ dpkg-buildpackage -B これは、別のアーキテクチャー上で、アーキテクチャー依存のバイナリ     ーパッケージを生成する作業をすべて行ってくれます。これには以下の 作業が含まれます: * ソースツリーのクリーン (debian/rules clean) * プログラムのビルド (debian/rules build) * アーキテクチャー依存のバイナリーパッケージをビルド(fakeroot     debian/rules binary-arch) * gpg を使用したソース.dscファイルへの署名 * dpkg-genchangesおよびgpgを使用したアップロード用.changesファ イルの生成と署名     あなたのパッケージが他のアーキテクチャー用にも存在するのは、この ためです。 Build-Depends-indepフィールドのパッケージは、通常のパッケージの場 合はインストールを要求されますが (参照「完全な（再）ビルド」)、オ ートビルダーシステムでは、アーキテクチャー依存のパッケージのみを     ビルドするのでこれらのインストールは必須ではありません。^[65] オ ートビルダーを使用した場合と普通のパッケージングとのこの違いによ り、debian/control ファイルの Build-Depends か Build-Depends-indep のどちらにパッケージを記載するかが決定されま す。(参照「control」) 6.3. debuildコマンド     dpkg-buildpackageによるビルドプロセス周辺は、debuildによりさらに 自動化できます。debuild(1)を参照してください。 debuild コマンドは、Debian パッケージをビルドのあと静的チェックを     する lintian コマンドを実行します。lintian コマンドは ~ /.devscripts を用いて以下のようにカスタマイズできます:     DEBUILD_DPKG_BUILDPACKAGE_OPTS="-us -uc -I -i" DEBUILD_LINTIAN_OPTS="-i -I --show-overrides"     以下のようにすれば一般ユーザーアカウントから、簡単にソースをクリ ーンしパッケージを再ビルドできます:     $ debuild     ソースツリーのクリーンも簡単です:     $ debuild -- clean 6.4. pbuilderパッケージ ビルド依存を確認するためのクリーンルーム (chroot) ビルド環境とし て、pbuilder パッケージが非常に便利です。^[66] これを使うことで、     異なるアーキテクチャー向けに sid 環境オートビルダーの下でのソース からのクリーンなビルドが保証され、常に RC (リリースクリティカル) に分類される重要度が serious (深刻)の FTBFS (Fails To Build From Source、ソースからのビルド失敗) バグを防ぎます。^[67]     それでは、pbuilder をカスタマイズしてみましょう: * /var/cache/pbuilder/resultディレクトリーを、ユーザーアカウン トから書き込めるように設定してください。 * フックスクリプトを置くために、ユーザーからの書き込みが可能な ディレクトリーを作成してください。例） /var/cache/pbuilder/     hooks * ~/.pbuilderrc か /etc/pbuilderrc に以下のように設定します。 AUTO_DEBSIGN=${AUTO_DEBSIGN:-no} HOOKDIR=/var/cache/pbuilder/hooks     それでは、ローカルpbuilder の chroot システムを以下のようにして初 期化しましょう:     $ sudo pbuilder create 既に完全なソースパッケージがあれば、foo.orig.tar.gzファイル、foo     .debian.tar.gzファイル、foo.dscファイルが存在するディレクトリーで 、ローカルの pbuilder の chrootシステムをアップデートし、バイナリ ーパッケージをその中でビルドしましょう:     $ sudo pbuilder --update $ sudo pbuilder --build foo_version.dsc     新しくビルドした GPG 署名の無いパッケージは非ルート所有権で /var/ cache/pbuilder/result/ に置かれます。     .dsc ファイルや .changes ファイルへのGPG 署名は次のようにするとで きます:     $ cd /var/cache/pbuilder/result/ $ debsign foo_version_arch.changes 更新されたソースツリーが既にあるが一致するソースパッケージを生成     していない場合は、この代わりに、debian ディレクトリーが存在するデ ィレクトリーで、以下のコマンドを発行します:     $ sudo pbuilder --update $ pdebuild pbuilder --login --save-after-loginコマンドで、chroot環境にログイ     ンし、好きに設定することができます。シェルプロンプトから^D (Control-D)で抜けると、その環境を保存しておくことができます。 最新のlintianコマンドはchroot環境から次のように設定されたフックス     クリプト/var/cache/pbuilder/hooks/B90lintianを使用して実行するこ とができます: ^[68] #!/bin/sh set -e install_packages() { apt-get -y --allow-downgrades install "$@" }     install_packages lintian echo "+++ lintian output +++" su -c "lintian -i -I --show-overrides /tmp/buildd/*.changes" - pbuilder # use this version if you don't want lintian to fail the build #su -c "lintian -i -I --show-overrides /tmp/buildd/*.changes; :" - pbuilder echo "+++ end of lintian output +++" sid 環境向けのパッケージを正しくビルドするには最新の sid 環境が必     要です。sid にはあなたの環境全てを移行するには望ましくない問題を 抱えていることが少なくありません。pbuilder パッケージはそのような 状況への対処の助けとなります。 stable/updatesやstable-proposed-updatesがリリースされた後、stable パッケージのアップデートが必要な場合があります。^[69]そのような場     合に、即座にアップデートしない言い訳として sid を使っているからと いうのは不十分です。pbuilderパッケージは、同じアーキテクチャーの ほぼ全ての Debian 派生であるディストリビューションへのアクセスを 手助けします。     http://www.netfort.gr.jp/~dancer/software/pbuilder.html と pdebuild(1) と pbuilderrc(5) と pbuilder(8) を参照下さい。 6.5. git-buildpackageコマンドとその仲間 アップストリームがソースコード管理システム (VCS) ^[70] を使ってい るのであれば、同様に使用することを考えるべきです。それによって、     マージとアップストリームパッチの取捨選択がより簡単になります。各 VCS 毎に Debian パッケージをビルドするための特別なラッパースクリ プトのパッケージもいくつかあります。 * git-buildpackage: Git リポジトリ内の Debian パッケージの支援 プログラム群です。     * svn-buildpackage: Debian パッケージを Subversion で管理するた めの支援プログラム群です。 * cvs-buildpackage: CVS ソースツリーのための Debian パッケージ スクリプト群です。 Debian デベロッパーが alioth.debian.org 上の Git サーバーを用い     Debian パッケージを管理するのに git-buildpackage を使うことがよく あります。^[71] このパッケージはパッケージ活動を自動化する多くの コマンドを提供します。 * gbp-import-dsc(1): import a previous Debian package to a Git repository. * gbp-import-orig(1): import a new upstream tar to a Git repository.     * gbp-dch(1): generate the Debian changelog from Git commit messages. * git-buildpackage(1): Debian パッケージを Git レポジトリーから ビルドします。 * git-pbuilder(1): Debian パッケージを Git レポジトリーから pbuilder/cowbuilder を持ちいてビルドします。     これらのコマンドはパッケージング活動を追跡する 3 つのブランチを使 用します: * Debian パッケージのソースツリーは、main 。     * アップストリームのソースツリーは、upstream。 * --pristine-tar オプションにより生成されるアップストリームtar アーカイブは、pristine-tar。^[72]     git-buildpackage は ~/.gbp.conf で設定できます。gbp.conf(5) を参 照下さい。 ^[73] 6.6. 部分的な再ビルド 大規模なパッケージの場合には、debian/rules をちょっといじるたびに     、毎回最初からパッケージの再ビルドをやりなおすのは手間です。テス ト目的であれば、以下の方法でアップストリームソースを再ビルドをせ ずに .deb ファイルを生成することができます。 ^[74]:     $ fakeroot debian/rules binary     また、以下の方法を使えば生成可能かどうかをチェックすることができ ます:     $ fakeroot debian/rules build 最終的にきちんとテストが完了したら、正しい手順に従ってパッケージ     を最初から再ビルドすることを忘れないでください。この方法でビルド した .deb ファイルをアップロードしようとしても、おそらくうまくア ップロードできないでしょう。 6.7. コマンド階層 パッケージ作成に用いる多くのコマンドが、コマンド階層の中でお互い     いかなる関係にあるかの簡単なまとめを以下に記します。同じ事をする のに多くの方法があります。 * debian/rules = パッケージビルド用のメンテナースクリプト * dpkg-buildpackage = パッケージビルドツールの核 * debuild = dpkg-buildpackage + lintian (サニタイズした環境変数 下でのビルド) * pbuilder = Debian の chroot 環境ツールの核     * pdebuild = pbuilder + dpkg-buildpackage (chroot 中でビルド) * cowbuilder = pbuilder 実行の加速 * git-pbuilder = pdebuild の使いやすいコマンドラインシンタック ス (gbp buildpackge が使用) * gbp = Debian ソースを git レポ下で管理 * gbp buildpackge = pbuilder + dpkg-buildpackage + gbp gbp buildpackge や pbuilder 等のよりハイレベルなコマンドを用いる     ことは完全なパッケージビルド環境を保証しますが、debian/rules や dpkg-buildpackage 等のよりローレベルのコマンドがそれらの下で実行 されるかを理解することは必須です。 --------------------------------------------------------------------- ^[62] GPG キーは信頼の網に連結するように Debian デベロッパーによ って署名され、the Debian keyring に登録されていなければいけません     。こうすることで Debian アーカイブにパッケージをアップロードして 受け付けられるようになります。Creating a new GPG key と Debian Wiki on Keysigning を参照下さい。 ^[63] 3.0 (quilt)ソースフォーマットでquiltパッチを当てないように     するには、上記コマンドに--skip-patchesオプションをつけて実行しま す。または、通常の操作の後に、quilt pop -aを実行する方法もありま す。 ^[64] 実際のオートビルダーシステムは、本稿の説明よりもかなり複雑     なスキームによって実現しています。それらの詳細は、本稿の範囲を超 えるため割愛します。 ^[65] pbuilderパッケージとは違い、オートビルダーによって使用され     るsbuildパッケージ下でのchroot環境では、最小システムを強制しない ので、多くのパッケージがインストールされたままになるかもしれませ ん。     ^[66] pbuilderパッケージはまだ進化の過程なので、実際の構成は、最 新の公式ドキュメントで確認して下さい。     ^[67] Debian パッケージのオートビルドに関しては http:// buildd.debian.org/ を参照下さい。 ^[68] HOOKDIR=/var/cache/pbuilder/hooks をここで仮定しています。     フックスクリプトのサンプルは /usr/share/doc/pbuilder/examples デ ィレクトリーににあります。     ^[69] stable パッケージのそのようなアップデートには制限が課せられ ます。     ^[70] 詳しくは Version control systems を参照下さい。     ^[71] alioth.debian.org サービスの使い方は、Debian wiki Alioth に 記載されています。 ^[72] --pristine-tar オプションは、小さなバイナリデルタと通常 VCS     の upstream ブランチ中に保存された tar アーカイブの内容のみを用い 完全に元通りの手付かずの tar アーカイブを再生成する pristine-tar コマンドを起動します。     ^[73] 以下は、上級者のみなさんの参考になるウェブ上で閲覧できる資 料です。 * git-buildpackage を使っての Debian パッケージ作成 (/usr/share /doc/git-buildpackage/manual-html/gbp.html)     * debian packages in git * Using Git for Debian Packaging * git-dpm: Debian packages in Git manager ^[74] その場合は、通常だと正しく設定される環境変数は設定されませ     ん。アップロード用のパッケージはこの簡易メソッドで生成しないでく ださい。 第7章パッケージのエラーの検証 最新の内容とより実用的な例でこの入門書を書き換えたものが Guide     for Debian Maintainers として入手できます。この新しい入門書を第一 次的な入門書として使ってください。 ここでは, 公式アーカイブにパッケージをアップロードする前に、作成     したパッケージのエラーをあなた自身で確認するために知っておかなけ ればならない方法について、幾つか述べます。 あなたのマシン以外でのテストもまた良いアイデアです。以下に述べる     すべてのテストにおける、どんな警告とエラーについてでもしっかりと 確認しておかなければなりません。 7.1. 怪しげな変更 あなたの 3.0 (quilt) フォーマットのノンネイティブ Debian パッケー ジをビルドした後で、debian/patches ディレクトリー内に debian-changes-* のような新規の自動生成されたパッチファイルを見つ けた場合。何かの間違いで何らかのファイルを変更したか、ビルドスク     リプトがアップストリームソースに変更を加えた可能性が大いにありま す。あなたの間違いなら、それを修正しましょう。ビルドスクリプトが 引き起こした場合は、「rules ファイルのカスタマイズ」にあるように dh-autoreconf を使って根本原因を修正するか、「source/options」に あるように source/options を使って回避策をとります。 7.2. インストールに対するパッケージの検証 あなたのパッケージが問題なくインストールできるかどうかをテストし     なければなりません。debi(1) コマンドはあなたが作成した全てのバイ ナリーパッケージのインストールテストに役立ちます。     $ sudo debi gentoo_0.9.12-1_i386.changes 別のシステムでインストール時に問題が起きるのを防ぐために、Debian アーカイブよりダウンロードした Contents-i386 ファイルを用いて、他 の既存のパッケージと重複するファイルがないことを確認しておかなけ ればなりません。apt-file コマンドはこの作業において恐らく役に立つ     でしょう。重複するファイルが存在するならば、実際に問題になること を回避するために、ファイルをリネームするか、複数のパッケージが依 存する独立のパッケージに共通ファイルを移動するか、他の影響のある パッケージと調整しながら alternatives (update-alternatives(1) 参 照)を用いるか、debian/controlに Conflicts 項目を宣言して下さい。 7.3. パッケージのメンテナースクリプトの検証 全てのメンテナースクリプト (preinst、prerm、postinst そして postrm ファイルのこと) は、それが debhelperプログラムで自動生成さ     れたのでない場合は、正しく書くことが非常に困難です。だからあなた が新米メンテナーならばこれらは使わないで下さい (「{pre,post} {inst,rm}」参照)。 パッケージがこれらの重要なメンテナースクリプトを使用するならば、 インストールだけではなく、削除、完全削除 (purge)、そしてアップグ     レードについても確実にテストしましょう。多くのメンテナースクリプ トのバグは削除もしくは完全削除の場合に発生します。これらのテスト のためには、以下の様に dpkg コマンドを実行します: $ sudo dpkg -r gentoo     $ sudo dpkg -P gentoo $ sudo dpkg -i gentoo_version-revision_i386.deb     以下のような順番で実行すべきでしょう: * (可能な場合は)前回バージョンをインストールします。 * 旧バージョンからアップグレードします。 * 旧バージョンになるよう、ダウングレードします (オプション)。 * 完全削除 (purge) します。     * 新しいパッケージとしてインストールします。 * 削除します。 * もう一度インストールします。 * 完全削除 (purge) します。 これが最初に作成したパッケージならば、将来発生するかもしれない問     題を防ぐために、異なるバージョンのダミーパッケージを作成すべきで す。 あなたのパッケージが過去の Debian にてリリースされていた場合には 、人々は大抵最新の Debian のリリース版に含まれているバージョンか     らパッケージのアップグレードをするであろう、ということに配慮しま しょう。上記の手順で、そのバージョンからきちんとアップグレードで きることを、忘れずに確認しておいてください。     ダウングレードは公式にはサポートされていませんが、これをサポート するのは友好的な態度です。 7.4. Using lintian lintian(1) を .changes に対して実行しましょう。lintian コマンドは     パッケージ作成時のよくある間違いをチェックするために多くのテスト スクリプトを実行します。^[75]     $ lintian -i -I --show-overrides gentoo_0.9.12-1_i386.changes もちろん、.changes のファイル名はあなたが作成したパッケージに置き     換えて下さい。lintian コマンドの出力は以下のようにマークされてい ます: * E: はエラーです。確実にポリシー違反もしくはパッケージエラーで す。 * W: は警告です。ポリシー違反もしくはパッケージングエラーである 可能性があります。     * I: は参考情報です。パッケージのとある性質について参考となる情 報を提供します。 * N: は覚書です。デバッグに有用な情報を詳述します。 * O: はオーバーライド通知です。 lintian-overrides ファイルによ りメッセージがオーバーライドされたメッセージです。これは --show-overrides オプションを指定した際に表示されます。 警告が出た場合には、パッケージを調整するか、その警告が不当である     ことを確認して下さい。もし警告が不当である場合には「{package .,source/}lintian-overrides」で述べた lintian-overrides を作成し て下さい。 dpkg-buildpackage によるパッケージの生成と lintian の実行は、     debuild(1) コマンド、もしくは pdebuild(1) コマンドを用いれば一気 に実行することができます。 7.5. debc コマンド     debc(1) コマンドを用いるとバイナリーパッケージに含まれるファイル の一覧が得られます。     $ debc package.changes 7.6. debdiff コマンド     debdiff(1) コマンドを用いると、二つのソースパッケージに含まれてい るファイルを比較することができます。     $ debdiff old-package.dsc new-package.dsc     debdiff(1) コマンドは二つのバイナリーパッケージに含まれるファイル の一覧を比較することもできます。     $ debdiff old-package.changes new-package.changes これらのコマンドは、ソースパッケージ中でどんな変更をしたのか、バ     イナリーパッケージの中で意図せず削除したり配置を間違えたりしてい ないか、そしてバイナリーパッケージの更新時に不用意な変更をしてい ないかどうか、といった事柄を確認するのに便利です。 7.7. interdiff コマンド interdiff(1) コマンドを用いると、二つの .diff.gz ファイルを比較す     ることができます。旧来の 1.0 ソース形式でパッケージを更新している 場合には、メンテナーがソースに意図しない変更をしていないことを確 認するのに便利です。     $ interdiff -z old-package.diff.gz new-package.diff.gz 新規の 3.0 ソースフォーマットは「patches/*」で説明したように複数     のパッチファイル中に変更を保存します。各々の debian/patches/* フ ァイルの変化も interdiff を使って追いかけられます。 7.8. mc コマンド mc(1) の様に、*.debパッケージファイルだけではなく、*.udev,     *.debian.tar.gz, *.diff.gz, *.orig.tar.gz の中身を閲覧することが できるファイルマネージャを用いると、多くのファイルの検査が直感的 に行なえます。 不要なファイルやサイズがゼロのファイルがバイナリーパッケージとソ     ースパッケージに含まれていないことをよく確認して下さい。大抵は不 要なファイルが正しく削除されずに残ってしまっています。rules を調 整しこれを修正して下さい。 --------------------------------------------------------------------- ^[75] /etc/devscripts.conf や ~/.devscripts において「debuildコマ     ンド」で述べた設定をしている場合には、lintian に -i -I --show-overrides オプションを指定する必要はありません。 第8章パッケージの更新 最新の内容とより実用的な例でこの入門書を書き換えたものが Guide     for Debian Maintainers として入手できます。この新しい入門書を第一 次的な入門書として使ってください。     パッケージをリリースしたなら、すぐにそれを更新する必要があります 。 8.1. Debian リビジョンの更新 例えば仮に、#654321 という番号のバグレポートがあなたのパッケージ     に対してファイルされ、解決可能な問題が記述されていたとしましょう 。パッケージの新しい Debian リビジョンを作成するには、以下を実行 する必要があります: * もしこれが新規のパッチとして記録される場合には、以下のように します: + dquilt new bugname.patch としてパッチ名を設定します。 + dquilt add buggy-file として変更されるファイルを宣言しま す。 + アップストリームバグに関してパッケージソース中の問題を修 正します。 + dquilt refresh として bugname.patch に記録します。 + dquilt header -e としてその内容記述を追加します。 * もし既存のパッチをアップデートする場合には、以下のようにしま す: + dquilt pop foo.patch として既存の foo.patch を呼び出しま す。 + 古い foo.patch 中の問題を修正します。 + dquilt refresh として foo.patch を更新します。 + dquilt header -e としてその内容記述を更新します。 + while dquilt push; do dquilt refresh; done として fuzz を     削除しながら全てのパッチを適用します。 * 次に Debian changelog ファイルの先頭に新しいリビジョンを追加 します。例えばdch -iを実行するか、またはバージョンを明示した い場合ならdch -v version-revision を実行してあなたの好きなエ ディタで説明を記入すると楽にできます。^[76] * changelog の説明行に、このリビジョンで解決されたバグと、その 解決方法についての簡単な説明を記載し、Closes: #54321 と続けて おきます。これによってあなたのパッケージが Debian アーカイブ 中に受け入れられた時、アーカイブ管理ソフトウェアによって該当 するバグレポートが魔法のように自動的に閉じられます。 * 上記であなたがしたことを繰り返し、必要に応じて Debian changelog ファイルを dch で更新しながら、更なるバグ修正を行い ます。 * 「完全な（再）ビルド」と 7章パッケージのエラーの検証で行った ことを繰り返して下さい。 * 一旦満足した時点で、changelog 中のディストリビューション値を UNRELEASED からターゲットディストリビューション値 unstable (もしくは場合に依っては experimental) へと変更すべきです。^ [77] * 9章パッケージをアップロードすると同様にパッケージをアップロー ドします。今までと違うのは、今回の場合オリジナルソースアーカ イブには変更が無く、同じものが既に Debian アーカイブ中に存在 しているため、アップロードするファイルにはオリジナルのソース アーカイブが含まれないという点だけです。 例えばオフィシャルのアーカイブへ 1.0.1-1 のようなノーマルのバージ ョンをアップロードする前にパッケージングを色々試すべくローカルパ ッケージを作る時には要注意です。スムースなアップグレードのために     は、1.0.1-1~rc1 のような文字列のバージョンの項目をchangelog に作 るのがいい考えです。オフィシャルパッケージのためには、そのような ローカル変更の複数項目を単一の項目にまとめて changelog をすっきり させてもいいです。バージョン文字列の順序に関しては「パッケージ名 とバージョン」を参照下さい。     8.2. 新規のアップストリームリリースの検査 Debian アーカイブ用の新しいアップストリームリリースパッケージの準     備をする際は、まず、新アップストリームリリースをチェックしなけれ ばなりません。     アップストリームの changelog や NEWS、その他の新しいバージョンで リリースされたドキュメントを読むことから始めてください     以下のようにすれば何かおかしな事が無いかに注意を払いつつ新旧のア ップストリームソース間の変更検査ができます:     $ diff -urN foo-oldversion foo-newversion missing や aclocal.m4 や config.guess や config.h.in や config.sub や configure や depcomp や install-sh や ltmain.sh や     Makefile.in 等の Autotools によって自動生成されるファイルへの変更 は無視していい場合があります。ソースを検査するための diff を実行 する前に消去してもいいです。 8.3. アップストリームソフトウェアの新版更新 もし foo パッケージが新規の 3.0 (native) や 3.0 (quilt) フォーマ ットで適正にパッケージされていれば、新規のアップストリームバージ     ョンをパッケージするのは基本的に旧 debian ディレクトリーを新規ソ ースへと移動するのみです。これは新規に展開されたソース中で tar xvzf /path/to/foo_oldversion.debian.tar.gz を実行すれば出来ます。 ^[78] もちろん当然するべき細々としたことをする必要はあります: * アップストリームソースのコピーを foo_newversion.orig.tar.gz ファイルとして作成します。 * Debian の changelog ファイルを dch -v newversion-1 を使って更 新します。 + New upstream release という項目を追加します。     + 報告のあったバグを修正する新規アップストリームリリース中 の変更点に関して簡潔に記載しバグを Closes: #バグ番号と追 記してクローズします。 + 報告のあったバグを修正する、メンテナーによる新規アップス トリームリリースへの変更点に関して簡潔に記載しバグを Closes: #バグ番号と追記しクローズします。 * while dquilt push; do dquilt refresh; done として fuzz を削除 しながら全てのパッチを適用します。     もしパッチやマージがクリーンに適用できない場合は、状況を精査しま す (.rej ファイル中にヒントがあります)。 * もしソースにあなたが適用していたパッチがアップストリームソー スに統合された場合は、 + dquilt delete として削除します。 * もしソースにあなたが適用していたパッチが新規アップストリーム ソースとぶつかる場合は、     + dquilt push -f として baz.rej としてリジェクトを強制しな がら古いパッチを適用します。 + baz.rej の本来目指した効果を実現するように、baz ファイル を手動で編集します。 + dquilt refresh としてパッチを更新します。 * while dquilt push; do dquilt refresh; done まで戻り継続します 。     このプロセスは uupdate(1) コマンドを以下のように使うことで自動化 できます: $ apt-get source foo ... dpkg-source: info: extracting foo in foo-oldversion dpkg-source: info: unpacking foo_oldversion.orig.tar.gz dpkg-source: info: applying foo_oldversion-1.debian.tar.gz $ ls -F foo-oldversion/ foo_oldversion-1.debian.tar.gz     foo_oldversion-1.dsc foo_oldversion.orig.tar.gz $ wget http://example.org/foo/foo-newversion.tar.gz $ cd foo-oldversion $ uupdate -v newversion ../foo-newversion.tar.gz $ cd ../foo-newversion $ while dquilt push; do dquilt refresh; done $ dch ... document changes made debian/watch ファイルを「watch」に記載されたように設定していれば 、 wget コマンドをスキップすることが出来ます。foo-oldversion ディ     レクトリー中で uupdate コマンドを実行する代わりに、単に uscan(1) コマンドを実行します。こうすると魔法のように更新されたソースを見 つけ、それをダウンロードし、uupdate コマンドを実行します。^[79] 今まで「完全な（再）ビルド」、 7章パッケージのエラーの検証、9章パ     ッケージをアップロードするの中で実行してきたことを繰り返し、更新 したソースをリリースできます。 8.4. パッケージ化スタイルの更新 パッケージスタイルの更新はパッケージ更新のために必須活動ではあり     ません。しかし、こうすることで最新の debhelper システムと 3.0 ソ ースフォーマットの全能力を活用できます。^[80] * もし何らかの理由で消去されたテンプレートファイルを追加する必 要がある場合には、同一の Debian ソースツリーの中で --addmissing オプションとともに dh_make をもう一度実行しても いいです。そして、それらを適正に編集しましょう。 * debian/rules ファイルに関して debhelper v7+ dh シンタックスへ とパッケージが更新されていない場合は dh を使うように更新しま しょう。debian/control ファイルもそれに合わせて変更しましょう 。 * コモン Debian ビルドシステム (cdbs) による Makefile 包含メカ ニズムで生成された rules ファイルを dh シンタックスに更新しよ うとする場合には、以下を参照し DEB_* 設定変数を理解して下さい 。 + /usr/share/doc/cdbs/cdbs-doc.pdf.gz のローカルコピー + The Common Debian Build System (CDBS), FOSDEM 2009 * foo.diff.gz ファイル無しの 1.0 ソースパッケージの場合、3.0     (native) と言う内容の debian/source/format を作成することで新 規の 3.0 (native) ソースフォーマットに更新できます。残りの debian/* ファイルは単にコピーするだけです。 * foo.diff.gz ファイルありの 1.0 ソースパッケージの場合、3.0 (quilt) と言う内容の debian/source/format を作成することで新 規の 3.0 (quilt) ソースフォーマットに更新できます。残りの debian/* ファイルは単にコピーするだけです。必要な場合、 filterdiff -z -x '*/debian/*' foo.diff.gz > big.diff コマンド により生成される big.diff ファイルをあなたの quilt システムに インポートします。^[81] * -p0 や -p1 や -p2 を使う dpatch や dbs や cdbs のような他のパ ッチシステムを用いてパッケージされ得ている場合には、http:// bugs.debian.org/581186にある deb3 を用いて quilt コマンドに変 換します。 * もし --with quilt オプション付きの dh コマンドとか、 dh_quilt_patch と dh_quilt_unpatch コマンドを用いてパッケージ されている場合には、これらを削除し新規の 3.0 (quilt) ソースフ ォーマットを使うようにします。     DEP - Debian エンハンスメント提案を確認し、ACCEPTED (採用) となっ た提案を取り入れるべきです。     「アップストリームソフトウェアの新版更新」に記載された他の作業も 行う必要があります。 8.5. UTF-8 変換     アップストリームの文書が旧来のエンコーディング法にてエンコードさ れている場合には、それらを UTF-8 に変換するのはいいことです。 * iconv(1) を使いプレインテキストのエンコーディングを変換します 。 iconv -f latin1 -t utf8 foo_in.txt > foo_out.txt     * w3m(1) を使用して HTML ファイルを UTF-8 のプレインテキストフ ァイルに変換します。これを行う際には、必ず UTF-8 ロケールで実 行して下さい。 LC_ALL=en_US.UTF-8 w3m -o display_charset=UTF-8 \ -cols 70 -dump -no-graph -T text/html \ < foo_in.html > foo_out.txt 8.6. パッケージをアップグレードする際の注意点     パッケージをアップグレードする際の注意点は以下です: * changelog の旧項目を保全します (自明ですが、dch -i とするべき 時に dch とした過去事例があります。) * 現存の Debian による変更は再評価する必要があります。(何らかの 形で)アップストリームが組み込んだことは捨て、アップストリーム が組み込まなかったことは残しましょう。 * ビルドシステムに変更が加えられた場合には (アップストリームの 変更を精査した際に分かっているはずですよね)、必要に応じて     debian/rules と debian/control のビルド依存関係を更新します。 * 現存もオープンのバグへのパッチを誰かが提供していないかを、 Debian Bug Tracking System (BTS) で確認します。 * 正しいディストリビューションへアップロードすること、 Closes フィールドに適切なバグのクローズがリストされていること、 Maintainer と Changed-By フィールドがマッチしていること、ファ イルが GPG 署名されていること等を確実にするように、.changes ファイルの内容を確認します。 ---------------------------------------------------------------------     ^[76] 日付を要求されるフォーマットで入力するには、LANG=C date -R を使います。     ^[77] もし dch -r コマンドを使ってこの最終変更をする場合には、エ ディターにより changelog ファイルを明示的に保存して下さい。 ^[78] もしパッケージ foo が旧 1.0 フォーマットでパッケージされて     いる場合は、新規に展開されたソース中で zcat /path/to/foo_ oldversion.diff.gz|patch -p1 を実行すれば出来ます。 ^[79] もし uscan コマンドが更新されたソースはダウンロードするが     uupdate コマンドを実行しない場合には、URLの最後に debian uupdate となるように debian/watch ファイルを修正するべきです。 ^[80] もしあなたのスポンサーや他のメンテナーが既存のパッケージス     タイル更新に異存がある場合には、更新することもまたその議論するこ とは意味がありません。他にするべきより重要なことがあります。     ^[81] splitdiff コマンドを用いると big.diff は多くの小さな増分パ ッチに分割できます。 第9章パッケージをアップロードする 最新の内容とより実用的な例でこの入門書を書き換えたものが Guide     for Debian Maintainers として入手できます。この新しい入門書を第一 次的な入門書として使ってください。     Debian now requires source-only uploads for normal upload. So this page is outdated.     あなたの新しいパッケージは徹底的にテストできたので、あなたはそれ を共有すべく公開アーカイブにリリースしたいでしょう。 9.1. Debian アーカイブへアップロードする 正規デベロッパー^[82]になると、パッケージを Debian アーカイブにア     ップロードできます。^[83] 手動でもできますが、 dupload(1) や dput (1) 等の既存の自動化ツールを用いる方が楽です。ここでは dupload を 使ってどうするかを説明します。^[84] まず dupload の設定ファイルを調整しなければいけません。システム全     体の設定ファイルである /etc/dupload.conf を編集するか、あるいはあ なた専用の設定ファイルである ~/.dupload.conf を使って変更したい項 目だけをオーバーライドさせてもかまいません。     またそれぞれのオプションが持つ意味を理解するため dupload.conf(5) マニュアルページを読むことができます。 $default_host オプションはデフォルトで利用されるアップロードキュ     ーを指定します。anonymous-ftp-masterがメインのアップロードキュー ですが、別のアップロードキューを利用したいこともあるでしょう。^ [85]     インターネットにつながった状態で、以下のようにすればあなたのパッ ケージをアップロード出来ます:     $ dupload gentoo_0.9.12-1_i386.changes dupload は各ファイルの SHA1/SHA256 チェックサムを計算し、     .changes ファイルの中の情報と照合します。もしそれらが一致しない場 合には、適正にアップロードされるように「完全な（再）ビルド」の説 明に従って最初から再ビルドをするよう警告します。 ftp://ftp.upload.debian.org/pub/UploadQueue/へのアップロードで問     題があった場合には、GPG 署名した *.commands ファイルを ftp を用い てftpで手動アップロードすることで修正出来ます。 ^[86] 例えば、 hello.commands を使います: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Uploader: Foo Bar Commands: rm hello_1.0-1_i386.deb     mv hello_1.0-1.dsx hello_1.0-1.dsc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) [...] -----END PGP SIGNATURE----- 9.2. アップロード用orig.tar.gzの内容 はじめてパッケージをアーカイブにアップロードする際は、オリジナル     のorig.tar.gz ソースファイルを含めなければなりません。当該パッケ ージの Debian リビジョン番号が 1 でも 0 でも無い場合には、 dpkg-buildpackage に -sa オプションを付けなければなりません。     dpkg-buildpackage コマンドの場合:     $ dpkg-buildpackage -sa     debuildコマンドの場合:     $ debuild -sa     debuildコマンドの場合:     $ pdebuild --debbuildopts -sa     逆に、-sdオプションを付けると、オリジナルのorig.tar.gz ソースファ イルを強制的に除外します。 9.3. スキップされたアップロード アップロードをスキップすることで debian/changelog 中に複数の項目 を作成した場合は、前回アップロード以来の全ての変更を含む適切な     *_.changes ファイルを作成しなければいけません。 dpkg-buildpackage オプションの -v を、例えば 1.2 と言うバージョンに関して指定すると 可能です。     dpkg-buildpackage コマンドの場合:     $ dpkg-buildpackage -v1.2     debuildコマンドの場合:     $ debuild -v1.2     debuildコマンドの場合:     $ pdebuild --debbuildopts "-v1.2" ---------------------------------------------------------------------     ^[82] 「Debianにおける社会ダイナミクス」を参照下さい。 ^[83] Debian アーカイブとほぼ同様に機能し、非-DD に対してアップロ ードエリアを提供する http://mentors.debian.net/ のような公開アー     カイブがあります。http://wiki.debian.org/ HowToSetupADebianRepository に列記されているツールを使い自分自身 で同様のアーカイブを設定することも出来ます。だからこのセクション は非-DD にも有用です。 ^[84] dput パッケージは、より多くの機能があり dupload パッケージ     より人気が出てきています。それは、/etc/dput ファイルをグローバル 設定に用い、 ~/.dput.cf ファイルをユーザー毎の設定に用います。更 にそれは、そのままUbuntu関連のサービスもサポートします。     ^[85] Debian Developer's Reference 5.6, "Uploading a package" を 参照下さい。 ^[86] ftp://ftp.upload.debian.org/pub/UploadQueue/README を参照下     さい。dput パッケージ中にある dcut コマンドをこれに代わる方法とし て用いることもできます。 付録A 上級パッケージング 最新の内容とより実用的な例でこの入門書を書き換えたものが Guide     for Debian Maintainers として入手できます。この新しい入門書を第一 次的な入門書として使ってください。 あなたが出会いそうな上級パッケージング課題に関するヒントや外部参     照をいくつか記します。ここに提案されたレファレンス全てに目を通す ことを切にお薦めします。 本章で取り上げたトピックをカバーするには dh_make コマンドで生成さ     れたパッケージ用テンプレートファイルではマニュアル編集する必要が あるかもしれません。より新しい debmake コマンドはこのようなトピッ クへの対応が優れています。 A.1. 共有ライブラリー     共有ライブラリーをパッケージングする前に、以下の一次レファレンス を詳細に読むべきです: * Debian Policy Manual, 8 "Shared libraries"     * Debian Policy Manual, 9.1.1 "File System Structure" * Debian Policy Manual, 10.2 "Libraries"     以下はあなたが手を付け始めるための少々簡略化しすぎたヒントです: * 共有ライブラリーとはコンパイルされたコードを含む ELF オブジェ クトファイルです。 * 共有ライブラリーは *.so ファイルとして頒布されます。(*.a ファ イルでも *.la ファイルでもありません) * 主に、共有ライブラリーは ld メカニズムを用い複数の実行プログ ラム間でコードを共有するのに使用されます。 * 時々、共有ライブラリーは dlopen メカニズムを用いある実行プロ グラムに複数のプラグインを提供するのに使用されます。 * 共有ライブラリーは変数や関数やクラスのようなコンパイルされた オブジェクトを表すシンボルをエキスポートし、リンクされた実行 プログラムからそれらへのアクセスを可能とします。 * 共有ライブラリー libfoo.so.1 の SONAME: objdump -p libfoo.so. 1 | grep SONAME ^[87] * 共有ライブラリーの SONAME は通常ライブラリーのファイル名と一 致します(例外もあります)。     * /usr/bin/foo にリンクされた共有ライブラリーの SONAME: objdump -p /usr/bin/foo | grep NEEDED ^[88] * libfoo1: 共有ライブラリー libfoo.so.1 で SONAME ABI バージョ ンが 1 のライブラリーパッケージ。^[89] * ライブラリーパッケージのパッケージメンテナースクリプトは SONAME に必要なシンボリックリンクを作成するために特定の環境下 で ldconfig を呼ばなければいけません。^[90] * libfoo1-dbg: 共有ライブラリー libfoo1 のデバッグシンボルを含 むデバッグシンボルパッケージ。 * libfoo-dev: 共有ライブラリー libfoo.so.1 用のヘッダーファイル 他を含む開発用パッケージ。^[91] * Debian パッケージは一般的に *.la Libtool アーカイブファイルを 含んではいけません。^[92] * Debian パッケージは一般的に RPATH を使うべきではありません。^ [93] * 少々内容が古くなった二次的なレファレンスですが、Debian Library Packaging Guide はまだ有用かもしれません。 A.2. debian/package.symbols の管理 共有ライブラリーをパッケージする際には、同一共有ライブラリーパッ ケージ名のライブラリーの同一 SONAME の下での後方互換性のある変更     に関して、各シンボルと関連付けられる最小のバージョンが記された debian/package.symbols ファイルを作成すべきです。^[94] 以下の一次 的レファレンスを詳細に読むべきです: * Debian Policy Manual, 8.6.3 "The symbols system"^[95] * dh_makeshlibs(1)     * dpkg-gensymbols(1) * dpkg-shlibdeps(1) * deb-symbols(5) 過去バージョン 1.3 のアップストリームバージョンから適切な debian/     libfoo1.symbols ファイルを用いて libfoo1 パッケージを作成する概略 例は以下です: * アップストリームの libfoo-1.3.tar.gz ファイルを用いてDebian 化し たソースツリーの骨子を準備します。 + もし libfoo1 パッケージの最初のパッケージングの場合は、内容が 空の debian/libfoo1.symbols ファイルを作成します。 + もし以前のアップストリームバージョン 1.2 が libfoo1 パッケー ジとして適切な debian/libfoo1.symbols を用いてパッケージされ ていた場合には、それを再び使いましょう。 + もし過去のアップストリームバージョン 1.2 が debian/ libfoo1.symbols を用いてパッケージされていない場合には、その ライブラリーの同一 SONAME を含む同一共有ライブラリーパッケー ジ名の全ての手に入るバイナリーパッケージ、例えば 1.1-1 と 1.2-1 バージョンから、それを symbols として生成できます。^ [96] $ dpkg-deb -x libfoo1_1.1-1.deb libfoo1_1.1-1 $ dpkg-deb -x libfoo1_1.2-1.deb libfoo1_1.2-1 $ : > symbols $ dpkg-gensymbols -v1.1 -plibfoo1 -Plibfoo1_1.1-1 -Osymbols $ dpkg-gensymbols -v1.2 -plibfoo1 -Plibfoo1_1.2-1 -Osymbols * debuild や pdebuild 等のツールを使ってソースツリーのテストビルド をします。 (もしシンボルの欠如等でビルドがうまく行かない場合には 、共有ライブラリーパッケージ名を libfoo1a 等と繰り上げる必要のあ る何らかの後方非互換な ABI 変更があったので、最初からやり直す必要 があります。) $ cd libfoo-1.3     $ debuild ... dpkg-gensymbols: warning: some new symbols appeared in the symbols file: ... see diff output below --- debian/libfoo1.symbols (libfoo1_1.3-1_amd64) +++ dpkg-gensymbolsFE5gzx 2012-11-11 02:24:53.609667389 +0900 @@ -127,6 +127,7 @@ foo_get_name@Base 1.1 foo_get_longname@Base 1.2 foo_get_type@Base 1.1 + foo_get_longtype@Base 1.3-1 foo_get_symbol@Base 1.1 foo_get_rank@Base 1.1 foo_new@Base 1.1 ... * もし上記のように dpkg-gensymbols によって diff がプリントされるの を発見した場合には、生成された共有ライブラリーのバイナリーパッケ ージから適切な symbols ファイルを抽出しましょう。^[97] $ cd .. $ dpkg-deb -R libfoo1_1.3_amd64.deb libfoo1-tmp $ sed -e 's/1\.3-1/1\.3/' libfoo1-tmp/DEBIAN/symbols \ >libfoo-1.3/debian/libfoo1.symbols * debuild や pdebuild のようなツールでリリースパッケージをビルドし ます。 $ cd libfoo-1.3 $ debuild -- clean $ debuild ...     上記の例に加えて、更に ABI 互換性を確認し、必要に応じていくつかの シンボルのバージョンを手作業で繰り上げる必要があります。^[98]     二次的なレファレンスではありますが、Debian wiki UsingSymbolsFiles とそこからリンクされているウェブページは有用かもしれません。 A.3. マルチアーチ Debian wheezy で導入されたマルチアーチ機能は dpkg と apt の中での     バイナリーパッケージのアーキテクチャー間サポート (他の組み合わせ もありますが、特にi386<->amd64) を統合します。以下のレファレンス を詳細に読んで下さい: * Ubuntu wiki MultiarchSpec (アップストリーム)     * Debian wiki Multiarch/Implementation (Debian の状況) マルチアーチは共有ライブラリーのインストールパスに i386-linux-gnu や x86_64-linux-gnu 等のトリプレットを使います。実際のトリプレッ     トパスは、ビルドごとに dpkg-architecture(1) によって動的に $ (DEB_HOST_MULTIARCH) 値として設定されます。例えば、マルチアーチラ イブラリーをインストールするパスは以下のように変更されます: ^[99] +-------------------------------------------------------------+ | 旧パス | i386 マルチアーチパス | amd64 マルチアーチパス |     |---------+------------------------+--------------------------| |/lib/ |/lib/i386-linux-gnu/ |/lib/x86_64-linux-gnu/ | |---------+------------------------+--------------------------| |/usr/lib/|/usr/lib/i386-linux-gnu/|/usr/lib/x86_64-linux-gnu/| +-------------------------------------------------------------+     以下の場合に関する典型的なパッケージ分割シナリオの例を示します。 * ライブラリーソース libfoo-1.tar.gz     * コンパイラー用の言語で書かれたツールのソース bar-1.tar.gz * インタープリター用言語で書かれたツールのソース baz-1.tar.gz +---------------------------------------------------------------+ | パッケージ |Architecture:|Multi-Arch:| パッケージ内容 | |------------+-------------+-----------+------------------------| |libfoo1 |any |same |共有ライブラリー、同時イ| | | | |ンストール可能 | |------------+-------------+-----------+------------------------| | | | |共有ライブラリーデバッグ| |libfoo1-dbg |any |same |シンボル、同時インストー| | | | |ル可能 | |------------+-------------+-----------+------------------------| | | | |共有ライブラリーヘッダー| |libfoo-dev |any |same |ファイル他、同時インスト| | | | |ール可能 | |------------+-------------+-----------+------------------------|     |libfoo-tools|any |foreign |実行時サポートプログラム| | | | |、同時インストール不可 | |------------+-------------+-----------+------------------------| |libfoo-doc |all |foreign |共有ライブラリーのドキュ| | | | |メンテーションファイル | |------------+-------------+-----------+------------------------| | | | |コンパイルされ実行される| |bar |any |foreign |プログラムファイル、同時| | | | |インストール不可 | |------------+-------------+-----------+------------------------| |bar-doc |all |foreign |プログラムのドキュメンテ| | | | |ーションファイル | |------------+-------------+-----------+------------------------| |baz |all |foreign |インタープリターで実行さ| | | | |れるプログラムファイル | +---------------------------------------------------------------+ 開発パッケージは関連した共有ライブラリーへのバージョン番号無しの     シンボリックリンクを含んでいるべきです。例えば: /usr/lib/ x86_64-linux-gnu/libfoo.so -> libfoo.so.1 A.4. 共有ライブラリーパッケージのビルド     dh(1) を以下のように使えばマルチアーチをサポートするようにして Debian のライブラリーパッケージをビルドできます: * debian/control を更新します。 + ソースパッケージセクションに Build-Depends: debhelper (>=10) を追加します。 + 共有ライブラリーのバイナリーパッケージごとに Pre-Depends: $ {misc:Pre-Depends} を追加します。 + Multi-Arch: スタンザを各バイナリーパッケージセクション毎に追 加します。 * debian/compat を "10" と設定します。 * すべてのパッケージングスクリプトに関して、通常の /usr/lib/ から、 マルチアーチの /usr/lib/$(DEB_HOST_MULTIARCH)/ へとパスを調整しま す。 + 最初に debian/rules 中で DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH) を呼び     DEB_HOST_MULTIARCH 変数を設定します。 + debian/rules 中の /usr/lib/ を /usr/lib/$(DEB_HOST_MULTIARCH) / で置き換えます。 + もし debian/rules 中の override_dh_auto_configure ターゲット の一部分として ./configure が用いられている場合には、それを dh_auto_configure -- と置き換えるようにしましょう。^[100] + debian/foo.install ファイル中にある全ての /usr/lib/ を /usr/ lib/*/ で置き換えます。 + debian/rules 中の override_dh_auto_configure ターゲットにスク リプトを追加し debian/foo.links.in から debian/foo.links を動 的に生成します。 override_dh_auto_configure: dh_auto_configure sed 's/@DEB_HOST_MULTIARCH@/$(DEB_HOST_MULTIARCH)/g' \ debian/foo.links.in > debian/foo.links     共有ライブラリーパッケージが期待されるファイルのみを含み、-dev パ ッケージも依然として動作することを確認しましょう。 マルチアーチパッケージとして同時に同一パスにインストールされる全     てのファイルはファイルの内容が完全に同じあるべきです。データのバ イトオーダーや圧縮アルゴリズムにより生成される相違に注意すべきで す。 A.5. ネイティブ Debian パッケージ もしパッケージが Debian のためだけとか、またローカル使用のために     保守されている場合、そのソースファイルは debian/* ファイルすべて をその中に含まれます。それをパッケージするのには2つの方法がありま す。 debian/* ファイルを除外したアップストリームターボールを作成し、「     Debian パッケージビルドのワークフロー」にあるようにしてノンネイテ ィブ Debian パッケージできます。これが一部の人に推奨される通常の 方法です。     この代わりの方法は、ネイティブ Debian パッケージのワークフローで す。 * 全てのファイルが含まれる単一の圧縮された tar ファイルを用いる 3.0 (native) フォーマットでネイティブの Debian ソースパッケー ジを作成します。     + package_version.tar.gz + package_version.dsc * ネイティブ Debian ソースパッケージから、Debian バイナリーパッ ケージをビルドします。 + package_version_arch.deb 例えば debian/* ファイルを含まない ~/mypackage-1.0 ソースファイル     があれば、以下のように dh_make コマンドを用いてネイティブ Debian パッケージが作れます:     $ cd ~/mypackage-1.0 $ dh_make --native すると、debian ディレクトリーとその内容は「最初のノンネイティブ Debian パッケージ」とちょうど同じように作成されます。これはネイテ     ィブ Debian パッケージなので tar アーカイブを作りません。しかし相 違点はこれだけです。他のパッケージング操作は実質的にまったく同じ です。     dpkg-buildpackage コマンドを実行した後、親ディレクトリーに以下の ファイルが生成します: * mypackage_1.0.tar.gz これは、dpkg-source コマンドにより mypackage-1.0 ディレクトリ ーから作られたソースコードのターボールです。(そのサフィックス は orig.tar.gz ではありません。) * mypackage_1.0.dsc これは、ノンネイティブ Debian パッケージと同様でソースコード 内容の要約です。(Debian リビジョンはありません。)     * mypackage_1.0_i386.deb これは、ノンネイティブ Debian パッケージと同様で完成したバイ ナリーパッケージです。(Debian リビジョンはありません。) * mypackage_1.0_i386.changes これは、ノンネイティブ Debian パッケージと同様で現パッケージ バージョンでの全変更を記述します。(Debian リビジョンはありま せん。) ---------------------------------------------------------------------     ^[87] もしくは: readelf -d libfoo.so.1 | grep SONAME     ^[88] もしくは: readelf -d libfoo.so.1 | grep NEEDED     ^[89] Debian Policy Manual, 8.1 "Run-time shared libraries" を参 照下さい。     ^[90] Debian Policy Manual, 8.1.1 "ldconfig" を参照下さい。     ^[91] See Debian Policy Manual, 8.3 "Static libraries" and Debian Policy Manual, 8.4 "Development files" を参照下さい。     ^[92] Debian wiki ReleaseGoals/LAFileRemoval を参照下さい。     ^[93] Debian wiki RpathIssue を参照下さい。 ^[94] 後方非互換な ABI 変更をした場合、通常、ライブラリーの     SONAME と共有ライブラリーパッケージ名を新規なものにそれぞれアップ デートしないといけません。 ^[95] C++ ライブラリーや個別シンボルを追跡するのが非常に困難な他     の場合には、これに代えて Debian Policy Manual, 8.6.4 "The shlibs system" に従いましょう。 ^[96] Debian パッケージの過去全てのバージョンは http://     snapshot.debian.org/ から得られます。パッケージのバックポートが楽 にできるように Debian リビジョンはバージョンから取り除きます。: 1.1 << 1.1-1~bpo70+1 << 1.1-1 と 1.2 << 1.2-1~bpo70+1 << 1.2-1     ^[97] Debian リビジョンはパッケージのバックポートを容易にすべく外 します: 1.3 << 1.3-1~bpo70+1 << 1.3-1     ^[98] Debian Policy Manual, 8.6.2 "Shared library ABI changes" を 参照下さい。     ^[99] 旧来の /lib32/ や /lib64/ 等の特定目的のライブラリーパスは 使われなくなっています。 ^[100] これに代えて、./configure に --libdir=\$${prefix}/lib/$ (DEB_HOST_MULTIARCH) と --libexecdir=\$${prefix}/lib/$ (DEB_HOST_MULTIARCH) 引数を追加することもできます。注意いただきた     いのは、ユーザーではなく他のプログラムによりのみ実行される実行プ ログラムをインストールするデフォルトパスを --libexecdir は設定し ます。その Autotools のデフォルトは /usr/libexec/ ですが、Debian デフォルトは /usr/lib/ です。