Re: 作業者求む: 「Debian 新メンテナガイド」

[victory.deb@xxxxxxxxx]

victory@ごぶさた-nでし
On Mon, 28 Sep 2009 07:42:12 +0900
Hideki Yamane <henrich@debian.or.jp> wrote:

> 　「Debian 新メンテナガイド」を見ると
> 　http://www.debian.org/doc/manuals/maint-guide/index.en.html
> 　と訳文に差が出ているようです。
> 　原文：version 1.2.13, 5 June 2008.
> 　訳文：version 1.2, 6 April 2002.

原版のcvsにあった2002/4頃のとsvnの最新版との差分を
テキトーに手動でマージして訳してみました。
行数にして半分ほど片づいた(Chapter で言えば4まで)ので一旦投げます。

developers-reference の best packaging practices 
はどーも既存の訳に組み込みにくいのでそのまま放置してます。

これは統一感の無い変更
668行辺りの変更
  6  Standards-Version: 3.6.2
なのに891行辺りそのまま
  6  Standards-Version: 3.5.2

-- 
victory
--
<!DOCTYPE debiandoc PUBLIC "-//DebianDoc//DTD DebianDoc//EN" [

<!-- textual data entities -->
<!-- first definition wins in SGML -->
<!ENTITY % default  SYSTEM "default.ent">  %default;

]>
<!-- CVS revision of this document "$Revision: 1.116 $"  -->
<!-- CVS revision of original english document "*.**"  -->

