Debian メンテナ入門

この文書は GNU 一般公有使用許諾書、バージョン 2 かそれ以降が規定する条件の下で利用できます。

この文書は以下の二つの文書を参考として書かれました。

この文書では、Debian GNU/Linux 用パッケージを作るにはどうしたらよいか、一般的な Debian ユーザ(と開発者予備軍)を対象に解説しようと思います。小難しい専門用語はできるだけ避けて、実用的な例を多く用いて説明していくつもりです。ことわざにもあるように、百聞は一見にしかず ですからね!

Debian が Linux ディストリビューションの最高峰と呼ばれるまでになった理由のひとつがそのパッケージ管理システムです。すでに膨大な数のソフトウェアが Debian 形式になっていますが、まだパッケージ化されていないソフトウェアをインストールしなければならないこともあるでしょう。あるいは、どうやったら自分でパッケージが作れるんだろう、とかそれはとても難しいことなんじゃないか、などと考えたことがあるかもしれません。まあ、もしあなたが本当に駆け出しの Linux ユーザならば困難な仕事でしょうが、でもそうだったら今ごろこんな文書読んでませんて :-) パッケージ作成には、 Unix のプログラミングについて多少の知識が必要です。がしかし、神様みたいに精通している必要は全くありません。

この文書の最新版は常に以下の場所からネットワーク経由で入手できます。また、「maint-guide」パッケージにも含まれています。開発に必要なプログラム

何かを始める前に、開発作業に必要となる以下に挙げるようなパッケージがきちんとインストールされていることをまず確かめておかなければいけません。以下のリストには「essential」または「required」なパッケージが含まれていないことに注意してください。 - これらのパッケージは既にインストールされていることを前提にしています。

この文書は 2.1 「slink」ディストリビューションが Debian の公式安定版リリースで、2.2 「potato」が開発中だった期間に書かれました。そのため、ここで名を挙げたパッケージはほとんどが「potato」に収録されているものとなっています。

以下のパッケージは普通に Debian 2.1 をインストールしたならばすでに(それらが依存する他のパッケージといっしょに)システムに入っているはずです。しかし、念のために「dpkg -s <パッケージ名>」で確認しておきましょう。 binutils - これらのプログラムは、プログラムの「素」となるオブジェクトファイルをアセンブル、あるいはリンクするために使われます。 (「info binutils」とすればマニュアルが読めます) cpp - C プリプロセッサ (詳しくはを参照) cpio - これは tar や zip と同じアーカイバと呼ばれる種のプログラムです(詳しくはを参照)。 dpkg-dev - このパッケージには Debian ソースパッケージを展開、構築、アップロードするのに必要なツール群が含まれています。 (詳しくはを参照)。 file - この便利なプログラムを使うとそのファイルがどういう形式のものか判定することができます(詳しくはを参照)。 gcc - GNU C コンパイラ。ほとんどの Linux プログラムは C 言語で書かれていますが、もしあなたのプログラムがその他のプログラミング言語、例えば C++、Fortran、Pascal などで書かれているならば、それぞれ g++、g77、gpc などをインストールしましょう (詳しくは、、、 )を参照)。 libc6-dev - gcc が、オブジェクトファイルを生成してリンクするのに必要な C ライブラリとヘッダファイルはこのパッケージに入っています。未だに libc5 の使用を推奨、あるいは現に使っているプログラムもありますが、ぜひ新バージョンの libc6 を使うようにしてください。(「info libc」でマニュアルが読めます) make - ふつう、プログラムはいくつかの手順を踏んで生成されます。同じコマンドを何度も何度も繰り返し入力する代わりに、 make プログラムを使えば「Makefile」を書くことで手続きを自動化することができます。また、ある種のプログラムは imake や xmkmf といった Makefile を一揃いのマクロ関数から生成するプログラムを使いますし、より新しいプログラムの多くは autoconf や automake といったプログラムを利用して configure スクリプトと Makefile をプログラムの生成に使っていますので、これらも必要になるかもしれません(詳しくは「info make」、、、、を参照)。 patch - このとても有用なユーティリティはオリジナルとの差異が列挙されたファイル(diff プログラムによって生成)を読み込んでオリジナルのファイルに適用し、パッチ済バージョンを作成します。 (詳しくはを参照)。 perl5 - Perl は今日の Un*x システムにおいてもっとも使われているインタープリタ型スクリプト言語のひとつで、その強力さはしばしば「Unix のスイス軍用チェーンソー」と形容されるほどです (詳しくはを参照)。

以下はおそらくディストリビューションの「devel」セクションから自分でインストールする必要のあるものです。 dh-make と debhelper - dh-make はあとで説明するパッケージのひな型を用意するのに必要となります。dh_make はひな型を作る過程で debhelper ツールのいくつかを使います。これらを使わなくてもパッケージ作成は可能ですが、初めてパッケージを作る方には利用を強くお勧めします。パッケージを作るのも、以後パッケージを管理するのもずっと簡単になるからです。 (詳しくは、、/usr/share/doc/debhelper/README を参照) devscripts - このパッケージはメンテナにとって便利であると思われるいくつかの有用で優れたスクリプトを含んでいますが、これらもまたパッケージ作成に当たって必要というわけではありません(詳しくは /usr/share/doc/devscripts/README.gz 参照)。 fakeroot - このユーティリティを使うと、パッケージ作成の諸段階のいくつかにおいて必要となる root 権限をエミュレートすることができます(詳しくはを参照)。 lintian - これは Debian パッケージチェッカで、あなたが構築したパッケージを調べて、その中にありがちなミスが見つかったらそれを指摘し、その問題について説明してくれます (詳しくは、 /usr/share/doc/lintian/lintian.html/index.html を参照)。

さて、以下のとても重要なパッケージはディストリビューションの「doc」セクションに収録されています。 debian-policy - 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 を参照) packaging-manual - パッケージングマニュアル。 Debian のバイナリ/ソースパッケージを作る上での技術的側面を解説しています。 (詳しくは /usr/share/doc/packaging-manual/packaging.html/index.html を参照)

