Debian 新メンテナガイド ----------------------- Josip Rodin 翻訳: 八田真行 日本語訳更新 (v1.2): 佐野武俊 version 1.2, 6 April 2002. ------------------------------------------------------------------------------- 著作権表示 ---------- Copyright (C) 1998-2002 Josip Rodin. この文書は GNU 一般公有使用許諾書、バージョン 2 かそれ以降が 規定する条件の下で利用できます。 この文書は以下の二つの文書を参考として書かれました。 Debian パッケージの作り方 (Debmake マニュアル)、 Copyright (C) 1997 Jaldhar Vyas. 新米メンテナのための Debian パッケージング Howto、 Copyright (C) 1997 Will Lowe. ------------------------------------------------------------------------------- 目次 ---- 1. まずは「正しいやり方で」始めよう 1.1. 開発に必要なプログラム 1.2. その他知っておくべきこと 2. はじめの一歩 2.1. パッケージ化するプログラムの選定 2.2. プログラムを手にいれて、試してみる 2.3. パッケージ名とバージョン 2.4. 最初の「Debian 化」 3. ソースコードの変更 3.1. サブディレクトリへのインストール 3.2. 使用ライブラリの違い 4. debian/ ディレクトリ以下に無くてはならないファイル 4.1. 「control」ファイル 4.2. 「copyright」ファイル 4.3. 「changelog」ファイル 4.4. 「rules」ファイル 5. debian/ の中にあるその他のファイル 5.1. README.Debian 5.2. conffiles.ex 5.3. cron.d.ex 5.4. dirs 5.5. docs 5.6. emacsen-*.ex 5.7. init.d.ex 5.8. manpage.1.ex, manpage.sgml.ex 5.9. menu.ex 5.10. watch.ex 5.11. ex.package.doc-base 5.12. postinst.ex、preinst.ex、postrm.ex、prerm.ex 6. パッケージの構築 6.1. 完全な再構築 6.2. 部分的な再構築 7. できたパッケージの誤りを調べる 8. パッケージをアップロードする 9. パッケージの更新 9.1. Debian レビジョンの更新 9.2. 上流ソフトウェアの更新 (New upstream release) 9.3. Verifying package upgrades 10. 相談するには ------------------------------------------------------------------------------- 1. まずは「正しいやり方で」始めよう ----------------------------------- この文書では、Debian パッケージを作るにはどうしたらよいか、 一般的な Debian ユーザと開発者予備軍を対象に解説しようと思います。 小難しい専門用語はできるだけ避けて、実用的な例を多く用いて説明していく つもりです。ことわざにもあるように、_百聞は一見にしかず_ ですからね! Debian が Linux ディストリビューションの最高峰と呼ばれる までになった理由のひとつがそのパッケージ管理システムです。 すでに膨大な数のソフトウェアが Debian パッケージとして配布されて いますが、まだパッケージ化されていないソフトウェアをインストール しなければならないこともあるでしょう。 あるいは、どうやったら自分でパッケージが作れるんだろう、とか それはとても難しいことなんじゃないか、などと考えたことがあるかも しれません。まあ、もしあなたが本当に駆け出しの Linux ユーザ ならば困難な仕事でしょうが、でもそうだったら今ごろこんな文書 読んでませんて :-) パッケージを作成するには Unix のプログラミングについてある程度 知っている必要がありますが、神様みたいに精通している必要は 全くありません。 ただ、確かなことがひとつあります。Debian パッケージを きちんと作成し、保守していくには、手間を惜しんではならない、 ということです。間違えないでください。Debian のシステムを うまく動かしていくためには、メンテナーは技術的に有能である だけでなく、勤勉であることも必要なのです。 この文書では (最初は関係無さそうに思えることまで) どんな 細かい手順も余さず説明します。 ともかく一つ作ってしまえば、あとは次のリリース、そして 他のパッケージへと経験を積んでいけばよいのです。 この文書の最新版は常に以下の場所からネットワーク経由で入手できます。 http://www.debian.org/doc/maint-guide/ また、 「`maint-guide'」パッケージにも含まれています。 日本語訳は「`maint-guide-ja'」パッケージの中にあります。 1.1. 開発に必要なプログラム --------------------------- 何かを始める前に、開発作業を行なうために必要な、 以下に挙げるようなパッケージがきちんとインストールされていることを まず確かめておかなければいけません。 以下のリストには「essential」または「required」なパッケージが 含まれていないことに注意してください。 - これらのパッケージは既にインストールされていることを前提と しています。 この文書の現在のバージョンは Debian 2.2 (`potato') および 3.0 (`woody') に含まれるパッケージを対象に更新されています。 以下のパッケージは Debian の「標準」(standard) インストール 構成に含まれており、すでに (それらが依存する他のパッケージと いっしょに) システムに含まれているはずです。 しかし、念のために「dpkg -s <パッケージ名>」で確認して おきましょう。 * `dpkg-dev' - このパッケージには Debian ソース パッケージを展開、構築、アップロードするために必要なツール群が 含まれています。 (詳しくは dpkg-source(1) を参照)。 * `file' - この便利なプログラムを使うと そのファイルがどういう形式のものか判定することが できます (詳しくは file(1) を参照)。 * `gcc' - GNU C コンパイラ。あなたのプログラムが 他の多くのプログラムと同様に C 言語で書かれている場合、必要と なります。(詳しくは gcc(1) を参照) このパッケージは、たとえばプログラムの「素」となるオブジェクト ファイルをアセンブル、リンクするための `binutils' (`binutils-doc' パッケージをインストールして 「info binutils」すれば詳細な説明を読めます)、 C プリプロセッサ `cpp' (詳しくは cpp(1) を参照) など他のパッケージをいくつか一緒に「引き連れて」きます。 * `g++' - GNU C++ コンパイラ。あなたの プログラムが C++ 言語で書かれている場合に必要です。 (詳しくは g++(1) を参照) * `libc6-dev' - gcc がオブジェクトファイルを 生成してリンクするために必要な C ライブラリとヘッダファイル が含まれています。(`glibc-doc' パッケージを インストールして「info libc」すればマニュアルが読めます) * `make' - ふつう、プログラムはいくつかの手順を踏んで 生成されます。同じコマンドを何度も何度も繰り返し入力する代わりに、 make プログラムを使えば「Makefile」を書くことで手続きを自動化 することができます。(詳しくは「info make」) * `patch' - このとても有用なユーティリティは オリジナルとの差異が列挙されたファイル (diff プログラムによって生成) を 読み込んでオリジナルのファイルに適用し、変更された (パッチの当たった) バージョンを作成します。 (詳しくは patch(1) を参照)。 * `perl' - Perl は今日の Un*x システムにおいてもっとも 使われているインタープリタ型スクリプト言語のひとつで、その強力さは しばしば「Unix のスイス軍用チェーンソー」と形容されるほどです (詳しくは perl(1)を参照)。 たぶん、以下のパッケージもインストールしたくなるでしょう。 * `autoconf' と `automake' - 多くの新しいプログラムがこれらのプログラムを使って 前処理される設定スクリプトや Makefile を利用しています。 (詳しくは「info autoconf」および「info automake」) * `dh-make' と `debhelper' - dh-make はあとで説明するパッケージのひな型を用意するのに 必要となります。またこのひな型ではパッケージを生成する ために debhelper ツールをいくつか使います。 これらを使わなくてもパッケージ作成は可能ですが、 初めてパッケージを作る方には利用を _強く_ お勧めします。 パッケージを作るのも、以後パッケージを管理するのも ずっと簡単になるからです。 (詳しくは dh_make(1)、 debhelper(1)、 /usr/share/doc/debhelper/README を参照) * `devscripts' - このパッケージは メンテナにとって便利であると思われるいくつかの 有用で優れたスクリプトを含んでいますが、だから といってパッケージを作成するために必須という わけではありません。 (詳しくは /usr/share/doc/devscripts/README.gz 参照)。 * `fakeroot' - このユーティリティを使うと、 パッケージを作成する際に何度か必要となる root 権限を エミュレートすることができます。 (詳しくは fakeroot(1) を参照) * `gnupg' - このツールを使うと、自分の パッケージに「デジタル _署名_」を付けることが できます。もしあなたが自分の作成したパッケージを他の 人々に配布したいのなら、これは特に重要です。 また、Debian ディストリビューションにあなたの作成した パッケージが含まれるようになった時には、確実にこの デジタル署名をすることになります。 (詳しくは gpg(1) を参照) * `g77' - GNU Fortran 77 コンパイラ。あなたの プログラムが Fortran 言語で書かれている場合に必要です。 (詳しくは g77(1) を参照) * `gpc' - GNU Pascal コンパイラ。あなたの プログラムが Pascal 言語で書かれている場合に必要です。 ここで注目に値するのは `fp-compiler'、 Free Pascal コンパイラで、こちらもまたこの作業に適して います。 (詳しくは gpc(1) および ppc386(1) を参照) * `xutils' - ある種のプログラム (通常 X11 のために開発されたもの) は、 これらのプログラムを利用して、マクロ関数の組み合わせから Makefile 群を生成します。 (詳しくは imake(1)、 xmkmf(1) を参照) * `lintian' - これは Debian パッケージチェッカで、 あなたが構築したパッケージを調べて、その中にありがちなミスが 見つかったらそれを指摘し、その問題について説明してくれます (詳しくは lintian(1)、 /usr/share/doc/lintian/lintian.html/index.html を参照)。 さて、以下はこの文書と合わせて読むべき_とても重要_な 文書です。 * `debian-policy' - Debian ポリシーマニュアル。 Debian アーカイブの構造と内容、OS の設計に関するいくつかの問題、 あるいは「ファイルシステム体系基準」(Filesystem Hierarchy Standard、 個々のファイルやディレクトリがどこにあるべきかを規定した文書) についてなどいろいろ載っていますが、 さしあたって重要なことは、ディストリビューションに含まれるために それぞれのパッケージが満たすべき必要条件の説明です (詳しくは /usr/share/doc/debian-policy/policy.html/index.html を参照)。 * _developers-reference_ - 開発者リファレンス。 例えばアーカイブの構造、パッケージ名の変更方法、 パッケージの選び方、メンテナを降りるにはどうしたらよいか、 どうやって NMU をするか、バグとのつき合い方、 いつどこにアップロードすればよいかなどなど、特に技術的な事柄以外の パッケージ化についてのありとあらゆる情報がここにあります。 (詳しくは /usr/share/doc/developers-reference/developers-reference.html/index.html を参照) 上記の簡単な説明は、それぞれのパッケージが何をするのか紹介 するだけのものです。先に進む前にどうかそれぞれのプログラムに 付属の文書を徹底的に熟読し、標準的な使い方だけでも理解しておいて ください。きついと思われるかも知れませんが、あとになればきっと _読んでてよかったなあ_と思うことでしょう。 注意: `debmake' は dh-make と似た働きをする いくつかのプログラムを含むパッケージですが、現在では このパッケージを _使うべきでない_ とされているため、 この文書では _説明しません_。 `debmake' について詳しく知りたい人は Debmake マニュアル (http://www.debian.org/~jaldhar/) を参照してください。 1.2. その他知っておくべきこと ----------------------------- これから作ろうとするのは 2 種類のパッケージで、それぞれ ソースパッケージ、バイナリパッケージと呼ばれています。 ソースパッケージはコンパイルしてプログラムになるソースコードが 含まれます。バイナリパッケージにはでき上がったプログラムそのものです。 紛らわしい言葉ですが、「プログラムのソース」と 「プログラムのソースパッケージ」を混同しないようにしましょう! もし用語についてもっと知りたければ他のマニュアル類を参照してください。 Debian では、「メンテナ(maintainer)」と言う用語はパッケージを 作る人を示し、「上流作者(upstream author)」とはプログラムそれ自身を 作った人を指します。そして「上流メンテナ(upstream maintainer)」 というのは Debian の外部で現在プログラムそのものを管理している人の ことです。 たいていの場合、作者と上流メンテナは同一人物ですが、メンテナすらも 同じという場合もあり得ます。 もしあなたが何かのプログラムを書いて、それを Debian に入れたいと 考えたならば、Debian プロジェクトに参加してメンテナになってください。 もしディストリビューションの次のリリースにあなたのプログラムを 含めたい(そのプログラムが有用なら、ぜひ!)ならば、パッケージを 構築したあとに(あるいはしている最中でも構いませんが) 正式な Debian メンテナになる必要があります。その手続きは 開発者リファレンスで説明されていますので、そちらを参照してください。 ------------------------------------------------------------------------------- 2. はじめの一歩 --------------- 2.1. パッケージ化するプログラムの選定 ------------------------------------- パッケージにしたいプログラムについてはすでに各自お考えがあると 思います。まず最初にしなければならないことは、そのパッケージが すでにディストリビューションに収録されていないかどうか確認することです。 もしあなたが「安定版」を使っているのなら、 たぶん パッケージ検索ページ (http://www.debian.org/distrib/packages) に行って調べるのが最上の策です。 ((訳注: Debian JP パッケージ (http://www.debian.or.jp/Packages.html) もついでに見ておくといいかもしれません。)) もしあなたが_現在の_「開発版」ディストリビューションを使って いるのなら、以下のコマンドを使って調べてみてください。 dpkg -s プログラム名 dpkg -l '*プログラム名*' もしパッケージが既に存在していたら、インストールしましょう！ :-) もしそのパッケージが「みなし子」にされていたら (もしメンテナの名前が 「Debian QA Group」になっていたら)、そのパッケージを引き取ることが できるかもしれません。 みなしごにされたパッケージ (http://www.debian.org/devel/wnpp/orphaned) および 引き取り手を探しているパッケージ (http://www.debian.org/devel/wnpp/rfa_bypackage) を調べて、本当にそのパッケージが引き取ってくれるメンテナを 待っている状態なのかどうか、確認してください。 もしパッケージを引き取ることができたら、 (`apt-get source パッケージ名' などの方法で) ソースを入手して、調べてみてください。 残念ながらこの文書ではパッケージを引き取ることについて わかりやすく説明してはいません。ありがたいことに、既に 誰かがあなたのためにパッケージを準備してくれたわけですから、 そのパッケージがどのように動作するのか理解することはそれほど 難しくはないでしょう。 とはいえ、そうした場合でもこの文書に書かれた多くのアドバイスは そのまま通用しますから、このまま読み進んでいってください。 もしあなたの選んだプログラムがまだパッケージ化されていない もので、それを Debian に入れたいと決めたなら、以下のチェック 項目について確認してください。 * 作業中のパッケージ (http://www.debian.org/devel/wnpp/being_packaged) ((訳注: 作業を必要としているパッケージ (http://www.debian.or.jp/devel/prospective-packages.html) も見ておきましょう))、 を見て、誰か他の人が同じプログラムのパッケージを作っていないかどうか 確かめてください。もし誰か作っていたら、必要に応じて連絡をとって ください。もしその必要が無ければ、まだ誰も手をつけていない 他の面白いプログラムを探して再チャレンジです。 * プログラムはライセンスを_与えられていなければなりません_。 そのライセンスが Debian フリーソフトウェアガイドライン、DFSG (http://www.debian.org/social_contract#guidelines) に示された基準を満たす「フリー」なものであれば言うことなしです。 ((訳注: 日本のミラーサイトは Debian フリーソフトウェアガイドライン (http://www.jp.debian.org/social_contract#guidelines) にあります)) もしガイドラインにそぐわない点があっても、ライセンスが プログラムの配布を許可している場合には、Debian の「contrib」や 「non-free」のセクションに含めることができます。 もしどのセクションに入れるべきか迷ったら、 で聞いてみてください。 * 動作のために setuid root が必要なプログラムを パッケージ作成の最初の練習問題として選ぶべきでは _ありません_。 さらに言えば、すべての場面において setuid や setgid でさえも 必要とすべきではありません。 * デーモンとして動作するプログラムや、システム管理者の ための専用のコマンド (*/sbin ディレクトリに含まれるもの)、 また root 特権を使ってポートを開くプログラムは、すくなくとも 最初は避けておいたほうが賢明です。 * バイナリ実行形式として使えるプログラムを選びましょう。 ライブラリをパッケージ化するのはずっと難しいのです。 * ちゃんとした説明書きのあること。あるいは理解可能な ソースコードであること (つまり、コードに書かれた処理の流れが 混乱していないこと)。 * プログラムの作者に連絡をとってパッケージ化の承諾をもらいましょう。 何かプログラムそのものに起因する問題が発生した際に、作者にいろいろ聞けると いうことは重要なので、由来のはっきりしないソフトウェアの断片をパッケージ化 するのはやめておきましょう。 * そして最後に、といってもこれが重要なのですが、 ちゃんと動くかどうか確かめましょう。そして何回か試してみましょう。 もちろんこれらのことは安全策というだけのことです。筆者としては、 何も知らないままにパッケージ化しておまけにミスった ある種の setuid デーモンのせいで 怒り狂ったユーザからあなたに向けて抗議殺到というような事態を 回避したいのです。 パッケージ化についてもっと経験を積めば、こうしたパッケージも 作れるようになるでしょう。しかし、どんなに老練な開発者だって 何か分からないことがあれば debian-mentors メーリングリストで 質問するのです。そこには喜んで手助けしてくれる人々がいます。 もっと詳しい話は、開発者リファレンスに載っていますので そちらを参照してください。 2.2. プログラムを手にいれて、試してみる --------------------------------------- さて、最初にすべきことは、オリジナルのソースを探してダウンロード することです。ここでは作者のホームページからすでにソースファイルを入手した として話を進めます。 フリーな Unix 用プログラムのソースはふつう tar/gzip 形式で提供されています。 拡張子は .tar.gz で、普通は「プログラム名-バージョン」という サブディレクトリを含んでいます。そこにすべてのソースが入っているわけです。 もしあなたのプログラムのソースが他の種類のアーカイブで提供されていたら (例えばファイル名が ".Z" とか ".zip" で終わっていたら)、 適切なツールで展開しましょう。どうやって展開したらよいのか 良く分からなかったら debian-mentors メーリングリストで聞いてみましょう (ヒント: 「file アーカイブ名.拡張子」を実行してみるとよいかも)。 さて本稿では、「gentoo」というプログラムを例にとって説明しようと 思います。これは X11 上で動く GTK+ を使用したファイルマネージャです。 ちなみにこのプログラムはすでにパッケージ化されており、また、 この文書が最初に書かれた時点から比べると大幅に改変が加えられていることに 注意してください。 自分のホームディレクトリ以下に 'debian'、'deb'、または何か適当だと 思われる名前のサブディレクトリを作りましょう (今回の場合には ~/gentoo/ としても良いでしょう)。 ダウンロードしたアーカイブをここにコピーし、 「tar xzf gentoo-0.9.12.tar.gz」を実行して展開してください。 この時 (一見「無関係」に思えるようなものも含めて) エラーは一切 発生しないということを確認しておいてください。 もしエラーが起きたら、それは他の人々のシステム上で展開する際にもおそらく エラーが起きるということです。そしてそこで使われている展開用のツールは こういった異常を無視するかも知れませんし、無視してくれないかもしれません。 さて、「gentoo-0.9.12」という別のサブディレクトリができました。 展開したディレクトリに移って、提供されているドキュメントを _徹底的に_読みましょう。 通常は README*、INSTALL*、*.lsm、*.html などといった名前の ファイルがあり、 それらの文書の中に、どうやったら正しくコンパイルできるのか、 どうインストールすればよいのかといった情報が見つかるはずです。 (たぶん /usr/local/bin にインストールするものとして説明されています が、 そうしてはいけません。これについては 第 3.1 節, `サブディレクトリへのインストール' を 参照してください)。 プログラムによって構築の手順は代わりますが、最近のプログラムだと 「configure」スクリプトが付属していることがあります。 このスクリプトはソースをあなたのシステムに合わせて設定し、 このままコンパイルできるかどうかをチェックします。 たいていのプログラムは「./configure」を実行してソースコードの 設定を行なった後、「make」を実行してコンパイルします。 「make check」でプログラムのソースツリーに含まれている 自己診断テストを実行できるものもあります。 目的のディレクトリへのインストールは一般に「make install」によって 実行されます。 さあ、試しにプログラムをコンパイルし、実行してみましょう。 インストール中や実行中に他の何かを壊してしまうことが無いかどうか、 またちゃんと動作するかどうか、などを確認してください。 それから、たいていの場合は「make clean」(「make distclean」を 使えるならそのほうが良いです) を実行すると、コンパイル用の ディレクトリをきれいにしてくれます。さらに「make uninstall」を 実行するとインストールされたファイルをすべて削除できることさえも あります。 2.3. パッケージ名とバージョン ----------------------------- パッケージ化の作業は完全にクリーンな (オリジナルのままの) ソースディレクトリ、簡単に言えば新しく展開したソースから 始めるべきです。 パッケージをきちんと作るためには、(もしまだそうなっていなければ) プログラム名がすべて小文字になるよう、オリジナルの名前から 変更しておかなければいけません。 またソースディレクトリ名を <パッケージ名>-<バージョン> に 変更しておきましょう。 もしプログラムの名前が一語以上で構成されていたら、 一つの語につなげるか省略形にしましょう。 例えば、「John's little editor for X」というソフトウェアならば johnledx とか jle4x というようにしましょう。あまり長すぎない程度、 せいぜい 20 文字くらいまでの長さで、適当に決めて下されば結構です。 プログラムの正確なバージョンもチェックしましょう (パッケージのバージョンに含めるために)。 もしそのソフトウェアが「バージョン X.Y.Z」という形式で番号付けされて おらず、ある種の日付で区別されている場合には、バージョン番号として "0.0." にその日付を続けたものを使ってもいいでしょう (先頭に "0.0." を付けておくのは、上流の開発者たちがある日 1.0 のような素敵なバージョンをリリースすると決めた場合に備えての ことです。) つまり、もしリリースの、あるいはスナップショットの 日付が 1998 年の 12 月 19 日だったら、0.0.19981219 としておけば 結構です。 およそバージョン番号に使えそうな情報がまったくないと言う場合、 上流メンテナに連絡をとって彼らが何か他のリビジョン管理手段を 使っているかどうか聞いてみましょう。 2.4. 最初の「Debian 化」 ------------------------ 現在の作業ディレクトリがプログラムのソースディレクトリである ことを確認し、以下を実行してください。 dh_make -e your.maintainer@address -f ../gentoo-0.9.12.tar.gz もちろん、"your.maintainer@address" の部分は changelog の エントリやその他のファイルに記載するための、あなたの電子メール アドレスに置き換えてくさい。またファイル名はあなたがパッケージ化 しようとしているプログラムのオリジナルソースアーカイブの名前に 置き換えてください。 詳細は dh_make(1) を参照してください。 画面にはいろいろ表示されて、あなたが作ろうとしているパッケージ がどういう種類のものか聞いてきます。gentoo は 単一バイナリパッケージ - すなわちパッケージに含まれるバイナリが一つだけで、一つの .deb ファイル のみが作成される - ですので最初の選択肢を選び、「s」キーを押しましょう。 その後、画面に表示される情報をよく読み、確認したら を押して ください。 初めてパッケージを作るというときには、マルチバイナリパッケージや ライブラリに手を出さない方が無難です。この話は前にもしましたね。 実際には作業自体はそれほど大変ではないのですが、ちょっとだけ より多くの知識が必要になります。そのため、ここではその作業について 一切説明しません。 dh_make の実行は _ただ一度だけ_ です。注意して ください。既に「Debian 化」された同じディレクトリで再び実行すると、 正しく動作しないでしょう。これはつまり、将来パッケージの改訂版や 新バージョンをリリースする時には別の方法を使うことになる、という ことでもあります。パッケージの更新作業についての詳細は後で説明する 第 9 章, `パッケージの更新' の部分を読んでください。 ------------------------------------------------------------------------------- 3. ソースコードの変更 --------------------- ふつう、プログラムは自分自身を /usr/local 以下のディレクトリに インストールするようになっています。しかし、Debian システムにおいては、 /usr/local 以下はシステム管理者(とユーザ)の個人的利用のために 予約されているので、Debian パッケージはこのディレクトリを使っては いけないことになっています。 このため、(通常は Makefile に始まる) プログラムを生成するための 仕組を調べる必要があります。 Makefile というのは make(1) がこのプログラムを 自動生成するために利用するスクリプトです。 Makefile についての詳細は、第 4.4 節, `「rules」ファイル'を参照してください。 もしあなたのプログラムが GNU automake(1) や autoconf(1) を使っているのでしたら、ソースに それぞれ Makefile.am や Makefile.in などのファイルが含まれているはずです。 このような場合には、Makefile ではなく、これらのファイルを変更する必要が あります。何故なら、automake を実行すると Makefile.am から生成された 情報によって Makefile.in が上書きされ、また ./configure を実行すると Makefile.in から生成した情報によって Makefile が上書きされるからです。 Makefile.am の編集には、automake の知識がすこしばかり必要になります。 これについては info automake で調べることができます。 一方、Makefile.in の編集は普通の Makefile の編集とほぼ同じです。 ただちょっと変数に気をつければいいだけです。変数というのは例えば @CFLAGS@ や @LN_S@ などのように「@」で囲まれた文字列のことです。 これらの変数は ./configure を実行した際に実際の内容に置き換えられます。 修正の具体的なやり方について_何から何まで_説明するにはとても 紙面が足りませんが、よくあるパターンとしては大体以下のようなものでしょう。 3.1. サブディレクトリへのインストール ------------------------------------- ほとんどのプログラムは自分自身をシステムの既存のディレクトリ構造に インストールするための仕組を備えています。これによってインストールされた バイナリがユーザの $PATH に含まれるようになり、また附属文書やマニュアル ページをシステムに共通の場所で見ることができるわけです。 しかし、もしこのようにしてしまうと、新しくインストールされた プログラムはシステム上に既に存在している他のすべてのプログラムの 中に混ざってしまい、パッケージ作成のためのツールにとって あなたのパッケージに含まれるファイルとそうでないファイルを 見分けることが非常に難しくなります。 従って、何か別の、例えば以下のような方法を採用する必要があります。 プログラムを作業用の一時的なサブディレクトリ以下にインストールし、 メンテナー用ツールを使ってそのサブディレクトリの内容をちゃんと 動作する .deb パッケージに仕立て上げる、という方法です。 このディレクトリ以下にあるファイルは、パッケージをインストール した際にすべてユーザのシステムへとインストールされます。 唯一の違いは dpkg がファイルをルートディレクトリ以下に インストールするということだけです。 通常、この一時的なディレクトリは、展開されたソースツリーの 中にある debian/ ディレクトリの下に作成されます。 またこのサブディレクトリは `debian/パッケージ名' といった名前で呼ばれる ことが多いです。 パッケージを作成するためにはプログラムを debian/パッケージ名 に インストールすることが必要ですが、一方 .deb パッケージをインストール した後は、ルートディレクトリ以下に展開されるため、その状態で正しく 動作できるようにしなければならない、ということを覚えておいてください。 このため、ビルドシステムが `/home/me/deb/gentoo-0.9.12/usr/share/gentoo' といった特定のパスを示す文字列をパッケージファイルの中に 記録してしまわないよう、注意しなければなりません。 GNU autoconf を使用するプログラムの場合は、これはとても 簡単な作業です。こうしたプログラムでは、 (例えば) /usr が本当の置き場所だということを残したままで、 任意のサブディレクトリにインストールできるような makefile が デフォルトで作成されます。 あなたのプログラムが autoconf を使っている場合、dh_make が それを検出して、こうした作業を行なうコマンドを自動的に設定 してくれるため、このセクションを読み飛ばしてしまってもいい くらい非常に簡単な作業です。 しかし、その他のプログラムについては、おそらく自分で Makefile を調べて 編集する必要があるでしょう。 以下は gentoo の Makefile 中の関連する部分です。 # Where to put binary on 'make install'? BIN = /usr/local/bin # Where to put icons on 'make install'? ICONS = /usr/local/share/gentoo オリジナルの設定では、それぞれのファイルを `/usr/local' 以下に インストールするようになっていることがわかります。 これらのパスを以下のように変更してください： # Where to put binary on 'make install'? BIN = $(DESTDIR)/usr/bin # Where to put icons on 'make install'? ICONS = $(DESTDIR)/usr/share/gentoo しかしなぜこのディレクトリなんでしょう。他の所じゃだめでしょうか？ だめです。 なぜなら Debian パッケージの場合、`/usr/local' 以下へファイルを インストールすることは絶対に無いと決まっているからです。このディレクトリ 以下は個別のシステムの管理者が使うために予約されています。 Debian システム上でパッケージからインストールされるファイルは その代わりに `/usr' へインストールされます。 バイナリ、アイコン、文書など、それぞれのファイルを 保存すべき場所については、 「ファイルシステム体系基準」 (/usr/share/doc/debian-policy/fhs を参照) の中でより正確に規定されています。もしまだ読んだことが無ければ、 ざっと目を通して、あなたのパッケージに関係しそうな箇所をきちんと 読んでおくことをお勧めします。 そういうわけで、バイナリは /usr/local/bin ではなく /usr/bin へ インストールしなければなりませんし、マニュアルページは /usr/local/man/man1 の代わりに /usr/share/man/man1 へ インストールする必要があります。 ここで gentoo の makefile にはマニュアルページに関する記述が まったく無いことに注意してください。Debian ポリシーでは すべてのプログラムがそれぞれマニュアルを用意しなければならないと 定めていますから、後で gentoo のマニュアルを作成して、それを /usr/share/man/man1 以下へインストールすることにします。 プログラムの中には、このようなパスを定義するための makefile 変数を 使っていないものもあります。このような場合、C のソースそのものを いじって、指定された場所を使うように修正しなければなりません。 でもどこを、そして何を探せばよいのでしょうか？ 以下のコマンドを実行すれば該当箇所を見つけることができます。 grep -nr -e 'usr/local/lib' --include='*.[c|h]' . これを使うと、grep がソースツリーを再帰的に検索し、 該当箇所を見つけたらそのファイルの名前と検索対象の文字列 （ここでは usr/local/lib）を含む行とを表示します。 見つかったファイルを編集して usr/local/ という部分を usr/ に 置き換えてください。これでもう作業完了です。 他の部分をいじってぐちゃぐちゃにしないよう気をつけましょう。:-) 修正が終ったら、インストールターゲットを探しましょう(「install:」 で始まる行を探してください。この方法でたいていうまくいきます)。 Makefile の先頭で直接定義されているものを除いて、ディレクトリへの参照を すべて変更してください。 gentoo の元々のインストールターゲットはこんな感じでした。 install: gentoo install ./gentoo $(BIN) install icons/* $(ICONS) install gentoorc-example $(HOME)/.gentoorc 修正後はこんな風になります。 install: gentoo-target install -d $(BIN) $(ICONS) $(DESTDIR)/etc install ./gentoo $(BIN) install -m644 icons/* $(ICONS) install -m644 gentoorc-example $(DESTDIR)/etc/gentoorc たぶんお気づきになったでしょうが、変更後はこのルールの 先頭に `install -d' コマンドが追加されています。 普通「make install」を実行するようなシステムなら /usr/local/bin や その他のディレクトリは既にシステム上に存在しているでしょうから、 もともとの makefile ではこのコマンドは使われていませんでした。 しかし、Debian パッケージを作成する場合には、空っぽの（あるいは まだ存在さえしていない）ディレクトリにインストールするわけですから、 これらのディレクトリのそれぞれを毎回作成する必要があります。 ルールの最後には、上流作者が省略することの多い付加的な資料の インストールなど、他の作業を追加することもできます。 install -d $(DESTDIR)/usr/share/doc/gentoo/html cp -a docs/* $(DESTDIR)/usr/share/doc/gentoo/html 鋭い人なら私が「install:」の行の「gentoo」を「gentoo-target」に変えた のに気づくでしょう。 こういうのをバグフィックスというのですな。:-) 今のような、特に Debian パッケージだけに限定されない変更を行った場合、 毎回その内容を上流メンテナに報告し、プログラムの次のリビジョンに反映して もらうことで、他のすべての利用者にとっても有益な結果をもたらすように しましょう。 また、あなたの修正を送る前に、Debian や Linux (あるいは Unix でさえも!) だけに通用するものでなく、できるだけ広範囲に通用するよう心がけることで、 上流の開発者があなたの変更を採用しやすくなるように努めましょう。 上流開発者に debian/ 以下のファイルを送る必要はありません。 注意してください。 3.2. 使用ライブラリの違い ------------------------- よくある問題としてもう一つ、ライブラリの問題があります。 ライブラリはしばしばプラットフォームごとに異なります。 例えば、 Makefile は Debian システム上に存在しない ライブラリへの参照すら含んでいるかもしれません。 その場合には、Debian 上に存在する互換のライブラリを 指すように変更してやらなければなりません。 そんなわけで、もしあなたのプログラムの Makefile (または Makefile.in) に以下のような部分があったら(そしてうまくコンパイルできなかったら)、 LIBS = -lcurses -lなんとか -lかんとか こういう風に変えましょう。今度はきっと大丈夫です。 LIBS = -lncurses -lなんとか -lかんとか ------------------------------------------------------------------------------- 4. debian/ ディレクトリ以下に無くてはならないファイル ----------------------------------------------------- プログラムのソースディレクトリの中に、「debian」という 名前の新しいディレクトリが作られています。 パッケージの動作を自分の意図に合わせて調整するには、 このディレクトリに存在する多くのファイルをその編集します。 最も重要なファイルは「control」、「changelog」、「copyright」、 そして「rules」であり、これらのファイルはすべてのパッケージが 必ず用意しなければならないものです。 4.1. 「control」ファイル ------------------------ このファイルには `dpkg' と `dselect' が パッケージを管理するために利用する 様々な情報が記載されています。 以下は dh_make が作ってくれる control ファイルのひな型です。 1 Source: gentoo 2 Section: unknown 3 Priority: optional 4 Maintainer: Josip Rodin 5 Build-Depends: debhelper (>> 3.0.0) 6 Standards-Version: 3.5.2 7 8 Package: gentoo 9 Architecture: any 10 Depends: ${shlibs:Depends} 11 Description: 12 (行番号は筆者が書き加えました) 1-6 行目はソースパッケージの管理情報です。 1 行目はソースパッケージの名前です。 2 行目はディストリビューションにおいて このパッケージが所属するセクションです。 既にお気づきかも知れませんが、Debian はいくつかのセクションに 分割されています。セクションには main (完全にフリーなソフトウェア)、 non-free (実際の所フリーであるとはいえないソフトウェア)、そして contrib (それ自身はフリーなソフトウェアであるけれども、non-free な ソフトウェアが無ければ使えないもの) があります。 更に、これらの下には各パッケージをおおまかに分類する 論理的なサブセクションが用意されており、 そこに含まれるパッケージの種類を簡単に説明するような 名前がつけられています。 つまり、管理者専用のプログラムのために「admin」、 基本的なツールのために「base」、 プログラマーのためのツールが含まれる「devel」、 文書の「doc」、ライブラリの「libs」、 電子メールの読み書きに使うリーダや 電子メールサーバを構築するためのデーモンは「mail」、 ネットワーク関係のアプリケーションやデーモンの「net」、 他のどんな分類にもあてはまらないような X11 用の プログラムは「x11」など、そしてさらに多くのものが 用意されています。（訳注：「デーモン」とは多くの場合 「サーバー」を作るためのものです。ご存知ですよね。） ここでは x11 に変更しておきましょう。 （「main」セクションは省略時のデフォルトなので、 ここには書きません。） 3 行目はこのパッケージをインストールすることが ユーザにとってどれくらい重要なものかを示しています。 このフィールドに何を設定すべきかについては、 Debian ポリシーマニュアルの説明を読んでください。 新規パッケージの場合、優先度「optional」（選択可能） としておけば、通常は問題無いでしょう。 セクション(Section) と優先度 (Priority) は、 `dselect' のようなフロントエンドが パッケージをソートする時とデフォルトを選ぶ時に 使われます。パッケージを Debian にアップロードすると、 これらのフィールドの値はアーカイブメンテナたちによって 上書きされる場合があります。このような場合、該当する パッケージのメンテナにそのことを知らせるための 電子メールが届きます。 （訳注：具体的な仕組みを説明すると、dpkg などのツールは アーカイブ中に用意される「Packages」ファイルの情報を パッケージ自体に記録された情報より優先するようになって います。そしてこの Packages ファイルの作成と更新は アーカイブメンテナの（たくさんある）仕事のひとつ、 というわけです。） この gentoo は通常の優先度を持つパッケージですし、 他のパッケージと衝突することもありませんから、 ここでは「optional」のままにしておきましょう。 4 行目はメンテナの名前と電子メールアドレスです。 電子メールの宛先として問題無くそのまま使えるように 記載してください。Debian のバグ追跡システムは、 パッケージがアップロードされたら、ここに記載された 情報を使ってあなたにユーザーからのバグ報告を 転送しようとします。コンマ ,、アンド記号 &、 および括弧 () などの使用は避けてください。 5 行目はあなたのパッケージを生成するために必要となる パッケージのリストです。例えば gcc や make のように 暗黙の前提としてこのリストに含まれているパッケージも いくつかあります。詳しくは `build-essential' パッケージをご覧ください。もしあなたのパッケージを 生成するために、このリストに記載されていない、 標準的でないコンパイラやその他のツールが必要なら、 それらを「Build-Depends」行に追加しておきます。 複数のパッケージを記載する場合は、コンマで区切ってください。 このフィールドの書式については、バイナリ依存関係（後述）の ところでもうすこし詳しく説明します。 ここには Build-Depends-Indep や Build-Conflicts など、 その他のソース依存関係を設定することもできます。 これらの情報は Debian がサポートしている他のコンピュータ プラットフォーム用にバイナリパッケージを作成する 自動パッケージ生成プログラムによって利用されます。 ソース依存関係についての詳細は Debian ポリシーマニュアルを、 また Debian がサポートしているプラットフォーム （アーキテクチャ）と、ソフトウェアをそれらへ移植 （ポート）する方法については開発者レファレンスを 参照してください。 以下のようにすれば、自分のパッケージを生成するために 必要となるパッケージを見つけることができます。 strace -f -o /tmp/log ./configure # or make instead of ./configure, if the package don't use autoconf for x in `dpkg -S $(grep open /tmp/log|\ perl -pe 's!.* open\(\"([^\"]*).*!$1!' |\ grep "^/"| sort | uniq|\ grep -v "^\(/tmp\|/dev\|/proc\)" ) 2>/dev/null|\ cut -f1 -d":"| sort | uniq`; \ do \ echo -n "$x (>=" `dpkg -s $x|grep ^Version|cut -f2 -d":"` "), "; \ done Gentoo の場合、パッケージを生成するために `xlibs-dev'、`libgtk1.2-dev' および `libglib1.2-dev' が必要でしたので、 これらを `debhelper' に追加しておきます。 6 行目はこのパッケージが準拠している Debian ポリシー基準の バージョン、つまりあなたがパッケージを作成する際に参照した ポリシーマニュアルのバージョンです。 8 行目はバイナリパッケージの名前です。これは通常ソースパッケージ の名前と同じですが、いつもそうだとは限りません。 9 行目にはバイナリパッケージをコンパイル可能な CPU アーキテクチャ を記述します。 ここを「any」のままにしておけば、 dpkg-gencontrol(1)が、このパッケージを コンパイルしたマシンに合わせて適当に埋めてくれます。 あなたのパッケージが特定のアーキテクチャに依存しないのであれば (例えば、シェルや Perl のスクリプトであるとか、あるいは 文書のパッケージである場合) ここを「all」に変更し、パッケージの 生成に「binary-arch」ではなく「binary-indep」を使う方法について の説明をあとで 第 4.4 節, `「rules」ファイル' の項で読んでおいてください。 10 行目は Debian パッケージ管理システムの最も強力な機能のひとつ を示しています。 それぞれのパッケージは様々な形で相互に関係情報を持つことができます。 パッケージ間の関係には、Depends: すなわち「依存」の他に、Recommends:、 Suggests:、Pre-depends:、Conflicts:、Provides:、Replaces: が あります。 dpkg、dselect、APT (そしてそのフロントエンド) などの パッケージ管理ツールは、通常これらの関係を処理する場合に、 同じ動作をします。 そうでない場合については、追々説明していきます。 (dpkg(8)、 dselect(8)、 apt(8)、 aptitude(1) などを参照してください)。 以下にこれらの依存関係が通常持つ意味を説明します。 * Depends: 「依存」 パッケージはここで指定したパッケージをインストールしない限り インストールされません。 あなたのプログラムが特定のパッケージに依存していて、そのパッケージが 存在しない限り全く動作しない (または非常に重大な問題が発生する) 場合には、これを使いましょう。 * Recommends: 「推奨」 dselect や aptitude などのフロントエンドの場合、ユーザが インストールのためにパッケージを選択すると、それが「推奨」 しているパッケージも一緒にインストールするよう促します。 さらに dselect の場合には、「Q」または「X」キーで強制的に やめさせるまで、推奨されたパッケージをインストールするよう、 何度でも繰り返し確認を求めてきます。 しかし dpkg と apt-get の場合、「推奨」されたパッケージに 関する情報は無視され、あるパッケージをインストールしても、 そのパッケージが「推奨」しているパッケージについては何の メッセージも表示しませんし、もちろんインストールもしません。 このフィールドには、厳密に言えばあなたのプログラムの動作に 必須ではないけれど、一緒に使うことがほぼ前提となっている ようなパッケージを指定しましょう。 * Suggests: 「提案」 ユーザがパッケージをインストールする際、dselect や aptitude の ようなフロントエンドはすべて、選択したパッケージによって「提案」 されているパッケージも合わせてインストールするかどうか聞いてきます。 dpkg と apt-get の場合はまったく気にしません。 あなたのパッケージの動作に必要というわけではないが、これがあると もっと便利に使える、というパッケージについては、この指定を使って ください。 * Pre-Depends: 「先行依存」 これは Depends: よりも強い関係を示します。 ここで指定されたパッケージがあらかじめインストールされ、 _かつ適切に設定されて_ いない限り、どのパッケージ 管理ツールもあなたのパッケージをインストールしません。 これを使う前に、まずは debian-devel メーリングリストで 相談しましょう。 _できるだけ_ 使わないようにしましょう。 早い話が、使っちゃいけません。:-) * Conflicts: 「競合」 ここで指定されたパッケージがすべて削除されない限り、 あなたのパッケージはインストールされません。 特定のパッケージが存在しているとあなたのプログラムが 動作しない (または非常に重大な問題が起きる) 場合に、 この指定を使います。 * Provides: 「提供」 ほぼ同じ機能を持つパッケージが複数あって、選択の余地が ある場合のために、仮想パッケージ名が定義されています。 仮想パッケージ名の一覧は、ファイル /usr/share/doc/debian-policy/virtual-package-names-list.txt.gz にあります。 あなたのプログラムが既存の仮想パッケージに相当する機能を 提供する場合には、これを使います。 * Replaces: 「置換」 あなたのプログラムが他のパッケージに含まれるファイルを 上書きする場合、または他のパッケージ全体を完全に置き換えて しまう場合 (この場合は Conflicts: も一緒に指定してください) この指定を使います。 ここで指定されたパッケージに含まれるファイルは、 あなたのパッケージのファイルによって上書きされます。 これらのフィールドはすべて共通の書式で記述します。 指定したいパッケージ名をコンマで区切って並べてください。 もしいくつか選択肢があれば、それらのパッケージ名を 縦棒 `|' (パイプ記号)で区切って並べてください。 あるバージョンより上でなければダメ、などというように パッケージのバージョン番号によって制限を加えることも可能です。 これを指定したい場合にはそれぞれのパッケージ名の後で 丸カッコ (パーレン) を開き、以下の関係式に続けて バージョン番号を指定してください。使用できる関係式は `<<'、`<='、`='、`>='、 `>>'で、それぞれ 「指定されたものより古いバージョンのみ」、 「指定されたバージョン以前」(指定のバージョンも当然含まれます)、 「指定のバージョンのみ」 「指定されたバージョン以降」(指定のバージョンも当然含まれます)、 「指定されたものより新しいバージョンのみ」 を意味します。 今まで説明してきた依存関係を使うことで、例えば以下のような 指定も可能です。 Depends: foo (>= 1.2), libbar1 (= 1.3.4) Conflicts: baz Recommends: libbaz4 (>> 4.0.7) Suggests: quux Replaces: quux (<< 5), quux-foo (<= 7.6) 最後に、知っておかなければいけない機能をもうひとつ。 それは $(shlibs:Depends) です。パッケージを生成する際に、 その中身が一時的なディレクトリにインストールされた後、 そこに含まれるバイナリとライブラリによって利用されている 共有ライブラリと、それらの共有ライブラリを含むパッケージ の名前 (例えば libc6 や xlib6g など) が dh_shlibdeps(1) によって自動的に 調べられます。そしてその結果は dh_gencontrol(1) に渡され、control ファイル中の $(shlibs:Depends) と置換されます。 これを使えば、あなた自身が自分で共有ライブラリを調べて記述する 必要はありません。 ここまでの説明でわかるように、今回は Depends: 行を dh_make が 生成してくれたデフォルトの状態のままにしておくことができます。 gentoo は「file」プログラム/パッケージによって提供される機能を いくつか利用することができるので、10 行目の後に新しい行を追加 して、`Suggests: file' を記入します。 11 行目はこのパッケージに関する短い説明です。多くの人々は 一行 (半角) 80 文字幅のスクリーンでこれを見ますから、 (半角) 60 文字以上にしてはいけません。 今回は「fully GUI configurable X file manager using GTK+」 としました。 12 行目はこのパッケージに関する詳細な説明文です。 ここでは一つの段落でパッケージについてより詳しく説明するように してください。それぞれの行の先頭は空白 (スペース文字) で 始めなければいけません。 また空白行を入れてはいけませんが、先頭の空白の後に . (半角ピリオド) をひとつ書くことで、それらしく見せることができます。 さらに、説明文の後には空白行をひとつも入れてはいけません。 以下が修正後の control ファイルです。 1 Source: gentoo 2 Section: x11 3 Priority: optional 4 Maintainer: Josip Rodin 5 Build-Depends: debhelper (>> 3.0.0), xlibs-dev, libgtk1.2-dev, libglib1.2-dev 6 Standards-Version: 3.5.2 7 8 Package: gentoo 9 Architecture: any 10 Depends: ${shlibs:Depends} 11 Suggests: file 12 Description: fully GUI configurable GTK+ file manager 13 gentoo is a file manager for Linux written from scratch in pure C. It 14 uses the GTK+ toolkit for all of its interface needs. gentoo provides 15 100% GUI configurability; no need to edit config files by hand and re- 16 start the program. gentoo supports identifying the type of various 17 files (using extension, regular expressions, or the 'file' command), 18 and can display files of different types with different colors and icons. 19 . 20 gentoo borrows some of its look and feel from the classic Amiga file 21 manager "Directory OPUS" (written by Jonathan Potter). (行番号は筆者が書き加えました) 4.2. 「copyright」ファイル -------------------------- このファイルにはパッケージの上流 (upstream) に関する リソース (URI など)、著作権、およびライセンスなどの情報を記載します。 このファイルの書式は Debian ポリシーに規定されていませんが、 内容については (12.6 節、「Copyright information (著作権情報)」に) 規定されています。 dh_make はデフォルトとして以下のようなひな型を作成します。 1 This package was debianized by Josip Rodin joy-mg@debian.org on 2 Wed, 11 Nov 1998 21:02:14 +0100. 3 4 It was downloaded from 5 6 Upstream Author(s): 7 8 Copyright: 9 10 (行番号は筆者が書き加えました) ここでファイルに追加すべき重要なことは、あなたがこのソフトウェアを 入手した場所と、実際に有効な著作権表示およびライセンスです。 原則としてライセンスは全文を含めなければなりません。 ただし、もしプログラムのライセンスが GNU GPL または LGPL、BSD、 あるいは Artistic などの良く知られたフリーソフトウェアのライセンス であって、どの Debian システムにも存在するディレクトリ /usr/share/common-licenses/ の中の適切なファイルを参照することで ライセンスの内容をすべて示すことができる場合に限って、 全文をここに引用する必要はありません。 つまり、gentoo の copyright ファイルはこんな風になります。 1 This package was debianized by Josip Rodin joy-mg@debian.org on 2 Wed, 11 Nov 1998 21:02:14 +0100. 3 4 It was downloaded from http://www.obsession.se/gentoo/ 5 6 Upstream Author(s): Emil Brink 7 8 This software is copyright (c) 1998-99 by Emil Brink, Obsession 9 Development. 10 11 You are free to distribute this software under the terms of 12 the GNU General Public License. 13 On Debian systems, the complete text of the GNU General Public 14 License can be found in the file `/usr/share/common-licenses/GPL'. (行番号は筆者が書き加えました) 4.3. 「changelog」ファイル -------------------------- これは必須のファイルです。ポリシーマニュアル 4.4 節 「debian/changelog」にはこのファイルのための特別な書式が 規定されています。 この書式は dpkg やその他のプログラムによってあなたのパッケージの バージョン番号、レビジョン、ディストリビューション、それに緊急度 (urgency) を識別するために利用されます。 あなたが行なったすべての変更をきちんと記載しておくことは 良いことであり、その意味でこのファイルはまた、パッケージメンテナ であるあなたにとっても重要なものです。 あなたのパッケージをダウンロードした人々は、 このファイルを見ることで、ユーザが最初に知っておくべき このパッケージに関する解決されていない問題があるかどうかを 知ることができます。 このファイルはバイナリパッケージ中に 「/usr/share/doc/gentoo/changelog.Debian.gz」として保存されます。 dh_make がデフォルトとして生成する changelog はこんな感じです。 1 gentoo (0.9.12-1) unstable; urgency=low 2 3 * Initial Release. 4 5 -- Josip Rodin Wed, 11 Nov 1998 21:02:14 +0100 6 (行番号は筆者が書き加えました) 1 行目はパッケージ名、バージョン、ディストリビューション、 そして緊急度 (urgency) です。 ここに書くパッケージ名はソースパッケージの名前と一致していなければ なりません。 またディストリビューションは「unstable」(または「experimental」) にすべきであり、緊急度は「low」より高いものに変更するべきでは ありません :-) 3-5 行目はログエントリで、ここにこのリビジョンのパッケージで 行われた変更を記述します (上流プログラムそのものの変更点では ありません - その目的のためには、上流作者によって作成され、 /usr/share/doc/gentoo/changelog.gz としてインストールされる 専用のファイルが存在しています)。 新しい行はアスタリスク(「*」)で始まる最初の行の直前に挿入します。 この操作は dch(1) を使うと便利ですが、 その他の普通のテキストエディタを使って実行しても もちろん構いません。 最終的にこんな風になればよいわけです。 1 gentoo (0.9.12-1) unstable; urgency=low 2 3 * Initial Release. 4 * This is my first Debian package. 5 * Adjusted the Makefile to fix $DESTDIR problems. 6 7 -- Josip Rodin Wed, 11 Nov 1998 21:02:14 +0100 8 (行番号は筆者が書き加えました) 後述する 第 9 章, `パッケージの更新' の中で、changelog ファイルを 更新する方法についてもっと詳しく説明します。 4.4. 「rules」ファイル ---------------------- さて、今度は dpkg-buildpackage(1) が 実際にパッケージを作成するために使う「rules」ファイルを 調べる必要があります。 このファイルは実はもう一つの Makefile といったものですが、 上流ソースに含まれる Makefile とは違います。 また debian/ ディレクトリに含まれる他のファイルとは異なり、 このファイルには実行属性が付けられています。 すべての「rules」ファイルは、他の Makefile と同じく、 ソースからプログラムを構築する方法を記述したいくつかの ルールによって構成されています。それぞれのルールには ターゲット、ファイル名、あるいは実行されるべき動作 (つまり「build:」や「install:」) などの名前がつけられて います。 あるルールを実行するには (例えば「./debian/rules build」 とか「make -f rules install」といった風に) そのルールを コマンドライン引数として指定します。 ターゲット名の後には、依存関係、つまりそのルールが 必要とするプログラムやファイルの名前を指定できます。 この次の行から、先頭を <タブ>で始めてそのルールの 中で実行すべきコマンドを書いていきます。コマンド行の 数に制限はありません。いくらでも好きなだけ続けられます。 新しいルールを始めるには、行の先頭からターゲット名の宣言を 書きます。複数の空行、および「#」 (ハッシュ) で始まる行は 行の終りまでコメントと見なされ、無視されます。 これだけ読んでもわけが分からないかもしれませんが、dh_make が デフォルトとして作成する「rules」ファイルについて調べていくうちに、 きっと理解できるようになります。 また、info コマンドの「make」エントリーに、より詳細な説明が あるので、これも合わせて読んでおくと良いでしょう。 dh_make によって作成された rules ファイルについて知っておくべき 最も重要なことは、これが単なるひな型であり、ひとつの例でしかない、 ということです。 単純なパッケージならそのまま使えるかもしれませんが、 もっと複雑なパッケージの場合には、必要に応じて追加したり 削除したりすることをためらってはいけません。 あなたが変えてはいけないのはたった一つ、rules ファイル内に 記述された各ルールの名前だけです。 パッケージ管理ツールはすべて、Debian ポリシーの規定に 従ってこれらのルール名を参照するので、変更してしまうと うまくパッケージを生成できなくなってしまいます。 dh_make はデフォルトの debian/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 # Uncomment this to turn on verbose mode. 9 #export DH_VERBOSE=1 10 configure: configure-stamp 11 configure-stamp: 12 dh_testdir 13 # Add here commands to configure the package. 14 touch configure-stamp 15 build: build-stamp 16 build-stamp: configure-stamp 17 dh_testdir 18 # Add here commands to compile the package. 19 $(MAKE) 20 #docbook-to-man debian/testpack.sgml > testpack.1 21 touch $@ 22 clean: 23 dh_testdir 24 dh_testroot 25 rm -f build-stamp configure-stamp 26 # Add here commands to clean up after the build process. 27 $(MAKE) clean 28 dh_clean 29 install: build 30 dh_testdir 31 dh_testroot 32 dh_clean -k 33 dh_installdirs 34 # Add here commands to install the package into debian/testpack. 35 $(MAKE) DESTDIR=$(CURDIR)/debian/testpack install 36 # Build architecture-independent files here. 37 binary-indep: build install 38 # We have nothing to do by default. 39 # Build architecture-dependent files here. 40 binary-arch: build install 41 dh_testdir 42 dh_testroot 43 dh_installchangelogs 44 dh_installdocs 45 dh_installexamples 46 # dh_install 47 # dh_installmenu 48 # dh_installdebconf 49 # dh_installlogrotate 50 # dh_installemacsen 51 # dh_installpam 52 # dh_installmime 53 # dh_python 54 # dh_installinit 55 # dh_installcron 56 # dh_installinfo 57 dh_installman 58 dh_link 59 dh_strip 60 dh_compress 61 dh_fixperms 62 # dh_perl 63 # dh_makeshlibs 64 dh_installdeb 65 dh_shlibdeps 66 dh_gencontrol 67 dh_md5sums 68 dh_builddeb 69 binary: binary-indep binary-arch 70 .PHONY: build clean binary-indep binary-arch binary install configure (行番号は筆者が書き加えました。実際の `debian/rules' ファイルでは行頭の空白は TAB コードです。) 1 行目は、シェルや Perl のスクリプトでおなじみの表現でしょう。 これは、このファイルが /usr/bin/make によって処理されることを オペレーティングシステムに指示しています。 8 行目から 9 行目にかけて記述されている、変数 DH_* の 意味は、コメントとして書かれている短い説明を読めばすぐに わかるでしょう。DH_COMPAT についての詳細はマニュアル ページ debhelper(1) の 「Debhelper compatibility levels (debhelper 互換レベル)」 の項を参照してください。 11 行目から 16 行目までは Debian ポリシー 10.1 節 「Binaries (バイナリ)」に規定されたパラメータ DEB_BUILD_OPTIONS をサポートするための枠組です。 簡単に言えば、このパラメータはバイナリをビルドする際に デバッグシンボルを付加するかどうか、またインストールの 際にそれらをストリップすべきかどうかを制御します。 繰り返しますが、ここに記載されているのは単なる枠組であり、 どうすべきかという点についてヒントを示しているに過ぎない、 ということに注意してください。 実際にパッケージを開発する際には、デバッグシンボルの付加と インストール時のストリップについて、上流開発者がソフトウェアを 生成する際にどのように扱っているかを調べ、そして自分自身で このパラメータをサポートする仕組を実装してください。 通常、デバッグシンボルを付加するには、コンパイルの際に CFLAGS 変数を使って gcc に「-g」オプションを指定します。 もしあなたのパッケージもこの方法でうまくいくようなら、 build ルール (後述) の中で $(MAKE) を実行している箇所に `CFLAGS="$(CFLAGS)"' を _追加_して、この 変数を指定します。もしあなたのパッケージが autoconf に よる configure スクリプトを利用しているなら、別の方法と して build ルールの中で ./configure を実行する際に 上記の `CFLAGS="$(CFLAGS)"' を _前置き_ して configure スクリプトに渡すこともできます。 ストリップについて説明すると、たいていのプログラムは ストリップせずにインストールされるよう設定されており、 また多くの場合、それを変更するためのオプションは用意されて いません。そのような場合でも Debian なら大丈夫、あなたは dh_strip(1) を利用することができます。 これは DEB_BUILD_OPTIONS=nostrip フラッグが設定されているか どうかを調べて、このフラッグが有効な場合にはバイナリを ストリップせずにそのまま (エラーを出さずに) 終了してくれます。 18 行目から 26 行目までは「build」 (およびその子供である 「build-stamp」) ルールを記述しており、その中でプログラムを コンパイルするためにアプリケーション自身の Makefile を実行 しています。コメントとして記載されている docbook-to-man の サンプルについては、後で説明する 第 5.8 節, `manpage.1.ex, manpage.sgml.ex' の箇所を 参照してください。 28 行目から 36 行目までに記述されている「clean」ルールは、 パッケージの生成過程によって自動生成されたバイナリその他の 不要なファイルをすべて削除します。 このルールはどんな時でも (たとえソースツリーが _削除_ されてしまっている状態でも!) きちんと動作しなければいけません。 このため、強制オプションを使うか (たとえば rm なら「-f」)、 返り値 (エラー) を無視する (コマンド名の前に「-」を追加) などの措置を講じてください。 インストール方法を記述する「install」ルールは 38 行目から 始まります。このルールは基本的にプログラム自身の Makefile に 記述されている「install」ルールを実行しますが、インストール 先は `$(CURDIR)/debian/gentoo' ディレクトリです - このために gentoo の Makefile の中で $(DESTDIR) を ルートインストールディレクトリとして指定しておいたのです。 コメントにもあるように、48 行目の「binary-indep」ルールは アーキテクチャに依存しないパッケージを生成するために使われます。 今回の例はそのようなパッケージではないため、ここでするべきことは 何もありません。 さあ、次のルール - 「binary-arch」の番です。52 行目から 79 行目に かけて記述されたこのルールでは、あなたのパッケージが Debian ポリシー に適合するよう、debhelper パッケージに収録されているいくつかの小さな ユーティリティを実行して、これから生成するパッケージ中のファイルに 対してさまざまな操作を行ないます。 もしあなたのパッケージが「Architecture: all」なら、パッケージを 生成するために必要なコマンドをすべて「binary-indep」ルールの中で 指定し、その代りに「binary-arch」ルールを空にしておかなければ いけません。 debhelper プログラムの名前は dh_ で始まり、残りの部分は そのユーティリティが実際に行なう内容に関する説明となっています。 これらはほとんど読めばすぐわかるような簡単なものですが、 以下に説明を追加しておきます。 * dh_testdir(1) はあなたが正しい ディレクトリ (つまり、ソースディレクトリのトップレベル) に いるかどうかをチェックします * dh_testroot(1) は「binary-arch」 および「binary-indep」ターゲットと「clean」ルールの実行に必要な ルート権限をあなたが持っているかどうかチェックします。 * dh_installman(1) はマニュアル ページをパッケージ作成用ディレクトリの中の適切な場所へコピー します。ただしこれを使う際には、インストールしたいマニュアル ページの場所をソースディレクトリのトップレベルからの相対的な 位置で指定しなければいけません。 * dh_strip(1) はデバッグ用ヘッダを 実行形式ファイルおよびライブラリから取り除き、それらのサイズを 小さくします。 * dh_compress(1) は マニュアルページとサイズが 4 kB より大きな附属文書を gzip(1) で圧縮します。 * dh_installdeb(1) はパッケージに 関連するファイル (例えばメンテナースクリプトなど) を `debian/gentoo/DEBIAN' ディレクトリにコピーします。 * dh_shlibdeps(1) はライブラリや 実行形式ファイルが依存している共有ライブラリを判定します。 * dh_gencontrol(1) は control ファイルに必要な情報を追加し、 `debian/gentoo/DEBIAN' へインストールします。 * dh_md5sums(1) はパッケージ中の すべてのファイルに対して MD5 チェックサムを計算します。 これらすべての dh_* スクリプトが実際にはそれぞれ何をするのか、 また他にはどんなオプションが使えるのか、などのさらに詳しい情報に ついては、それぞれのマニュアルページを参照してください。 また、ここでは取り上げませんでしたが、非常に便利だと思われる dh_* スクリプトが他にもいくつか用意されています。 これらに関しては、必要に応じて debhelper の説明書を読んでみて ください。 binary-arch セクションの中にある、不要な処理を 実行している行はすべてどんどんコメントにしてしまうか、 あるいは削除してしまうべきです。 gentoo の場合、examples、cron、init、man、そして info に 関する処理は必要ありませんから、コメントにしておきます。 また今回の場合、68 行目の「ChangeLog」を「FIXES」に変更して おきます。上流開発者 (upstream) の changelog (変更履歴) ファイルの名前が FIXES だからです。 最後の 2 行は (説明しなかった他の行と同様に) 多少なりとも 必要なものです。これらについては make のマニュアルや Debian ポリシーマニュアルの中に説明があります。 今のところは、必ず知っておかなくてはいけないような重要な項目 というわけではありません。 ------------------------------------------------------------------------------- 5. debian/ の中にあるその他のファイル ------------------------------------- debian/ サブディレクトリには他にもいくつかのファイルが あるはずです。それらのほとんどには「.ex」サフィックスが 付いており、そのファイルがただの例、サンプルであることを 示しています。 これらのファイルにはすべて目を通しておいてください。 もしこれらの機能のどれかを使いたいと思ったり、また使う必要が 生じたりした場合には、 * 関連する文書 (ヒント: Debian ポリシーマニュアル) を調べ、 * 必要に応じてそのファイルの内容を変更し、 * 「.ex」というサフィックスが付いていたら、それを取り除く ために名前を変更し、 * 必要なら「rules」ファイルを編集してください。 これらのファイルのうち、特によく利用されるものについては、 以下のセクションに説明があります。 5.1. README.Debian ------------------ パッケージに関して何か特別にユーザに知らせる必要がある情報や、 オリジナルのソフトウェアとあなたが Debian パッケージにした バージョンとの相違点は、ここに記述しておくべきです。 以下はデフォルトとして dh_make が生成するものです。 gentoo for Debian ---------------------- Josip Rodin , Wed, 11 Nov 1998 21:02:14 +0100 今回は特に何も書き込む必要はありませんから、あとでこのファイルを 削除しておきます。 5.2. conffiles.ex ----------------- ソフトウェアに関して最もうんざりさせられることのひとつに、 大変な量の時間と労力を費してプログラムをカスタマイズした後で そのための設定変更が一回のアップグレードによってすべて上書き されてしまった場合が挙げられるでしょう。 Debian はこの問題を、設定ファイルを記録しておいて、パッケージを アップグレードする際に古い設定をそのまま使いたいかどうか質問する という方法で解決しました。 この機能を使うには、パッケージのプログラムが使う各設定ファイル (たいてい /etc にあります) のフルパス名を 1 行にひとつずつ、 `conffiles' という名前のファイルに記載します。 gentoo では /etc/gentoorc という名前の設定ファイルが 使われるので、これを `conffiles' ファイルに記載します。 あなたのプログラムが設定ファイルを利用する場合であっても、 その設定ファイルがプログラム自身によって頻繁に上書きされる ような場合には、パッケージをアップグレードするたびに dpkg に よって設定ファイルの変更について確認を求められることになるので、 その設定ファイルを conffiles に登録しないほうが良いでしょう。 あなたがパッケージにしたプログラムでは、設定ファイルを 変更しない限り、誰も利用できない、というような場合も、 その設定ファイルを conffile として登録しないほうが良いかも しれません。 設定ファイルのサンプルを「メンテナースクリプト」によって 用意することも可能です。詳細は 第 5.12 節, `postinst.ex、preinst.ex、postrm.ex、prerm.ex' を 参照してください。 もしあなたのプログラムが設定ファイルを一切利用しないので あれば、 debian/ ディレクトリから `conffiles' ファイルを 問題無く削除できます。 5.3. cron.d.ex -------------- もしあなたのパッケージがきちんと動作するために、 決められたスケジュールに従った定期的な作業の実行を 必要とする場合、このファイルを使ってその作業を cron に登録します。 ここではログのローテーションは扱いません。 ログローテーションについては dh_installlogrotate(1) および logrotate(8) を参照してください。 もし必要無ければ、このファイルを削除してください。 5.4. dirs --------- このファイルには、我々のパッケージが必要としているが、 通常のインストール手順 (make install) では作成されない ディレクトリを指定します。 デフォルトでは、こんな風になっています: usr/bin usr/sbin 一番最初のスラッシュが含まれない事に注意してください。 たいていの場合、このファイルの内容は以下のように変更して おけば問題無いでしょう。 usr/bin usr/share/man/man1 ただ今回の場合、これらのディレクトリは Makefile 中の 処理によって既に作成されているので、このファイルは 不要であり、そのまま削除してしまうことにします。 5.5. docs --------- このファイルには、dh_installdocs を使ってパッケージ 生成用の一時的なディレクトリにインストールするために、 パッケージに附属する資料のファイル名を指定します。 ソースディレクトリのトップレベルに存在する「BUGS」、 「README*」、「TODO」などの名前を持つファイルはすべて デフォルトとして含まれます。 ここでは gentoo のために、附属文書をいくつか指定します。 BUGS CONFIG-CHANGES CREDITS ONEWS README README.gtkrc TODO 別の方法として、このファイルを削除し、その代わり以下のように `rules' ファイルにある `dh_installdocs' コマンド行の中で これらの文書ファイル名を指定することも可能です。 dh_installdocs BUGS CONFIG-CHANGES CREDITS ONEWS README \ README.gtkrc TODO ありそうにないことですが、パッケージのソース中にここで 指定したくなるような附属文書がまったく存在しないという 場合もあるかもしれません。 そうした場合には、この docs ファイルを削除しても問題無い でしょう。 ただし、その場合にも `rules' ファイルの中の `dh_installdocs' コマンドを削除してはいけません。 このコマンドは `copyright' ファイルやその他のファイルを インストールするために利用されます。 5.6. emacsen-*.ex ----------------- パッケージをインストールする際にバイトコンパイル可能な Emacs ファイルがあなたのパッケージに含まれている場合、 　これらの emacsen-* ファイルを利用してそれを設定することが 　できます。 これらの emacsen-* ファイルは dh_installemacsen(1) によってパッケージ作成用の一時的なディレクトリに インストールされます。このため、もしこれらのファイルを 使用するのなら、`rules' ファイルの中にコメントとして 書かれている、この dh_installemacsen コマンドを起動して いる行を、忘れずに有効にしておいてください。 もしこれらの emacsen-* ファイルが必要なければ、 削除しておいてください。 5.7. init.d.ex -------------- もしあなたのパッケージがデーモンであり、システムの起動時に 自動的に動作させる必要があるとしたら、私が最初に勧めたことを あなたはまるっきり無視してしまったわけですよね。そうでしょ ? :-) これは `/etc/init.d/' スクリプトの 非常に一般的なほんの骨組みのファイルにすぎません。 もしこれを使いたければ、内容を大幅に変更する必要が あるでしょう。このファイルは dh_installinit(1) によってパッケージ作成用の一時的なディレクトリに インストールされます。 もし不要なら、このファイルを削除してください。 5.8. manpage.1.ex, manpage.sgml.ex ---------------------------------- すべてのプログラムは man ページを持つべきです。 もし無かったら、これらのひな型のどちらかを利用して、 必要な情報を追加すれば作成できます。 マニュアルページは通常 nroff(1) を利用して作成されます。 これにならって、`manpage.1.ex'　も nroff で 作成されています。 man(7) のマニュアルページには、 このファイルの編集方法についての簡潔な説明があります。 一方、もし nroff より SGML のほうが好みでしたら、 `manpage.sgml.ex' のほうをひな型として使うことも できます。こちらの場合には、以下の手順が必要です。 * パッケージ `docbook-to-man' のインストール * `control' ファイルの `Build-Depends' 行へ `docbook-to-man' を追加 * `rules' ファイルに記述された「build」ルールの 中で docbook-to-man を実行している行を有効にする それから、このファイルの名前を `gentoo.sgml' と いった名前に変更することを忘れないように! 最終的なマニュアルページファイルの名前には、そのマニュアル ページで解説するプログラムの名前が含まれているべきです。 このため、ここではファイル名を「gentoo」から「manpage」に 変更します。ファイル名にはまた、デフォルトの拡張子として 「.1」が含まれていますが、これはこのファイルがユーザー コマンドのマニュアルページであることを示しています。 この拡張子の示す分類が正しいものであることを確認して おいてください。 マニュアルページの分類をまとめたリストを以下に示します。 セクション | 説明 | メモ 1 ユーザコマンド 実行可能なコマンドやスクリプト 2 システムコール カーネルの提供する機能 3 ライブラリコール システムライブラリに含まれる機能 4 特別ファイル たいていは /dev 内にあるもの 5 ファイルの書式 例えば /etc/passwd の書式 6 ゲーム またはその他のおもしろいプログラム 7 マクロパッケージ man マクロのようなもの 8 システム管理 実行するのに root 権限が必要なものなど 9 カーネルルーチン 標準的でないシステムコールや内部仕様 そんなわけで gentoo のman ページは gentoo.1 と呼ばれることに なります。 元のソースには gentoo.1 という man ページが含まれていなかったので、 上に説明したサンプルと、上流開発者が提供している文書からの情報を もとに筆者が作成しました。 5.9. menu.ex ------------ X Window System のユーザはたいていウィンドウマネージャを 使っており、そのメニュー機能を設定することで好きなプログラムを ウィンドウマネージャから起動できます。 もしユーザが Debian の `menu' パッケージをインストール していれば、システムにあるすべてのプログラム用のメニューが作成され、 menu に対応したウィンドウマネージャから利用できます。 以下が dh_make によって生成されたデフォルトの `menu.ex' ファイルです。 ?package(gentoo):needs=X11|text|vc|wm section=Apps/see-menu-manual\ title="gentoo" command="/usr/bin/gentoo" コロン (:) の後の最初の「needs」フィールドには、 プログラムがどういう種類のインターフェースを必要とするかを 指定します。このフィールドはデフォルトとして列挙された 選択肢のどれか (例えばテキスト、X11 など) に変更してください。 次は「section」、プログラムのエントリーが表示される メニューやサブメニューの指定です。現在のセクション一覧は `/usr/share/doc/debian-policy/menu-policy.html/ch2.html#s2.1' に 記載されています。 「title」フィールドはプログラムの名称です。 好みによって、大文字から始めることもできます。 ただし、なるべく短くしておきましょう。 最後の「command」フィールドは、実際にプログラムを 実行するコマンドです。 さて、今回はこんな風に menu エントリを変えましょう。 ?package(gentoo): needs=X11 section=Apps/Tools title="Gentoo" command="gentoo" 他にも「longtitle」、「icon」、「hints」などの フィールドを追加することができます。 より詳細な説明は menufile(5)、 update-menus(1)、 および `/usr/share/doc/debian-policy/menu-policy.html/' を 参照してください。 5.10. watch.ex -------------- このファイルを uscan(1) および uupdate(1) プログラム (これらは `devscripts' パッケージにあります) と 合わせて使うことによって、オリジナルソースを入手したサイトの 更新をチェックすることができます。 今回は以下のようにしました。 # watch control file for uscan # Site Directory Pattern Version Script ftp.obsession.se /gentoo gentoo-(.*)\.tar\.gz debian uupdate ヒント:このファイルを作成したら、インターネットに接続し、ソースを 展開したディレクトリの中から「uscan」を試しに実行してみるとよいでしょう。 それから、マニュアルページも読んでみてください。:) 5.11. ex.package.doc-base ------------------------- もしあなたのパッケージがマニュアルページや info 形式の 文書以外に附属文書を含んでいるのなら、 「`doc-base'」ファイルを使ってそれを登録し、 ユーザがそれらの附属文書を、例えば dhelp(1) や dwww(1) あるいは doccentral(1) などの コマンドで参照できるようにするべきです。 これには通常 `/usr/share/doc/packagename/' の中に収められるような HTML、PS および PDF などの形式の 附属文書が含まれます。 以下に 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: Apps/Tools Format: HTML Index: /usr/share/doc/gentoo/html/index.html Files: /usr/share/doc/gentoo/html/*.html このファイルの書式については install-docs(8) および `/usr/share/doc/doc-base/doc-base.html/' にある `doc-base' のマニュアルを参照してください。 5.12. postinst.ex、preinst.ex、postrm.ex、prerm.ex -------------------------------------------------- これらのファイルはメンテナスクリプトと呼ばれるもので、 パッケージの制御パートに収録され、 あなたのパッケージがインストール、アップグレード、あるいは 削除されるときに dpkg によって実行されます。 今のところは、メンテナスクリプトを手でいじるのは、 できるだけ避けるようにするべきでしょう。 というのも、これらはどんどん複雑になっていってしまう傾向が あるからです。 詳しくはポリシーマニュアルの第 6 章と dh_make によって用意されたこれらのサンプルファイルを 注意して読んでください。 ------------------------------------------------------------------------------- 6. パッケージの構築 ------------------- これでパッケージを構築する準備が整いました。 6.1. 完全な再構築 ----------------- プログラムのメインディレクトリに移動して 以下のコマンドを実行してください: dpkg-buildpackage -rfakeroot このコマンドは、あなたのためにパッケージ構築の 作業をすべて行なってくれます。これには以下の作業が 含まれます。 * `fakeroot' を使ったソースツリーの初期化 (debian/rules clean) * ソースパッケージの構築 (dpkg-source -b) * プログラムの構築 (debian/rules build) * `fakeroot' を使ったバイナリパッケージの構築 (debian/rules binary) * `gnupg' を使ったソース `.dsc' ファイルへの署名 * `dpkg-genchanges' および `gnupg' を使った アップロード用 `.changes' ファイルの作成および署名 途中で GPG の秘密鍵を 2 回入力する必要がありますが、 それを除けばこのプログラムにすべてお任せで大丈夫です。 一連の作業が終わった後、上記のディレクトリ (`~/debian/') には 以下のファイルが作成されているはずです。 * _gentoo_0.9.12.orig.tar.gz_ これは単に Debian 標準に合わせるために名前を変更しただけで、 中身はオリジナルなソースコードの tar アーカイブです。 これは `dh_make' を最初に実行した際、「-f」オプションを 指定して作成されたということを覚えておいてください。 * _gentoo_0.9.12-1.dsc_ これはソースコードの内容の概要です。このファイルは あなたの「control」ファイルから生成され、 dpkg-source(1) によって ソースを展開する時に使われます。 このファイルは GPG で署名されているので、本当にあなた自身が 作成したものかどうかを利用者が検証できます。 * _gentoo_0.9.12-1.diff.gz_ この圧縮されたファイルにはあなたがオリジナルのソースコードに 行なったすべての変更や追加などの情報が「unified diff」の形式で 含まれています。これは dpkg-source(1) によって生成され、また利用されます。警告: もしオリジナルの tar アーカイブの名前を packagename_version.orig.tar.gz の形式に 変更していなかった場合、`dpkg-source' を使って 適切な .diff.gz ファイルを作成できなくなります! 上記の 3 つのファイルを使えば、誰でも簡単にあなたのパッケージを 最初から再構築できます。ソースツリーを取り出す手順は簡単です。 単にこれらの 3 つのファイルをどこか別の場所にコピーして、 `dpkg-source -x gentoo_0.9.12-1.dsc'. を実行するだけです。 * _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 メーリングリストへ流されます。 .dsc ファイルと .changes ファイルに記載されている長い数字の 羅列は各ファイルの MD5 チェックサムで、パッケージをダウンロード した人は md5sum(1) を使って整合性を テストすることができます。もし数字が一致しない場合には、 ファイルが壊れているか、あるいは何者かによって改ざんされている と分かるわけです。 6.2. 部分的な再構築 ------------------- 大規模なパッケージの場合には、`debian/rules' を ちょっといじるたびに、毎回最初からパッケージの再構築を やりなおしたくはないでしょう。 テスト目的の場合、以下のようにすれば上流 (upstream) ソースの 再構築をしないで .deb ファイルを生成できます。 fakeroot debian/rules binary 最終的にきちんとテストが完了したら、正しい手順に従って パッケージを最初から再構築することを忘れないでください。 このやり方で生成した .deb ファイルをアップロードしようと しても、おそらくきちんとアップロードできないでしょう。 ------------------------------------------------------------------------------- 7. できたパッケージの誤りを調べる --------------------------------- lintian(1) をあなたの .changes ファイルに かけてみましょう。このプログラムはパッケージ化におけるよくある間違いを チェックしてくれます。実行するコマンドは以下のとおりです。 lintian -i gentoo_0.9.12-1_i386.changes もちろん、ファイル名はあなたのパッケージのために生成された .changes ファイルの名前に置き換えてください。 もしエラー (E: で始まる行) が表示されたなら、説明 (N: の行) を 読んで誤りを訂正し、第 6.1 節, `完全な再構築' に記述されているように パッケージを完全に再構築してください。 もし W: で始まる行、つまり警告が表示されたら、パッケージを 調整するか、あるいはその警告が間違いであることを確認してください。 (そして Lintian の override ファイルに記載するための設定を 作成してください。この詳細については文書を参照してください。) `dpkg-buildpackage' によるパッケージの生成と、 `lintian' の実行をすべてひとつのコマンド debuild(1) で行なうこともできます。 mc(1) などのファイルマネージャを 使ってパッケージの中を見たり、dpkg-deb(1) を使ってパッケージの中身を一時的な場所へ取り出したりしてみましょう。 なにかがうまく行かず、妙なものが削除されないまま残されてしまった 場合に備えて、バイナリおよびソースパッケージの両方について不要な ファイルが余分に含まれたりしていないかどうか、しっかり検査して ください。 ヒント:「zgrep ^+++ ../gentoo_0.9.12-1.diff.gz」を実行すると、 ソースファイルに対してあなたが行なった変更や追加のリストを 得ることができます。 また `dpkg-deb -c gentoo_0.9.12-1_i386.deb` を実行すると バイナリパッケージ中のファイルのリストを得ることができます。 自分でパッケージをインストールして試してみましょう。 例えば、debi(1) コマンドを root で 実行してみましょう。 自分の環境以外のマシンでも試してみて、パッケージをインストール する際やプログラムを実行する際に警告やエラーが発生しないか 注意深く観察してみてください。 ------------------------------------------------------------------------------- 8. パッケージをアップロードする ------------------------------- 徹底的に新パッケージをテストしたら、これらのファイルを Debian アーカイブにアップロードする必要があります。 これは手作業で行なってもかまいませんが、 dupload(1) や dput(1) のような、あらかじめ 用意されている自動化されたツールを利用したほうがずっと 簡単です。 ここでは `dupload' を使う方法について説明します。 まず dupload の設定ファイルを調整しなければいけません。 システム全体の設定ファイルである `/etc/dupload.conf' を編集するのでも、あるいはあなた専用の設定ファイルである `~/.dupload.conf' を使って変更したい項目だけ 上書きさせるのでも、どちらでもかまいません。 このファイルには以下のような項目を記載します。 package config; $default_host = "ftp-master"; $cfg{"ftp-master"}{"login"} = "yourdebianusername"; $cfg{"non-us"}{"login"} = "yourdebianusername"; 1; もちろん、私の個人的な設定の部分はあなたの設定に従って 変更してください。またそれぞれのオプションが持つ意味を理解する ために dupload.conf(5) マニュアルページ を読んでください。 もっとも気をつけるべき項目は $default_host の選択です。 この項目にはデフォルトとして利用するアップロードキューを指定します。 「ftp-master」がメインのサーバーですが、場合によっては別の、もっと 速い (ネットワーク的に近い) ホストを利用したいこともあるでしょう。 アップロードキューについて、詳しくは開発者レファレンスの 「Uploading a package (パッケージのアップロード)」の節、 `/usr/share/doc/developers-reference/developers-reference.html/ch-upload.en.html#s-uploading' を参照してください。 さてそれでは、インターネットプロバイダに接続し、 以下のコマンドを実行してください: dupload gentoo_0.9.12-1_i386.changes `dupload' は各ファイルの MD5 チェックサムを計算し、 .changes ファイルの中の情報と照合します。 もし一致しない場合にはうまく upload できないため、 第 6.1 節, `完全な再構築' の説明に従って最初から再構築を やり直すよう、警告してきます。 「ftp-master」へアップロードするよう指定した場合、 `dupload' は Debian マシン上でのあなたのパスワードを 確認し、そしてパッケージを upload します。 ------------------------------------------------------------------------------- 9. パッケージの更新 ------------------- 9.1. Debian レビジョンの更新 ---------------------------- 例えば仮に、#54321 という番号のバグレポートがあなたのパッケージ に対してファイルされ、解決するべき問題が記述されていたとしましょう。 パッケージの新しい Debian レビジョンを作成するには、以下を実行する 必要があります。 * もちろん、パッケージソース中の問題を修正します。 * 次に Debian changelog ファイルの先頭に新しいレビジョンを 追加します。例えば「dch -i」を実行するか、またはバージョンを 明示したい場合なら「dch -v -」 を実行してあなたの好きなエディタで説明を記入すると楽にできます。 ヒント: 指定された形式で日付情報を取得する方法は ? 答: 「822-date」または「date -R」を使いましょう。 * changelog の説明行に、このレビジョンで解決されたバグと、 その解決方法についての簡単な説明を記載し、 「Closes: #54321」と続けておきます。 これによってあなたのパッケージが Debian アーカイブ中に受け入れられた時、 アーカイブ管理ソフトウェアによって該当するバグレポート (今回の場合は #54321) が自動的に閉じられます。 * これまで 第 6.1 節, `完全な再構築'、第 7 章, `できたパッケージの誤りを調べる'、 第 8 章, `パッケージをアップロードする' の中で実行してきたことを再度繰り返します。 今までと違うのは、今回の場合オリジナルソースアーカイブには 変更が無く、同じものが既に Debian アーカイブ中に存在しているため、 upload するファイルにはこのファイルが含まれないという点だけです。 9.2. 上流ソフトウェアの更新 (New upstream release) -------------------------------------------------- さて、ではまた別の、もうすこし複雑な状況を考えてみましょう。 新しい上流のバージョン (new upstream version) がリリースされ、 もちろんあなたはそれをパッケージ化したい、という状況です。 この場合、以下を実行する必要があります。 * 新しいソースをダウンロードして (例えば「gentoo-0.9.13.tar.gz」 という名前で) tarball にまとめ、古いソースツリーの上のディレクトリ (例えば ~/debian/) にそれを置きます。 * 古いソースディレクトリに移動し、以下を実行: uupdate -u gentoo-0.9.13.tar.gz もちろん、このファイル名はあなたのプログラムのソースアーカイブ名で 置き換えてください。uupdate(1) は tarball の名前を適切に変更し、以前の .diff.gz ファイルにある変更をすべて 適用して新しい debian/changelog ファイルの内容を更新します。 * ディレクトリを新しいパッケージソースツリーである 「../gentoo-0.9.13」に変更し、今まで 第 6.1 節, `完全な再構築'、 第 7 章, `できたパッケージの誤りを調べる'、第 8 章, `パッケージをアップロードする' の中で 実行してきたことを再度繰り返します。 もし「debian/watch」ファイルを 第 5.10 節, `watch.ex' で 説明したように設定していれば、 uscan(1) を実行して、改訂されたソースを探し、ダウンロードし、 `uupdate' を実行、という一連の手順を (魔法のように) 自動的に行なわせることができます。 9.3. Verifying package upgrades ------------------------------- パッケージの新しいバージョンを構築したら、 (それが New Debian revision でも New upstream release でも) 古いパッケージから安全にアップグレードできることを 検証するために、以下を実行してください。 * 旧バージョンからアップグレードする * 再び旧バージョンにダウングレードして、削除する * 新パッケージとしてインストールする * いったん削除して、またインストールする * 完全削除する もしあなたのパッケージが過去にリリースされたバージョンの Debian に含まれていた場合には、多くの人々が Debian の最新の リリース版に含まれていたバージョンのパッケージから アップグレードしてくるだろうということを覚えておいてください。 そして、そのバージョンからもきちんとアップグレードできることを 忘れずに上記の手順で確認しておいてください。 ------------------------------------------------------------------------------- 10. 相談するには ---------------- 公共の場で質問する前に、まずはマニュアルを読みましょう。 ここでいうマニュアルには、例えば `/usr/share/doc/dpkg'、 `/usr/share/doc/debian'、`/usr/share/doc/package/*' といったディレクトリに含まれる文書や、この文書で言及されたプログラムに 関する man/info ページなどが含まれます。 もしパッケージ化の作業について疑問があり、文書を読んでも その答を見つけられない時には、Debian Mentors メーリングリスト で相談してみましょう。そこには喜んであなたを援助してくれる 経験豊富な Debian 開発者が待っています。ただし、質問する前に あらかじめ関連する文書を (すくなくとも上に挙げたものくらいは) きちんと読んでおきましょう! Debian Mentors メーリングリストについて、詳しくは http://lists.debian.org/debian-mentors/ を御覧ください。 もしあなたがバグレポート (そう、ホンモノのバグレポートです!) を受け取ったら、それはあなたが Debian バグ追跡システム (http://www.debian.org/Bugs/) をじっくり調べて、そこにある文書を読み、バグレポートに効率よく 対処する方法を知る時が来たということです。その時がきたら、 開発者レファレンスの「Handling Bugs (バグの扱い)」という節、 `/usr/share/doc/developers-reference/developers-reference.html/ch-bug-handling.en.html' を調べることを、強くお勧めしておきます。 それでもまだ質問があるのなら、Debian Developers メーリングリスト で尋ねてみるとよいでしょう。 このメーリングリストへの参加方法など、詳しくは http://lists.debian.org/debian-devel/ を御覧ください。 ((訳注: 日本では、Debian JP Project が主催する Debian JP 開発者 メーリングリスト に参加して質問して みても良いでしょう。 詳しくは Debian JP メーリングリスト (http://www.debian.or.jp/MailingList.html) を参照してください。)) 万事うまく行ったとしても、神様にお祈りを忘れずに。 なんでかって？考えても見てください、ほんの数時間の内に (あるいは 数日かかるかも知れませんが) 世界中のユーザがあなたのパッケージを 使うようになるのです。 そしてもしあなたがとんでもないヘマをしでかしていたら、きっと数知れぬ 怒れる Debian ユーザからメール爆撃を食らうはめになるでしょう… まあ冗談ですけど :-) 楽に構えて、バグ報告に対応する準備をしましょう。 それに、Debian ポリシーに完全に沿うようにするまでには まだまだやるべきことがいっぱい残っています。 (もう一度言いますが、_ちゃんとした文書_ を読んで勉強しましょう)。 好運を祈ります! ------------------------------------------------------------------------------- Debian 新メンテナガイド Josip Rodin 翻訳: 八田真行 日本語訳更新 (v1.2): 佐野武俊 version 1.2, 6 April 2002.