Debian 新メンテナーガイド --------------------------------------------------------------------- Josip Rodin 初期の内容  Osamu Aoki 更新された内容  倉澤望 日本語訳  八津尾雄介 日本語訳  佐々木洋平 日本語訳  倉敷悟 日本語訳  青木修 日本語訳  バージョン 1.2.32-svn --------------------------------------------------------------------- 製作著作 © 1998-2002 Josip Rodin 製作著作 © 2005-2011 Osamu Aoki 製作著作 © 2010 Craig Small 製作著作 © 2010 Raphaël Hertzog     この文書は GNU 一般公有使用許諾書、バージョン 2 かそれ以降が規定 する条件の下で使用できます。     この文書は以下の二つの文書を参考にして書かれました。 * Debian パッケージの作り方 (別名 Debmake マニュアル)、 Copyright © 1997 Jaldhar Vyas.     * 新メンテナー向け Debian パッケージング法、copyright © 1997 Will Lowe. 2013-10-02 08:24:12 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 パッケージ 2.9. 最初のネイティブ 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. menu 5.18. NEWS 5.19. {pre,post}{inst,rm} 5.20. package.symbols 5.21. TODO 5.22. watch 5.23. source/format 5.24. source/local-options 5.25. source/options 5.26. patches/* 6. パッケージのビルド 6.1. 完全な（再）ビルド 6.2. オートビルダー 6.3. debuildコマンド 6.4. pbuilderパッケージ 6.5. git-buildpackageコマンドとその仲間 6.6. 部分的な再ビルド 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. アップロード用orig.tar.gzの内容 8.3. スキップされたアップロード 9. パッケージの更新 9.1. Debian リビジョンの更新 9.2. 新規のアップストリームリリースの検査 9.3. アップストリームソフトウェアの新版更新 9.4. パッケージ化スタイルの更新 9.5. UTF-8 変換 9.6. パッケージをアップグレードする際の注意点 A. 上級パッケージング A.1. 共有ライブラリー A.2. debian/package.symbols の管理 A.3. マルチアーチ A.4. 共有ライブラリーパッケージのビルド 第1章まずは正攻法で始めよう この文書では、一般の Debian ユーザーやデベロッパーを目指している 人を対象に Debian パッケージのビルド方法の解説を試みます。技術用     語はできるだけ避けて、実用的な例示を多用してします。古いラテンの 諺にもあるように、Longum iter est per praecepta, breve et efficax per exempla (百聞は一見にしかず) です。     この文書は、Debian squeeze リリース用に更新されています。^[1] Debian を最高峰の Linux ディストリビューションたらしめている理由 のひとつが、そのパッケージ管理システムです。すでに膨大な数のソフ トウェアが Debian 形式で配布されていますが、まだパッケージ化され ていないソフトウェアをインストールしなければならないことがあるで     しょう。どうやったら自分でパッケージが作れるんだろうとか、それは とても難しいことなんじゃないかなどと考えたことがありませんか。確 かに、もしあなたが本当に駆け出しの Linux ユーザーなら難しいでしょ うが、それなら今ごろこんな文書を読んでませんよね :-) Unix のプロ グラミングについて少々知っている必要がありますが、神様みたいに精 通している必要は全くありません。 ^[2] ただ、確かなことがひとつあります。Debian パッケージをきちんと作成     し保守していくには時間がかかるということです。間違えないでくださ い、Debian のシステムが機能するには、メンテナーは技術的に有能であ るだけでなく、勤勉であることも必要なのです。     パッケージ作成において手助けが必要なら、「相談するには」を読んで ください。 この文書の最新版は常に以下の場所からネットワーク経由で入手できま す。http://www.debian.org/doc/maint-guide/ (http://www.debian.org     /doc/maint-guide/) また、maint-guideパッケージにも含まれています 。日本語訳はmaint-guide-jaパッケージに含まれています。本文書の内 容が少々古くなっているかもしれない事に注意して下さい。 本書は入門書ですので、一部の重要なトピックスは詳細なステップを個     々説明するようにしました。あなたには不要と思われる部分があるかも しれません。我慢して下さい。本文書を簡潔にするように一部のコーナ ーケースを意識的に省略したり参照を提供するだけに止めています。 1.1. Debianにおける社会ダイナミクス     あなたがDebian と関わる際の準備となることを望み、Debianの社会ダイ ナミクスの観察結果を記します。 * 我々全員はボランティアです。 o 他人に何をするかを押し付けてはいけません。 o 自分自身で行う意欲を持つべきです。 * 友好的な協力が推進力です。 o あなたの寄与は他人にストレスを掛けすぎてはいけません。 o あなたの寄与は他人に評価されて初めて価値があります。     * Debian は教師の注意が自動的にあなたに注がれるあなたの学校とは 違います。 o 多様な案件の独学能力を持つべきです。 o 他ボランティアに注意を払ってもらうことは貴重なリソースで す。 * Debian は常に改良されています。 o あなたには高品質パッケージを作成することが期待されていま す。 o あなたは変化に自らを適合させる必要があります。     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年間 (http://upsilon.cc/ ~zack/talks/2011/20110321-taipei.pdf) (紹介スライド、英語) * Debian に協力するには? (http://www.debian.org/intro/help) (正 規) * The Debian GNU/Linux FAQ, Chapter 13 - "Contributing to the     Debian Project" (http://www.debian.org/doc/FAQ/ ch-contributing) (準正規) * Debian Wiki, HelpDebian (http://wiki.debian.org/HelpDebian) (補足) * Debian New Member サイト (https://nm.debian.org/) (正規) * Debian Mentors FAQ (http://wiki.debian.org/DebianMentorsFaq) (補足) 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] * 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 (/usr/share/doc/lintian/ lintian.html/index.html) 参照。) * 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 (http://www.debian.org/ doc/devel-manuals#policy) (Debian ポリシーマニュアル)は、 Debian アーカイブの構造と内容、OS の設計に関するいくつかの案 件、Filesystem Hierarchy Standard (http://www.debian.org/doc/ packaging-manuals/fhs/fhs-2.3.html) (FHS、個々のファイルやデ ィレクトリーがどこにあるべきかを規定した文書) が含まれていま す。さしあたって重要なのは、ディストリビューションに含まれる ためにそれぞれのパッケージが満たすべき必要条件の説明です (ロ ーカルコピーのpolicy.pdf (/usr/share/doc/debian-policy/ policy.pdf.gz) と /usr/share/doc/debian-policy/fhs/     fhs-2.3.pdf.gz を参照。) * developers-reference - Debian Developer's Reference (http:// www.debian.org/doc/devel-manuals#devref) (Debian デベロッパー リファレンス)には、例えばアーカイブの構造、パッケージ名の変更 方法、パッケージの選び方、メンテナーを降りるにはどうしたらよ いか、どうやって NMU をするか、バグとのつき合い方、パッケージ 作成のベストプラクティス、いつどこにアップロードすればよいか などなど、特に技術的な事柄以外のパッケージ化についてのありと あらゆる情報がここにあります。(ローカルコピーの /usr/share/ doc/developers-reference/developers-reference.pdf を参照。)     以下は、この文書と合わせて読むべきとても重要な文書です。 * Autotools Tutorial (http://www.lrde.epita.fr/~adl/ autotools.html) は、Autoconf、Automake、Libtool や gettext を 最も重要な構成要素としてもつ GNU Autotools として知られる GNU ビルドシステムの非常に好適な入門書です。 * gnu-standards - このパッケージには、GNU プロジェクトからの文     書が 2 つ含まれています。GNU コーディング標準 (http:// www.gnu.org/prep/standards/html_node/index.html) と、GNU ソフ トウェアのメンテナー向け情報 (http://www.gnu.org/prep/ maintain/html_node/index.html) です。Debian ではこれらに従う ことは求められませんが、ガイドラインまたは常識としても有用で す(ローカルコピーの /usr/share/doc/gnu-standards/ standards.pdf.gz と /usr/share/doc/gnu-standards/ maintain.pdf.gz を参照。) この文書が、上記文書の記述と矛盾している場合は、そちらが正解です     。reportbug を使ってmaint-guide パッケージにバグレポートをしてく ださい。     以下は、この文書と合わせて読める同様の入門書です。     * Debian Packaging Tutorial (http://www.debian.org/doc/ packaging-manuals/packaging-tutorial/packaging-tutorial) 1.4. 相談するには     公開の場で質問をすると決心する前に、良好な文書を読みましょう。 * 全ての関与するパッケージの /usr/share/doc/package 中のファイ ル * 全ての関与するコマンドの man command の内容     * 全ての関与するコマンドの info command の内容 * debian-mentors@lists.debian.org メーリングリストのアーカイブ (http://lists.debian.org/debian-mentors/) の内容 * debian-devel@lists.debian.org メーリングリストのアーカイブ (http://lists.debian.org/debian-devel/) の内容 site:lists.debian.org のような検索文字列を含めてドメインを制約す     るようなことでウエッブ検索エンジンをより効率的に利用することを考 えましょう。 小さなテストパッケージを作ることは、パッケージ作成の詳細を学ぶよ     い方法です。他の人がどのようにパッケージを作成しているか学ぶには 、既存のよく保守されているパッケージを調べるのが一番です。     入手可能な文書やウエッブのリソースからは答えを見つけられない疑問 が残った場合には、インタラクティブに疑問を聞く事が出来ます。 * debian-mentors@lists.debian.org メーリングリスト (http:// lists.debian.org/debian-mentors/) 。 (初心者向けメーリングリ ストです。)     * debian-devel@lists.debian.org メーリングリスト (http:// lists.debian.org/debian-devel/) 。 (上級者向けメーリングリス トです。) * #debian-mentors の様な IRC (http://www.debian.org/support# irc) 。     あなたがするべき努力をした後に適切に質問すれば、より経験を持った Debian デベロッパーは喜んで助けてくれるでしょう。 バグレポート (そう、本物のバグレポートです！) を受けとったら、レ ポートを効率的に処理するために、Debian バグ追跡システム (http:// www.debian.org/Bugs/) に入り込み、その説明文書を読む時だというこ     とがわかるでしょう。Debian デベロッパーリファレンスの 5.8. 'Handling bugs' (http://www.debian.org/doc/manuals/ developers-reference/pkgs.html#bug-handling) を読むよう、強くおす すめします。 すべてうまくやったとしても、これからはお祈りの時間です。なぜか？ それは、ほんの数時間 (あるいは数日) で、世界中のユーザーがそのパ     ッケージを使いはじめるからです。もし何か致命的なエラーをやらかし ていたら、膨大な数の怒った Debian ユーザーからメール爆弾を受けと ることになります……なんて冗談ですが :-) リラックスしてバグ報告に備えてください。なにしろ、そのパッケージ     が Debian ポリシーやそのベストプラクティスに完全に沿うようになる までには、やらなくてはいけないことは沢山あるのですから (繰り返し ますが、詳細は正式の文書を読んでください)。頑張ってください！ -------------- ^[1] 文中では、squeeze より新しいシステムを使っていると想定してい     ます。古いシステム (古い Ubuntu システム等を含む)を使ってこの文書 についていきたいのであれば、少なくともバックポートされた dpkg お よび debhelper パッケージをインストールする必要があります。 ^[2] Debian システムの基本的な操作は Debian Reference (http://     www.debian.org/doc/manuals/debian-reference/) から学べます。Unix プログラミングに関しても学べるいくつかのポインターも含まれていま す。     ^[3] dh-make-perl、dh-make-php等のように、同様の内容で特化したパ ッケージもいくつかあります。 第2章はじめの一歩     (できれば既存パッケージを引き取り) 自分のパッケージを作成しましょ う。 2.1. Debian パッケージビルドのワークフロー アップストリームのプログラムを使って Debian パッケージを作成する     場合、Debian パッケージビルドは以下の各ステップでいくつかの特定の 命名をされたファイルを生成することからなります。 * 通常圧縮された tar フォーマットのアップストリームソフトウエア ーのコピーを入手します。 o package-version.tar.gz * debian ディレクトリー下へ Debian 固有のパッケージ用の変更をア ップストリームプログラムへ追加し、3.0 (quilt) フォーマットで ノンネイティブのソースパッケージを作成します。(ソースパッケー ジとは、Debian パッケージビルドのために用いる入力ファイルセッ トのこと。)     o package_version.orig.tar.gz o package_version-revision.debian.tar.gz^[4] o package_version-revision.dsc * Debian ソースパッケージから .deb フォーマット (または Debian のインストーラーが使う .udeb フォーマット)で提供される通常の インストール可能な Debian のバイナリーパッケージをビルドしま す。 o package_version-revision_arch.deb package と version の間の文字が tar 玉の名前の - (ハイフン)が     Debian パッケージファイルの名前では _ (下線)に変更されていること に注目して下さい。 Debian Policy Manual に従い、上記のファイル名中の、package 部分は     パッケージ名に置き換え、version 部分はアップストリームバージョン に置き換え、revision 部分は Debian リビジョンに置き換え、arch 部 分はパッケージアーキテクチャーに置き換えます。^[5] これに代えて、アップストリーム無しに Debian 固有のパッケージを作     成する場合、Debian パッケージビルドの典型的なワークフローはより簡 単となります。 * 全てのファイルが含まれる単一の圧縮された tar ファイルを用いる 3.0 (native) フォーマットでネイティブの Debian ソースパッケー ジを作成します。     o package_version.tar.gz o package_version.dsc * ネイティブ Debian ソースパッケージから、Debian バイナリーパッ ケージをビルドします。 o package_version_arch.deb     以下で、このアウトラインの各ステップは後述のセクションで詳細に説 明します。 2.2. プログラムの選定 おそらく、作成したいパッケージを選んだことと思います。まず最初に     しなければならないことは、ディストリビューションのアーカイブにそ のパッケージがすでにあるかどうかを以下をを使って確認することです 。 * aptitude コマンド * Debian パッケージ (http://www.debian.org/distrib/packages) ウ     エッブページ * Debian Package Tracking System (http://packages.qa.debian.org /common/index.html) ウエッブページ もしパッケージが既に存在していたら、インストールしましょう! :-) もしそのパッケージがみなし子状態 (メンテナーが Debian QA Group     (http://qa.debian.org/) に設定されていること)なら、そのパッケージ を他人にとられていなければ、そのパッケージを引き取ることができる かもしれません。パッケージのメンテナーが引き取り依頼 (RFA) を出し ているパッケージも引きとれます。^[6]     パッケージの所有状態の情報源がいくつかあります。 * Work-Needing and Prospective Packages (http://www.debian.org/ devel/wnpp/) * Debian Bug report logs: Bugs in pseudo-package wnpp in     unstable (http://bugs.debian.org/wnpp) * Debian Packages that Need Lovin' (http://wnpp.debian.net/) * Browse wnpp bugs based on debtags (http:// wnpp-by-tags.debian.net/) 注釈ですが、Debian にはすでにほとんどの種類のプログラムが含まれて いることと、Debian アーカイブにすでに含まれているパッケージの数は アップロード権限をもつユーザーの数よりもはるかに多いことに注意し     ておくのは重要です。従って、すでにアーカイブに含まれているパッケ ージへの作業は、他のデベロッパーからはるかに喜ばれ (よりスポンサ ーしてもらえる見込みがあり)ます^[7]。貢献の仕方はいろいろあります 。 * まだよく使われている、みなしごのパッケージを引き取る * パッケージ化チーム (http://wiki.debian.org/Teams) に参加する     * よく使われているパッケージのバグに対処する * QA もしくは NMU アップロード (http://www.debian.org/doc/ developers-reference/pkgs.html#nmu-qa-upload) を準備する もしパッケージを引き取ることができるなら、(apt-get source packagename などの方法で) ソースを入手して、調べてみてください。 残念ながらこの文書では、パッケージを引き取ることについて、わかり     やすく説明してはいません。ありがたいことに、既に誰かがあなたのた めにパッケージを準備してくれたわけですから、そのパッケージがどの ように動作するのか理解することは、それほど難しくはないでしょう。 とはいえ、そうした場合でもこの文書に書かれた多くのアドバイスはそ のまま通用しますから、このまま読み進めていってください。 もしあなたの選んだプログラムがまだパッケージ化されていないもので     、それを Debian に入れたいと決めたなら、以下のチェック項目につい て確認してください。 * まず、そのプログラムが機能することを理解し、ある程度の期間使 用してその有用性について確認するべきです。 * 作業中のパッケージ (http://www.debian.org/devel/wnpp/) サイト を確認し、他の誰も同じパッケージに関して作業していないことを 確かめてください。誰も作業していなければ、reportbug を使って ITP (Intent To Package) のバグレポートを、wnpp 疑似パッケージ に送ってください。もし既に誰かが作業していたら、連絡を取りた いならそうしてください。もしその気が無いなら、まだ誰も手をつ けていない他の面白いプログラムを探しましょう。 * プログラムには、ライセンスが必須です。 o main セクションは、Debian ポリシーにより Debian フリーソ フトウェアガイドライン (DFSG (http://www.debian.org/ social_contract#guidelines) ) に完全に準拠しなければなり ませんし、またコンパイル・実行時に main 以外のパッケージ に依存してはなりません。これが望ましいケースです。 o contrib セクションは、DFSG に完全に準拠していなければなり ませんが、コンパイル・実行時に main にあるもの以外のパッ ケージに依存していても構いません。 o non-free セクションは、DFSG に準拠していない部分があるか     もしれませんが、配布可能でなければなりません。 o どうするべきかよくわからなければ、 debian-legal@lists.debian.org (http://lists.debian.org/ debian-legal/) にライセンス文を送り、アドバイスを求めてく ださい。 * プログラムは、Debian システムにセキュリティーやメインテナンス 上の懸念を招いてはいけません。 o ちゃんとした説明書きのあるプログラムで、ソースコードが理 解可能なもの (つまり、難読化されていないこと)。 o プログラムの作者に連絡をとって、パッケージ化の承諾と Debian に友好的かどうかを確認しておきましょう。何かプログ ラムそのものに起因する問題が発生した際に、作者にいろいろ 聞けるということは重要なので、メンテナンスされていないソ フトウェアをパッケージ化するのはやめておきましょう。 o プログラムは root に setuid で実行されるべきではありませ ん。もっと言えば、どのユーザーへの setuid や setgid もす るべきではありません。 o デーモンとして動作するプログラムや、*/sbin ディレクトリー に配置するプログラム、また root 特権を使ってポートを開く プログラムで無いほうが良いでしょう。 もちろんこの最後の件は単なる安全策で、setuid デーモン等で何かミス     して怒り狂ったユーザーから抗議殺到という事態を招くことを回避する ためです。パッケージ化についてもっと経験を積めば、こうしたパッケ ージも作れるようになるでしょう。 新規メンテナーであるあなたには、比較的簡単なパッケージで経験を積     むことをお勧めし、複雑なパッケージを作成することお勧めはできませ ん。 * 単純なパッケージ、 o 単一のバイナリーパッケージ、arch = all (壁紙グラフィクス のようなデータのコレクション) o 単一のバイナリーパッケージ、arch = all (POSIX のようなイ ンタープリタ言語で書かれた実行可能プログラム) * ほどほど複雑なパッケージ o 単一のバイナリーパッケージ、arch = all (C や C++ のような 言語からコンパイルされた ELF バイナリーの実行可能プログラ ム) o 複数のバイナリーパッケージ、arch = all + any (ELF バイナ リーの実行可能プログラム + 文書のパッケージ) o ソースファイルの形式が、tar.gz. や tar.bz2 でないもの     o 配布できない内容が tar 玉に含まれるアップストリームソース * 高度に複雑なパッケージ o 他のパッケージにより利用される、インタープリタのモジュー ルパッケージ o 他のパッケージにより利用される汎用 ELF ライブラリーパッケ ージ o ELF ライブラリーパッケージを含む複数バイナリーパッケージ o 複数のアップストリームソースからなるソースパッケージ o カーネルモジュールパッケージ o カーネルパッチパッケージ o 非自明なメンテナースクリプトを含むあらゆるパッケージ 高度に複雑なパッケージをパッケージすることはそれほど難しいことで     はありませんが、少々知識が必要です。それぞれの複雑な特徴には固有 のガイダンスを探すべきです。例えば、いくつかの言語にはそれぞれの サブポリシー文書があります。 * Perl policy (http://www.debian.org/doc/packaging-manuals/ perl-policy/)     * Python policy (http://www.debian.org/doc/packaging-manuals/ python-policy/) * Java policy (http://www.debian.org/doc/packaging-manuals/ 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 (>=9) 6 Standards-Version: 3.9.4     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で問題ないでしょう。     * extra以外のパッケージと競合する可能性のある、新規パッケージの 場合は、extraとすると大抵うまくいきます。 セクション (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 (http://     www.debian.org/doc/devel-manuals#policy) のバージョンです。これは 、あなたがパッケージ作成の際に参照したポリシーマニュアルのバージ ョンです。     7行目にはソフトウエアーのアップストリームプホームページ URL を記 載できます。     9行目はバイナリーパッケージの名前です。ソースパッケージと同名にす るのが通例ですが、そうでなくてもかまいません。 10 行目にはバイナリーパッケージがコンパイルされる対象のアーキテク     チャーを記載します。この値はバイナリーパッケージのタイプによって 通常以下の２つのどちらかです。^[32] * Architecture: any o 生成されるバイナリーパッケージが通常コンパイルされたマシ ンコードからなるアーキテクチャー依存パッケージである。     * Architecture: all o 生成されたバイナリーパッケージは、通常テキストやイメージ やインタープリター言語のスクリプトからなる、アーキテクチ ャー依存の無いパッケージです。 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 (http://lists.debian.org/     debian-devel/) で議論を尽くした上で、とても慎重に扱うべきです 。つまり、使わないでください。:-) * Conflicts (競合) 競合しているパッケージが削除されない限り、パッケージはインス トールされません。あなたのプログラムが特定のパッケージと一緒 だと動かない（または深刻な破壊の原因になる恐れがある）場合は これを使います。 * Breaks (破壊) パッケージがインストールされると、全てのリストされたパッケー ジを破壊します。通常、Breaks の項目は特定の値より旧いバージョ ンに対して規程します。通常、上位パッケージマネジメントツール を用い、記載されたパッケージをアップグレードし解決します。 * Provides (提供) パッケージによっては、選択の予知があるために仮想パッケージ名 が定義されています。仮想パッケージ名の一覧仮想パッケージ名の 一覧は virtual-package-names-list.txt.gz (http:// www.debian.org/doc/packaging-manuals/ virtual-package-names-list.txt) にあります。あなたのプログラ ムが既存の仮想パッケージの機能を提供する場合には、これを使い ます。 * 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/ (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 (>=9), xlibs-dev, libgtk1.2-dev, libglib1.2-dev 6 Standards-Version: 3.9.4 7 Vcs-Git: git://git.debian.org/git/collab-maint/gentoo.git 8 Vcs-browser: http://git.debian.org/?p=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" (http://www.debian.org/doc/ debian-policy/ch-docs.html#s-copyrightfile) に規定され、DEP-5: Machine-parseable debian/copyright (http://dep.debian.net/deps/ dep5/) がそのフォーマットのガイドラインを提供しています。 dh_makeはcopyrightファイルのテンプレートを作成します。GPL-2でリリ     ースされたgentooパッケージのテンプレートを入手するには、 --copyright gpl2オプションを使用します。 パッケージの入手先や著作権表示やラインセンス等の抜けている情報を 書き加え、ファイルを完成させましょう。一般的にフリーソフトウェア に使用される特定の共通ライセンス (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 と Artistic のライセンス) は、各 Debian シ ステムの /usr/share/common-licenses/ ディレクトリー内にあるファイ ルを参照することができるので、全文の引用は不要です。その他のライ センスの場合、完全なライセンスを含めなければなりません。     つまり、gentoo パッケージの copyright ファイルは以下のようになり ます: 1 Format-Specification: http://svn.debian.org/wsvn/dep/web/deps/dep5.mdwn?op=file&rev=135 2 Name: gentoo 3 Maintainer: Josip Rodin 4 Source: http://sourceforge.net/projects/gentoo/files/ 5 6 Copyright: 1998-2010 Emil Brink 7 License: GPL-2+ 8 9 Files: icons/* 10 Copyright: 1998 Johan Hanson 11 License: GPL-2+ 12 13 Files: debian/* 14 Copyright: 1998-2010 Josip Rodin 15 License: GPL-2+ 16     17 License: GPL-2+ 18 This program is free software; you can redistribute it and/or modify 19 it under the terms of the GNU General Public License as published by 20 the Free Software Foundation; either version 2 of the License, or 21 (at your option) any later version. 22 . 23 This program is distributed in the hope that it will be useful, 24 but WITHOUT ANY WARRANTY; without even the implied warranty of 25 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the 26 GNU General Public License for more details. 27 . 28 You should have received a copy of the GNU General Public License along 29 with this program; if not, write to the Free Software Foundation, Inc., 30 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. 31 . 32 On Debian systems, the full text of the GNU General Public 33 License version 2 can be found in the file 34 `/usr/share/common-licenses/GPL-2'.     (行番号は筆者による) ftpmasterにより提供され debian-devel-announce に投稿された手順書     http://lists.debian.org/debian-devel-announce/2006/03/ msg00023.html (http://lists.debian.org/debian-devel-announce/2006 /03/msg00023.html) に従って下さい。 4.3. changelog これは必須のファイルで、Debian Policy Manual, 4.4 "debian/ changelog" (http://www.debian.org/doc/debian-policy/     ch-source.html#s-dpkgchangelog) で既定された特別な書式となってい ます。この書式は、dpkg やその他のプログラムが、パッケージのバージ ョン番号、リビジョン、ディストリビューション、緊急度 (urgency) を 識別するために利用します。 あなたが行なったすべての変更をきちんと記載しておくことは良いこと であり、その意味でこのファイルはまた、パッケージメンテナーである あなたにとっても重要なものです。パッケージをダウンロードした人は     、このファイルを見ることで、このパッケージに関する未解決の問題が あるかどうかを知ることができます。このファイルはバイナリーパッケ ージ中に/usr/share/doc/gentoo/changelog.Debian.gzとして保存されま す。     dh_makeがデフォルトを生成し、以下のようになっています: 1 gentoo (0.9.12-1) unstable; urgency=low 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の更新については、9章パッケージの更新で詳しく説明します 。 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 # -*- makefile -*- 3 # Sample debian/rules that uses debhelper. 4 # This file was originally written by Joey Hess and Craig Small. 5 # As a special exception, when this file is copied by dh-make into a 6 # dh-make output file, you may use that output file without restriction.     7 # This special exception was added by Craig Small in version 0.37 of dh-make. 8 9 # Uncomment this to turn on verbose mode. 10 #export DH_VERBOSE=1 11 12 %: 13 dh $@     (行番号は筆者による。実際のrulesファイルでは、行頭の空白はTABコー ドです。)     1行目はシェルやパールスクリプトでお馴染みの表現です。オペレーティ ングシステムに/usr/bin/makeで処理するように指示しています。 10 行目のコメントを外し　DH_VERBOSE 変数を 1 に設定すれば、dh コ マンドがどの dh_* コマンドを実行しているかを出力するようにできま す。必要であればここに、export DH_OPTIONS=-vという行を追加すれば     、dh_*コマンドが、dh_*によって実行されたコマンドを出力します。こ の単純な rules ファイルが影で何をしているのかを理解し、その問題デ バッグの際の助けとなるでしょう。この新しい dh がdebhelper ツール の中核から設計され、あなたに対して一切隠し事をしません。 12 と 13 行目は、パターンルールを用いて非明示的ルールで全てが行わ れる場所です。パーセント記号「%」は「いかなるターゲット」を意味し     、ターゲットの名前を引数に 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] o python パッケージを Build-Depends に含めます。 o dh $@ --with python2を使用します。 o これは pythonフレームワークを使用してPythonモジュールを取 り扱います。 * dh_pysupport コマンドのサポートを追加します。(非推奨) o python-support を Build-Depends に含めます。 o dh $@ --with pysupportを使用します。 o これでpython-supportフレームワークを使用してPythonモジュ ールを利用できます。 * dh_pycentral コマンドのサポートを追加します。(非推奨) o Build-Depends に、python-central パッケージを含めます。 o 代わりにdh $@ --with python-centralを使用します。 o これでdh_pysupportコマンドも無効化されます。 o これでpython-centralフレームワークを使用してPythonモジュ ールを利用できます。 * dh_installtex コマンドのサポートを追加します。 o Build-Depends に、tex-commonパッケージを含めます。 o 代わりにdh $@ --with texを使用します。 o これで、TeXによるType1フォント、ハイフネーション、または フォーマットが登録されます。 * dh_quilt_patch と dh_quilt_unpatch コマンドのサポートを追加し ます。 o Build-Depends に、quilt パッケージを含めます。 o 代わりにdh $@ --with quiltを使用します。 o 1.0 フォーマットのソースパッケージの debian/patches ディ レクトリー内にあるファイルを用いて、アップストリームソー スにパッチを当てたり外したりできます。 o もし新規の 3.0 (quilt) ソースパッケージフォーマットを使用     している場合、これは不要です。 * dh_dkms コマンドのサポートを追加します。 o Build-Depends に、dkms パッケージを含めます。 o 代わりにdh $@ --with dkmsを使用します。 o カーネルモジュールパッケージによる DKMS の使用を正しく処 理します。 * dh_autotools-dev_updateconfig と dh_autotools-dev_restoreconfig コマンドのサポートを追加します 。 o Build-Depends に、autotools-dev パッケージを含めます。 o 代わりに dh $@ --with autotools-dev を使用します。 o これでconfig.subとconfig.guessをアップデートおよびレスト アします。 * dh_autoreconf と dh_autoreconf_clean コマンドのサポートを追加 します。 o Build-Depends に、dh-autoreconf パッケージを含めます。 o 代わりにdh $@ --with autoreconfを使用します。 o これは、ビルド後にGNUビルドシステムのファイルのアップデー トおよびレストアを行います。 * dh_girepository コマンドのサポートを追加します。 o Build-Depends に、gobject-introspection パッケージを含め ます。 o 代わりにdh $@ --with girを使用します。 o これは GObject イントロスペクションデーターを提供している パッケージの依存関係を計算し、パッケージ依存関係用に $ {gir:Depends} 代替変数を生成します。 * bash 補完機能のサポートを追加します。 o Build-Depends に、bash-completion パッケージを含めます。 o 代わりにdh $@ --with bash-completionを使用します。 o このコマンドを使用すると、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_cleanターゲットを作ることで、スキップできます。     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" (http://www.debian.org     /doc/debian-policy/ch-archive.html#s-subsections) と List of sections in sid (http://packages.debian.org/unstable/) を参照下さ い。 ^[29] Debian Policy Manual, 2.5 "Priorities" (http://     www.debian.org/doc/debian-policy/ch-archive.html#s-priorities) を 参照下さい。 ^[30] Debian Policy Manual, 7.7 "Relationships between source and binary packages - Build-Depends, Build-Depends-Indep,     Build-Conflicts, Build-Conflicts-Indep" (http://www.debian.org/ doc/debian-policy/ch-relationships.html#s-sourcebinarydeps) を参 照下さい。 ^[31] この少し変な状況はDebian Policy Manual, Footnotes 55 (http: //www.debian.org/doc/debian-policy/footnotes.html#f55) で詳しく説     明されている特徴です。これは、debian/rules ファイル内の dh コマン ドではなく、dpkg-buildpackage に起因します。同様の状況は auto build system for Ubuntu (https://bugs.launchpad.net/ launchpad-buildd/+bug/238141) にも当てはまります。 ^[32] 詳細は Debian Policy Manual, 5.6.8 "Architecture" (http://     www.debian.org/doc/debian-policy/ch-controlfields.html# s-f-Architecture) を参照下さい。 ^[33] Debian Policy Manual, 7 "Declaring relationships between     packages" (http://www.debian.org/doc/debian-policy/ ch-relationships.html) を参照下さい。 ^[34] これらの説明は英語です。これらの説明の翻訳は The Debian     Description Translation Project - DDTP (http://www.debian.org/ intl/l10n/ddtp) によって提供されています。 ^[35] Developer's Reference, 6.2.5. "Version Control System     location" (http://www.debian.org/doc/manuals/developers-reference /best-pkging-practices.html#bpp-vcs) を参照下さい。     ^[36] もし dch -r コマンドを使ってこの最終変更をする場合には、エ ディターにより changelog ファイルを明示的に保存して下さい。 ^[37] Debian Reference, 12.2 "Make" (http://www.debian.org/doc/ manuals/debian-reference/ch12#_make) から Makefile の書き方を学び     始められます。http://www.gnu.org/software/make/manual/html_node/ index.html (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" (http://www.debian.org/doc/debian-policy/ch-source.html# s-debianrules) に詳細に説明されています。     ^[39] このターゲットは例えば、「完全な（再）ビルド」などで、 dpkg-buildpackageが使用します。     ^[40] このターゲットは例えば、「オートビルダー」などで、 dpkg-buildpackage -Bが使用します。     ^[41] このターゲットは、 dpkg-buildpackage -Aが使用します。 ^[42] これは新しい debhelper v7+ の機能です。このデザインコンセプ トはDebConf9で debhelper アップストリームによって Not Your Grandpa's Debhelper (http://joey.kitenet.net/talks/debhelper/ debhelper-slides.pdf) として提示されました。lenny の dh_make は、 必須となる明示されたターゲットごとに、もっと複雑な rules ファイル     と dh_* スクリプトを量産し、最初にパッケージ化した際の状態に凍結 していました。新しい dh コマンドは、もっとシンプルで、旧来の制約 に縛られません。その上、override_dh_* ターゲットがあるのでカスタ マイズする利便性は失われていません。詳しくは「rules ファイルのカ スタマイズ」を参照してください。これは、debhelper パッケージがも とになっており、cdbs のようにパッケージのビルドプロセスを難読化す ることはありません。 ^[43] 特定の target 変数で起動される dh_* プログラムシーケンスは     、dh --no-act target もしくは、debian/rules -- '--no-act target' でプログラムを実際に実行せず確認することができます。 ^[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ディレクトリーにあるその他のファイル debhelperがパッケージのビルド中に行うことは、オプションの設定ファ イルを debian ディレクトリーに置けばコントロールできます。この章 では、設定ファイルの機能と書式を概説します。パッケージングのガイ     ドラインについての詳細は Debian Policy Manual (http:// www.debian.org/doc/devel-manuals#policy) と Debian Developer's Reference (http://www.debian.org/doc/devel-manuals#devref) を参照 してください。 dh_makeコマンドは、debianディレクトリーの中に設定ファイルのテンプ レートを作成します。大抵の場合、.exサフェックスが付いています。フ     ァイル名の先頭にpackageなどのように、バイナリーパッケージの名前が つくものもあります。これらのファイルにはすべて目を通しておいてく ださい。^[54] dh_makeコマンドは、一部の debhelper用の設定テンプレートファイルを     作らないことがあります。その場合、自分でエディターを使いそれらを 作成しなければなりません。     設定ファイルを有効にしたい際は、以下を実行して下さい。 * テンプレートファイルに .ex や .EX のサフェックスがついていれ ば、それらを削除するようにリネームしてください。 * packageの代わりに、実際のバイナリーパッケージの名前に設定ファ イルをリネームしてください。     * 必要に応じて、テンプレートファイルの中身を書き換えます。 * 不要なテンプレートファイルは削除してください。 * 必要であれば、control ファイル(参照「control」)を変更します。 * 必要ならrulesファイル(参照「rules」)を編集してください。 package をプリフェックスとして持たない、例えば install のような debhelper の設定ファイルは、最初のバイナリーパッケージへ適用され     ます。バイナリーパッケージが多数ある場合、package-1install、 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 v9 に設定しましょう。     $ echo 9 > debian/compat 5.3. conffiles 大変な時間と労力を費やしてプログラムをカスタマイズしても、一回の アップグレードであなたの変更をあちこち上書きされてしまうとうんざ     りします。このような設定ファイルを conffile と記録しておくことで 、Debianはこの問題を解決しました。^[55] パッケージをアップグレー ドする際に、あなたは古い設定ファイルをキープしたいかかどうかを尋 ねられます。 dh_installdeb(1) は自動的に /etc ディレクトリー以下のファイルを全 て conffiles とみなすので、あなたのプログラムが他のディレクトリー     に conffiles を持たない場合は特に指定する必要はありません。ほとん どのパッケージの場合、/etc 以下にのみ conffiles がある（そうある べきです）ので、このファイルの存在は不要です。 あなたのプログラムが設定ファイルを利用する場合であっても、その設 定ファイルがプログラム自身によって頻繁に上書きされるような場合に     は、パッケージをアップグレードするたびに dpkg によって設定ファイ ルの変更について確認を求められることになるので、その設定ファイル を conffiles に登録しないほうが良いでしょう。 あなたのパッケージングするプログラムが、ユーザーに /etc ディレク     トリーの中にある設定ファイルを編集することを要求する場合、dpkg を 黙らせるために conffiles として登録しない良く使われる方法が２つあ ります。 * /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 - Installed as /etc/cron.monthly/package :としてインストール: 1ヶ月に1度実行。 * 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 もしあなたのパッケージがデーモンであり、システムの起動時に自動的     に動作させる必要があるとしたら、私が最初に勧めたことをあなたはま るっきり無視してしまったわけですよね。そうでしょ ?:-) package.init ファイルはデーモンの起動や停止をする init スクリプト のための /etc/init.d/package スクリプトとしてインストールされます 。その極めて標準的なテンプレートファイルは dh_make コマンドによっ て提供される init.d.ex です。Linux Standard Base (http://     www.linuxfoundation.org/collaborate/workgroups/lsb) (LSB) に準拠 したヘッダーを提供するように確実にするとともに、ファイル名の変更 とかなりの内容編集がおそらく必要です。このファイルは dh_installinit(1) によって、一時的なディレクトリーにインストール されます。 package.default ファイルは /etc/default/package にインストールさ れます。このファイルは init スクリプトによりソースされるデフォル トを設定します。この package.default ファイルは大抵、デーモンを停     止したり、デフォルトのフラグやタイムアウトなどの設定に使われます 。もしもあなたの init スクリプトが、特定の設定可能な機能を有して いるのであれば、それは init スクリプトではなく、この package .default ファイルに設定しておくべきでしょう。 アップストリームプログラムが init スクリプト用ファイルを提供する 場合、それを使用するかしないかは自由です。もしアップストリームか らの init スクリプトを使わないのであれば package.init に新しいの     を作成しましょう。アップストリームの init スクリプトが問題なく正 しい場所にインストールされるとしても、rc* シンボリックリンクの設 定は必要です。そのためには、rules ファイルに以下を追加して、 dh_installinit をオーバーライドしましょう。     override_dh_installinit: dh_installinit --onlyscripts     不要なら、このファイルを削除してください。 5.11. install パッケージにとってインストールが必要なファイルがあるにも関わらず 、 make install ではインストールされない場合、そのファイル名とフ ァイルを置く目的地を install ファイルに記述します。そうすると、     dh_install(1) によってそれらのファイルがインストールされます。^[ 56] まずは使えそうな別のツールがないかどうかを調べましょう。例え ば、ドキュメントはこのファイルではなく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 (/usr/share /doc/lintian/lintian.html/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コマンドを用いて マニュアルページを作成することも可能です。^[57] 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. menu X Window System のユーザーは、大抵ウィンドウマネージャを使ってお り、好きなプログラムを起動できるようにメニュー機能をカスタマイズ     しています。menu パッケージをインストールしていれば、システムにあ る全プログラムのメニュー項目が作成され、menu に対応したウィンドウ マネージャから利用できます。     以下が dh_make が生成したデフォルトの menu.ex ファイルです。 ?package(gentoo):needs=X11|text|vc|wm \     section=Applications/see-menu-manual\ title=gentoo command=/usr/bin/gentoo コロン「:」の後の最初のフィールドはneedsです。このフィールドは、     プログラムがどんなどんなインターフェースが必要かを規定します。デ フォルトとして挙げられたもの（例：text や X11など）に変更してくだ さい。     次はメニューやサブメニューの項目が現れる sectionです。^[58]     titleフィールドはプログラムの名称です。そうしたければ、大文字では じめても大丈夫です。ただ、短くするようにしましょう。     最後の command フィールドは、実際にプログラムを実行するコマンドで す。     それでは、ファイル名をmenuに変更し、メニューの項目を以下のように 変更しましょう。 ?package(gentoo): needs=X11 \     section=Applications/Tools \ title=Gentoo command=gentoo 他にも、longtitle、icon、hints 等のフィールドを追加できます。詳し     くは dh_installmenu(1)、 menufile(5)、 update-menus(1)、The Debian Menu sub-policy (http://www.debian.org/doc/ packaging-manuals/menu-policy/) を参照してください。 5.18. NEWS     dh_installchangelogs(1)コマンドでインストールします。 5.19. {pre,post}{inst,rm} postinst や preinst や postrm や prerm ファイルは^[59]メンテナー     スクリプトと呼ばれています。これらのスクリプトは、パッケージを管 理するアリアに置かれ、インストール、アップグレード、削除される際 にdpkgによって実行されます。 メンテナー初心者のうちは、問題になることが多いのでメンテナースク リプトを直接編集しないようにしましょう。詳しくは Debian Policy     Manual, 6 "Package maintainer scripts and installation procedure" (http://www.debian.org/doc/debian-policy/ ch-maintainerscripts.html) を参照し、dh_make によって生成されるサ ンプルファイルに目を通してください。 もし私の忠告を無視して、メンテナースクリプトを直接編集した場合は     、インストール、アップグレードだけでなく、削除とパージのテストも しっかり行ってください。 新バージョンへのアップグレードは静かであるべきで、押し付けがまし     くてはいけません。（現行ユーザーは、バグが直されたことや新機能が 追加されたことで気づかない限りアップグレードに気づかないのが理想 です。) アップグレードが出しゃばる必要がある場合 (例えば、構造がまったく 異なる設定ファイルがホームディレクトリーに散在する場合など)、パッ ケージのデフォルトを(例えばサービスを停止する等の)安全側に設定し     たり、最後の手段としてはポリシーに要求されるきちんとしたドキュメ ント (README.DebianとNEWS.Debian) を提供するなどの対策を考えるべ きです。アップグレード際にメンテナースクリプトで debconf ノートを 呼び出したりしてユーザーに迷惑を掛けないでください。 ucf パッケージは、メンテナースクリプトによって管理されているよう な conffiles とラベルされていないファイルに関して、ユーザーによっ     て変更されたファイルを保存する conffileのような処理をする仕組みを 提供します。この仕組みを使うとこれらに関する問題を最小化できます 。 これら、メンテナースクリプトはなぜ Debian を選ぶのかという理由の     1 つでもあります。これらの仕組みで、ユーザーが迷惑がる原因となら ないよう細心の注意をはらいましょう。 5.20. package.symbols 新米メンテナーにとってはライブラリーのパッケージは容易ではないし     、避けるべき行為です。このように言いましたが、もしあなたのパッケ ージがライブラリーを含む場合には、debian/package.symbols ファイル を作成すべきです。「debian/package.symbols の管理」を参照下さい。 5.21. TODO     dh_installdocs(1)コマンドでインストールします。 5.22. watch watch ファイルの書式は uscan(1) を参照してください。watch ファイ     ルは、uscan ( devscriptsパッケージに含まれます) を設定し、最初ソ ースを入手しサイトを監視します。Debian External Health Status (DEHS) (http://wiki.debian.org/DEHS) によっても使用されています。     いかが素の内容です: # 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 (http://sf.net) の SourceForge のダウンロードサービスは例外です。watchファイルが Perl の正規表現 ^http://sf\.net/ に一致する URL を含む場合、uscan プログラムが代わりにhttp://qa.debian.org/watch/sf.php/ を使い、こ     のルールを当てはめます。http://qa.debian.org/ (http:// qa.debian.org/) の URL リダイレクトは http://sf.net/project/ tar-name-(.+)\.tar\.gzを含むwatch ファイルを対象に安定したリダイ レクトを提供するよう設計されています。これにより、そこで周期的に 変化する URL に関する問題を解決しています。 5.23. source/format debian/source/formatファイルでは、ソースパッケージのための理想の     書式を示すための行があります。 (完全なリストは、dpkg-source(1)を 参照してください。)squeeze以降は、以下のどちらかになっているべき です。 * 3.0 (native)：　Debianネイティブなパッケージ     * 3.0 (quilt)：　それ以外の全て。 新しい3.0 (quilt)の書式はquiltパッチによる変更を debian/patchesに 記録します。そして、その変更は自動的にソースパッケージを展開する ときに適用されます。^[60]Debianの変更は、debianディレクトリー以下     のファイル全てを含め、debian.tar.gzアーカイブに保存されています。 この新しい書式は、特殊な方法を用いることなく、PGNアイコンなどのパ ッケージメンテナーによるバイナリーファイルを含めることが可能です 。^[61] dpkg-sourceが3.0 (quilt)の書式でソースパッケージを展開する際、     debian/patches/seriesに列挙されたパッチを自動的に適用します。 --skip-patchesオプションで、展開時にパッチを適用しないようにでき ます。 5.24. 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.25. 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.26. 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 に記載する必要はありません。^[62] quilt コマンドについてはquilt(1) で説明されています。ソースへの変 更は、debian/patches ディレクトリー内 -p1 パッチファイルのスタッ     クとして記録され、debian ディレクトリーの外のソースツリーには触れ ません。それらのパッチの順番は debian/patches/series ファイルに記 録されます。パッチの適用 (=push)も、外す (=pop)のも、更新(= refresh)も、簡単にできます。 ^[63]     3章ソースコードの変更では、debian/patchesに３つのパッチを作りまし た。     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] 自明な場合、本章では debian ディレクトリー中のファイルは、 前に付く debian/ を省略し簡明に表記しています。 ^[55] dpkg(1) and Debian Policy Manual, "D.2.5 Conffiles" (http:/     /www.debian.org/doc/debian-policy/ap-pkg-controlfields.html# s-pkg-f-Conffiles) を参照下さい。     ^[56] filesファイルによって、dh_movefiles(1)コマンドが設定され、 置換されます。 ^[57] help2man が作成する仮のマニュアルページに、詳細なドキュメン     トが info システムにあると記載されることに注意して下さい。info ペ ージ中にコマンドが無い場合は、help2man コマンドが生成したページを 手動で修正するべきです。 ^[58] セクションに関する最新リストは The Debian Menu sub-policy     2.1 "Preferred menu structure" (http://www.debian.org/doc/ packaging-manuals/menu-policy/ch2.html#s2.1) にあります。メニュー 構造の大幅な改変が squeeze で行われました。 ^[59] {pre,post}{inst,rm} という bash 独自の短縮形をこれらのファ     イル名の表記としていますが、システムシェルである dash との互換性 のために、これらのメンテナースクリプトでは純粋の POSIX シンタック スを使うべきです。 ^[60] ソースの書式を 3.0 (quilt) や 3.0 (native) に移行する際の注     意点などは、DebSrc3.0 (http://wiki.debian.org/Projects/DebSrc3.0) を参照下さい。 ^[61] この新しいフォーマットは、複数のアップストリームの tar 玉や     この他の圧縮方法もサポートしています。詳細は本稿の範疇を超えるた め割愛します。 ^[62] パッチセットをメンテナンスするためのいくつかの方法が提案さ     れ、Debian パッケージで使われていますが、quilt が推奨されています 。他には、dpatch、dbs、cdbs、などがあります。これらの方法は、大抵 debian/patches/* ファイルでパッチを管理しています。 ^[63] スポンサーにパッケージのアップロードを頼む時にも、あなたが     加えた変更に対するこのような明確な分離とドキュメントは、スポンサ ーによるパッケージのレビューを促進させるためにも、非常に重要です 。 第6章パッケージのビルド     これでパッケージをビルドする準備が整いました。 6.1. 完全な（再）ビルド     完全なパッケージの（再）ビルドを行うには、以下を確実にインストー ルして下さい。 * build-essentialパッケージ     * Build-Dependsに挙げられているパッケージ(参照「control」) * Build-Depends-indepに挙げられているパッケージ(参照「control」 )     ソースディレクトリーで以下のコマンドを実行してください。     $ dpkg-buildpackage     このコマンドはバイナリーパッケージとソースパッケージをビルドする 作業をすべて行ってくれます。これには以下の作業が含まれます。 * ソースツリーのクリーン (debian/rules clean) * ソースパッケージのビルド (dpkg-source -b) * プログラムのビルド (debian/rules build)     * バイナリーパッケージのビルド (fakeroot debian/rules binary) * gpg を使用したソース.dscファイルへの署名 * dpkg-genchangesおよびgpgを使用したアップロード用.changesファ イルの生成と署名 あなたの GPG 秘密パスフレーズを２回入力するだけが必要なことです。     ^[64] 自分自身のローカルでの使用のためだけに Debian パッケージを 作っている場合は、.dsc ファイルと .changes ファイルに GPG 署名す るためのプロンプトを以下のようにしてスキップ出来ます:     $ dpkg-buildpackage -us -uc     ノンネイティブパッケージの場合、パッケージビルド後の親ディレクト リー (~/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)によってソースを展 開する時に使われます。また、GPG で署名されているので、本当に あなた自身が作成したものかどうかを利用者が検証できます。 * gentoo_0.9.12-1.debian.tar.gz この圧縮されたターボールには、あなたのdebianディレクトリーの 中身が含まれています。オリジナルのソースコードに行った変更や 追加などの情報は全て debian/patches 内に、quilt パッチとして 保存されます。 上記３つのファイルを使えば誰でも簡単にあなたのパッケージをス クラッチからビルドすることができます。３つのファイルを任意の 場所にコピーし、dpkg-source -x gentoo_0.9.12-1.dscを実行する     だけです。^[65] * gentoo_0.9.12-1_i386.deb これは、あなたが生成した完全なバイナリーパッケージです。他の 全てのパッケージと同じく、dpkgを使ってインストールしたり削除 したりできます。 * gentoo_0.9.12-1_i386.changes このファイルは現在のリビジョンパッケージにおける変更点をすべ て記載したもので、Debian FTP アーカイブ管理プログラムによって 、バイナリーおよびソースパッケージを FTP アーカイブにインスト ールするために利用されます。このファイルの一部は、changelog ファイルと .dsc をもとに生成されます。また、GPG で署名されて いるので、本当にあなた自身が作成したものかどうかを利用者が検 証できます。 パッケージの保守管理を続けていくと、挙動の変更や新機能の追加 をすることがあります。あなたのパッケージをダウンロードする人 は、このファイルを見れば何が変わったのか、一目でわかります。 また、このファイルの中身は Debian アーカイブ管理プログラムに よって、debian-devel-changes@lists.debian.org (http:// lists.debian.org/debian-devel-changes/) メーリングリストへ流 されます。 .dsc と .changes ファイルに記載されている長い数字の羅列は各ファイ ルの MD5/SHA1/SHA256 チェックサムです。パッケージをダウンロードし     た人は、sha1sum(1)、sha256sum(1)を使って整合性をテストすることが できます。もし、数字が一致しない場合には、ファイルが壊れているか 、あるいは何者かによって改ざんされていると分かるわけです。     ネイティブパッケージの場合、一連の作業が終わった後の親ディレクト リー (~/gentoo) には以下のファイルが生成されているはずです。 * mypackage_1.0.tar.gz これは、dpkg-source コマンドにより mypackage-1.0 ディレクトリ ーから作られたソースコード tar 玉です。(そのサフィックスは orig.tar.gz ではありません。) * mypackage_1.0.dsc これは、ノンネイティブ Debian パッケージと同様でソースコード 内容の要約です。(Debian リビジョンはありません。)     * mypackage_1.0_i386.deb これは、ノンネイティブ Debian パッケージと同様で完成したバイ ナリーパッケージです。(Debian リビジョンはありません。) * mypackage_1.0_i386.changes これは、ノンネイティブ Debian パッケージと同様で現パッケージ バージョンでの全変更を記述します。(Debian リビジョンはありま せん。) 6.2. オートビルダー Debian は、様々なアーキテクチャー上で buildd デーモンを走らせてい るオートビルダーネットワーク (http://www.debian.org/devel/buildd /) によって、色々な移植版 (http://www.debian.org/ports/) をサポー     トしています。あなたがそれらを明示的に使う必要はありませんが、パ ッケージがどうなるのかを知っておくと良いでしょう。それでは、あな たのパッケージがどのように異なるアーキテクチャー向けに再ビルドさ れるのかを見ていきましょう。^[66]     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フィールドのパッケージは、通常のパッケージの場 合はインストールを要求されますが (参照「完全な（再）ビルド」)、オ ートビルダーシステムでは、アーキテクチャー依存のパッケージのみを     ビルドするのでこれらのインストールは必須ではありません。^[67] オ ートビルダーを使用した場合と普通のパッケージングとのこの違いによ り、debian/control ファイルの Build-Depends か Build-Depends-indep のどちらにパッケージを記載するかが決定されま す。(参照「control」) 6.3. debuildコマンド     dpkg-buildpackageによる自動ビルドプロセスは、debuildによりさらに 進めることができます。debuild(1)を参照してください。 debuild コマンドのカスタマイズは /etc/devscripts.conf や ~     /.devscripts を用いて行います。少なくとも以下の設定をすると良いで しょう。     DEBSIGN_KEYID=Your_GPG_keyID DEBUILD_LINTIAN_OPTS=-i -I --show-overrides これによって、パッケージは常にあなたのGPG鍵で署名され（これはスポ     ンサーの作業にも適しています）、lintianコマンドで詳細にチェックさ れます。     以下のようにすれば一般ユーザーアカウントから、簡単にソースをクリ ーンしパッケージを再ビルドできます。     $ debuild もしあなたが Debian パッケージを自分自身のローカル使用のためにの     み作成している場合は、.dsc ファイルや .changes ファイルへのGPG 署 名のプロンプトを次のようにするとスキップできます。     $ debuild -us -uc     ソースツリーのクリーンも簡単です     $ debuild clean 6.4. pbuilderパッケージ ビルド依存を確認するためのクリーンルーム (chroot) ビルド環境とし て、pbuilder パッケージが非常に便利です。^[68] これを使うことで、     異なるアーキテクチャー向けに sid 環境オートビルダーの下でのソース からのクリーンなビルドが保証され、常に RC (リリースクリチカル) に 分類される重要度が serious (深刻)の FTBFS (Fails To Build From Source、ソースからのビルド失敗) バグを防ぎます。^[69]     それでは、pbuilder をカスタマイズしてみましょう。 * /var/cache/pbuilder/resultディレクトリーを、ユーザーアカウン トから書き込めるように設定してください。 * フックスクリプトを置くために、ユーザーからの書き込みが可能な ディレクトリーを作成してください。例） /var/cache/pbuilder/     hooks * ~/.pbuilderrc か /etc/pbuilderrc に以下のように設定します。 AUTO_DEBSIGN=${AUTO_DEBSIGN:-yes} HOOKDIR=/var/cache/pbuilder/hooks     これにより、~/.gnupg/ディレクトリーにある、あなたのGPGキーで生成 されたパッケージへの署名を許可します。     それでは、初めてのローカル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.dsc $ debsign foo_version_arch.changes 更新されたソースツリーが既にあるが一致するソースパッケージを生成     していない場合は、この代わりに、debian ディレクトリーが存在するデ ィレクトリーで、以下のコマンドを発行します。     $ sudo pbuilder --update $ pdebuild ここで、あなたのローカル使用のためにのみ Debian パッケージをビル     ドしている場合、.dscファイルと .changes ファイルに GPG 署名をする プロンプトを以下のようにすればスキップできます:     $ AUTO_DEBSIGN=no pdebuild pbuilder --login --save-after-loginコマンドで、chroot環境にログイ     ンし、好きに設定することができます。シェルプロンプトから^D (Control-D)で抜けると、その環境を保存しておくことができます。 最新のlintianコマンドはchroot環境から次のように設定されたフックス     クリプト/var/cache/pbuilder/hooks/B90lintianを使用して実行するこ とができます。^[70] #!/bin/sh set -e install_packages() { apt-get -y --force-yes 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 パッケージのアップデートが必要な場合があります。^[71]そのような場     合に、即座にアップデートしない言い訳として sid を使っているからと いうのは不十分です。pbuilderパッケージは、同じアーキテクチャーの ほぼ全ての Debian 派生であるディストリビューションへのアクセスを 手助けします。 http://www.netfort.gr.jp/~dancer/software/pbuilder.html (http://     www.netfort.gr.jp/~dancer/software/pbuilder.html) と pdebuild(1) と pbuilderrc(5) と pbuilder(8) を参照下さい。 6.5. git-buildpackageコマンドとその仲間 アップストリームがソースコード管理システム (VCS) ^[72] を使ってい るのであれば、同様に使用することを考えるべきです。それによって、     マージとアップストリームパッチの取捨選択がより簡単になります。各 VCS 毎に Debian パッケージをビルドするための特別なラッパースクリ プトのパッケージもいくつかあります。 * git-buildpackage: Git リポジトリ内の Debian パッケージの支援 プログラム群です。     * svn-buildpackage:Debian パッケージを Subversion で管理するた めの支援プログラム群です。 * cvs-buildpackage: CVS ソースツリーのための Debian パッケージ スクリプト群です。 Debian デベロッパーが alioth.debian.org (http://alioth.debian.org     /) 上の Git サーバーを用い Debian パッケージを管理するのに git-buildpackage を使うことがよくあります。^[73] このパッケージは パッケージ活動を自動化する多くのコマンドを提供します。 * git-import-dsc(1): 過去の Debian パッケージを Git レポジトリ ーにインポートする。 * git-import-orig(1): 新アップストリーム tar を Git レポジトリ ーにインポートします。     * git-dch(1): Debian changelog を Git のコミットメッセージから 生成します。 * git-buildpackage(1): Debian パッケージを Git レポジトリーから ビルドします。 * git-pbuilder(1): Debian パッケージを Git レポジトリーから pbuilder/cowbuilder を持ちいてビルドします。     これらのコマンドはパッケージング活動を追跡する 3 つのブランチを使 用します。 * Debian パッケージのソースツリーは、main 。     * アップストリームのソースツリーは、upstream。 * --pristine-tar オプションにより生成されるアップストリーム tar 玉は、pristine-tar。^[74]     git-buildpackage は ~/.gbp.conf で設定できます。gbp.conf(5) を参 照下さい。 ^[75] 6.6. 部分的な再ビルド 大規模なパッケージの場合には、debian/rules をちょっといじるたびに     、毎回最初からパッケージの再ビルドをやりなおすのは手間です。テス ト目的であれば、以下の方法でアップストリームソースを再ビルドをせ ずに .deb ファイルを生成することができます。 ^[76]:     $ fakeroot debian/rules binary     また、以下の方法を使えば生成可能かどうかをチェックすることができ ます。     $ fakeroot debian/rules build 最終的にきちんとテストが完了したら、正しい手順に従ってパッケージ     を最初から再ビルドすることを忘れないでください。この方法でビルド した .deb ファイルをアップロードしようとしても、おそらくうまくア ップロードできないでしょう。 -------------- ^[64] This GPG キーは信頼の網に連結するように Debian デベロッパー によって署名され、the Debian keyring (http://keyring.debian.org) に登録されていなければいけません。こうすることで Debian アーカイ     ブにパッケージをアップロードして受け付けられるようになります。 Creating a new GPG key (http://keyring.debian.org/ creating-key.html) と Debian Wiki on Keysigning (http:// wiki.debian.org/Keysigning ) を参照下さい。 ^[65] 3.0 (quilt)ソースフォーマットでquiltパッチを当てないように     するには、上記コマンドに--skip-patchesオプションをつけて実行しま す。または、通常の操作の後に、quilt pop -aを実行する方法もありま す。 ^[66] 実際のオートビルダーシステムは、本稿の説明よりもかなり複雑     なスキームによって実現しています。それらの詳細は、本稿の範囲を超 えるため割愛します。 ^[67] pbuilderパッケージとは違い、オートビルダーによって使用され     るsbuildパッケージ下でのchroot環境では、最小システムを強制しない ので、多くのパッケージがインストールされたままになるかもしれませ ん。     ^[68] pbuilderパッケージはまだ進化の過程なので、実際の構成は、最 新の公式ドキュメントで確認して下さい。     ^[69] Debian パッケージのオートビルドに関しては http:// buildd.debian.org/ (http://buildd.debian.org/) を参照下さい。 ^[70] HOOKDIR=/var/cache/pbuilder/hooks をここで仮定しています。     フックスクリプトのサンプルは /usr/share/doc/pbuilder/examples デ ィレクトリーににあります。     ^[71] stable パッケージのそのようなアップデートには制限が課せられ ます。 ^[72] 詳しくは Version control systems (http://www.debian.org/doc     /manuals/debian-reference/ch10#_version_control_systems) を参照下 さい。 ^[73] alioth.debian.org (http://alioth.debian.org/) サービスの使     い方は、Debian wiki Alioth (http://wiki.debian.org/Alioth) に記載 されています。 ^[74] --pristine-tar オプションは、小さなバイナリデルタと通常 VCS     の upstream ブランチ中に保存された tar 玉の内容のみを用い完全に元 通りの手付かずの tar 玉を再生成する pristine-tar コマンドを起動し ます。     ^[75] 以下は、上級者のみなさんの参考になるウェブ上で閲覧できる資 料です。 * git-buildpackage を使っての Debian パッケージ作成 (/usr/share /doc/git-buildpackage/manual-html/gbp.html) * debian packages in git (https://honk.sigxcpu.org/piki/ development/debian_packages_in_git/) * Using Git for Debian Packaging (http://www.eyrie.org/~eagle/     notes/debian/git.html) * git-dpm: Debian packages in Git manager (http:// git-dpm.alioth.debian.org/) * Using TopGit to generate quilt series for Debian packaging (http://git.debian.org/?p=collab-maint/topgit.git;a= blob_plain;f=debian/HOWTO-tg2quilt;hb=HEAD) ^[76] その場合は、通常だと正しく設定される環境変数は設定されませ     ん。アップロード用のパッケージはこの簡易メソッドで生成しないでく ださい。 第7章パッケージのエラーの検証 ここでは, 公式アーカイブにパッケージをアップロードする前に、作成     したパッケージのエラーをあなた自身で確認するために知っておかなけ ればならない方法について、幾つか述べます。 あなたのマシン以外でのテストもまた良いアイデアです。以下に述べる     すべてのテストにおける、どんな警告とエラーについてでもしっかりと 確認しておかなければなりません。 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 コマンドは     パッケージ作成時のよくある間違いをチェックするために多くのテスト スクリプトを実行します。^[77]     $ 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 を調整し これを修正して下さい。 -------------- ^[77] /etc/devscripts.conf や ~/.devscripts において「debuildコマ     ンド」で述べた設定をしている場合には、lintian に -i -I --show-overrides オプションを指定する必要はありません。 第8章パッケージをアップロードする     あなたの新しいパッケージは徹底的にテストできたので、あなたはそれ を共有すべく公開アーカイブにリリースしたいでしょう。 8.1. Debian アーカイブへアップロードする 正規デベロッパー^[78]になると、パッケージを Debian アーカイブにア     ップロードできます。^[79] 手動でもできますが、 dupload(1) や dput (1) 等の既存の自動化ツールを用いる方が楽です。ここでは dupload を 使ってどうするかを説明します。^[80] まず dupload の設定ファイルを調整しなければいけません。システム全     体の設定ファイルである /etc/dupload.conf を編集するか、あるいはあ なた専用の設定ファイルである ~/.dupload.conf を使って変更したい項 目だけをオーバーライドさせてもかまいません。     またそれぞれのオプションが持つ意味を理解するため dupload.conf(5) マニュアルページを読むことができます。 $default_host オプションはデフォルトで利用されるアップロードキュ     ーを指定します。anonymous-ftp-masterがメインのアップロードキュー ですが、別のアップロードキューを利用したいこともあるでしょう。^[ 81]     インターネットにつながった状態で、以下のようにすればあなたのパッ ケージをアップロード出来ます。     $ dupload gentoo_0.9.12-1_i386.changes dupload は各ファイルの SHA1/SHA256 チェックサムを計算し、     .changes ファイルの中の情報と照合します。もしそれらが一致しない場 合には、適正にアップロードされるように「完全な（再）ビルド」の説 明に従って最初から再ビルドをするよう警告します。 ftp://ftp.upload.debian.org/pub/UploadQueue/ (ftp:// ftp.upload.debian.org/pub/UploadQueue/) へのアップロードで問題が     あった場合には、GPG 署名した *.commands ファイルを ftp を用いて ftpで手動アップロードすることで修正出来ます。 ^[82] 例えば、 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----- 8.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 ソースファ イルを強制的に除外します。 8.3. スキップされたアップロード アップロードをスキップすることで debian/changelog 中に複数の項目 を作成した場合は、前回アップロード以来の全ての変更を含む適切な     *_.changes ファイルを作成しなければいけません。 dpkg-buildpackage オプションの -v を、例えば 1.2 と言うバージョンに関して指定すると 可能です。     dpkg-buildpackage コマンドの場合:     $ dpkg-buildpackage -v1.2     debuildコマンドの場合:     $ debuild -v1.2     debuildコマンドの場合:     $ pdebuild --debbuildopts "-v1.2" --------------     ^[78] 「Debianにおける社会ダイナミクス」を参照下さい。 ^[79] Debian アーカイブとほぼ同様に機能し、非-DD に対してアップロ ードエリアを提供する http://mentors.debian.net/ (http:// mentors.debian.net/) のような公開アーカイブがあります。http://     wiki.debian.org/HowToSetupADebianRepository (http:// wiki.debian.org/HowToSetupADebianRepository) に列記されているツー ルを使い自分自身で同様のアーカイブを設定することも出来ます。だか らこのセクションは非-DD にも有用です。 ^[80] dput パッケージは、より多くの機能があり dupload パッケージ     より人気が出てきています。それは、/etc/dput ファイルをグローバル 設定に用い、 ~/.dput.cf ファイルをユーザー毎の設定に用います。更 にそれは、そのままUbuntu関連のサービスもサポートします。 ^[81] Debian Developer's Reference 5.6. "Uploading a package"     (http://www.debian.org/doc/manuals/developers-reference/pkgs.html #upload) を参照下さい。 ^[82] ftp://ftp.upload.debian.org/pub/UploadQueue/README (ftp://     ftp.upload.debian.org/pub/UploadQueue/README) を参照下さい。dput パッケージ中にある dcut コマンドをこれに代わる方法として用いるこ ともできます。 第9章パッケージの更新     パッケージをリリースしたなら、間もなくそれを更新する必要がありま す。 9.1. Debian リビジョンの更新 例えば仮に、#654321 という番号のバグレポートがあなたのパッケージ     に対してファイルされ、解決可能な問題が記述されていたとしましょう 。パッケージの新しい Debian リビジョンを作成するには、以下を実行 する必要があります。 * もしこれが新規のパッチとして記録される場合には、以下のように します。 o dquilt new bugname.patch としてパッチ名を設定します。 o dquilt add buggy-file として変更されるファイルを宣言しま す。 o アップストリームバグに関してパッケージソース中の問題を修 正します。 o dquilt refresh として bugname.patch に記録します。 o dquilt header -e としてその内容記述を追加します。 * もし既存のパッチをアップデートする場合には、以下のようにしま す。 o dquilt pop foo.patch として既存の foo.patch を呼び出しま す。 o 古い foo.patch 中の問題を修正します。 o dquilt refresh として foo.patch を更新します。 o dquilt header -e としてその内容記述を更新します。 o while dquilt push; do dquilt refresh; done として fuzz を     削除しながら全てのパッチを適用します。 * 次に Debian changelog ファイルの先頭に新しいリビジョンを追加 します。例えばdch -iを実行するか、またはバージョンを明示した い場合ならdch -v version-revision を実行してあなたの好きなエ ディタで説明を記入すると楽にできます。^[83] * changelog の説明行に、このリビジョンで解決されたバグと、その 解決方法についての簡単な説明を記載し、Closes: #54321 と続けて おきます。これによってあなたのパッケージが Debian アーカイブ 中に受け入れられた時、アーカイブ管理ソフトウェアによって該当 するバグレポートが魔法のように自動的に閉じられます。 * 上記であなたがしたことを繰り返し、必要に応じて Debian changelog ファイルを dch で更新しながら、更なるバグ修正を行い ます。 * 「完全な（再）ビルド」と 7章パッケージのエラーの検証で行った ことを繰り返して下さい。 * 一旦満足した時点で、changelog 中のディストリビューション値を UNRELEASED からターゲットディストリビューション値 unstable (もしくは場合に依っては experimental) へと変更すべきです。^[ 84] * 8章パッケージをアップロードすると同様にパッケージをアップロー ドします。今までと違うのは、今回の場合オリジナルソースアーカ イブには変更が無く、同じものが既に Debian アーカイブ中に存在 しているため、アップロードするファイルにはオリジナルのソース アーカイブが含まれないという点だけです。 例えばオフィシャルのアーカイブへ 1.0.1-1 のようなノーマルのバージ ョンをアップロードする前にパッケージングを色々試すべくローカルパ ッケージを作る時には要注意です。スムースなアップグレードのために     は、1.0.1-1~rc1 のような文字列のバージョンの項目をchangelog に作 るのがいい考えです。オフィシャルパッケージのためには、そのような ローカル変更の複数項目を単一の項目にまとめて changelog をすっきり させてもいいです。バージョン文字列の順序に関しては「パッケージ名 とバージョン」を参照下さい。     9.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 を実行 する前に消去してもいいです。 9.3. アップストリームソフトウェアの新版更新 もし foo パッケージが新規の 3.0 (native) や 3.0 (quilt) フォーマ ットで適正にパッケージされていれば、新規のアップストリームバージ     ョンをパッケージスリのは基本的に旧 debian ディレクトリーを新規ソ ースへと移動するのみです。これは新規に展開されたソース中で tar xvzf /path/to/foo_oldversion.debian.tar.gz を実行すれば出来ます。 ^[85] もちろん当然するべき細々としたことをする必要はあります。 * アップストリームソースのコピーを foo_newversion.orig.tar.gz ファイルとして作成します。 * Debian の changelog ファイルを dch -v newversion-1 を使って更 新します。 o New upstream release という項目を追加します。     o 報告のあったバグを修正する新規アップストリームリリース中 の変更点に関して簡潔に記載しバグを Closes: #バグ番号と追 記してクローズします。 o 報告のあったバグを修正する、メンテナーによる新規アップス トリームリリースへのの変更点に関して簡潔に記載しバグを Closes: #バグ番号と追記しクローズします。 * while dquilt push; do dquilt refresh; done として fuzz を削除 しながら全てのパッチを適用します。     もしパッチやマージがクリーンに適用できない場合は、状況を精査しま す (.rej ファイル中にヒントがあります)。 * もしソースにあなたが適用していたパッチがアップストリームソー スに統合された場合は、 o dquilt delete として削除します。 * もしソースにあなたが適用していたパッチが新規アップストリーム ソースとぶつかる場合は、     o dquilt push -f として baz.rej としてリジェクトを強制しな がら古いパッチを適用します。 o baz.rej の本来目指した効果を実現するように、baz ファイル を手動で編集します。 o 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 コマンドを実行します。^[86] 今まで「完全な（再）ビルド」、 7章パッケージのエラーの検証、8章パ     ッケージをアップロードするの中で実行してきたことを繰り返し、更新 したソースをリリースできます。 9.4. パッケージ化スタイルの更新 パッケージスタイルの　更新はパッケージ更新のために必須活動ではあ     りません。しかし、こうすることで最新の debhelper システムと 3.0 ソースフォーマットの全能力を活用できます。^[87] * もし何らかの理由で消去されたテンプレートファイルを追加する必 要がある場合には、同一の Debian ソースツリーの中で --addmissing オプションとともに dh_make をもう一度実行しても いいです。そして、それらを適正に編集しましょう。 * debian/rules ファイルに関して debhelper v7+ dh シンタックスへ とパッケージが更新されていない場合は dh を使うように更新しま しょう。debian/control ファイルもそれに合わせて変更しましょう 。 * コモン Debian ビルドシステム (cdbs) による Makefile 包含メカ ニズムで生成された rules ファイルを dh シンタックスに更新しよ うとする場合には、以下を参照し DEB_* 設定変数を理解して下さい 。 o /usr/share/doc/cdbs/cdbs-doc.pdf.gz のローカルコピー o The Common Debian Build System (CDBS), FOSDEM 2009 (http: //meetings-archive.debian.net/pub/debian-meetings/2009/ fosdem/slides/The_Common_Debian_Build_System_CDBS/)     * 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 システムに インポートします。^[88] * -p0 や -p1 や -p2 を使う dpatch や dbs や cdbs のような他のパ ッチシステムを用いてパッケージされ得ている場合には、http:// bugs.debian.org/581186 (http://bugs.debian.org/581186) にある deb3 を用いて quilt コマンドに変換します。 * もし --with quilt オプション付きの dh コマンドとか、 dh_quilt_patch と dh_quilt_unpatch コマンドを用いてパッケージ されている場合には、これらを削除し新規の 3.0 (native) ソース フォーマットを使うようにします。     DEP - Debian エンハンスメント提案 (http://dep.debian.net/) を確認 し、ACCEPTED (採用) となった提案を取り入れるべきです。     「アップストリームソフトウェアの新版更新」に記載された他の作業も 行う必要があります。 9.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=C.UTF-8 w3m -o display_charset=UTF-8 \ -cols 70 -dump -no-graph -T text/html \ < foo_in.html > foo_out.txt 9.6. パッケージをアップグレードする際の注意点     パッケージをアップグレードする際の注意点は以下です。 * changelog の旧項目を保全します (自明ですが、dch -i とするべき 時に dch とした過去事例があります。) * 現存の Debian による変更は再評価する必要があります。(何らかの 形で)アップストリームが組み込んだことは捨て、アップストリーム が組み込まなかったことは残しましょう。 * ビルドシステムに変更が加えられた場合には (アップストリームの 変更を精査した際に分かっているはずですよね)、必要に応じて     debian/rules と debian/control のビルド依存関係を更新します。 * 現存もオープンのバグへのパッチを誰かが提供していないかを、 Debian Bug Tracking System (BTS) (http://www.debian.org/Bugs /) で確認します。 * 正しいディストリビューションへアップロードすること、 Closes フィールドに適切なバグのクローズがリストされていること、 Maintainer と Changed-By フィールドがマッチしていること、ファ イルが GPG 署名されていること等を確実にするように、.changes ファイルの内容を確認します。 --------------     ^[83] 日付を要求されるフォーマットで入力するには、LANG=C date -R を使います。     ^[84] もし dch -r コマンドを使ってこの最終変更をする場合には、エ ディターにより changelog ファイルを明示的に保存して下さい。 ^[85] もしパッケージ foo が旧 1.0 フォーマットでパッケージされて     いる場合は、新規に展開されたソース中で zcat /path/to/foo_ oldversion.diff.gz|patch -p1 を実行すれば出来ます。 ^[86] もし uscan コマンドが更新されたソースはダウンロードするが     uupdate コマンドを実行しない場合には、URLの最後に debian uupdate となるように debian/watch ファイルを修正するべきです。 ^[87] もしあなたのスポンサーや他のメンテナーが既存のパッケージス     タイル更新に異存がある場合には、更新することもまたその議論するこ とは意味がありません。他にするべきより重要なことがあります。     ^[88] splitdiff コマンドを用いると big.diff は多くの小さな増分パ ッチに分割できます。 付録A 上級パッケージング あなたが出会いそうな上級パッケージング課題に関するヒントや外部参     照をいくつか記します。ここに提案されたレファレンス全てに目を通す ことを切にお薦めします。 A.1. 共有ライブラリー     共有ライブラリーをパッケージングする前に、以下の一次レファレンス を詳細に読むべきです。 * Debian Policy Manual, 8 "Shared libraries" (http:// www.debian.org/doc/debian-policy/ch-sharedlibs.html)     * Debian Policy Manual, 9.1.1 "File System Structure" (http:// www.debian.org/doc/debian-policy/ch-opersys.html#s-fhs) * Debian Policy Manual, 10.2 "Libraries" (http://www.debian.org /doc/debian-policy/ch-files.html#s-libraries)     以下はあなたが手を付け始めるための少々簡略化しすぎたヒントです。 * 共有ライブラリーとはコンパイルされたコードを含む ELF オブジェ クトファイルです。 * 共有ライブラリーは *.so ファイルとして頒布されます。(*.a ファ イルでも *.la ファイルでもありません) * 主に、共有ライブラリーは ld メカニズムを用い複数の実行プログ ラム間でコードを共有するのに使用されます。 * 時々、共有ライブラリーは dlopen メカニズムを用いある実行プロ グラムに複数のプラグインを提供するのに使用されます。 * 共有ライブラリーは変数や関数やクラスのようなコンパイルされた オブジェクトを表すシンボルをエキスポートし、リンクされた実行 プログラムからそれらへのアクセスを可能とします。 * 共有ライブラリー libfoo.so.1 の SONAME: objdump -p libfoo.so. 1 | grep SONAME ^[89] * 共有ライブラリーの SONAME は通常ライブラリーのファイル名と一 致します(例外もあります)。 * /usr/bin/foo にリンクされた共有ライブラリーの SONAME: objdump     -p /usr/bin/foo | grep NEEDED ^[90] * libfoo1: 共有ライブラリー libfoo.so.1 で SONAME ABI バージョ ンが 1 のライブラリーパッケージ。^[91] * ライブラリーパッケージのパッケージメンテナースクリプトは SONAME に必要なシンボリックリンクを作成するために特定の環境下 で ldconfig を呼ばなければいけません。^[92] * libfoo1-dbg: 共有ライブラリー libfoo1 のデバグシンボルを含む デバグシンボルパッケージ。 * libfoo-dev: 共有ラーブラリー libfoo.so.1 用のヘッダーファイル 他を含む開発用パッケージ。^[93] * Debian パッケージは一般的に *.la Libtool アーカイブファイルを 含んではいけません。^[94] * Debian パッケージは一般的に RPATH を使うべきではありません。^ [95] * 少々内容が古くなった二次的なレファレンスですが、Debian Library Packaging Guide (http://www.netfort.gr.jp/~dancer/ column/libpkg-guide/libpkg-guide.html) はまだ有用かもしれませ ん。 A.2. debian/package.symbols の管理 共有ライブラリーをパッケージする際には、同一共有ライブラリーパッ ケージ名のライブラリーの同一 SONAME の下でのバックワードコンパテ     ィブルな変更に関して、各シンボルと関連付けられる最小のバージョン が記された debian/package.symbols ファイルを作成すべきです。^[96] 以下の1次的レファレンスを詳細に読むべきです。 * Debian Policy Manual, 8.6.3 "The symbols system" (http:// www.debian.org/doc/debian-policy/ch-sharedlibs.html# s-sharedlibs-symbols) ^[97] * dh_makeshlibs(1)     * dpkg-gensymbols(1) * dpkg-shlibdeps(1) * deb-symbols(5) 過去バージョン 1.3 のアップストリームバージョンから適切な debian/     libfoo1.symbols ファイルを用いて libfoo1 パッケージをを作成する概 略例は以下です。 * アップストリームの libfoo-1.3.tar.gz ファイルを持ちいて Debian 化 したソースツリーの骨子を準備します。 o もし libfoo1 パッケージの最初のパッケージングの場合は、内容が 空の debian/libfoo1.symbols ファイルを作成します。 o もし以前のアップストリームバージョン 1.2 が libfoo1 パッケー ジとして適切な debian/libfoo1.symbols をそのパッケージ内に持 ちいてパッケージされていた場合には、それを再び使いましょう。 o もし過去のアップストリームバージョン 1.2 が debian/ libfoo1.symbols を用いてパッケージされていない場合には、その ライブラリーの同一 SONAME を含む同一共有ライブラリーパッケー ジ名の全ての手に入るバイナリーパッケージ、例えば 1.1-1 と 1.2-1 バージョンから、それを symbols として生成できます。^[98 ] $ 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 and 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 ファイルを抽出しましょう。^[99] $ 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 コンパティビリティーを確認し、必要に応     じていくつかのシンボルのバージョンをマニュアル操作で繰り上げる必 要があります。^[100] 2 次的なレファレンスではありますが、Debian wiki UsingSymbolsFiles     (http://wiki.debian.org/UsingSymbolsFiles) とそこからリンクされて いるウエッブページは有用かもしれません。 A.3. マルチアーチ Debian wheezy で導入されたマルチアーチフィーチャーは dpkg と apt     の中でのバイナリーパッケージのアーキテクチャー間サポート (他の組 み合わせもありますが、特にi386<->amd64) を統合します。以下のレフ ァレンスを詳細に読んで下さい。 * Ubuntu wiki MultiarchSpec (https://wiki.ubuntu.com/ MultiarchSpec) (アップストリーム)     * Debian wiki Multiarch/Implementation (http://wiki.debian.org/ Multiarch/Implementation) (Debian の状況) マルチアーチは共有ライブラリーのインストールパスに i386-linux-gnu や x86_64-linux-gnu 等のトリプレットを使います。実際のトリプレッ     トパスは、ビルドごとに dpkg-architecture(1) によって動的に $ (DEB_HOST_MULTIARCH) 値として設定されます。例えば、マルチアーチラ イブラリーをインストールするパスは以下のように変更されます。^[101 ] +-------------------------------------------------------------+ |旧パス |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 を更新します。 o ソースパッケージセクションに Build-Depends: debhelper (>=9) を追加します。 o 共有ライブラリーのバイナリーパッケージごとに Pre-Depends: $ {misc:Pre-Depends} を追加します。 o Multi-Arch: スタンザを各バイナリーパッケージセクション毎に追 加します。 * debian/compat を "9" と設定します。 * すべてのパッケージングスクリプトに関して、通常の /usr/lib/ から、 マルチアーチの /usr/lib/$(DEB_HOST_MULTIARCH)/ へとパスを調整しま す。 o 最初に debian/rules 中で DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH) を呼び     DEB_HOST_MULTIARCH 変数を設定します。 o debian/rules 中の /usr/lib/ を /usr/lib/$(DEB_HOST_MULTIARCH) / で置き換えます。 o もし debian/rules 中の override_dh_auto_configure ターゲット の一部分として ./configure が用いられている場合には、それを dh_auto_configure -- と置き換えるようにしましょう。^[102] o debian/foo.install ファイル中にある全ての /usr/lib/ を /usr/ lib/*/ で置き換えます。 o 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 パ ッケージも依然として動作することを確認しましょう。 マルチアーチパッケージとして同時に同一パスにインストールされる全     てのファイルはファイルの内容が完全に同じあるべきです。データーの バイトオーダーや圧縮アルゴリズムにより生成される相違に注意すべき です。 --------------     ^[89] もしくは: readelf -d libfoo.so.1 | grep SONAME     ^[90] もしくは: readelf -d libfoo.so.1 | grep NEEDED ^[91] Debian Policy Manual, 8.1 "Run-time shared libraries"     (http://www.debian.org/doc/debian-policy/ch-sharedlibs.html# s-sharedlibs-runtime) を参照下さい。 ^[92] Debian Policy Manual, 8.1.1 "ldconfig" (http://     www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-ldconfig) を参照下さい。 ^[93] See Debian Policy Manual, 8.3 "Static libraries" (http:// www.debian.org/doc/debian-policy/ch-sharedlibs.html#     s-sharedlibs-static) and Debian Policy Manual, 8.4 "Development files" (http://www.debian.org/doc/debian-policy/ ch-sharedlibs.html#s-sharedlibs-dev) を参照下さい。     ^[94] Debian wiki ReleaseGoals/LAFileRemoval (http:// wiki.debian.org/ReleaseGoals/LAFileRemoval) を参照下さい。     ^[95] Debian wiki RpathIssue (http://wiki.debian.org/RpathIssue) を参照下さい。 ^[96] バックワード非コンパティブルな ABI 変更をすると、通常ライブ     ラリーの SONAME と共有ライブラリーパッケージ名を新規なものにそれ ぞれアップデートしないといけません。 ^[97] C++ ライブラリーや個別シンボルを追跡するのが非常に困難な他     の場合には、これに代えて Debian Policy Manual, 8.6.4 "The shlibs system" (http://www.debian.org/doc/debian-policy/ ch-sharedlibs.html#s-sharedlibs-shlibdeps) に従いましょう。 ^[98] Debian パッケージの過去全てのバージョンは http:// snapshot.debian.org/ (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     ^[99] Debian リビジョンはパッケージのバックポートを容易にすべく外 します: 1.3 << 1.3-1~bpo70+1 << 1.3-1 ^[100] Debian Policy Manual, 8.6.2 "Shared library ABI changes"     (http://www.debian.org/doc/debian-policy/ch-sharedlibs.html# s-sharedlibs-updates) を参照下さい。     ^[101] 旧来の /lib32/ や /lib64/ 等の特定目的のライブラリーパスは 使われなくなっています。 ^[102] これに代えて、./configure に --libdir=\$${prefix}/lib/$ (DEB_HOST_MULTIARCH) と --libexecdir=\$${prefix}/lib/$ (DEB_HOST_MULTIARCH) 引数を追加することもできます。注意いただきた     いのは、ユーザーではなく他のプログラムによりのみ実行される実行プ ログラムをインストールするデフォルトパスを --libexecdir は設定し ます。その Autotools のデフォルトは /usr/libexec/ ですが、Debian デフォルトは /usr/lib/ です。