[update] maint-guide.ja.sgml (2/5)

[Taketoshi Sano <kgh12351@xxxxxxxxxxx>]

佐野＠浜松です。Debian New Maintainers' Guide 日本語訳更新の
第 2 弾です。よろしくお願いします。

  ====== Japanese translation ======

  <chapt id="modify">ソースコードの変更

  <p>ふつう、プログラムは自分自身を /usr/local 以下のディレクトリに
  インストールするようになっています。しかし、Debian システムにおいては、
  /usr/local 以下はシステム管理者(とユーザ)の個人的利用のために
  予約されているので、Debian パッケージはこのディレクトリを使っては
  いけないことになっています。
  このため、(通常は Makefile に始まる) プログラムを生成するための
  仕組を調べる必要があります。
  Makefile というのは <manref name="make" section="1"> がこのプログラムを
  自動生成するために利用するスクリプトです。
  Makefile についての詳細は、<ref id="rules">を参照してください。

  <p>もしあなたのプログラムが GNU <manref name="automake" section="1"> や
  <manref name="autoconf" section="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 を実行した際に実際の内容に置き換えられます。

  <p>修正の具体的なやり方について<em>何から何まで</em>説明するにはとても
  紙面が足りませんが、よくあるパターンとしては大体以下のようなものでしょう。

  <sect id="destdir">サブディレクトリへのインストール

  <p>ほとんどのプログラムは自分自身をシステムの既存のディレクトリ構造に
  インストールするための仕組を備えています。これによってインストールされた
  バイナリがユーザの $PATH に含まれるようになり、また附属文書やマニュアル
  ページをシステムに共通の場所で見ることができるわけです。
  しかし、もしこのようにしてしまうと、新しくインストールされた
  プログラムはシステム上に既に存在している他のすべてのプログラムの
  中に混ざってしまい、パッケージ作成のためのツールにとって
  あなたのパッケージに含まれるファイルとそうでないファイルを
  見分けることが非常に難しくなります。

  <p>従って、何か別の、例えば以下のような方法を採用する必要があります。
  プログラムを作業用の一時的なサブディレクトリ以下にインストールし、
  メンテナー用ツールを使ってそのサブディレクトリの内容をちゃんと
  動作する .deb パッケージに仕立て上げる、という方法です。
  このディレクトリ以下にあるファイルは、パッケージをインストール
  した際にすべてユーザのシステムへとインストールされます。
  唯一の違いは dpkg がファイルをルートディレクトリ以下に
  インストールするということだけです。

  <p>通常、この一時的なディレクトリは、展開されたソースツリーの
  中にある debian/ ディレクトリの下に作成されます。
  またこのサブディレクトリは <file>debian/tmp</file> とか
  <file>debian/パッケージ名</file> といった名前で呼ばれる
  ことが多いです。

  <p>パッケージを作成するためにはプログラムを debian/パッケージ名 に
  インストールすることが必要ですが、一方 .deb パッケージをインストール
  した後は、ルートディレクトリ以下に展開されるため、その状態で正しく
  動作できるようにしなければならない、ということを覚えておいてください。
  このため、ビルドシステムが
    <tt>/home/me/deb/gentoo-0.9.12/usr/share/gentoo</tt>
  といった特定のパスを示す文字列をパッケージファイルの中に
  記録してしまわないよう、注意しなければなりません。

  <p> GNU autoconf を使用するプログラムの場合は、これはとても
  簡単な作業です。こうしたプログラムでは、
  (例えば) /usr が本当の置き場所だということを残したままで、
  任意のサブディレクトリにインストールできるような makefile が
  デフォルトで作成されます。
  あなたのプログラムが autoconf を使っている場合、dh_make が
  それを検出して、こうした作業を行なうコマンドを自動的に設定
  してくれるため、このセクションを読み飛ばしてしまってもいい
  くらい非常に簡単な作業です。
  しかし、その他のプログラムについては、おそらく自分で Makefile を調べて
  編集する必要があるでしょう。

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

  <p><example>
  # Where to put binary on 'make install'?
  BIN     = /usr/local/bin

  # Where to put icons on 'make install'?
  ICONS   = /usr/local/share/gentoo
  </example>

  <p>オリジナルの設定では、それぞれのファイルを <file>/usr/local</file> 以下に
  インストールするようになっていることがわかります。
  これらのパスを以下のように変更してください：

  <p><example>
  # Where to put binary on 'make install'?
  BIN     = $(DESTDIR)/usr/bin

  # Where to put icons on 'make install'?
  ICONS   = $(DESTDIR)/usr/share/gentoo
  </example>

  <p>しかしなぜこのディレクトリなんでしょう。他の所じゃだめでしょうか？
  だめです。
  なぜなら Debian パッケージの場合、<file>/usr/local</file> 以下へファイルを
  インストールすることは絶対に無いと決まっているからです。このディレクトリ
  以下は個別のシステムの管理者が使うために予約されています。
  Debian システム上でパッケージからインストールされるファイルは
  その代わりに <file>/usr</file> へインストールされます。

  <p>バイナリ、アイコン、文書など、それぞれのファイルを
  保存すべき場所については、
   「ファイルシステム体系基準」 (/usr/share/doc/debian-policy/fhs を参照)
  の中でより正確に規定されています。もしまだ読んだことが無ければ、
  ざっと目を通して、あなたのパッケージに関係しそうな箇所をきちんと
  読んでおくことをお勧めします。

  <p>そういうわけで、バイナリは /usr/local/bin ではなく /usr/bin へ
  インストールしなければなりませんし、マニュアルページは
  /usr/local/man/man1 の代わりに /usr/share/man/man1 へ
  インストールする必要があります。
  ここで gentoo の makefile にはマニュアルページに関する記述が
  まったく無いことに注意してください。Debian ポリシーでは
  すべてのプログラムがそれぞれマニュアルを用意しなければならないと
  定めていますから、後で gentoo のマニュアルを作成して、それを
  /usr/share/man/man1 以下へインストールすることにします。

  <p>プログラムの中には、このようなパスを定義するための makefile 変数を
  使っていないものもあります。このような場合、C のソースそのものを
  いじって、指定された場所を使うように修正しなければなりません。
  でもどこを、そして何を探せばよいのでしょうか？
  以下のコマンドを実行すれば該当箇所を見つけることができます。

  <p><example>
  grep -rn usr/local/lib *.[ch]
  </example>

  <p>これを使うと、grep がソースツリーを再帰的に検索し、
  該当箇所を見つけたらそのファイルの名前と検索対象の文字列
  （ここでは usr/local/lib）を含む行とを表示します。
  
  <p>見つかったファイルを編集して usr/local/ という部分を usr/ に
   置き換えてください。これでもう作業完了です。
   他の部分をいじってぐちゃぐちゃにしないよう気をつけましょう。:-)

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

  <p><example>
  install:        gentoo
                  install ./gentoo $(BIN)
                  install icons/* $(ICONS)
                  install gentoorc-example $(HOME)/.gentoorc
  </example>

  <p>修正後はこんな風になります。
  <example>
  install:        gentoo-target
                  install -d $(BIN) $(ICONS) $(DESTDIR)/etc
                  install ./gentoo $(BIN)
                  install -m644 icons/* $(ICONS)
                  install -m644 gentoorc-example $(DESTDIR)/etc/gentoorc
  </example>

  <p>たぶんお気づきになったでしょうが、変更後はこのルールの
  先頭に <tt>install -d</tt> コマンドが追加されています。
  普通「make install」を実行するようなシステムなら /usr/local/bin や
  その他のディレクトリは既にシステム上に存在しているでしょうから、
  もともとの makefile ではこのコマンドは使われていませんでした。
  しかし、Debian パッケージを作成する場合には、空っぽの（あるいは
  まだ存在さえしていない）ディレクトリにインストールするわけですから、
  これらのディレクトリのそれぞれを毎回作成する必要があります。

  <p>ルールの最後には、上流作者が省略することの多い付加的な資料の
  インストールなど、他の作業を追加することもできます。

  <p><example>
                  install -d $(DESTDIR)/usr/share/doc/gentoo/html
                  cp -a docs/* $(DESTDIR)/usr/share/doc/gentoo/html
  </example>


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

  <p>今のような、特に Debian パッケージだけに限定されない変更を行った場合、
  毎回その内容を上流メンテナに報告し、プログラムの次のリビジョンに反映して
  もらうことで、他のすべての利用者にとっても有益な結果をもたらすように
  しましょう。
  また、あなたの修正を送る前に、Debian や Linux (あるいは Unix でさえも!)
  だけに通用するものでなく、できるだけ広範囲に通用するよう心がけることで、
  上流の開発者があなたの変更を採用しやすくなるように努めましょう。

  <p>上流開発者に debian/ 以下のファイルを送る必要はありません。
  注意してください。

  <sect id="difflibs">使用ライブラリの違い

  <p>よくある問題としてもう一つ、ライブラリの問題があります。
  ライブラリはしばしばプラットフォームごとに異なります。
  例えば、 Makefile は Debian システム上に存在しない
  ライブラリへの参照すら含んでいるかもしれません。
  その場合には、Debian 上に存在する互換のライブラリを
  指すように変更してやらなければなりません。

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

  <p><example>
  LIBS = -lcurses -lなんとか -lかんとか
  </example>

  <p>こういう風に変えましょう。今度はきっと大丈夫です。
  <p><example>
  LIBS = -lncurses -lなんとか -lかんとか
  </example>

  <chapt id="dreq"> debian/ ディレクトリ以下に無くてはならないファイル

  <p>プログラムのソースディレクトリの中に、「debian」という
  名前の新しいディレクトリが作られています。
  パッケージの動作を自分の意図に合わせて調整するには、
  このディレクトリに存在する多くのファイルをその編集します。
  最も重要なファイルは「control」、「changelog」、「copyright」、
  そして「rules」であり、これらのファイルはすべてのパッケージが
  必ず用意しなければならないものです。

  <sect id="control">「control」ファイル

  <p>このファイルには <prgn/dpkg/ と <prgn/dselect/ が
  パッケージを管理するために利用する
  様々な情報が記載されています。

  <p>以下は dh_make が作ってくれる control ファイルのひな型です。

  <p><example>
  1  Source: gentoo
  2  Section: unknown
  3  Priority: optional
  4  Maintainer: Josip Rodin &lt;jrodin@xxxxxxxxxxxxx&gt;
  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: &lt;insert up to 60 chars description&gt;
  12  &lt;insert long description, indented with spaces&gt;
  </example>
  (行番号は筆者が書き加えました)

  <p>1-6 行目はソースパッケージの管理情報です。

  <p>1 行目はソースパッケージの名前です。

  <p>2 行目はディストリビューションにおいて
  このパッケージが所属するセクションです。

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

  <p>ここでは x11 に変更しておきましょう。
  （「main」セクションは省略時のデフォルトなので、
  ここには書きません。）

  <p>3 行目はこのパッケージをインストールすることが
  ユーザにとってどれくらい重要なものかを示しています。
  このフィールドに何を設定すべきかについては、
  Debian ポリシーマニュアルの説明を読んでください。
  新規パッケージの場合、優先度「optional」（選択可能）
  としておけば、通常は問題無いでしょう。

  <p>セクション(Section) と優先度 (Priority) は、
  <prgn/dselect/ のようなフロントエンドが
  パッケージをソートする時とデフォルトを選ぶ時に
  使われます。パッケージを Debian にアップロードすると、
  これらのフィールドの値はアーカイブメンテナたちによって
  上書きされる場合があります。このような場合、該当する
  パッケージのメンテナにそのことを知らせるための
  電子メールが届きます。
  （訳注：具体的な仕組みを説明すると、dpkg などのツールは
  アーカイブ中に用意される「Packages」ファイルの情報を
  パッケージ自体に記録された情報より優先するようになって
  います。そしてこの Packages ファイルの作成と更新は
  アーカイブメンテナの（たくさんある）仕事のひとつ、
  というわけです。）
  
  <p>この gentoo は通常の優先度を持つパッケージですし、
  他のパッケージと衝突することもありませんから、
  ここでは「optional」のままにしておきましょう。

  <p>4 行目はメンテナの名前と電子メールアドレスです。
  電子メールの宛先として問題無くそのまま使えるように
  記載してください。Debian のバグ追跡システムは、
  パッケージがアップロードされたら、ここに記載された
  情報を使ってあなたにユーザーからのバグ報告を
  転送しようとします。コンマ ,、アンド記号 &、
  および括弧 () などの使用は避けてください。

  <p>5 行目はあなたのパッケージを生成するために必要となる
  パッケージのリストです。例えば gcc や make のように
  暗黙の前提としてこのリストに含まれているパッケージも
  いくつかあります。詳しくは <package/build-essential/
  パッケージをご覧ください。もしあなたのパッケージを
  生成するために、このリストに記載されていない、
  標準的でないコンパイラやその他のツールが必要なら、
  それらを「Build-Depends」行に追加しておきます。
  複数のパッケージを記載する場合は、コンマで区切ってください。
  このフィールドの書式については、バイナリ依存関係（後述）の
  ところでもうすこし詳しく説明します。

  <p>ここには Build-Depends-Indep や Build-Conflicts など、
  その他のソース依存関係を設定することもできます。
  これらの情報は Debian がサポートしている他のコンピュータ
  プラットフォーム用にバイナリパッケージを作成する
  自動パッケージ生成プログラムによって利用されます。
  ソース依存関係についての詳細は Debian ポリシーマニュアルを、
  また Debian がサポートしているプラットフォーム
  （アーキテクチャ）と、ソフトウェアをそれらへ移植
  （ポート）する方法については開発者レファレンスを
  参照してください。

  <p>以下のようにすれば、自分のパッケージを生成するために
  必要となるパッケージを見つけることができます。
  <example>
  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
  </example>

  <p>Gentoo の場合、パッケージを生成するために
  <package/xlibs-dev/、<package/libgtk1.2-dev/ 
  および <package/libglib1.2-dev/ が必要でしたので、
  これらを <package/debhelper/ に追加しておきます。

  <p>6 行目はこのパッケージが準拠している Debian ポリシー基準の
  バージョン、つまりあなたがパッケージを作成する際に参照した
  ポリシーマニュアルのバージョンです。

  <p>8 行目はバイナリパッケージの名前です。これは通常ソースパッケージ
  の名前と同じですが、いつもそうだとは限りません。

  <p>9 行目にはバイナリパッケージをコンパイル可能な CPU アーキテクチャ
  を記述します。
  ここを「any」のままにしておけば、
  <manref name="dpkg-gencontrol" section="1">が、このパッケージを
  コンパイルしたマシンに合わせて適当に埋めてくれます。

  <p>
  あなたのパッケージが特定のアーキテクチャに依存しないのであれば
  (例えば、シェルや Perl のスクリプトであるとか、あるいは
  文書のパッケージである場合) ここを「all」に変更し、パッケージの
  生成に「binary-arch」ではなく「binary-indep」を使う方法について
  の説明をあとで <ref id="rules"> の項で読んでおいてください。

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

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

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

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

  <item>Recommends: 「推奨」
  <p>dselect や aptitude などのフロントエンドの場合、ユーザが
  インストールのためにパッケージを選択すると、それが「推奨」
  しているパッケージも一緒にインストールするよう促します。
  さらに dselect の場合には、「Q」または「X」キーで強制的に
  やめさせるまで、推奨されたパッケージをインストールするよう、
  何度でも繰り返し確認を求めてきます。
  しかし dpkg と apt-get の場合、「推奨」されたパッケージに
  関する情報は無視され、あるパッケージをインストールしても、
  そのパッケージが「推奨」しているパッケージについては何の
  メッセージも表示しませんし、もちろんインストールもしません。
  このフィールドには、厳密に言えばあなたのプログラムの動作に
  必須ではないけれど、一緒に使うことがほぼ前提となっている
  ようなパッケージを指定しましょう。</item>

  <item>Suggests: 「提案」
  <p>ユーザがパッケージをインストールする際、dselect や aptitude の
  ようなフロントエンドはすべて、選択したパッケージによって「提案」
  されているパッケージも合わせてインストールするかどうか聞いてきます。
  dpkg と apt-get の場合はまったく気にしません。
  あなたのパッケージの動作に必要というわけではないが、これがあると
  もっと便利に使える、というパッケージについては、この指定を使って
  ください。</item>

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

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

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

  <item>Replaces: 「置換」
  <p>あなたのプログラムが他のパッケージに含まれるファイルを
  上書きする場合、または他のパッケージ全体を完全に置き換えて
  しまう場合 (この場合は Conflicts: も一緒に指定してください)
  この指定を使います。
  ここで指定されたパッケージに含まれるファイルは、
  あなたのパッケージのファイルによって上書きされます。
  </item>
  </list>

  <p>これらのフィールドはすべて共通の書式で記述します。
  指定したいパッケージ名をコンマで区切って並べてください。
  もしいくつか選択肢があれば、それらのパッケージ名を
  縦棒 <tt>|</tt> (パイプ記号)で区切って並べてください。

  <p>あるバージョンより上でなければダメ、などというように
  パッケージのバージョン番号によって制限を加えることも可能です。
  これを指定したい場合にはそれぞれのパッケージ名の後で
  丸カッコ (パーレン) を開き、以下の関係式に続けて
  バージョン番号を指定してください。使用できる関係式は
  <tt>&lt;&lt;</tt>、<tt>&lt;=</tt>、<tt>=</tt>、<tt>&gt;=</tt>、
  <tt>&gt;&gt;</tt>で、それぞれ
  「指定されたものより古いバージョンのみ」、
  「指定されたバージョン以前」(指定のバージョンも当然含まれます)、
  「指定のバージョンのみ」
  「指定されたバージョン以降」(指定のバージョンも当然含まれます)、
  「指定されたものより新しいバージョンのみ」
  を意味します。

  今まで説明してきた依存関係を使うことで、例えば以下のような
  指定も可能です。

  <p><example>
  Depends: foo (>= 1.2), libbar1 (= 1.3.4)
  Conflicts: baz
  Recommends: libbaz4 (>> 4.0.7)
  Suggests: quux
  Replaces: quux (<< 5), quux-foo (<= 7.6)
  </example>
  
  <p>最後に、知っておかなければいけない機能をもうひとつ。
  それは $(shlibs:Depends) です。パッケージを生成する際に、
  その中身が一時的なディレクトリにインストールされた後、
  そこに含まれるバイナリとライブラリによって利用されている
  共有ライブラリと、それらの共有ライブラリを含むパッケージ
  の名前 (例えば libc6 や xlib6g など) が
  <manref name="dh_shlibdeps" section="1"> によって自動的に
  調べられます。そしてその結果は
  <manref name="dh_gencontrol" section="1"> に渡され、control
  ファイル中の $(shlibs:Depends) と置換されます。
  これを使えば、あなた自身が自分で共有ライブラリを調べて記述する
  必要はありません。

  <p>ここまでの説明でわかるように、今回は Depends: 行を dh_make が
  生成してくれたデフォルトの状態のままにしておくことができます。
  gentoo は「file」プログラム/パッケージによって提供される機能を
  いくつか利用することができるので、10 行目の後に新しい行を追加
  して、<tt>Suggests: file</tt> を記入します。

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

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

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

  <p><example>
  1  Source: gentoo
  2  Section: x11
  3  Priority: optional
  4  Maintainer: Josip Rodin &lt;jrodin@xxxxxxxxxxxxx&gt;
  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: A 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).
  </example>
  (行番号は筆者が書き加えました)

  <sect id="copyright">「copyright」ファイル

  <p>このファイルにはパッケージの上流 (upstream) に関する
  リソース (URI など)、著作権、およびライセンスなどの情報を記載します。
  このファイルの書式は Debian ポリシーに規定されていませんが、
  内容については (13.6 節、「Copyright information (著作権情報)」に) 
  規定されています。

  <p>dh_make はデフォルトとして以下のようなひな型を作成します。

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

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

  <p>つまり、gentoo の copyright ファイルはこんな風になります。

  <p><example>
  1  This package was debianized by Josip Rodin jrodin@xxxxxxxxxxxxx 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 &lt;emil@xxxxxxxxxxxx&gt;
  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'.
  </example>
  (行番号は筆者が書き加えました)

  <sect id="changelog">「changelog」ファイル

  <p>これは必須のファイルです。ポリシーマニュアル 5.3 節
  「debian/changelog」にはこのファイルのための特別な書式が
  規定されています。
  この書式は dpkg やその他のプログラムによってあなたのパッケージの
  バージョン番号、レビジョン、ディストリビューション、それに緊急度
  (urgency) を識別するために利用されます。

  <p>あなたが行なったすべての変更をきちんと記載しておくことは
  良いことであり、その意味でこのファイルはまた、パッケージメンテナ
  であるあなたにとっても重要なものです。
  あなたのパッケージをダウンロードした人々は、
  このファイルを見ることで、ユーザが最初に知っておくべき
  このパッケージに関する解決されていない問題があるかどうかを
  知ることができます。
  このファイルはバイナリパッケージ中に
  「/usr/share/doc/gentoo/changelog.Debian.gz」として保存されます。

  <p>dh_make がデフォルトとして生成する changelog はこんな感じです。

  <p><example>
  1  gentoo (0.9.12-1) unstable; urgency=low
  2
  3   * Initial Release.
  4
  5  -- Josip Rodin &lt;jrodin@xxxxxxxxxxxxx&gt; Wed, 11 Nov 1998 21:02:14 +0100
  6
  </example>
  (行番号は筆者が書き加えました)

  <p>1 行目はパッケージ名、バージョン、ディストリビューション、
  そして緊急度 (urgency) です。
  ここに書くパッケージ名はソースパッケージの名前と一致していなければ
  なりません。
  またディストリビューションは「unstable」(または「experimental」)
  にすべきであり、緊急度は「low」より高いものに変更するべきでは
  ありません :-)
  
  <p>3-5 行目はログエントリで、ここにこのリビジョンのパッケージで
  行われた変更を記述します (上流プログラムそのものの変更点では
  ありません - その目的のためには、上流作者によって作成され、
  /usr/share/doc/gentoo/changelog.gz としてインストールされる
  専用のファイルが存在しています)。
  新しい行はアスタリスク(「*」)で始まる最初の行の直前に挿入します。
  この操作は
  <manref name="dch" section="1"> を使うと便利ですが、
  その他の普通のテキストエディタを使って実行しても
  もちろん構いません。

  <p>最終的にこんな風になればよいわけです。

  <p><example>
  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 &lt;jrodin@xxxxxxxxxxxxx&gt; Wed, 11 Nov 1998 21:02:14 +0100
  8
  </example>
  (行番号は筆者が書き加えました)

  <p>後述する <ref id="update"> の中で、changelog ファイルを
  更新する方法についてもっと詳しく説明します。

  <sect id="rules">「rules」ファイル

  <p>さて、今度は <manref name="dpkg-buildpackage" section="1"> が
  実際にパッケージを作成するために使う「rules」ファイルを
  調べる必要があります。
  このファイルは実はもう一つの Makefile といったものですが、
  上流ソースに含まれる Makefile とは違います。
  また debian/ ディレクトリに含まれる他のファイルとは異なり、
  このファイルには実行属性が付けられています。

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

  <p>これだけ読んでもわけが分からないかもしれませんが、dh_make が
  デフォルトとして作成する「rules」ファイルについて調べていくうちに、
  きっと理解できるようになります。
  また、info コマンドの「make」エントリーに、より詳細な説明が
  あるので、これも合わせて読んでおくと良いでしょう。

  <p>dh_make によって作成された rules ファイルについて知っておくべき
  最も重要なことは、これが単なるひな型であり、ひとつの例でしかない、
  ということです。
  単純なパッケージならそのまま使えるかもしれませんが、
  もっと複雑なパッケージの場合には、必要に応じて追加したり
  削除したりすることをためらってはいけません。
  あなたが変えてはいけないのはたった一つ、rules ファイル内に
  記述された各ルールの名前だけです。
  パッケージ管理ツールはすべて、Debian ポリシーの規定に
  従ってこれらのルール名を参照するので、変更してしまうと
  うまくパッケージを生成できなくなってしまいます。

  <p>dh_make はデフォルトの debian/rules ファイルとして
  (おおよそ) 以下のようなひな型を作成します。

  <p><example>
  1  #!/usr/bin/make -f
  2  # Sample debian/rules that uses debhelper.
  3  # GNU copyright 1997 to 1999 by Joey Hess.
  4
  5  # Uncomment this to turn on verbose mode.
  6  #export DH_VERBOSE=1
  7
  8  # This is the debhelper compatibility version to use.
  9  export DH_COMPAT=3
  10
  11 ifneq (,$(findstring debug,$(DEB_BUILD_OPTIONS)))
  12         CFLAGS += -g
  13 endif
  14 ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS)))
  15         INSTALL_PROGRAM += -s
  16 endif
  17
  18 build: build-stamp
  19 build-stamp:
  20	dh_testdir
  21
  22	# Add here commands to compile the package.
  23	$(MAKE)
  24	#/usr/bin/docbook-to-man debian/gentoo.sgml > gentoo.1
  25
  26	touch build-stamp
  27
  28 clean:
  29	dh_testdir
  30	dh_testroot
  31	rm -f build-stamp
  32
  33	# Add here commands to clean up after the build process.
  34	-$(MAKE) clean
  35
  36	dh_clean
  37
  38 install: build
  39	dh_testdir
  40	dh_testroot
  41	dh_clean -k
  42	dh_installdirs
  43
  44	# Add here commands to install the package into debian/gentoo.
  45	$(MAKE) install DESTDIR=$(CURDIR)/debian/gentoo
  46
  47 # Build architecture-independent files here.
  48 binary-indep: build install
  49 # We have nothing to do by default.
  50
  51 # Build architecture-dependent files here.
  52 binary-arch: build install
  53	dh_testdir
  54	dh_testroot
  55 #	dh_installdebconf
  56	dh_installdocs
  57	dh_installexamples
  58	dh_installmenu
  59 #	dh_installlogrotate
  60 #	dh_installemacsen
  61 #	dh_installpam
  62 #	dh_installmime
  63 #	dh_installinit
  64	dh_installcron
  65	dh_installman
  66	dh_installinfo
  67 #	dh_undocumented
  68	dh_installchangelogs ChangeLog
  69	dh_link
  70	dh_strip
  71	dh_compress
  72	dh_fixperms
  73 #	dh_makeshlibs
  74	dh_installdeb
  75 #	dh_perl
  76	dh_shlibdeps
  77	dh_gencontrol
  78	dh_md5sums
  79	dh_builddeb
  80
  81 binary: binary-indep binary-arch
  82 .PHONY: build clean binary-indep binary-arch binary install
  </example>
  (行番号は筆者が書き加えました)

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

  <p>6 行目から 9 行目にかけて記述されている、変数 DH_* の
  意味は、コメントとして書かれている短い説明を読めばすぐに
  わかるでしょう。DH_COMPAT についての詳細はマニュアル
  ページ <manref name="debhelper" section="1"> の
  「Debhelper compatibility levels (debhelper 互換レベル)」
  の項を参照してください。

  <p>11 行目から 16 行目までは Debian ポリシー 11.1 節
  「Binaries (バイナリ)」に規定されたパラメータ
  DEB_BUILD_OPTIONS をサポートするための枠組です。
  簡単に言えば、このパラメータはバイナリをビルドする際に
  デバッグシンボルを付加するかどうか、またインストールの
  際にそれらをストリップすべきかどうかを制御します。
  繰り返しますが、ここに記載されているのは単なる枠組であり、
  どうすべきかという点についてヒントを示しているに過ぎない、
  ということに注意してください。
  実際にパッケージを開発する際には、デバッグシンボルの付加と
  インストール時のストリップについて、上流開発者がソフトウェアを
  生成する際にどのように扱っているかを調べ、そして自分自身で
  このパラメータをサポートする仕組を実装してください。

  <p>通常、デバッグシンボルを付加するには、コンパイルの際に
  CFLAGS 変数を使って gcc に「-g」オプションを指定します。
  もしあなたのパッケージもこの方法でうまくいくようなら、
  build ルール (後述) の中で $(MAKE) を実行している箇所に
  <tt>CFLAGS="$(CFLAGS)"</tt> を <em>追加</em>して、この
  変数を指定します。もしあなたのパッケージが autoconf に
  よる configure スクリプトを利用しているなら、別の方法と
  して build ルールの中で ./configure を実行する際に
  上記の <tt>CFLAGS="$(CFLAGS)"</tt> を <em>前置き</em> して
  configure スクリプトに渡すこともできます。

  <p>ストリップについて説明すると、たいていのプログラムは
  ストリップせずにインストールされるよう設定されており、
  また多くの場合、それを変更するためのオプションは用意されて
  いません。そのような場合でも Debian なら大丈夫、あなたは
  <manref name="dh_strip" section="1"> を利用することができます。
  これは DEB_BUILD_OPTIONS=nostrip フラッグが設定されているか
  どうかを調べて、このフラッグが有効な場合にはバイナリを
  ストリップせずにそのまま (エラーを出さずに) 終了してくれます。

  <p>18 行目から 26 行目までは「build」 (およびその子供である
  「build-stamp」) ルールを記述しており、その中でプログラムを
  コンパイルするためにアプリケーション自身の Makefile を実行
  しています。コメントとして記載されている docbook-to-man の
  サンプルについては、後で説明する <ref id="manpage"> の箇所を
  参照してください。

  <p>28 行目から 36 行目までに記述されている「clean」ルールは、
  パッケージの生成過程によって自動生成されたバイナリその他の
  不要なファイルをすべて削除します。
  このルールはどんな時でも (たとえソースツリーが <em/削除/ 
  されてしまっている状態でも!) きちんと動作しなければいけません。
  このため、強制オプションを使うか (たとえば rm なら「-f」)、
  返り値 (エラー) を無視する (コマンド名の前に「-」を追加) 
  などの措置を講じてください。
  
  <p>インストール方法を記述する「install」ルールは 38 行目から
  始まります。このルールは基本的にプログラム自身の Makefile に
  記述されている「install」ルールを実行しますが、インストール
  先は <tt>$(CURDIR)/debian/gentoo</tt> ディレクトリです - 
  このために gentoo の Makefile の中で $(DESTDIR) を
  ルートインストールディレクトリとして指定しておいたのです。
  
  <p>コメントにもあるように、48 行目の「binary-indep」ルールは
  アーキテクチャに依存しないパッケージを生成するために使われます。
  今回の例はそのようなパッケージではないため、ここでするべきことは
  何もありません。
  
  <p>さあ、次のルール - 「binary-arch」の番です。52 行目から 79 行目に
  かけて記述されたこのルールでは、あなたのパッケージが Debian ポリシー
  に適合するよう、debhelper パッケージに収録されているいくつかの小さな
  ユーティリティを実行して、これから生成するパッケージ中のファイルに
  対してさまざまな操作を行ないます。
  
  <p>もしあなたのパッケージが「Architecture: all」なら、パッケージを
  生成するために必要なコマンドをすべて「binary-indep」ルールの中で
  指定し、その代りに「binary-arch」ルールを空にしておかなければ
  いけません。

  <p>debhelper プログラムの名前は dh_ で始まり、残りの部分は
  そのユーティリティが実際に行なう内容に関する説明となっています。
  これらはほとんど読めばすぐわかるような簡単なものですが、
  以下に説明を追加しておきます。

  <list>
  <item><manref name="dh_testdir" section="1"> はあなたが正しい
  ディレクトリ (つまり、ソースディレクトリのトップレベル) に
  いるかどうかをチェックします
  <item><manref name="dh_testroot" section="1"> は「binary-arch」
  および「binary-indep」ターゲットと「clean」ルールの実行に必要な
  ルート権限をあなたが持っているかどうかチェックします。
  <item><manref name="dh_installman" section="1"> はマニュアル
  ページをパッケージ作成用ディレクトリの中の適切な場所へコピー
  します。ただしこれを使う際には、インストールしたいマニュアル
  ページの場所をソースディレクトリのトップレベルからの相対的な
  位置で指定しなければいけません。
  <item><manref name="dh_strip" section="1"> はデバッグ用ヘッダを
  実行形式ファイルおよびライブラリから取り除き、それらのサイズを
  小さくします。
  <item><manref name="dh_compress" section="1"> は
  マニュアルページとサイズが 4 kB より大きな附属文書を
  <manref name="gzip" section="1"> で圧縮します。
  <item><manref name="dh_installdeb" section="1"> はパッケージに
  関連するファイル (例えばメンテナースクリプトなど) を
  <file>debian/gentoo/DEBIAN</file> ディレクトリにコピーします。
  <item><manref name="dh_shlibdeps" section="1"> はライブラリや
  実行形式ファイルが依存している共有ライブラリを判定します。
  <item><manref name="dh_gencontrol" section="1"> は
  control ファイルに必要な情報を追加し、
  <file>debian/gentoo/DEBIAN</file> へインストールします。
  <item><manref name="dh_md5sums" section="1"> はパッケージ中の
  すべてのファイルに対して MD5 チェックサムを計算します。
  </list>

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

  <p>binary-arch セクションの中にある、不要な処理を
  実行している行はすべてどんどんコメントにしてしまうか、
  あるいは削除してしまうべきです。
  gentoo の場合、examples、cron、init、man、そして info に
  関する処理は必要ありませんから、コメントにしておきます。
  また今回の場合、68 行目の「ChangeLog」を「FIXES」に変更して
  おきます。上流開発者 (upstream) の changelog (変更履歴) 
  ファイルの名前が FIXES だからです。  

  <p>最後の 2 行は (説明しなかった他の行と同様に) 多少なりとも
  必要なものです。これらについては make のマニュアルや
  Debian ポリシーマニュアルの中に説明があります。
  今のところは、必ず知っておかなくてはいけないような重要な項目
  というわけではありません。

  ====== Original version ======

  <chapt id="modify">Modifying the source

  <p>Normally, programs install themselves in the /usr/local subdirectories. 
  But, Debian packages must not use that directory, since it is reserved for
  system administrator's (or user's) private use. This means that you have
  to take a look at your program's build system, usually starting with the
  Makefile. This is the script <manref name="make" section="1"> will use to
  automate building this program. For more details on Makefiles, look in
  <ref id="rules">.

  <p>Note that if your program uses GNU <manref name="automake" section="1">
  and/or <manref name="autoconf" section="1">, meaning the source includes
  Makefile.am and/or Makefile.in files, respectively, you will need to
  modify those files. This is because each automake invocation will rewrite
  Makefile.in's with information generated from Makefile.am's, and each
  ./configure invocation will do the same with Makefile's, with data from
  Makefile.in's. Editing Makefile.am files requires some knowledge of
  automake, which you can read about in the automake info entry, whereas editing
  Makefile.in files is pretty much the same as editing Makefile files, just
  pay attention on the variables, i.e. any strings surrounded with `@'s, for
  example @CFLAGS@ or @LN_S@, which are replaced with actual stuff on each
  ./configure invocation.

  <p>Also note that there isn't space here to go into <em>all</em> the
  details of fixing upstream sources, but here are a few problems people
  often run across.

  <sect id="destdir">Installation in a subdirectory

  <p>Most of the programs have some way of installing themselves in the
  existing directory structure of your system, so that their binaries get
  included in your $PATH, and that you find their documentation and manual
  pages in common places. However, if you do that, the program will be
  installed among everything else already on your system. This would make
  it hard for the packaging tools to figure out which files belong to your
  package and which don't.

  <p>Therefore you need to do something else: install the program into a
  temporary subdirectory from which the maintainer tools will build a working
  .deb package. Everything that is contained in this directory will be
  installed on user's system when they install your package, the only
  difference is that dpkg will be installing the files in the root
  directory.

  <p>This temporary directory is usually created under your debian/
  directory in the unpacked source tree. It is usually called
  <file>debian/tmp</file> or <file>debian/packagename</file>.

  <p>Bear in mind that even though you need to make the program install in
  debian/packagename, it still needs to behave correctly when placed in the
  root directory, i.e. when installed from the .deb package. So you mustn't
  allow the build system to hardcode strings like
  <tt>/home/me/deb/gentoo-0.9.12/usr/share/gentoo</tt> into the package
  files.

  <p>With programs that use GNU autoconf, this will be quite easy. Most such
  programs have makefiles that are by default set up to allow installation
  into a random subdirectory while keeping in mind that /usr (for example)
  is the canonical prefix. When it detects your program uses autoconf,
  dh_make will set up commands for doing all this
  automatically, so you might as well skip reading this section. But with
  other programs, you will most probably have to examine and edit the
  Makefiles.

  <p>Here's the relevant part of gentoo's Makefile:

  <p><example>
  # Where to put binary on 'make install'?
  BIN     = /usr/local/bin

  # Where to put icons on 'make install'?
  ICONS   = /usr/local/share/gentoo
  </example>

  <p>We see that the files are set to install under <file>/usr/local</file>.
  Change those paths to:

  <p><example>
  # Where to put binary on 'make install'?
  BIN     = $(DESTDIR)/usr/bin

  # Where to put icons on 'make install'?
  ICONS   = $(DESTDIR)/usr/share/gentoo
  </example>

  <p>But why in that directory, and not some other? Because Debian packages
  never install files beneath <file>/usr/local</file> -- that tree is
  reserved for the system administrator's use. Such files on Debian
  systems go under <file>/usr</file> instead.

  <p>The more exact locations for binaries, icons, documentation etc are
  specified in the Filesystem Hierarchy Standard
  (see /usr/share/doc/debian-policy/fhs/). I recommend you browse it and read
  the sections that might concern your package.

  <p>So, we should install the binary in /usr/bin instead of /usr/local/bin,
  the manual page in /usr/share/man/man1 instead of /usr/local/man/man1 etc.
  Notice how there's no manual page mentioned in gentoo's makefile, but
  since the Debian Policy requires that every program has one, we'll make
  one later and install it in /usr/share/man/man1.

  <p>Some programs don't use makefile variables to define paths such as
  these. This means you might have to edit some real C sources in order to
  fix them to use the right locations.
  But where and what to search? You can find this out by issuing:

  <p><example>
  grep -rn usr/local/lib *.[ch]
  </example>

  <p>Grep will run recursively through the source tree and tell
  you the name of the file and the line in it, when it finds an occurrence.

  <p>Edit those files and in those lines replace /usr/local/* with usr/*
  -- and that's about it. Be careful that you don't mess up the rest of
  the code! :-)

  <p>After that you should find the install target (search for line that
  starts with `install:', that will usually work) and rename all references
  to directories other than ones defined at the top of the Makefile.
  Previously, gentoo's install target said:

  <p><example>
  install:        gentoo
                  install ./gentoo $(BIN)
                  install icons/* $(ICONS)
                  install gentoorc-example $(HOME)/.gentoorc
  </example>

  <p>After our change it says:
  <example>
  install:        gentoo-target
                  install -d $(BIN) $(ICONS) $(DESTDIR)/etc
                  install ./gentoo $(BIN)
                  install -m644 icons/* $(ICONS)
                  install -m644 gentoorc-example $(DESTDIR)/etc/gentoorc
  </example>

  <p>You've surely noticed that there's now a <tt>install -d</tt> command
  before the other commands in the rule. The original makefile didn't have
  it because usually the /usr/local/bin and other directories already exist
  on the system where one runs `make install`. However, since we will
  install into our own empty (or even nonexistent) directory, we will have
  to create each and every one of those directories.

  <p>We can also add in other things at the end of the rule, like the
  installation of additional documentation that the upstream authors
  sometimes omit:

  <p><example>
                  install -d $(DESTDIR)/usr/share/doc/gentoo/html
                  cp -a docs/* $(DESTDIR)/usr/share/doc/gentoo/html
  </example>

  <p>A careful reader will notice that I changed `gentoo' to `gentoo-target'
  in the `install:' line. That is called an unrelated bug fix :-)

  <p>Whenever you make changes that are not specifically related to Debian
  package, be sure to send them to the upstream maintainer so they can be
  included in the next program revision and be useful to everyone else.
  Also remember to make your fixes not specific to Debian or Linux (or even
  Unix!) prior to sending them -- make them portable. This will make your
  fixes much easier to apply.

  <p>Note that you don't have to send the debian/* files upstream.

  <sect id="difflibs">Differing libraries

  <p>There is one other common problem: libraries are often different from
  platform to platform. For example, Makefile can contain a reference to a
  library which doesn't exist on Debian systems. In that case, we
  need to change it to a library which does exist in Debian, and serves the
  same purpose.

  <p>So, if there is a line in your program's Makefile (or Makefile.in) that
  says something like this (and your program doesn't compile):

  <p><example>
  LIBS = -lcurses -lsomething -lsomethingelse
  </example>

  <p>Change it to this, and it will most probably work:
  <p><example>
  LIBS = -lncurses -lsomething -lsomethingelse
  </example>

  <p>(The author realizes that this is not the best example considering our
  libncurses package now ships with a libcurses.so symlink, but he couldn't
  think of a better one. Suggestions very welcome :-)

  <chapt id="dreq">Required stuff under debian/

  <p>There is a new subdirectory under the program's source directory,
  it's called `debian'. There are a number of files in this directory that
  we should edit in order to customize
  the behavior of the package. The most important of them are `control',
  `changelog', `copyright' and 'rules', which are required for all packages.

  <sect id="control">`control' file

  <p>This file contains various values which <prgn/dpkg/, <prgn/dselect/ and
  other package management tools will use to manage the package.

  <p>Here is the control file dh_make creates for us:

  <p><example>
  1  Source: gentoo
  2  Section: unknown
  3  Priority: optional
  4  Maintainer: Josip Rodin &lt;jrodin@xxxxxxxxxxxxx&gt;
  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: &lt;insert up to 60 chars description&gt;
  12  &lt;insert long description, indented with spaces&gt;
  </example>
  (I've added the line numbers.)

  <p>Lines 1-6 are the control information for the source package.

  <p>Line 1 is the name of the source package.

  <p>Line 2 is the section of the distribution the source package goes into. 

  <p>As you may have noticed, Debian is divided in sections: main (the free
  software), non-free (the not really free software) and contrib (free
  software that depends on non-free software). Under those, there are
  logical subsections that describe in short what packages are in.
  So we have `admin' for administrator-only programs, `base' for the
  basic tools, `devel' for programmer tools, `doc' for documentation,
  `libs' for libraries, `mail' for e-mail readers and daemons, `net' for
  network apps and daemons, `x11' for X11 programs that don't fit anywhere
  else, and many more.

  <p>Let's change it then to x11. (A "main/" prefix is implied so we can
  omit it.)

  <p>Line 3 describes how important it is that the user installs this package.
  See the Policy manual for guidance on what to set this field to. The
  "optional" priority will usually work for new packages.

  <p>Section and priority are used by frontends like <prgn/dselect/ when
  they sort packages and select defaults. Once you upload the package to
  Debian, the value of these two fields can be overridden by the archive
  maintainers, in which case you will be notified by email.
  
  <p>As this is a normal priority package and doesn't conflict with anything
  else, we'll leave it as "optional".

  <p>Line 4 is the name and email address of the maintainer. Make sure that
  this field includes a valid "To: " header for an email, because after you
  upload it, the bug tracking system will use it to deliver bug emails to
  you. Avoid using commas, ampersands and parenthesis.

  <p>The 5th line includes the list of packages required to build your
  package. Some packages like gcc and make are implied, see the
  <package/build-essential/ package for details. If some non-standard
  compiler or other tool is needed to build your package, you should add
  it to the `Build-Depends' line. Multiple entries are separated with
  commas; read on for the explanation of binary dependencies to find out
  more about the syntax of this field.

  <p>You can also have Build-Depends-Indep, Build-Conflicts and other fields
  here. This data will be used by the Debian automatic package building
  software in order to create binary packages for other computer platforms.
  See the Policy manual for more information about the build-dependencies
  and the Developers' Reference for more information about these other
  platforms (architectures) and how to port software to them.

  <p>Here's a hack you can use to find out which packages your package needs
  to be built:
  <example>
  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
  </example>

  <p>Gentoo also happens to require <package/xlibs-dev/,
  <package/libgtk1.2-dev/ and <package/libglib1.2-dev/ to build, so we'll
  add them here next to <package/debhelper/.

  <p>Line 6 is the version of the Debian Policy standards this package
  follows, the versions of the Policy manual you read while making your
  package.

  <p>Line 8 is the name of the binary package. This is usually the same as
  the name of the source package, but it doesn't necessarily have to be that
  way.

  <p>Line 9 describes the CPU architecture the binary package can be compiled
  for. We'll leave this as "any" because <manref name="dpkg-gencontrol"
  section="1"> will fill in the appropriate value for any machine this
  package gets compiled on.

  <p>If your package is architecture independent
  (for example, a shell or Perl script, or a document), change this to
  "all", and read later in <ref id="rules"> about using the `binary-indep'
  rule instead of `binary-arch' for building the package.

  <p>Line 10 shows one of the most powerful features of the Debian packaging
  system. Packages can relate to each other in various ways. Apart from
  Depends:, other relationship fields are Recommends:, Suggests:,
  Pre-Depends:, Conflicts:, Provides:, and Replaces:.

  <p>The package management tools usually behave the same way when dealing
  with these relations; if not, it will be explained.
  (see <manref name="dpkg" section="8">, <manref name="dselect" section="8">,
  <manref name="apt" section="8">, <manref name="aptitude" section="1"> etc.)

  <p>This is what the dependencies mean:

  <p><list>
  <item>Depends:
  <p>The package will not be installed unless the packages it depends on
  are installed. Use this if your program absolutely will not run (or will
  cause severe breakage) unless a particular package is present.</item>

  <item>Recommends:
  <p>Frontends such as dselect or aptitude will prompt you to install the
  recommended packages along with your package; dselect will even insist. 
  dpkg and apt-get will ignore this field, though. Use this for packages
  that are not strictly necessary but are typically used with your
  program.</item>

  <item>Suggests:
  <p>When a user installs your program, all frontends will likely prompt
  them to install the suggested packages. dpkg and apt-get won't care. Use
  this for packages which will work nicely with your program but are not at
  all necessary.</item>

  <item>Pre-Depends:
  <p>This is stronger than Depends:. The package will not be installed
  unless the packages it pre-depends on are installed <em>and correctly
  configured</em>. Use this <strong>very</strong> sparingly and only after
  discussing it on the debian-devel mailing list. Read: don't use it at
  all. :-)</item>

  <item>Conflicts:
  <p>The package will not be installed until all the packages it conflicts
  with have been removed. Use this if your program absolutely will not run
  or will cause severe problems if a particular package is present.</item>

  <item>Provides:
  <p>For some types of packages where there are multiple alternatives
  virtual names have been defined. You can get the full list in the
  /usr/share/doc/debian-policy/virtual-package-names-list.txt.gz file.
  Use this if your program provides a function of an existing virtual
  package.</item>

  <item>Replaces:
  <p>Use this when your program replaces files from another package, or
  completely replaces another package (used in conjunction with Conflicts:).
  Files from the named packages will be overwritten with the files from your
  package.
  </item>
  </list>

  <p>All these fields have uniform syntax. They are a list of package names
  separated by commas. These package names may also be lists of alternative
  package names, separated by vertical bar symbols `<tt>|</tt>' (pipe symbols).

  <p>The fields may restrict their applicability to particular versions of
  each named package. These versions are listed in parentheses after each
  individual package name, and they should contain a relation from the list
  below followed by the version number. The relations allowed are:
  <tt>&lt;&lt;</tt>, <tt>&lt;=</tt>, <tt>=</tt>, <tt>&gt;=</tt> and
  <tt>&gt;&gt;</tt> for strictly earlier, earlier or equal, exactly equal,
  later or equal and strictly later, respectively. For example,

  <p><example>
  Depends: foo (>= 1.2), libbar1 (= 1.3.4)
  Conflicts: baz
  Recommends: libbaz4 (>> 4.0.7)
  Suggests: quux
  Replaces: quux (<< 5), quux-foo (<= 7.6)
  </example>
  
  <p>The last feature you need to know about is ${shlibs:Depends}.
  After your package has been built and installed into the temporary
  directory, <manref name="dh_shlibdeps" section="1"> will scan it for
  binaries and libraries, determine their shared library dependencies and
  detect which packages they are in, such as libc6 or xlib6g. It'll pass
  on the list to <manref name="dh_gencontrol" section="1"> which will fill
  it in the right place, and you won't have to worry about this yourself.

  <p>Having said all that, we can leave the Depends: line exactly as it is
  now, and insert another line after it saying <tt>Suggests: file</tt>,
  because gentoo can use some features provided by that program/package.

  <p>Line 11 is the short description. Most people screens are 80 columns
  wide so this shouldn't be longer than about 60 characters. I'll change
  it to "A fully GUI configurable X file manager using GTK+".

  <p>Line 12 is where the long description goes. This should be a paragraph
  which gives more details about the package. Column 1 of each line should
  be empty. There must be no blank lines, but you can put a single . (dot)
  in a column to simulate that. Also, there must be no more that one blank
  line after the long description.

  <p>Finally, here is the updated control file:

  <p><example>
  1  Source: gentoo
  2  Section: x11
  3  Priority: optional
  4  Maintainer: Josip Rodin &lt;jrodin@xxxxxxxxxxxxx&gt;
  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: A fully GUI configurable X file manager using GTK+
  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).
  </example>
  (I've added the line numbers.)

  <sect id="copyright">`copyright' file

  <p>This file contains the information about package upstream resources,
  copyright and license information. Its format is not dictated by the
  Policy, but the contents is (section 13.6 "Copyright information").

  <p>dh_make created a default one, this is what it looks like:

  <p><example>
  1  This package was debianized by Josip Rodin &lt;jrodin@xxxxxxxxxxxxx&gt; on
  2  Wed, 11 Nov 1998 21:02:14 +0100.
  3
  4  It was downloaded from &lt;fill in ftp site&gt;
  5
  6  Upstream Author(s): &lt;put author(s) name and email here&gt;
  7
  8  Copyright:
  9
  10 &lt;Must follow here&gt;
  </example>
  (I've added the line numbers.)

  <p>The important things to add to this file are the place you got the
  package from and the actual copyright notice and license. You must
  include the complete license, unless it's one of the common free software
  licenses such as GNU GPL or LGPL, BSD or the Artistic license, when you
  can just refer to the appropriate file in /usr/share/common-licenses/
  directory that exists on every Debian system.

  <p>In short, here's how gentoo's copyright file should look like:

  <p><example>
  1  This package was debianized by Josip Rodin &lt;jrodin@xxxxxxxxxxxxx&gt; on
  2  Wed, 11 Nov 1998 21:02:14 +0100.
  3
  4  It was downloaded from: ftp://ftp.obsession.se/gentoo/
  5
  6  Upstream author: Emil Brink &lt;emil@xxxxxxxxxxxx&gt;
  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'.
  </example>
  (I've added the line numbers.)

  <sect id="changelog">`changelog' file

  <p>This is a required file, which has a special format described in
  the Policy section 5.3 "debian/changelog". This format is used by dpkg and
  other programs to obtain the version number, revision, distribution and
  urgency of your package.

  <p>For you, it is also important, since it is good to have documented
  all changes you have done. It will help people downloading your package
  to see whether there are issues with the package that they should know
  about. It will be saved as
  `/usr/share/doc/gentoo/changelog.Debian.gz' in the binary package.

  <p>dh_make creates a default one, and this is how it looks like:

  <p><example>
  1  gentoo (0.9.12-1) unstable; urgency=low
  2
  3   * Initial Release.
  4
  5  -- Josip Rodin &lt;jrodin@xxxxxxxxxxxxx&gt;  Wed, 11 Nov 1998 21:02:14 +0100
  6
  </example>
  (I've added the line numbers.)

  <p>Line 1 is the package name, version, distribution, and urgency.
  The name must match the source package name, distribution should be
  either `unstable' (or even `experimental'), and urgency shouldn't
  be changed to anything higher than `low'. :-)
  
  <p>Lines 3-5 are a log entry, where you document changes made in this
  package revision (not the upstream changes - there is special file for
  that purpose, created by the upstream authors, which you will later install as
  /usr/share/doc/gentoo/changelog.gz). New lines must be inserted just
  before the uppermost line that begins with asterisk (`*'). You can do
  it with <manref name="dch" section="1">, or manually with a text editor.

  <p>You will end up with something like this:

  <p><example>
  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 &lt;jrodin@xxxxxxxxxxxxx&gt; Wed, 11 Nov 1998 21:02:14 +0100
  8
  </example>
  (I've added the line numbers.)

  <p>You can read more about updating the changelog file later in
  <ref id="update">.

  <sect id="rules">`rules' file

  <p>Now we need to take a look at the exact rules which
  <manref name="dpkg-buildpackage" section="1"> will use to actually create
  the package. This file is actually another Makefile, but different than
  the one(s) in the upstream source. Unlike other files in debian/, this one
  is marked as executable.

  <p>Every `rules' file, as any other Makefile, consists of several rules
  specifying how to handle the source. Each rule consists of targets,
  filenames or names of actions that should be carried out (e.g. `build:'
  or `install:'). Rules that you want to execute are invoked as command
  line arguments (for example, `./debian/rules build` or `make -f rules
  install`). After the target name, you can name the dependency, program
  or file that that rule depends on. After that, there can be any number
  of commands, indented with &lt;tab&gt;. A new rule begins with the target
  declaration in the first column. Empty lines and lines beginning
  with `#' (hash) are treated as comments and ignored.

  <p>You are probably confused now, but it will all be clear upon examination
  of the `rules' file that dh_make gives us as a default. You should also
  read the `make' entry in info for more information.

  <p>The important part to know about the rules file created by dh_make, is
  that it is just a suggestion. It will work for simple packages but for
  more complicated ones, don't be afraid to add and subtract from it to fit
  your needs. Only thing that you must not change are the names of the
  rules, because all the tools use these names, as mandated by the Policy.

  <p>Here's (approximately) how the default debian/rules file that dh_make
  generated for us looks like:

  <p><example>
  1  #!/usr/bin/make -f
  2  # Sample debian/rules that uses debhelper.
  3  # GNU copyright 1997 to 1999 by Joey Hess.
  4
  5  # Uncomment this to turn on verbose mode.
  6  #export DH_VERBOSE=1
  7
  8  # This is the debhelper compatibility version to use.
  9  export DH_COMPAT=3
  10
  11 ifneq (,$(findstring debug,$(DEB_BUILD_OPTIONS)))
  12         CFLAGS += -g
  13 endif
  14 ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS)))
  15         INSTALL_PROGRAM += -s
  16 endif
  17
  18 build: build-stamp
  19 build-stamp:
  20	dh_testdir
  21
  22	# Add here commands to compile the package.
  23	$(MAKE)
  24	#/usr/bin/docbook-to-man debian/gentoo.sgml > gentoo.1
  25
  26	touch build-stamp
  27
  28 clean:
  29	dh_testdir
  30	dh_testroot
  31	rm -f build-stamp
  32
  33	# Add here commands to clean up after the build process.
  34	-$(MAKE) clean
  35
  36	dh_clean
  37
  38 install: build
  39	dh_testdir
  40	dh_testroot
  41	dh_clean -k
  42	dh_installdirs
  43
  44	# Add here commands to install the package into debian/gentoo.
  45	$(MAKE) install DESTDIR=$(CURDIR)/debian/gentoo
  46
  47 # Build architecture-independent files here.
  48 binary-indep: build install
  49 # We have nothing to do by default.
  50
  51 # Build architecture-dependent files here.
  52 binary-arch: build install
  53	dh_testdir
  54	dh_testroot
  55 #	dh_installdebconf
  56	dh_installdocs
  57	dh_installexamples
  58	dh_installmenu
  59 #	dh_installlogrotate
  60 #	dh_installemacsen
  61 #	dh_installpam
  62 #	dh_installmime
  63 #	dh_installinit
  64	dh_installcron
  65	dh_installman
  66	dh_installinfo
  67 #	dh_undocumented
  68	dh_installchangelogs ChangeLog
  69	dh_link
  70	dh_strip
  71	dh_compress
  72	dh_fixperms
  73 #	dh_makeshlibs
  74	dh_installdeb
  75 #	dh_perl
  76	dh_shlibdeps
  77	dh_gencontrol
  78	dh_md5sums
  79	dh_builddeb
  80
  81 binary: binary-indep binary-arch
  82 .PHONY: build clean binary-indep binary-arch binary install
  </example>
  (I've added the line numbers.)

  <p>You are probably familiar with lines like line 1 from shell and Perl
  scripts. It tells the operating system that this file is to be processed
  with /usr/bin/make.

  <p>The meaning of DH_* variables mentioned on lines 6 and 9 should be
  evident from the short description. For more information on DH_COMPAT
  read the "Debhelper compatibility levels" section of the
  <manref name="debhelper" section="1"> manual page.

  <p>The lines 11 through 16 are a skeleton of support for DEB_BUILD_OPTIONS
  parameters, described in the Policy section 11.1 "Binaries". Basically,
  these things control if the binaries are to be built with the debugging
  symbols, and if they should be stripped upon installation. Again, this is
  just a skeleton, a hint that you should do it. You should check into how
  the upstream build system handles the inclusion of debugging symbols and
  stripping on installation and implement this yourself.

  <p>Usually you can tell gcc to compile with "-g" using the CFLAGS variable
  -- if that's the case for your package, propagate the variable by
  <em>appending</em> <tt>CFLAGS="$(CFLAGS)"</tt> to the $(MAKE) invocation
  in the build rule (see below). Alternatively, if your package uses an
  autoconf configure script, you can pass it to configure by
  <em>prepending</em> the above string to the ./configure invocation in the
  build rule.

  <p>As for the stripping, programs are commonly configured to install
  themselves unstripped, and often without an option to change this. 
  Fortunately, you still have <manref name="dh_strip" section="1"> which
  will detect when the DEB_BUILD_OPTIONS=nostrip flag is set and silently
  exit.

  <p>Lines 18 through 26 describe the `build' (and its child `build-stamp')
  rule, which runs make with the application's own Makefile to compile the
  program. We'll talk about the commented out docbook-to-man example later
  in <ref id="manpage">.

  <p>The `clean' rule, as specified in lines 28-36, cleans up any unneeded
  binary or auto-generated stuff, left over from building the package.
  This rule must be working at all times (even when the source tree <em/is/
  cleaned up!), so please use the forcing options (e.g. for rm, that is
  `-f'), or have make ignore return values (failures) using a `-' in front
  of the command name.

  <p>The installation process, the `install' rule, starts with line 38.
  It basically runs the `install' rule from the program's own Makefile,
  but installs in the <tt>$(CURDIR)/debian/gentoo</tt> directory - this is
  why we specified
  $(DESTDIR) as the root installation directory in gentoo's Makefile.

  <p>As the comments suggest, the `binary-indep' rule, on the line 48, is
  used to build packages independent of architecture. As we don't have any,
  nothing will be done there.

  <p>On to the next rule - `binary-arch', on lines 52 through 73, in which
  we run several small utilities from the debhelper package that do various
  operations on your package files to make the package Policy conforming.

  <p>If your package is an `Architecture: all' one, you need to include all
  the commands for building the package under the `binary-indep' rule, and
  leave the `binary-arch' rule empty instead.
  
  <p>The names of debhelper programs start with dh_, and the rest is the
  description of what the particular utility does. It is all quite
  self-explanatory, but here are some additional explanations:

  <list>
  <item><manref name="dh_testdir" section="1"> checks that you are in the
        right directory (i.e. the top-level source directory),
  <item><manref name="dh_testroot" section="1"> checks that you have root
        permissions which is needed for the targets `binary-arch',
        `binary-indep' and `clean',
  <item><manref name="dh_installman" section="1"> will copy the manpages
        into the right place in the destination directory, you just have to
        tell it where they are, relative to the top-level source directory,
  <item><manref name="dh_strip" section="1"> strips debugging headers from
        executable files and libraries, to make them smaller,
  <item><manref name="dh_compress" section="1"> compresses man pages and
        documentation larger than 4 kB with <manref name="gzip" section="1">,
  <item><manref name="dh_installdeb" section="1"> copies package related
        files (e.g. the maintainer scripts) to the
        <file>debian/gentoo/DEBIAN</file> directory,
  <item><manref name="dh_shlibdeps" section="1"> calculates shared libraries
        dependencies of the libraries and executables,
  <item><manref name="dh_gencontrol" section="1"> installs a fine-tuned
        version of the control file into <file>debian/gentoo/DEBIAN</file>,
  <item><manref name="dh_md5sums" section="1"> generates MD5 checksums for
        all the files in the package.
  </list>

  <p>For more complete information on what do all these dh_* scripts do, and
  what are their other options, please read their respective manual pages. There
  are some other, possibly very useful, dh_* scripts, which were not
  mentioned here. If you need them, read the debhelper documentation.

  <p>The binary-arch section is the one where you really should comment
  out or remove any lines that call features you don't need. For gentoo,
  I'll comment out lines about examples, cron, init, man and info,
  simply because gentoo doesn't need them. Also, on the line 68, I'll
  replace `ChangeLog' with `FIXES', because that is the real name of the
  upstream changelog file.

  <p>The last two lines (along with any other not explained ones) are just
  some more-or-less necessary things, regarding which you can read in the
  make manual, and the Policy. For now, they're not important to know about.

  ====== End ======
--
   ＃ わたしのおうちは浜松市、アカウミガメもやってくる
    <kgh12351@xxxxxxxxxxx> : Taketoshi Sano (佐野　武俊)