これらに加え、あなたのパッケージに電子的に署名するために暗号化ソフトウェア PGP (pgp-* パッケージ群)または GPG (gnupg パッケージ)が必要です。これは、もしあなたがご自分のパッケージを他の人に配布したい場合 (あなたのパッケージを Debian ディストリビューションに含めるということは、つまりそういうことなのですが)特に重要になってきます。しかし、アメリカ合衆国のへんちくりんな輸出規制法のせいで、単にこれを近くの Debian FTP サイトからダウンロードするというわけにはいきません。このため、 Debian はこれらのパッケージを物理的にアメリカ合衆国内にないサイトである non-US.debian.org(ftp://non-us.debian.org/debian-non-US/) を通して提供しています。あなたの FTP サイトには README.non-us というファイルがあるはずで、それを見ればどうすればサイトのより近いミラーを探せるかが分かります。

上記の簡単な説明は、それぞれのパッケージが何をするのか紹介するだけのものです。先に進む前にどうかそれぞれのプログラムに付属の文書を徹底的に熟読し、標準的な使い方だけでも理解しておいてください。きついと思われるかも知れませんが、あとになればきっと 読んでてよかったなあと思うことでしょう。注意: debmakeは dh-make と似た働きをするいくつかのプログラムを含むパッケージですが、それ特有の使い方はこの文書の範囲外です。詳しくはを参照してください。その他知っておくべきこと

これから作ろうとするのは 2 種類のパッケージで、それぞれソースパッケージ、バイナリパッケージと呼ばれています。ソースパッケージはコンパイルしてプログラムになるソースコードが含まれます。バイナリパッケージにはでき上がったプログラムそのものです。紛らわしい言葉ですが、「プログラムのソース」と「プログラムのソースパッケージ」を混同しないようにしましょう! もし用語についてもっと知りたければ他のマニュアル類を参照してください。

Debian では、「メンテナ(maintainer)」と言う用語はパッケージを作る人を示し、「上流作者(upstream author)」とはプログラムそれ自身を作った人を指します。そして「上流メンテナ(upstream maintainer)」というのは Debian の外部で現在プログラムそのものを管理している人のことです。たいていの場合、作者と上流メンテナは同一人物ですが、メンテナすらも同じという場合もあり得ます。もしあなたが何かのプログラムを書いて、それを Debian に入れたいと考えたならば、ぜひあなたのアプリケーションを自分でパッケージ化してメンテナになってください。

もしディストリビューションの次のリリースにあなたのプログラムを含めたい(そのプログラムが有用なら、ぜひ!)ならば、パッケージを構築したあとに(あるいはしている最中でも構いませんが) 正式な Debian メンテナになる必要があります。その手続きは開発者リファレンスで説明されていますので、そちらを参照してください。はじめの一歩

にある文書には、パッケージ化を始める上でどこからどうやって手をつけたらよいのかについてあまり書いてありません。この文書ではどんな細かい(最初見た時はほとんど無関係に思えるような)手順も余さず説明し、あなたが最初のパッケージを作るお手伝いをします。ともかく一つ作ってしまえば、あとは次のリリース、そして他のパッケージへと経験を積んでいけばよいのです。パッケージ化するプログラムの選定

パッケージにしたいプログラムについてはすでに各自お考えがあると思いますが、未経験者なら以下をチェックしてみてください。そのパッケージがすでにディストリビューションに収録されていないかどうか確かめてください。もしあなたが「安定版」を使っているのなら、たぶんに行って調べるのが最上の策です。 ((訳注: もついでに見ておくといいかもしれません。)) もしあなたが現在の「開発版」ディストリビューションを使っているのなら、以下のコマンドを使って調べてみてください。 dpkg -s プログラム名 dpkg -l '*プログラム名*' ((訳注: も見ておきましょう))、あるいは debian-devel メーリングリストで誰か他の人が同じプログラムのパッケージを作っていないかどうか確かめてください。もし誰か作っていたら、現在のメンテナに連絡をとってご自分の要望を伝えてください。それで満足したならば、まだ誰も手をつけていない他の面白いプログラムを探して再チャレンジです。プログラムはライセンスを与えられていなければなりません。それがで示されているようなフリーのものであれば言うことなしです。 ((訳注: 日本のミラーサイトはにあります)) もしガイドラインにそぐわない点があっても、Debian の「contrib」や「non-free」セクションに入れることは可能です。もしどのセクションに入れればよいか良く分からなければ、プログラムは setuid root で動くものであってはなりません。 。一番良いのは、setuid とか setgid とかの使用を要求しないプログラムです。デーモンや何か */sbin に行くようなものは手始めとしてはよろしくない。プログラムはバイナリ実行形式になるものがよいでしょう。ライブラリは今はやめといたほうがいいですよ。ちゃんとした説明書きのあること。あるいは少なくとも誰にとっても理解可能なプログラムであること。プログラムの作者に連絡をとってパッケージ化の承諾をもらいましょう。何かプログラムそのものに起因する問題が発生した際に、作者にいろいろ聞けるということは重要なので、由来のはっきりしないソフトウェアの断片をパッケージ化するのはやめておきましょう。そして最後に、といってもこれが重要なのですが、ちゃんと動くかどうか確かめましょう。そして何回か試してみましょう。

もちろんこれらのことは安全策というだけのことです。筆者としては、何も知らないままにパッケージ化しておまけにミスったある種の setuid デーモンのせいで怒り狂ったユーザからあなたに向けて抗議殺到というような事態を回避したいのです。パッケージ化についてもっと経験を積めば、こうしたパッケージも作れるようになるでしょう。しかし、どんなに老練な開発者だって何か分からないことがあれば debian-devel メーリングリストで質問するのです。そこには喜んで手助けしてくれる人々がいます。

もっと詳しい話は、開発者リファレンスに載っていますのでそちらを参照してください。プログラムを手にいれて、試してみる

さて、最初にすべきことは、オリジナルのソースを探してダウンロードすることです。ここでは作者のホームページからすでにソースファイルを入手したとして話を進めます。フリーな Linux 用プログラムのソースはふつう 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 にインストールするものとして説明されていますが、そうしてはいけません。これについてはを参照してください)。

プログラムによって構築の手順は代わりますが、最近のプログラムだと「configure」スクリプトが付属していることがあります。このスクリプトはソースをあなたのシステムに応じて設定し、あなたのシステムにおいてコンパイルできるかどうか確かめます。設定したあと(「./configure」と実行)、プログラムは普通「make」でコンパイルされます。「make check」でプログラムに含まれている自己診断テストを実行できるものもあります。目的のディレクトリへのインストールは一般に「make install」によって実行されます。

さあ、試しにプログラムをコンパイルし、実行してみましょう。インストール中や実行中に他の何かを壊してしまうことが無いかどうか、またちゃんと動作するかどうか、などを確認してください。

それから、「make uninstall」を実行するとインストールされたファイルをすべて削除できる場合が多いです。また「make clean」(もっと良いのは「make distclean」) を実行するとコンパイル用のディレクトリをきれいにしてくれます。「dh_make」を実行する前にやっておくべきこと

パッケージ化の作業は完全にクリーンな (オリジナルのままの) ソースディレクトリ、簡単に言えば新しく展開したソースから始めるべきです。

パッケージをきちんと作るためには、(もしまだそうなっていなければ) プログラム名がすべて小文字になるよう、オリジナルの名前から変更しておかなければいけません。またソースディレクトリ名を <パッケージ名>-<バージョン> に変更しておきましょう。

もしプログラムの名前が一語以上で構成されていたら、一つの語につなげるか省略形にしましょう。例えば、「John's little editor for X」というソフトウェアならば johnledx とか jle4x というようにしましょう。あまり長すぎない程度、せいぜい 20 文字くらいまでの長さで、適当に決めて下されば結構です。

プログラムの正確なバージョンもチェックしましょう (パッケージのバージョンに含めるために)。もしそのソフトウェアが「バージョン X.Y.Z」という形式で番号付けされておらず、ある種の日付で区別されている場合には、バージョン番号として "0.0." にその日付を続けたものを使ってもいいでしょう (先頭に "0.0." を付けておくのは、上流の開発者たちがある日 1.0 のような素敵なバージョンをリリースすると決めた場合に備えてのことです。) つまり、もしリリースの、あるいはスナップショットの日付が 1998 年の 12 月 19 日だったら、0.0.19981219 としておけば結構です。およそバージョン番号に使えそうな情報がまったくないと言う場合、上流メンテナに連絡をとって彼らが何か他のリビジョン管理手段を使っているかどうか聞いてみましょう。「dh_make」の実行

現在プログラムのソースディレクトリにいることを確認し、以下を実行してください。

dh_make -e your.maintainer@address -f gentoo-0.9.12.tar.gz

もちろん、"your.maintainer@address" の部分は changelog のエントリやその他のファイルに記載するための、あなたの電子メールアドレスに置き換えてくさい。またファイル名はオリジナルソースアーカイブの名前に置き換えてください。詳細はを参照してください。

画面にはいろいろ表示されて、あなたが作ろうとしているパッケージがどういう種類のものか聞いてきます。gentoo は単一バイナリパッケージ - すなわちパッケージに含まれるバイナリが一つだけで、一つの .deb ファイルのみが作成される - ですので最初の選択肢を選び、「s」キーを押しましょう。その後、画面に表示される情報をよく読み、確認したら <enter> を押してください。初めてパッケージを作るというときには、マルチバイナリパッケージやライブラリに手を出さない方が無難です。この話は前にもしましたね。実際には作業自体はそれほど大変ではないのですが、ちょっとだけより多くの知識が必要になります。そのため、ここではそれについてごちゃごちゃ説明することは控えます。