<debiandoc>

 <book>

  <titlepag>

   <title>Debian 新メンテナガイド</title>

   <author>Josip Rodin <email/joy-mg@debian.org/
   </author>

   <author> 翻訳: 八田真行 <email/mhatta@debian.or.jp/
   </author>

   <author> 日本語訳更新 (v1.2): 佐野武俊 <email/sano@debian.org/
   </author>

   <version>version 1.2.13, 5 June 2008.</version>

   <copyright>
   <copyrightsummary>Copyright &copy; 1998-2002 Josip Rodin.</copyrightsummary>
   <copyrightsummary>Copyright &copy; 2005-2007 Osamu Aoki.</copyrightsummary>

   <p>この文書は GNU 一般公有使用許諾書、バージョン 2 かそれ以降が
   規定する条件の下で利用できます。
   
   <p>この文書は以下の二つの文書を参考として書かれました。

   <p>Debian パッケージの作り方 (Debmake マニュアル)、
   Copyright &copy; 1997 Jaldhar Vyas.

   <p>新米メンテナのための Debian パッケージング Howto、
   Copyright &copy; 1997 Will Lowe.
  </copyright>

  </titlepag>

  <toc sect>

  <chapt id="start">まずは「正しいやり方で」始めよう

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

  <p>Debian が Linux ディストリビューションの最高峰と呼ばれる
  までになった理由のひとつがそのパッケージ管理システムです。
  すでに膨大な数のソフトウェアが Debian パッケージとして配布されて
  いますが、まだパッケージ化されていないソフトウェアをインストール
  しなければならないこともあるでしょう。
  あるいは、どうやったら自分でパッケージが作れるんだろう、とか
  それはとても難しいことなんじゃないか、などと考えたことがあるかも
  しれません。まあ、もしあなたが本当に駆け出しの Linux ユーザ
  ならば困難な仕事でしょうが、でもそうだったら今ごろこんな文書
  読んでませんて :-)

  パッケージを作成するには Unix のプログラミングについてある程度
  知っている必要がありますが、神様みたいに精通している必要は
  全くありません。

  <p>ただ、確かなことがひとつあります。Debian パッケージを
     きちんと作成し、保守していくには、手間を惜しんではならない、
     ということです。間違えないでください。Debian のシステムを
     うまく動かしていくためには、メンテナーは技術的に有能である
     だけでなく、勤勉であることも必要なのです。

  <p>この文書では (最初は関係無さそうに思えることまで) どんな
  細かい手順も余さず説明します。
  ともかく一つ作ってしまえば、あとは次のリリース、そして
  他のパッケージへと経験を積んでいけばよいのです。

  <p>この文書の最新版は常に以下の場所からネットワーク経由で入手できます。
  <url name="http://www.debian.org/doc/maint-guide/"; id="http://www.debian.org/doc/maint-guide/";>
  また、 「<package/maint-guide/」パッケージにも含まれています。
  日本語訳は「<package/maint-guide-ja/」パッケージの中にあります。

  <sect id="needprogs">開発に必要なプログラム

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

  <p>この文書の現在のバージョンは Debian 2.2 (`potato') および
  3.0 (`woody') に含まれるパッケージを対象に更新されています。

  <p>以下のパッケージは Debian の「標準」(standard) インストール
  構成に含まれており、すでに (それらが依存する他のパッケージと
  いっしょに) システムに含まれているはずです。
  しかし、念のために「dpkg -s &lt;パッケージ名&gt;」で確認して
  おきましょう。

  <list>
  <item><package/dpkg-dev/ - このパッケージには Debian ソース
  パッケージを展開、構築、アップロードするために必要なツール群が
  含まれています。
  (詳しくは <manref name="dpkg-source" section="1"> を参照)。

  <item><package/file/ - この便利なプログラムを使うと
  そのファイルがどういう形式のものか判定することが
  できます
  (詳しくは <manref name="file" section="1"> を参照)。

  <item><package/gcc/ - GNU C コンパイラ。あなたのプログラムが
  他の多くのプログラムと同様に C 言語で書かれている場合、必要と
  なります。(詳しくは <manref name="gcc" section="1"> を参照)
  このパッケージは、たとえばプログラムの「素」となるオブジェクト
  ファイルをアセンブル、リンクするための <package/binutils/
  (<package/binutils-doc/ パッケージをインストールして
   「info binutils」すれば詳細な説明を読めます)、
  C プリプロセッサ <package/cpp/ 
  (詳しくは <manref name="cpp" section="1"> を参照)
  など他のパッケージをいくつか一緒に「引き連れて」きます。

  <item><package/g++/  - GNU C++ コンパイラ。あなたの
  プログラムが C++ 言語で書かれている場合に必要です。
  (詳しくは <manref name="g++" section="1"> を参照)

  <item><package/libc6-dev/ - gcc がオブジェクトファイルを
  生成してリンクするために必要な C ライブラリとヘッダファイル
  が含まれています。(<package/glibc-doc/ パッケージを
  インストールして「info libc」すればマニュアルが読めます)

  <item><package/make/ - ふつう、プログラムはいくつかの手順を踏んで
  生成されます。同じコマンドを何度も何度も繰り返し入力する代わりに、
  make プログラムを使えば「Makefile」を書くことで手続きを自動化
  することができます。(詳しくは「info make」)

  <item><package/patch/ - このとても有用なユーティリティは
  オリジナルとの差異が列挙されたファイル (diff プログラムによって生成) を
  読み込んでオリジナルのファイルに適用し、変更された (パッチの当たった)
  バージョンを作成します。
  (詳しくは <manref name="patch" section="1"> を参照)。

  <item><package/perl/ - Perl は今日の Un*x システムにおいてもっとも
  使われているインタープリタ型スクリプト言語のひとつで、その強力さは
  しばしば「Unix のスイス軍用チェーンソー」と形容されるほどです
  (詳しくは <manref name="perl" section="1">を参照)。
  </list>

  <p>たぶん、以下のパッケージもインストールしたくなるでしょう。

  <list>
  <item><package/autoconf/ と <package/automake/ - 
  多くの新しいプログラムがこれらのプログラムを使って
  前処理される設定スクリプトや Makefile を利用しています。
  (詳しくは「info autoconf」および「info automake」)

  <item><package/dh-make/ と <package/debhelper/ - 
  dh-make はあとで説明するパッケージのひな型を用意するのに
  必要となります。またこのひな型ではパッケージを生成する
  ために debhelper ツールをいくつか使います。
  これらを使わなくてもパッケージ作成は可能ですが、
  初めてパッケージを作る方には利用を
  <strong>強く</strong> お勧めします。
  パッケージを作るのも、以後パッケージを管理するのも
  ずっと簡単になるからです。
  (詳しくは <manref name="dh_make" section="1">、
  <manref name="debhelper" section="1">、
  /usr/share/doc/debhelper/README を参照)

  <item><package/devscripts/ - このパッケージは
  メンテナにとって便利であると思われるいくつかの
  有用で優れたスクリプトを含んでいますが、だから
  といってパッケージを作成するために必須という
  わけではありません。
  (詳しくは /usr/share/doc/devscripts/README.gz 参照)。

  <item><package/fakeroot/ - このユーティリティを使うと、
  パッケージを作成する際に何度か必要となる root 権限を
  エミュレートすることができます。
  (詳しくは <manref name="fakeroot" section="1"> を参照)

  <item><package/gnupg/ - このツールを使うと、自分の
  パッケージに「デジタル <em>署名</em>」を付けることが
  できます。もしあなたが自分の作成したパッケージを他の
  人々に配布したいのなら、これは特に重要です。
  また、Debian ディストリビューションにあなたの作成した
  パッケージが含まれるようになった時には、確実にこの
  デジタル署名をすることになります。
  (詳しくは <manref name="gpg" section="1"> を参照)

  <item><package/g77/ - GNU Fortran 77 コンパイラ。あなたの
  プログラムが Fortran 言語で書かれている場合に必要です。
  (詳しくは <manref name="g77" section="1"> を参照)

  <item><package/gpc/ - GNU Pascal コンパイラ。あなたの
  プログラムが Pascal 言語で書かれている場合に必要です。
  ここで注目に値するのは <package/fp-compiler/、
  Free Pascal コンパイラで、こちらもまたこの作業に適して
  います。
  (詳しくは <manref name="gpc" section="1"> および
  <manref name="ppc386" section="1"> を参照)

  <item><package/xutils/ - 
  ある種のプログラム (通常 X11 のために開発されたもの) は、
  これらのプログラムを利用して、マクロ関数の組み合わせから
  Makefile 群を生成します。
  (詳しくは <manref name="imake" section="1">、
  <manref name="xmkmf" section="1"> を参照)

  <item><package/lintian/ - これは Debian パッケージチェッカで、
  あなたが構築したパッケージを調べて、その中にありがちなミスが
  見つかったらそれを指摘し、その問題について説明してくれます
  (詳しくは <manref name="lintian" section="1">、
  /usr/share/doc/lintian/lintian.html/index.html を参照)。
  </list>

  <p>さて、以下はこの文書と合わせて読むべき<em>とても重要</em>な
  文書です。

  <list>
  <item><package/debian-policy/ - Debian ポリシーマニュアル。
  Debian アーカイブの構造と内容、OS の設計に関するいくつかの問題、
  あるいは「ファイルシステム体系基準」(Filesystem Hierarchy Standard、
  個々のファイルやディレクトリがどこにあるべきかを規定した文書)
  についてなどいろいろ載っていますが、
  さしあたって重要なことは、ディストリビューションに含まれるために
  それぞれのパッケージが満たすべき必要条件の説明です
  (詳しくは /usr/share/doc/debian-policy/policy.html/index.html を参照)。

  <item><em>developers-reference</em> - 開発者リファレンス。
  例えばアーカイブの構造、パッケージ名の変更方法、
  パッケージの選び方、メンテナを降りるにはどうしたらよいか、
  どうやって NMU をするか、バグとのつき合い方、best packaging practices
  いつどこにアップロードすればよいかなどなど、特に技術的な事柄以外の
  パッケージ化についてのありとあらゆる情報がここにあります。
  (詳しくは /usr/share/doc/developers-reference/developers-reference.html/index.html を参照)
  </list>

  <p>上記の簡単な説明は、それぞれのパッケージが何をするのか紹介
  するだけのものです。先に進む前にどうかそれぞれのプログラムに
  付属の文書を徹底的に熟読し、標準的な使い方だけでも理解しておいて
  ください。きついと思われるかも知れませんが、あとになればきっと
  <em>読んでてよかったなあ</em>と思うことでしょう。

  注意: <package/debmake/ は dh-make と似た働きをする
  いくつかのプログラムを含むパッケージですが、現在では
  このパッケージを <em>使うべきでない</em> とされているため、
  この文書では <strong>説明しません</strong>。

  <sect id="debiandeveloper">正式な Debian 開発者

  <p>自分のパッケージがビルドできた後(あるいはその最中でも)、
  正式な Debian 開発者になって新しいパッケージを次の
  ディストリビューションに取り込むことを目指すのも良い案です
  (そのプログラムが便利なら、ですがもちろん便利ですよね?)。
  
  <p>一夜にして正式な Debian 開発者になることはできません。
  これは技術的なスキルだけに留まらない何かが必要となるからです。
  そのことでがっかりしないでください。それが他の人にとっても
  便利なものならメンテナとして、正式な Debian 開発者にならなくとも、
  <url name="Debian 新規メンテナ (New Maintainer, NM) プロセス"
       id="&nm-home;"> に応募した上で、
  スポンサーを通してパッケージをアップロードすることは可能です。
  ここで述べたスポンサーとは正式な Debian 開発者で、
  メンテナがパッケージを Debian アーカイブにアップロード
  するのを補助する人を指します。この手順に関する詳細は
  <url id="&mentors-faq;" name="debian-mentors FAQ">
  にあります。

  <p>正式な Debian 開発者になるのに新しいパッケージの作成は
  必須ではないことに注意してください。既存のパッケージに対して
  貢献していくことでも正式な Debian 開発者への道は開かれます。

  <sect id="otherinfo">その他知っておくべきこと

  <p>これから作ろうとするのは 2 種類のパッケージで、それぞれ
  ソースパッケージ、バイナリパッケージと呼ばれています。
  ソースパッケージはコンパイルしてプログラムになるソースコードが
  含まれます。バイナリパッケージにはでき上がったプログラムそのものです。
  紛らわしい言葉ですが、「プログラムのソース」と
  「プログラムのソースパッケージ」を混同しないようにしましょう!
  もし用語についてもっと知りたければ他のマニュアル類を参照してください。
  
  <p>Debian では、「メンテナ(maintainer)」と言う用語はパッケージを
  作る人を示し、「上流作者(upstream author)」とはプログラムそれ自身を
  作った人を指します。そして「上流メンテナ(upstream maintainer)」
  というのは Debian の外部で現在プログラムそのものを管理している人の
  ことです。
  たいていの場合、作者と上流メンテナは同一人物ですが、メンテナすらも
  同じという場合もあり得ます。
  もしあなたが何かのプログラムを書いて、それを Debian に入れたいと
  考えたならば、Debian プロジェクトに参加してメンテナになってください。

  <chapt id="first">はじめの一歩

  <sect id="choose">パッケージ化するプログラムの選定

  <p>パッケージにしたいプログラムについてはすでに各自お考えがあると
  思います。まず最初にしなければならないことは、そのパッケージが
  すでにディストリビューションに収録されていないかどうか確認することです。
  もしあなたが「安定版」を使っているのなら、
  たぶん
  <url name="パッケージ検索ページ" id="http://www.debian.org/distrib/packages";>
  に行って調べるのが最上の策です。
  ((訳注: <url name="Debian JP パッケージ"
               id="http://www.debian.or.jp/Packages.html";>
  もついでに見ておくといいかもしれません。))

  <p>もしパッケージが既に存在していたら、インストールしましょう！ :-)
  もしそのパッケージが「みなしご」にされていたら (もしメンテナの名前が
  「Debian QA Group」になっていたら)、そのパッケージを引き取ることが
  できるかもしれません。

  <p>その場合、Debian ウェブサイト
  <url name="作業が望まれるパッケージ (WNPP)"
       id="http://www.debian.org/devel/wnpp/";>
  とそのリンク先を見て最新の「養子/みなしご」状態を確認してください。

  <p>もしパッケージを引き取ることができたら、
  (<tt/apt-get source パッケージ名/ などの方法で) 
  ソースを入手して、調べてみてください。
  残念ながらこの文書ではパッケージを引き取ることについて
  わかりやすく説明してはいません。ありがたいことに、既に
  誰かがあなたのためにパッケージを準備してくれたわけですから、
  そのパッケージがどのように動作するのか理解することはそれほど
  難しくはないでしょう。
  とはいえ、そうした場合でもこの文書に書かれた多くのアドバイスは
  そのまま通用しますから、このまま読み進んでいってください。
  
  <p>もしあなたの選んだプログラムがまだパッケージ化されていない
  もので、それを Debian に入れたいと決めたなら、以下のチェック
  項目について確認してください。
  
  <list>
  <item><url name="作業中のパッケージ" 
             id="http://www.debian.org/devel/wnpp/being_packaged";>
  ((訳注:
  <url id="http://www.debian.or.jp/devel/prospective-packages.html";
     name="作業を必要としているパッケージ"> も見ておきましょう))、
  を見て、誰か他の人が同じプログラムのパッケージを作っていないかどうか
  確かめてください。もし誰か作っていたら、必要に応じて連絡をとって
  ください。もしその必要が無ければ、まだ誰も手をつけていない
  他の面白いプログラムを探して再チャレンジです。</item>

  <item>プログラムはライセンスを
  <strong>与えられていなければなりません</strong>。
  <list>
  <item><tt>main</tt> に分類されるものについては、
  Debian ポリシーの規定により、
  <url name="Debian フリーソフトウェアガイドライン"
       id="http://www.debian.org/social_contract#guidelines";>
  (DFSG) に完全に準拠しなければならず、
  そのコンパイルや実行に際して、
  <tt>main</tt> 以外にあるパッケージを必要とすることは
  <strong>許されません</strong>。これは好ましい例です。</item>
  <item><tt>contrib</tt> に分類されるものについては、
  DSFG に完全に準拠<strong>しなければなりません</strong>が、
  そのコンパイルや実行に際して、
  <tt>main</tt> 以外にあるパッケージを必要とすることが許容されます。
  </item>
  <item><tt>non-free</tt> に分類されるものについては、
  DSFG に準拠<strong>しない</strong>部分があっても許容されますが、
  配布可能であることは<strong>必須</strong>です。</item>
  ((訳注: 日本のミラーサイトは
   <url name="Debian フリーソフトウェアガイドライン"
        id="http://www.jp.debian.org/social_contract#guidelines";>
   にあります))

  もしどのセクションこに入れるべきか迷ったら、
  <email/debian-legal@list.debian.org/ で聞いてみてください。
  </item>
  
  <item>動作のために setuid root が必要なプログラムを
  パッケージ作成の最初の練習問題として選ぶべきでは
  <strong>ありません</strong>。

  さらに言えば、すべての場面において setuid や setgid でさえも
  必要とすべきではありません。</item>

  <item>デーモンとして動作するプログラムや、システム管理者の
  ための専用のコマンド (*/sbin ディレクトリに含まれるもの)、
  また root 特権を使ってポートを開くプログラムは、すくなくとも
  最初は避けておいたほうが賢明です。
  </item>

  <item>バイナリ実行形式として使えるプログラムを選びましょう。
  ライブラリをパッケージ化するのはずっと難しいのです。
  </item>

  <item>ちゃんとした説明書きのあること。あるいは理解可能な
  ソースコードであること (つまり、コードに書かれた処理の流れが
  混乱していないこと)。</item>

  <item>プログラムの作者に連絡をとってパッケージ化の承諾をもらいましょう。
  何かプログラムそのものに起因する問題が発生した際に、作者にいろいろ聞けると
  いうことは重要なので、由来のはっきりしないソフトウェアの断片をパッケージ化
  するのはやめておきましょう。
  </item>

  <item>そして最後に、といってもこれが重要なのですが、
  ちゃんと動くかどうか確かめましょう。そして何回か試してみましょう。
  </item>
  </list>

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

  <p>もっと詳しい話は、開発者リファレンスに載っていますので
     そちらを参照してください。

  <sect id="getit">プログラムを手にいれて、試してみる

  <p>さて、最初にすべきことは、オリジナルのソースを探してダウンロード
  することです。ここでは作者のホームページからすでにソースファイルを入手した
  として話を進めます。
  フリーな Unix 用プログラムのソースはふつう tar/gzip 形式で提供されています。
  拡張子は .tar.gz で、普通は「プログラム名-バージョン」という
  サブディレクトリを含んでいます。そこにすべてのソースが入っているわけです。
  もしあなたのプログラムのソースが他の種類のアーカイブで提供されていたら
  (例えばファイル名が ".Z" とか ".zip" で終わっていたら)、
  適切なツールで展開しましょう。どうやって展開したらよいのか
  良く分からなかったら debian-mentors メーリングリストで聞いてみましょう
  (ヒント: 「file アーカイブ名.拡張子」を実行してみるとよいかも)。

  <p>さて本稿では、「gentoo」というプログラムを例にとって説明しようと
  思います。これは X11 上で動く GTK+ を使用したファイルマネージャです。
  ちなみにこのプログラムはすでにパッケージ化されており、また、
  この文書が最初に書かれた時点から比べると大幅に改変が加えられていることに
  注意してください。

  <p> 自分のホームディレクトリ以下に 'debian'、'deb'、または何か適当だと
  思われる名前のサブディレクトリを作りましょう (今回の場合には
  </file>~/gentoo/</file> としても良いでしょう)。
  ダウンロードしたアーカイブをここにコピーし、
  「tar xzf gentoo-0.9.12.tar.gz」を実行して展開してください。
  この時 (一見「無関係」に思えるようなものも含めて) エラーは一切
  発生しないということを確認しておいてください。
  もしエラーが起きたら、それは他の人々のシステム上で展開する際にもおそらく
  エラーが起きるということです。そしてそこで使われている展開用のツールは
  こういった異常を無視するかも知れませんし、無視してくれないかもしれません。
  
  <p>さて、「gentoo-0.9.12」という別のサブディレクトリができました。
  展開したディレクトリに移って、提供されているドキュメントを
  <strong>徹底的に</strong>読みましょう。
  通常は README*、INSTALL*、*.lsm、*.html などといった名前のファイルがあり、
  それらの文書の中に、どうやったら正しくコンパイルできるのか、
  どうインストールすればよいのかといった情報が見つかるはずです。
  (たぶん /usr/local/bin にインストールするものとして説明されていますが、
  そうしてはいけません。
  これについては <ref id="destdir"> を参照してください)。

  <p>プログラムによって構築の手順は変わりますが、最近のプログラムだと
  「configure」スクリプトが付属していることがあります。
  このスクリプトはソースをあなたのシステムに合わせて設定し、
  このままコンパイルできるかどうかをチェックします。
  たいていのプログラムは「./configure」を実行してソースコードの
  設定を行なった後、「make」を実行してコンパイルします。
  「make check」でプログラムのソースツリーに含まれている
  自己診断テストを実行できるものもあります。
  目的のディレクトリへのインストールは一般に「make install」によって
  実行されます。

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

  <p>それから、たいていの場合は「make clean」(「make distclean」を
  使えるならそのほうが良いです) を実行すると、コンパイル用の
  ディレクトリをきれいにしてくれます。さらに「make uninstall」を
  実行するとインストールされたファイルをすべて削除できることさえも
  あります。

  <sect id="namever">パッケージ名とバージョン

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

  <p>パッケージをきちんと作るためには、(もしまだそうなっていなければ) 
  プログラム名がすべて小文字になるよう、オリジナルの名前から
  変更しておかなければいけません。
  またソースディレクトリ名を &lt;パッケージ名&gt;-&lt;バージョン&gt; に
  変更しておきましょう。
  
  <p>もしプログラムの名前が一語以上で構成されていたら、
  一つの語につなげるか省略形にしましょう。
  例えば、「John's little editor for X」というソフトウェアならば
   johnledx とか jle4x というようにしましょう。あまり長すぎない程度、
  せいぜい 20 文字くらいまでの長さで、適当に決めて下されば結構です。

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

  <p>およそバージョン番号に使えそうな情報がまったくないと言う場合、
  上流メンテナに連絡をとって彼らが何か他のリビジョン管理手段を
  使っているかどうか聞いてみましょう。

  <sect id="dh_make">最初の「Debian 化」

  <p>現在の作業ディレクトリがプログラムのソースディレクトリである
  ことを確認し、以下を実行してください。

  <p><example>
  dh_make -e your.maintainer@address -f ../gentoo-0.9.12.tar.gz
  </example>
   
  <p>もちろん、"your.maintainer@address" の部分は changelog の
  エントリやその他のファイルに記載するための、あなたの電子メール
  アドレスに置き換えてくさい。またファイル名はあなたがパッケージ化
  しようとしているプログラムのオリジナルソースアーカイブの名前に
  置き換えてください。
  詳細は <manref name="dh_make" section="1"> を参照してください。

  <p>画面にはいろいろ表示されて、あなたが作ろうとしているパッケージ
  がどういう種類のものか聞いてきます。gentoo は 単一バイナリパッケージ - 
  すなわちパッケージに含まれるバイナリが一つだけで、一つの .deb ファイル
  のみが作成される - ですので最初の選択肢を選び、「s」キーを押しましょう。
  その後、画面に表示される情報をよく読み、確認したら &lt;enter&gt; を押して
  ください。

  <p>この <prgn>dh_make</prgn> の実行後、上流の tarball
  の複製が親ディレクトリに <file>gentoo_0.9.12.orig.tar.gz</file>
  といった名前で生成され、<file>diff.gz</file> と合わせて
  non-native Debian ソースパッケージの作成に対応します。
  このファイル名には 2 つの特徴があることに注目してください。
  <list compact>
  <item>パッケージ名とバージョン番号は "<tt>_</tt>" で区切られる。
  <item>"<tt>orig.</tt>" が "<tt>tar.gz</tt>" の前に付く。
  </list>

  <p>初めてパッケージを作るというときには、複雑なパッケージ、つまり
  <list compact>
  <item>マルチバイナリパッケージ
  <item>ライブラリ
  <item>ソースファイルの形式が <tt>tar.gz.</tt> でも
       <tt>tar.bz2</tt> でもないもの
  <item>ソース tarball に配布不可能なものが含まれる場合
  </list>
  には手を出さない方が無難です。この話は前にもしましたね。
  実際には作業自体はそれほど大変ではないのですが、ちょっとだけ
  より多くの知識が必要になります。そのため、ここではその作業について
  一切説明しません。

  <p><prgn>dh_make</prgn> の実行は <strong>ただ一度だけ</strong>
  です。注意してください。既に「Debian 化」された同じディレクトリで
  再び実行すると正しく動作しないでしょう。これはつまり、
  将来パッケージの改訂版や新バージョンをリリースする時には
  別の方法を使うことになる、ということでもあります。
  パッケージの更新作業についての詳細は後で説明する <ref id="update">
  の部分を読んでください。

  <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 を実行した際に実際の内容に置き換えられます。
  Please make sure to read 
  <file>&autotools-dev;</file> before proceeding.
  
  <p>修正の具体的なやり方について<em>何から何まで</em>説明するにはとても
  紙面が足りませんが、よくあるパターンとしては大体以下のようなものでしょう。

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

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

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

  <p>通常、この一時的なディレクトリは、展開されたソースツリーの
  中にある debian/ ディレクトリの下に作成されます。
  またこのサブディレクトリは 
  <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 -nr -e 'usr/local/lib' --include='*.[c|h]' .
  </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;joy-mg@debian.org&gt;
  5  Build-Depends: debhelper (>> 3.0.0)
  6  Standards-Version: 3.6.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>このスクリプトは "Build-depends" のバージョン番号を全て返してきます。
  バージョン依存については、安定版(stable) で条件が満たされるものは
  "Build-depends" でバージョンを特定すべきではないことに注意してください。

  <p><prgn><var>/usr/bin/foo</var></prgn>
  の実際のビルド依存を確認するには
  <example>
  objdump -p <var>/usr/bin/foo</var> | grep NEEDED
  </example>
  として表示される各ライブラリについても、例えば
  <prgn>libfoo.so.6</prgn> の場合
  <example>
  dpkg -S libfoo.so.6 
  </example>
  とします。それから `Build-deps' にある各パッケージの -dev
  バージョンについても処理していきます。この目的で <prgn>ldd</prgn>
  を使うとライブラリの間接的な依存も同様に示されるので、
  過度のビルド依存という問題を起こすことになります。

  <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;joy-mg@debian.org&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 joy-mg@debian.org 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 joy-mg@debian.org on
  2  Wed, 11 Nov 1998 21:02:14 +0100.
  3
  4  It was downloaded from http://www.obsession.se/gentoo/
  5
  6  Upstream Author(s): Emil Brink &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  either version 2 of the License,
  13 or (at your option) any later version.
  14 On Debian systems, the complete text of the GNU General Public
  15 License can be found in the file `/usr/share/common-licenses/GPL-2'.
  </example>
  (行番号は筆者が書き加えました)

  <p>debian-devel-announce <url id="&copyright-howto;">
  に投稿された手順を追ってみてください。

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

  <p>これは必須のファイルです。ポリシーマニュアル 4.4 節
  「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;joy-mg@debian.org&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;joy-mg@debian.org&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>
&makefile;
  </example>
  (行番号は筆者が書き加えました。実際の <file>debian/rules</file> 
  ファイルでは行頭の空白は TAB コードです。)

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

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

  <p>11 行目から 16 行目までは Debian ポリシー 10.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 を実行
  しています。バイナリパッケージの作成に GNU configure
  ユーティリティを使用している場合は <file>&autotools-dev;</file>
  を確実に熟読してください。コメントとして記載されている
  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 ポリシーマニュアルの中に説明があります。
  今のところは、必ず知っておかなくてはいけないような重要な項目
  というわけではありません。
--