dh_make の実行は ただ一度だけ です。注意してください。既に「デビアン化」された同じディレクトリで再び実行すると、正しく動作しないでしょう。これはつまり、将来パッケージの改訂版や新バージョンをリリースする時には別の方法を使うことになる、ということでもあります。後で説明するの部分をしっかり読んでください。ソースコードの変更

ふつう、プログラムは自分自身を /usr/local 以下のディレクトリにインストールするようになっています。しかし、Debian システムにおいては、 /usr/local 以下はシステム管理者(とユーザ)の個人的利用のために予約されているので、Debian パッケージはこのディレクトリを使ってはいけないことになっています。このため、Makefile に始まるプログラムを生成するための仕組を調べなければいけません。Makefile というのはがこのプログラムを自動生成するために利用するスクリプトです。 Makefile について詳しくは、を参照してください。

もしあなたのプログラムが GNU やを使っているのでしたら、ソースにそれぞれ 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 を実行した際に実際の内容に置き換えられます。

修正の具体的なやり方について何から何まで説明するにはとても紙面が足りませんが、よくあるパターンとしては大体以下のようなものでしょう。サブディレクトリへのインストール

ほとんどのプログラムは自分自身をシステムの既存のディレクトリ構造にインストールするための仕組を備えています。これによってインストールされたバイナリがユーザの $PATH に含まれるようになり、また附属文書やマニュアルページをシステムに共通の場所で見ることがでるようになるわけです。あなたがパッケージ化するプログラムがこの作業をきちんと実行できることを確認しなければいけません。さらに、Debian パッケージを作成するためには、プログラムを通常 debian/ ディレクトリの下に作成される作業用のサブディレクトリ以下にインストールさせなければなりません。この一時的なサブディレクトリには通常 debian/tmp という名前が付けられていて、ここの中身をメンテナー用ツールがきちんとした一つの .deb パッケージにまとめあげてくれます。このディレクトリ以下にあるファイルは、パッケージをインストールした際にはすべてユーザのシステムへとインストールされます。唯一の違いは dpkg がファイルをルートディレクトリ以下にインストールするということだけです。

基本的に、パッケージを作成するためにはプログラムを debian/tmp にインストールすることが必要ですが、一方パッケージをインストールした後はルートディレクトリ以下に置かれるため、その状態で正しく動作できるようにしなければなりません。GNU autoconf を使用するプログラムの場合は、 dh_make がこの作業を行なうコマンドを自動的に設定してくれるため、このセクションを読み飛ばしてしまってもいいくらい非常に簡単な作業です。しかし、その他のプログラムについては、おそらく自分で Makefile を調べて編集する必要があるでしょう。

以下は gentoo の Makefile 中の関連する部分です。

# Where to put binary on 'make install'? BIN = /usr/local/bin # Where to put icons on 'make install'? Note: if you change this, # gentoo will not find the icons as it starts up. You're going to # have to alter gentoo's icon path (in the config window, "Paths" # tab) to get it work. ICONS = /usr/local/lib/gentoo/

まず始めに、以下のような新しい行を 2 行挿入しましょう。

# Edited for Debian GNU/Linux. DESTDIR = これはパッケージ構築の過程で必要になります(後のの項で説明します)。

次に、 Makefile で最終的に生成されたバイナリがインストールされる場所が指定されているところを探し、こんな風に変えます。

# Where to put binary on 'make install'? BIN = $(DESTDIR)/usr/X11R6/bin

しかしなぜこのディレクトリなんでしょう。他の所じゃだめでしょうか？だめです。というのも Debian ではどこにプログラムをインストールするかいくつかのルールが決められているからです。これは「ファイルシステム体系基準」 (/usr/share/doc/debian-policy/fhs)で指定されています。 Gentoo は X11 用のプログラムですので、/usr/local/bin ではなく /usr/X11R6/bin にインストールしなければなりません。 man ページは(大抵のプログラムには付属していますが、無い場合もあります。今回は無いのであとでひとつ書くことにします) /usr/local/man/man1 ではなく /usr/share/man/man1 にインストールしなければなりません。

さて次はちょっと厄介な問題です。例えばあなたが次の行を以下のように変更したとします。

ICONS = $(DESTDIR)/usr/share/gentoo/ さて、ポリシーに合わせたのは良いのですが、今度は C のソースそのものをいじってアイコンを参照しているところすべてを修正しなければなりません。でもどこを、そして何を探せばよいのでしょうか？修正すべき個所を探すには ( .c と .h という拡張子のファイルを含むすべてのディレクトリで) こんな風に実行すればよいでしょう。

grep -n usr/local/lib *.[ch] Grep は usr/local/lib という文字列を探して、見つかったファイル名とそれが何行めであるかを教えてくれるでしょう。そうしたらそれらのファイルを編集して usr/local/lib という部分を usr/share に置き換えてやれば良いのです。それでおしまい。usr/local/lib をあなたの指定した場所に置き換えるだけです。他の部分をいじってぐちゃぐちゃにしないよう気をつけましょう。もしあなたが C プログラミングについてあまりご存知ないならば :-)

修正が終ったら、インストールターゲットを探しましょう(「install:」で始まる行を探してみてください)。Makefile の先頭で直接定義されているものを除いて、ディレクトリへの参照をすべて変更してください。 gentoo の元々のインストールターゲットはこんな感じでした。

# ----------------------------------------- Installation # You're going to have to be root to do this! install: gentoo install ./gentoo $(BIN) install icons $(ICONS) install gentoorc-example $(HOME)/.gentoorc

修正後はこんな風になります。 # ----------------------------------------- Installation # You're going to have to be root to do this! 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 $(DESTDIR)/usr/share/doc/gentoo/html cp -a docs/* $(DESTDIR)/usr/share/doc/gentoo/html

鋭い人なら私が「install:」の行の「gentoo」を「gentoo-target」に変えたのに気づくでしょう。こういうのをバグフィックスというのですな。:-)

今のような、特に Debian パッケージだけに関係しない変更はすべて上流メンテナに報告し、プログラムの次のリビジョンに反映してもらうようにしましょう。注意すべきことは debian/* 以下のファイルを送る必要は無いということです。それらを除いたパッチを用意して送りましょう。また、あなたの修正を送る前に、Debian や Linux (あるいは Unix でさえも!) だけに通用するものでなく、できるだけ広範囲に通用するよう心がけることで、上流の開発者にとっての負担を軽減するように努めましょう。使用ライブラリの違い

よくある問題としてもう一つ、ライブラリの問題があります。ライブラリはしばしばプラットフォームごとに異なります。例えば、 Makefile は Debian 上には、あるいはもしかしたら Linux 上には存在しないライブラリへの参照すら含んでいるかもしれません。その場合、その個所を探して、Debian 上に存在する互換のライブラリを指すように変更してやらなければなりません。一番良いのはそういう行をコメントにしておくことです。そうしておけば、他の人が違うプラットフォーム上でコンパイルしようとして何か問題が起こったときに、解決のヒントになるかも知れませんから。

そんなわけで、もしあなたのプログラムの Makefile (または Makefile.in) に以下のような部分があったら(そしてうまくコンパイルできなかったら)、

LIBS = -lcurses -lなんとか -lかんとか

こういう風に変えましょう。今度はきっと大丈夫です。

LIBS = -lncurses -lなんとか -lかんとか #LIBS = -lcurses -lなんとか -lかんとか debian/ ディレクトリ以下に無くてはならないファイル

プログラムのメインディレクトリ (「gentoo-0.9.12」) の中に、「debian」という名前の新しいディレクトリが作られています。このディレクトリ内には様々なファイルが納められていますが、パッケージの動作をカスタマイズするために、これらのファイルをこれから編集していきます。最も重要なファイルは「control」、「changelog」、「copyright」、そして「rules」であり、これらのファイルはすべてのパッケージが必ず用意しなければならないものです。「control」ファイル

このファイルには dpkg と dselect がパッケージを管理するために利用する様々な情報が納められています。以下は dh_make が作ってくれる control ファイルのひな型です。

1 Source: gentoo 2 Section: unknown 3 Priority: optional 4 Maintainer: Josip Rodin <jrodin@jagor.srce.hr> 5 Standards-Version: 3.0.1 6 7 Package: gentoo 8 Architecture: any 9 Depends: ${shlibs:Depends} 10 Description: <insert up to 60 chars description> 11 <insert long description, indented with spaces> (行番号は筆者が書き加えました)

1-5 行目はソースパッケージの管理情報です。1行目はソースパッケージの名前です。

2 行目はディストリビューションにおいてこのパッケージが所属するセクションです。既にお気づきかも知れませんが、Debian はいくつかのセクションに分割されています。セクションには main (完全にフリーなソフトウェア)、 non-free (実際の所フリーであるとはいえないソフトウェア)、そして contrib (それ自身はフリーなソフトウェアであるけれども、non-free なソフトウェアが無ければ使えないもの) があります。更に、これらの下にはどんなパッケージが含まれているのか簡単に説明するような名前の付いた、論理的なサブセクションがいくつか存在しています。つまり、管理者専用のプログラムのために「admin」、基本的なツールのために「base」、プログラマーのためのツールが含まれる「devel」、文書の「doc」、ライブラリの「libs」、電子メールを読み書きするためのリーダやデーモンのための「mail」、ネットワーク関係のアプリケーションやデーモンの「net」、X11 用のプログラムのための「x11」など、そしてさらに多くのものが用意されています。

ここでは x11 に変更しておきましょう。

3行目はこのパッケージがこのパッケージをインストールするユーザにとってどれくらい重要なものかを示しています。セクション(Section) と優先度 (Priority) は、実際には dselect がパッケージをソートするときとデフォルトを選ぶときにしか使われません。そしてこれらのフィールドは (よくあることですが) 我々の FTP メンテナたちによって上書きされることがあります。これらのフィールドに何を設定すべきかについては、ポリシーマニュアルの説明を読んでください。

この gentoo は通常の優先度を持つパッケージなので、ここでは optional のままにしておきましょう。

4 行目はメンテナの名前と電子メールアドレスです。

5 行目はこのパッケージが準拠している Debian ポリシー基準のバージョン (インストールされている debian-policy パッケージの 2 つのメジャーバージョン) です。

もしパッケージを生成するために標準的でないコンパイラ、またはその他のツールが必要なら、ここ (5 行目と 6 行目(空行) の間) に「Build-Depends」行を追加して、必要なパッケージをそこに記載しておきましょう。これについての詳細は、パッケージングマニュアル (8.7 節) および「build-essential」パッケージの附属文書を参照してください。

7 行目はバイナリパッケージの名前です。

8 行目にはバイナリパッケージをコンパイル可能な CPU アーキテクチャを記述します。ここを「any」のままにしておけば、が、このパッケージをコンパイルしたマシンに合わせて適当に埋めてくれます。 (パッケージのポーティングについては、開発者レファレンスを参照してください。) あなたのパッケージが特定のアーキテクチャに依存しないのであれば (例えば、シェルや Perl のスクリプトであるとか、あるいは文書のパッケージである場合) ここを「all」に変更し、パッケージの生成に「binary-arch」ではなく「binary-indep」を使う方法についての説明をあとでの項で読んでおいてください。

9 行目は Debian パッケージ管理システムの最も強力な機能のひとつを示しています。それぞれのパッケージは様々な形で相互に関係情報を持つことができます。パッケージ間の関係には、Depends: すなわち「依存」の他に、Recommends:、 Suggests:、Pre-depends:、Conflicts:、Provides:、Replaces: があります。

dpkg、dselect、APT (そしてそのフロントエンド) などのパッケージ管理ツールは、通常これらの関係を処理する場合に、同じ動作をします。そうでない場合については、追々説明していきます。 (、、、、を参照してください)。

以下にこれらの依存関係が通常持つ意味を説明します。

Depends: 「依存」

パッケージはここで指定したパッケージをインストールしない限りインストールされません。あなたのプログラムが特定のパッケージに依存していて、そのパッケージが存在しない限り全く動作しない (または非常に重大な問題が発生する) 場合には、これを使いましょう。 Recommends: 「推奨」

dselect はここで指定されたパッケージがインストールされていない限りあなたのパッケージをインストールしません。 dpkg と APT の場合には、無視してインストールすることが可能です。厳密に言えばあなたのプログラムの動作に必須ではないけれど、一緒に使うことがほぼ前提となっているようなパッケージはここで指定しましょう。 Suggests: 「提案」

dselect はあなたのプログラムをインストールする際に、ここで指定したパッケージをインストールするかどうかユーザに質問します。 dpkg と APT はこの指定を無視します。必要というわけではないが、あなたのプログラムと一緒に使うと便利というパッケージについては、ここで指定しておきましょう。 Pre-Depends: 「先行依存」

これは Depends: よりも強い関係を示します。ここで指定されたパッケージがあらかじめインストールされ、かつ適切に設定されていない限り、あなたのパッケージはインストールされません。これを使う前に、まずは debian-devel メーリングリストで相談しましょう。できるだけ使わないようにしましょう。早い話が、使っちゃいけません。:-) Conflicts: 「競合」

ここで指定されたすべてのパッケージが削除されない限り、あなたのパッケージはインストールされません。特定のパッケージが存在しているとあなたのプログラムが動作しない (または非常に重大な問題が起きる) 場合には、これを使います。 Provides: 「提供」

ほぼ同じ機能を持つパッケージが複数あって、選択の余地があるような場合のために仮想パッケージ名というものが定義されています。仮想パッケージ名の一覧は、ファイル /usr/share/doc/debian-policy/virtual-package-names-list.text.gz にあります。あなたのプログラムが既存の仮想パッケージに相当する機能を提供する場合には、これを使います。 Replaces: 「置換」

あなたのプログラムが他のパッケージに含まれるファイルを上書きする場合、または他のパッケージ全体を完全に置き換えてしまう場合 (この場合は Conflicts: も一緒に指定してください) には、これを使います。指定されたパッケージに含まれる (上書き対象の) ファイルは、あなたのプログラムをインストールする前に削除されます。

これらのフィールドはすべて共通の書式で記述します。指定したいパッケージ名をコンマで区切って並べてください。もしいくつか選択肢があれば、それらのパッケージ名を縦棒 | (パイプ記号)で区切って並べてください。あるバージョンより上でなければダメ、などというようにパッケージのバージョン番号によって制限を加えることも可能です。これを指定したい場合にはそれぞれのパッケージ名の後で丸カッコ(パーレン) を開き、以下の関係式に続けてバージョン番号を指定してください。使用できる関係式は <<、<=、=、>=、 >>で、それぞれ「指定されたものより古いバージョンのみ」、「指定されたもの以前か指定のバージョン」、「指定のバージョンのみ」「指定されたもの以降か指定のバージョン」、「指定されたものより新しいバージョンのみ」を意味します。

最後に、知っておかなければいけない機能をもうひとつ。それは $(shlibs:Depends) で、例えば libc6 や xlib6g のようなあなたのプログラムが利用している共有ライブラリの名前すべてがによって自動的に調べられ、その結果はによってこの記述と置換されます。これを使えば、あなた自身が自分で共有ライブラリを調べて記述する必要はありません。以上の説明から、今回は 9 行目をそのままにしておくことができます。

ここで 10 行目に gentoo が「提案」するパッケージの一覧を追加します。 gentoo は「file」プログラム/パッケージによって提供される機能をいくつか利用することができるので、ここではそれだけを記載しておきましょう。

11 行目はこのパッケージに関する簡潔な説明です。多くの人々は一行半角 80 文字幅のスクリーンでこれを見ますから、半角 60 文字以上にしてはいけません。今回は「A fully GUI configurable GTK+ file manager」としました。

12 行目はこのパッケージに関する詳細な説明文です。ここでは一つの段落でパッケージについてより詳しく説明するようにしてください。それぞれの行は空白で始めなければいけません。また空白行を入れてはいけませんが、先頭の空白の後に . (半角ピリオド) を書くことで、それらしく見せることができます。また、説明文の後に空白行があってはいけません。

以下が修正後の control ファイルです。

1 Source: gentoo 2 Section: x11 3 Priority: optional 4 Maintainer: Josip Rodin <jrodin@jagor.srce.hr> 5 Standards-Version: 3.0.1 6 7 Package: gentoo 8 Architecture: any 9 Depends: ${shlibs:Depends} 10 Suggests: file 11 Description: A fully GUI configurable GTK+ file manager 12 gentoo is a file manager for Linux written from scratch in pure C. It 13 uses the GTK+ toolkit for all of its interface needs. gentoo provides 14 100% GUI configurability; no need to edit config files by hand and re- 15 start the program. gentoo supports identifying the type of various 16 files (using extension, regular expressions, or the 'file' command), 17 and can display files of different types with different colors and icons. 18 . 19 gentoo borrows some of its look and feel from the classic Amiga file 20 manager "Directory OPUS" (written by Jonathan Potter). 「copyright」ファイル

このファイルにはパッケージの上流 (upstream) に関するリソース (URI など)、著作権、およびライセンスなどの情報を記載します。このファイルの書式はポリシーに規定されていませんが、内容については (6.5 節に) 規定されています。 dh_make はデフォルトとして以下のようなひな型を作成します。

1 This package was debianized by Josip Rodin jrodin@jagor.srce.hr on 2 Wed, 11 Nov 1998 21:02:14 +0100. 3 4 It was downloaded from <fill in ftp site> 5 6 Upstream Author(s): <put author(s) name and email here> 7 8 Copyright: 9 10 <Must follow here> (行番号は筆者が書き加えました)

ここでファイルに追加すべき重要なことは、あなたがこのソフトウェアを入手した場所と、実際に有効な著作権表示およびライセンスです。原則としてライセンスは全文を含めなければなりません。ただし、もしプログラムのライセンスが GNU GPL または LGPL、BSD、あるいは Artistic などの良く知られたフリーソフトウェアのライセンスであって、どの Debian システムにも存在するディレクトリ /usr/share/common-licenses/ の中の適切なファイルを参照することでライセンスの内容をすべて示すことができる場合に限って、全文をここに引用する必要はありません。 gentoo は GNU 一般使用許諾 (GPL) に従って配布されていますから、こんな風に変更しましょう。

1 This package was debianized by Josip Rodin jrodin@jagor.srce.hr 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 <emil@obsession.se> 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 /usr/share/common-licenses/GPL file. (行番号は筆者が書き加えました) 「changelog」ファイル

これは必須のファイルです。パッケージングマニュアル (3.2.3 節) にはこのファイルのための特別な書式が規定されています。この書式は 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 <jrodin@jagor.srce.hr> Wed, 11 Nov 1998 21:02:14 +0100 6 7 Local variables: 8 mode: debian-changelog 9 End: (行番号は筆者が書き加えました)

1 行目はパッケージ名、バージョン、ディストリビューション、そして緊急度 (urgency) です。ここに書くパッケージ名はソースパッケージの名前と一致していなければなりません。またディストリビューションは (今の時点では) 「unstable」または「experimental」のどちらかにすべきであり、緊急度は「low」より高いものに変更するべきではありません :-)

3-5 行目はログエントリで、ここにこのリビジョンのパッケージで行われた変更を記述します (上流プログラムそのものの変更点ではありません - その目的のためには、上流作者によって作成され、 /usr/share/doc/gentoo/changelog.gz としてインストールされる専用のファイルが存在しています)。新しい行はアスタリスク(「*」)で始まる最初の行の直前に挿入します。この操作は、や (7-10 行目は Emacs エディタ用のモード情報です) を使うと便利ですが、その他の普通のテキストエディタを使って実行してももちろん構いません。最終的にこんな風になればよいわけです。

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 <jrodin@jagor.srce.hr> Wed, 11 Nov 1998 21:02:14 +0100 8 9 Local variables: 10 mode: debian-changelog 11 End: (行番号は筆者が書き加えました)

パッケージの新バージョンをリリースする際には、バージョン番号を増やさなければいけません。これは単に「dch -i」を実行するか、あるいは「dch -v <version>-<revision>」によって明示的にバージョン番号を指定して、その後で好みのエディタを使って必要なコメントを記載していきます。ヒント: 規定の書式で日時を入力する簡単な方法。「822-date」または「date -R」を使いましょう。

新バージョンについての情報は changelog ファイルの先頭に追加されます。作業後 changelog はこんな風になります。

1 gentoo (0.9.12-2) unstable; urgency=low 2 3 * Fixed a glitch in the menu file. 4 5 -- Josip Rodin <jrodin@jagor.srce.hr> Wed, 11 Nov 1998 22:15:39 +0100 6 7 gentoo (0.9.12-1) unstable; urgency=low 8 9 * Initial Release. 10 * This is my first Debian package. 11 * Adjusted the Makefile to fix $DESTDIR problems. 12 13 -- Josip Rodin <jrodin@jagor.srce.hr> Wed, 11 Nov 1998 21:02:14 +0100 14 15 Local variables: 16 mode: debian-changelog 17 End: (行番号は筆者が書き加えました)

あとからの中で新しいパッケージのバージョンとレビジョンについてもっと詳しく説明します。「rules」ファイル

さて、今度はが実際にパッケージを作成するために使う「rules」ファイルを調べる必要があります。このファイルは「make -f」で実行されるため、実はもう一つの Makefile といったものですが、上流ソースに含まれる Makefile とは違います。

すべての「rules」ファイルは、他の Makefile と同じく、ソースからプログラムを構築する方法を記述したいくつかのルールによって構成されています。それぞれのルールはいくつかのターゲット、ファイル名、あるいは実行されるべき動作の名前(つまり「build:」や「install:」) によって構成されます。実行したいルールは、コマンドライン引数として指定します (例えば「./debian/rules build」または「make -f rules install」というように)。ターゲット名の後には、依存関係、そのルールが依存しているプログラムやファイルの名前を指定できます。この後には、いくらでもコマンドを記述できます (各行を <タブ>で始めてください!) 空行があると、そこで一つのルールが終り、次のルールが始まります。複数の空行、および「#」 (ハッシュ) で始まる行は行の終りまでコメントと見なされ、無視されます。

以上を読んでもわけが分からないかもしれませんが、dh_make がデフォルトとして作成する「rules」ファイルを実際に読んでみると、理解できるようになるでしょう。また、info コマンドの「make」エントリーに、より詳細な説明があるので、読んでおくと良いでしょう。

dh_make によって作成された rules ファイルについて知っておくべき最も重要なことは、これが単なる提案であり、サンプルに過ぎない、ということです。単純なパッケージに対してはこのままでも使えるでしょうけれど、もっと複雑なパッケージの場合には、必要に応じて追加したり省略したりすることをためらってはいけません。あなたが変えてはいけないのはたった一つ、rules ファイル内に記述された各ルールの名前だけです。すべてのツールがパッケージングマニュアルに規定されたようにこれらの名前を参照するので、ルールの名前を変更してしまうとうまくパッケージを生成できなくなってしまいます。

1 #!/usr/bin/make -f 2 # Made with the aid of dh_make, by Craig Small 3 # Sample debian/rules that uses debhelper. GNU copyright 1997 by Joey Hess. 4 # Some lines taken from debmake, by Christoph Lameter. 5 6 # Uncomment this to turn on verbose mode. 7 #export DH_VERBOSE=1 8 9 # This is the debhelper compatability version to use. 10 export DH_COMPAT=1 11 12 build: build-stamp 13 build-stamp: 14 dh_testdir 15 16 # Add here commands to compile the package. 17 $(MAKE) 18 19 touch build-stamp 20 21 clean: 22 dh_testdir 23 dh_testroot 24 rm -f build-stamp 25 26 # Add here commands to clean up after the build process. 27 -$(MAKE) clean 28 29 dh_clean 30 31 install: build-stamp 32 dh_testdir 33 dh_testroot 34 dh_clean -k 35 dh_installdirs 36 37 # Add here commands to install the package into debian/tmp. 38 $(MAKE) install DESTDIR=`pwd`/debian/tmp 39 40 # Build architecture-independent files here. 41 binary-indep: build install 42 # We have nothing to do by default. 43 44 # Build architecture-dependent files here. 45 binary-arch: build install 46 # dh_testversion 47 dh_testdir 48 dh_testroot 49 # dh_installdebconf 50 dh_installdocs 51 dh_installexamples 52 dh_installmenu 53 # dh_installemacsen 54 # dh_installpam 55 # dh_installinit 56 dh_installcron 57 dh_installmanpages 58 dh_installinfo 59 # dh_undocumented 60 dh_installchangelogs 61 dh_link 62 dh_strip 63 dh_compress 64 dh_fixperms 65 # You may want to make some executables suid here. 66 dh_suidregister 67 # dh_makeshlibs 68 dh_installdeb 69 # dh_perl 70 dh_shlibdeps 71 dh_gencontrol 72 dh_md5sums 73 dh_builddeb 74 75 binary: binary-indep binary-arch 76 .PHONY: build clean binary-indep binary-arch binary install (行番号は筆者が書き加えました)

1 行目は、シェルや Perl のスクリプトでおなじみの表現でしょう。これは、このファイルが /usr/bin/make によって処理されることをオペレーティングシステムに指示しています。

12 行目から 19 行目までは「build」 (およびその子供である「build-stamp」) ルールを記述しており、その中でプログラムをコンパイルするためにアプリケーション自身の Makefile を実行しています。

21 行目から 29 行目までに記述されている「clean」ルールは、パッケージの生成過程によって自動生成されたバイナリその他の不要なファイルをすべて削除します。このルールはどんな時でも (たとえソースツリーがインストール方法を記述する「install」ルールは 31行目から始まります。このルールは基本的にプログラム自身の Makefile に記述されている「install」ルールを実行しますが、インストール先は `pwd`/debian/tmp ディレクトリです - このために gentoo の Makefile の中で $(DESTDIR) をルートインストールディレクトリとして指定しておいたのです。

コメントにもあるように、41 行目の「binary-indep」ルールはアーキテクチャに依存しないパッケージを生成するために使われます。今回の例はそのようなパッケージではないため、ここでするべきことは何もありません。もしあなたのパッケージが「Architecture: all」なら、パッケージを生成するために必要なコマンドをすべてこのルールの中で指定し、その代りに次のルール (「binary-arch」) を空にしておかなければいけません。

さあ、次のルール - 「binary-arch」の番です。45 行目から 73 行目にかけて記述されたこのルールでは、あなたのパッケージが Debian ポリシーに適合するよう、debhelper パッケージに収録されているいくつかの小さなユーティリティを実行して、これから生成するパッケージ中のファイルに対してさまざまな操作を行ないます。

これらのユーティリティの名前は dh_ で始まり、残りの部分はそのユーティリティが実際に行なう内容に関する説明となっています。これらはほとんど読めばすぐわかるような簡単なものですが、以下に説明を追加しておきます。はあなたが正しいディレクトリ (つまり、ソースディレクトリのトップレベル) にいるかどうかをチェックしますは binary* ターゲットと clean ルールの実行に必要なルート権限をあなたが持っているかどうかチェックします。はソースツリーの中に見つかったすべての man ページをパッケージにコピーします。(注意: これは DWIM、つまり書いたとおりの意味です。) ((訳注: DWIM の意味については jargon を参照のこと)) はデバッグ用ヘッダを実行形式ファイルおよびライブラリから取り除き、それらのサイズを小さくします。は man ページとサイズが 4 kB より大きな附属文書を gzip で圧縮します。 ((訳注: 附属文書のうち圧縮形式の画像ファイルと HTML ファイルはサイズに関わらず圧縮されません。既に圧縮済みのファイルも、二重に圧縮されることはありません。)) はパッケージに関連するファイル (例えばメンテナースクリプトなど) を debian/tmp/DEBIAN ディレクトリにコピーします。はライブラリや実行形式ファイルが依存している共有ライブラリを判定します。は control ファイルに必要な情報を追加し、インストールします。はパッケージ中のすべてのファイルに対して MD5 チェックサムを計算します。

これらすべての dh_* スクリプトが実際にはそれぞれ何をするのか、また他にはどんなオプションが使えるのか、などのさらに詳しい情報については、それぞれの man ページを参照してください。また、ここでは取り上げませんでしたが、非常に便利だと思われる dh_* スクリプトが他にもいくつか用意されています。これらに関しては、必要に応じて debhelper の説明書を読んでみてください。

binary-arch セクションの中にある、不要な処理を実行している行はすべてどんどんコメントにしてしまうべきです。gentoo の場合には、 testversion、emacsen、pam、init、cron、manpages、info、undocumented、 suidregister, makeshlibs、そして perl に関する行を、単に gentoo がこれらの処理を必要としていないという理由によってコメントにします。また、今回の場合、60 行目に「FIXES」を追加する必要があります。上流開発者 (upstream) の changelog (変更履歴) ファイルの名前が FIXES だからです。

最後の 2 行は (説明しなかった他の行と同様に) 多少なりとも必要なものです。これらについては make のマニュアルやパッケージングマニュアルの中に説明があります。今のところは、必ず知っておかなくてはいけないような重要な項目というわけではありません。 debian/ の中にあるその他のファイル

debian/ サブディレクトリには他にもいくつかのファイルがあるはずです。それらのほとんどには「.ex」サフィックスが付いており、そのファイルがサンプルであることを示しています。もしこれらの機能のどれかを使いたいと思ったり、また使う必要が生じたりした場合には、そのファイル自身と関連する文書 (ヒント: ポリシーマニュアル) を調べ、「.ex」というサフィックスを取り除くように名前を変更し、そのファイルの内容と rules ファイルとを必要に応じて編集してください。これらのファイルのうち、特によく利用されるものについては、以下のセクションに説明があります。 README.Debian

パッケージに関して何か特別にユーザに知らせる必要がある情報や、オリジナルのソフトウェアとあなたが Debian パッケージにしたバージョンとの相違点は、ここに記述しておくべきです。以下はデフォルトとして dh_make が生成するものです。 gentoo for Debian ---------------------- <possible notes regarding this package - if none, delete this file> Josip Rodin <jrodin@jagor.srce.hr>, Wed, 11 Nov 1998 21:02:14 +0100

今回は特に何も書き込む必要はありません - つまりこのファイルを削除してもいいということです。 conffiles

ソフトウェアに関して最もうんざりさせられることのひとつに、大変な量の時間と労力を費してプログラムをカスタマイズした後でそのための設定変更が一回のアップグレードによってすべて上書きされてしまった場合が挙げられるでしょう。 Debian はこの問題を、設定ファイルを記録しておいて、パッケージをアップグレードする際に古い設定をそのまま使いたいかどうか質問するという方法で解決しました。この機能を使うには、パッケージのプログラムが使う各設定ファイル (たいてい /etc にあります) のフルパス名を 1 行にひとつずつ、この conffiles という名前のファイルに記載します。

gentoo には設定ファイルがひとつあり、それは /etc/gentoorc という名前です。これを「conffiles」ファイルに記載します。もしプログラムに設定ファイルがまったく存在しない場合には、この「conffiles」というファイルは実のところ不要です。 dirs

このファイルには、我々のパッケージが必要としているが、通常のインストール手順 (make install) では作成されないディレクトリを指定します。デフォルトでは、こんな風になっています:

1 usr/bin 2 usr/sbin

一番最初のスラッシュが含まれない事に注意してください。ここではこんな風に変えましょう:

1 usr/X11R6/bin 2 usr/X11R6/man/man1 とはいえ、これらのディレクトリは既に Makefile の中の処理によって既に作成されているはずなので、このファイルは必要ではなく、今回の場合には削除してしまうことができます。 manpage.1.ex

*.ex で終るファイルは、どうやってパッケージにその種のサポートを加えるかという例です。これらの機能を使うには、ファイルを適宜編集して拡張子 .ex を取り除きます。もし使いたくなければ、そのまま削除してください。

すべてのプログラムは man ページを持つべきです。もし無かったら、このひな型を利用して、必要な情報を追加すれば自分で作成しましょう。の man ページには、 man ページの作成方法についての簡潔な説明があります。このファイルの名前をプログラムの名前に変更し、また拡張子をそれが属すべきマニュアル分類に従って付けることを忘れないように。以下がマニュアル分類の要点をまとめたリストです。

セクション | 説明 | メモ 1 ユーザコマンド実行可能なコマンドやスクリプト 2 システムコールカーネルの提供する機能 3 ライブラリコールシステムライブラリに含まれる機能 4 特別ファイルたいていは /dev 内にあるもの 5 ファイルの書式例えば /etc/passwd の書式 6 ゲームまたはその他のどうでもいいプログラム 7 マクロパッケージ man マクロのようなもの 8 システム管理実行するのに root 権限が必要なものなど 9 カーネルルーチン非標準的コールや内部仕様

そんなわけで gentoo のman ページは gentoo.1, あるいは gentoo.1x と呼ばれることになります。1x というのは、gentoo が X11 用のプログラムだからです。元のソースには gentoo.1 という man ページが含まれていなかったので、筆者がサンプルと、上流開発者が提供している文書からの情報をもとに書きました。 menu.ex

X Window System のユーザはたいていプログラムを起動するための設定可能なメニューの機能をもつウィンドウマネージャを使っています。もしユーザが Debian の「menu」パッケージをインストールしていればシステムにあるすべてのプログラム用のメニューのセットが作成され、 menu に対応したウィンドウマネージャから利用できます。 Debian ポリシーでは必要とまではされていない機能ですが、ユーザはきっと喜ぶでしょう。このファイルを編集することで、gentoo をメニューに追加することができます。以下が dh_make によって生成されたデフォルトです:

?package(gentoo):needs=X11|text|vc|wm section=Apps/see-menu-manual\ title="gentoo" command="/usr/bin/gentoo"

最初のフィールドはプログラムがどういう種類のインターフェースを必要とするのか指定します (例えばテキスト、X11 など)。次はプログラムのエントリーが表示されるメニューやサブメニューの指定です。現在のセクション一覧は /usr/share/doc/debian-policy/menu-policy.html/ch2.html#s2.1 に記載されています。第 3 のフィールドはプログラムの名称です。第 4 のフィールドはそのプログラムのアイコンの定義ですが、もしアイコンがなかったら空白のままにしておきましょう。第 5 のフィールドはメニューに実際に表示されるタイトルです。第 6 のフィールドはプログラムを実行するコマンドです。

さて、今回はこんな風に menu エントリを変えましょう。

?package(gentoo):needs=X11 section=Apps/Misc \ title="Gentoo" command="/usr/X11R6/bin/gentoo"

より詳細な説明は、、および /usr/share/doc/debian-policy/menu-policy.html/ を参照してください。 watch.ex

このファイルをおよびプログラム (これらは devscripts パッケージにあります) と合わせて使うことによって、オリジナルソースを入手したサイトの更新をチェックすることができます。今回は以下のようにしました。

# watch control file for uscan # Site Directory Pattern Version Script ftp.obsession.se /gentoo gentoo-(.*)\.tar\.gz debian uupdate

ヒント:このファイルを作成したら、インターネットに接続し、ソースを展開したディレクトリの中から「uscan」を試しに実行してみるとよいでしょう。それから、マニュアルページも読んでみてください。 ex.doc-base

もしあなたのパッケージが HTML やその他の形式の附属文書を (マニュアルページと info 形式の文書以外に) 含んでいるのなら、「doc-base」ファイルを使ってそれを登録し、ユーザがそれらの附属文書を、例えばやなどのコマンドによって見つけられるようにするべきです。

以下に 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

このファイルの書式についてはおよび /usr/doc/doc-base/doc-base.html/index.html にある doc-base のマニュアルを参照してください。 postinst.ex、preinst.ex、postrm.ex、prerm.ex

これらのファイルはメンテナスクリプトと呼ばれるもので、パッケージの制御パートに収録され、あなたのパッケージがインストール、アップグレード、あるいは削除されるときに dpkg によって実行されます。

今のところは、メンテナスクリプトを手でいじるのは、できるだけ避けるようにするべきでしょう。というのも、これらはどんどん複雑になっていってしまう傾向があるからです。詳しくはパッケージングマニュアルの第 6 節と dh_make によって用意されたこれらのサンプルファイルを注意して読んでください。

これでパッケージを構築する準備が整いました。最終段階パッケージの構築

プログラムのメインディレクトリに移動して以下のコマンドを実行してください:

dpkg-buildpackage -rfakeroot

途中で PGP の秘密鍵を 2 回入力する必要がありますが、それを除けばこのプログラムにすべてお任せで大丈夫です。一連の作業が終わった後、上記のディレクトリ (~/debian/) には新しいファイルが 4 つ作成されているはずです。

gentoo_0.9.12-1_i386.deb

これは作成されたバイナリパッケージです。他のすべてのパッケージと同じく、dpkg や dselect を使ってインストールしたり削除したりできます。 gentoo_0.9.12.orig.tar.gz

元のソースコードをまとめてアーカイブにしたもので、誰か他の人がソースからパッケージを再構築したいという場合に使ってもらうことができます。また、現在 Debian パッケージ管理システムを使っていないが、そのプログラムのソースを自分の手でダウンロードし、コンパイルしたいという場合にも役に立ちます。 gentoo_0.9.12-1.dsc

これはソースコードの内容の概要です。このファイルは gentoo-0.9.12/debian/control ファイルから生成され、ソースをによって展開する時に使われます。このファイルは PGP で署名されているので、本当にあなた自身が作成したものかどうかを利用者が検証できます。 gentoo_0.9.12-1.diff.gz

この圧縮されたファイルにはあなたがオリジナルのソースコードに行なったすべての変更や追加などの情報が「unified diff」の形式で含まれています。これはによって生成され、また利用されます。 gentoo_0.9.12-1_i386.changes

このファイルは現在のレビジョンのパッケージにおける変更点をすべて記載したもので、Debian FTP アーカイブ管理プログラムによってバイナリおよびソースパッケージを FTP アーカイブにインストールするために利用されます。これは gentoo-0.9.12/debian/changelog ファイルと .dsc ファイルとを元にして生成されます。

パッケージの保守管理を続けていくと、プログラムの動作が変更されたり新機能が追加されたりすることがあります。あなたのパッケージをダウンロードする人は、このファイルを見れば何が変わったのか一目で分かります。長い数字の羅列は各ファイルの MD5 チェックサムで、パッケージをダウンロードした人はを使って整合性をテストすることができます。もし数字が一致しない場合には、ファイルが壊れているか、あるいは何者かによって改ざんされていると分かるわけです。このファイルは PGP で署名されているので、パッケージの利用者はこのファイルが本当にあなた自身が作成したものかどうかをちゃんと判断できます。

大規模なパッケージの場合には、debian/rules をちょっといじるたびに毎回最初からパッケージの再構築をやりなおしたくはないでしょう。テスト目的の場合、以下のようにすれば上流 (upstream) ソースの再構築をしないで .deb ファイルを生成できます。

fakeroot debian/rules binary

`dh_clean -k` が確実に毎回実行されるように、「install」ルールが「install-stamp」という子供 (これは最近のデフォルトです) を *持たない* ことだけは確認してください。それから、最終的にきちんとテストが完了したら、ちゃんと upload できるようにするため、正しい手順に従ってパッケージを再構築することを忘れないようにしてください。できたパッケージの誤りを調べる

をあなたの .changes ファイルにかけてみましょう。このプログラムはパッケージ化におけるよくある間違いをチェックしてくれます。実行するコマンドは:

lintian -i gentoo_0.9.12-1_i386.changes

もちろん、ファイル名はあなたのパッケージのために生成された changes ファイルの名前に置き換えてください。もしエラー (E: で始まる行) が表示されたなら、説明 (N: の行) を読んで誤りを訂正し、に記述されているように再構築してください。 W: で始まる行は単なる警告ですので、もし大丈夫だという確信があれば無視してしまっても結構です (しかし多くの場合には、修正すべき点が何かしら存在しているようです)。

dpkg-buildpackage によるパッケージの生成と、lintian の実行をすべてひとつのコマンドで行なってしまうこともできます。

などのファイルマネージャを使ってパッケージの中を見たり、を使ってパッケージの中身を一時的な場所へ取り出したりしてみましょう。なにかがうまく行かなくて、妙なものが削除されないままに残されてしまった場合に備えて、バイナリおよびソースパッケージの両方について不要なファイルが余分に含まれたりしていないかどうか、しっかり検査してください。ヒント: `zgrep ^+++ ../gentoo_0.9.12-1.diff.gz` を実行すると、ソースファイルに対してあなたが行なった変更や追加のリストを得ることができ、また `dpkg-deb -c gentoo_0.9.12-1_i386.deb` を実行するとパッケージ中のファイルのリストを得ることができます。

自分でパッケージをインストールして試してみましょう。例えば、コマンドを root で実行してみましょう。自分の環境以外のマシンでも試してみて、インストール時や実行時に警告やエラーが発生しないか注意深く観察してみてください。

また、後日プログラムの新版を元にしたバージョンを構築する際には、パッケージが基本的にアップグレード可能であることを検証するために、以下を実行してください。旧バージョンからアップグレードする (Debian ディストリビューションの旧版に納められているバージョンからのアップグレードもやってみてください) またダウングレードする。新パッケージとしてインストールする(前のバージョンがインストールされていない状態からインストール) 削除して、またインストールして、さらに完全削除してみる。パッケージをアップロードする

徹底的に新パッケージをテストしたら、次にこれらのファイルをを使って master.debian.org にアップロードする必要があります。まず dupload の設定ファイル ~/.dupload.conf を編集しましょう以下はこのファイルの例です。 package config; $default_host = "master"; $cfg{"master"}{"method"} = "scpb"; $cfg{"master"}{"login"} = "joy"; $cfg{"master"}{"visibleuser"} = "jrodin"; $cfg{"master"}{"visiblename"} = "jagor.srce.hr"; $cfg{"master"}{"fullname"} = "Josip Rodin"; $cfg{"non-us"}{"method"} = "scpb"; $cfg{"non-us"}{"login"} = "joy"; $cfg{"non-us"}{"visibleuser"} = "jrodin"; $cfg{"non-us"}{"visiblename"} = "jagor.srce.hr"; $cfg{"non-us"}{"fullname"} = "Josip Rodin"; 1;

もちろん、私の個人的な設定の部分はあなたの設定に従って変更してください。またそれぞれのオプションが持つ意味を理解するためにマニュアルページを読んでください。

インターネットプロバイダに接続し、以下のコマンドを実行してください:

dupload --to master gentoo_0.9.12-1_i386.changes

dupload は各ファイルの md5 チェックサムを計算し、 .changes ファイルの中の情報と照合します。もし一致しない時は正しく upload できるようにの説明に従って再構築するよう、警告してきます。

dupload は master.debian.org 上でのあなたのパスワードを質問し、パッケージを upload し、今回のあなたの upload についての短いアナウンスを必要に応じてもしあなたがヨーロッパに住んでいるなら、master の代わりに他のいくつかの upload queue を利用することが可能です。詳細については、、および開発者レファレンスを参照してください。パッケージの更新

例えば仮に、#54321 という番号のバグレポートがあなたのパッケージに対してファイルされ、解決するべき問題が記述されていたとしましょう。パッケージの新しい Debian レビジョンを作成するには、以下を実行する必要があります。もちろん、パッケージソース中の問題を修正します。 `dch -i` を使って Debian changelog ファイルに新しいレビジョンを追加します。そしてそこにバグとその解決策についての簡単な説明を記載し、「Closes: #54321」と続けておきます。これによってあなたのパッケージが Debian アーカイブ中に受け入れられた時、アーカイブ管理ソフトウェアによってバグレポートが自動的に閉じられます。、、の中で実行してきたことを再度繰り返します。今回のような場合には、オリジナルソースアーカイブは変更されておらず、既に Debian アーカイブ中に存在しているため、upload するファイルにはこのファイルが含まれないという点が前回と異なる点です。

さて、ではまた別の、もうすこし複雑な状況を考えてみましょう - 新しい上流のバージョン (new upstream version) がリリースされ、もちろんあなたはそれをパッケージ化したい、という状況です。この場合、以下を実行する必要があります。新しいソースをダウンロードして (例えば「gentoo-0.9.13.tar.gz」という名前で) tarball にまとめ、古いソースツリーの上のディレクトリ (例えば ~/debian/) にそれを置きます。古いソースディレクトリに移動し、以下を実行: uupdate -u gentoo-0.9.13.tar.gz もちろん、このファイル名はあなたのプログラムのソースアーカイブ名で置き換えてください。は tarball の名前を適切に変更し、以前の .diff.gz ファイルにある変更をすべて適用して新しい debian/changelog ファイルの内容を更新します。ディレクトリを新しいパッケージソースツリーである「../gentoo-0.9.13」に変更し、、、の中で実行してきたことを再度繰り返します。

もし「debian/watch」ファイルをで説明したように設定していれば、を実行して、改訂されたソースを探して、ダウンロードし、 uupdate を実行、という手順を自動的に行なわせることができます。相談するには

公共の場で質問する前に、まずはマニュアルを読みましょう。ここでいうマニュアルには、例えば /usr/share/doc/dpkg、 /usr/share/doc/debian、/usr/share/doc/package/* といったディレクトリに含まれる文書や、この文書で言及されたプログラムに関する man/info ページなどが含まれます。もしあなたがバグレポート (そう、ホンモノのバグレポートです!) を受け取ったら、それはあなたがをじっくり調べて、そこにある文書を読み、バグレポートに効率よく対処する方法を知る時が来たということです。

Debian Mentors メーリングリストそれでもまだ質問があるのなら、Debian Developers メーリングリスト ((訳注: 日本では、Debian JP Project が主催する Debian JP 開発者メーリングリストを参照してください。))

万事うまく行ったとしても、神様にお祈りを忘れずに。なんでかって？考えても見てください、ほんの数時間の内に (あるいは数日かかるかも知れませんが) 世界中のユーザがあなたのパッケージを使うようになるのです。そしてもしあなたがとんでもないヘマをしでかしていたら、きっと数知れぬ怒れる Debian ユーザからメール爆撃を食らうはめになるでしょう… まあ冗談ですけど :-)

楽に構えて、バグ報告に対応する準備をしましょう。それに、Debian ポリシーに完全に沿うようにするまでにはまだまだやるべきことがいっぱい残っています。 (もう一度言いますが、ちゃんとした文書 を読んで勉強しましょう)。好運を祈ります!