
                      Debian 新メンテナーガイド


---------------------------------------------------------------------
                                  
                             Josip Rodin

                   初期の内容 <joy-mg@debian.org>

                             Osamu Aoki

                  更新された内容 <osamu@debian.org>

倉澤望

日本語訳 <nabetaro@debian.or.jp>

八津尾雄介

日本語訳 <yyatsuo@gmail.com>

佐々木洋平

日本語訳 <uwabami@gfd-dennou.org>

倉敷悟

日本語訳 <lurdan@gmail.com>

青木修

日本語訳 <osamu@debian.org>

                       バージョン 1.2.53build1

---------------------------------------------------------------------

製作著作 © 1998-2002 Josip Rodin

製作著作 © 2005-2015 Osamu Aoki

製作著作 © 2010 Craig Small

製作著作 © 2010 Raphaël Hertzog

    この文書は GNU 一般公有使用許諾書、バージョン 2 もしくはそれ以降
    により規定される条件の下で使用できます。

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

      * Debian パッケージの作り方 (別名 Debmake マニュアル)、
        Copyright © 1997 Jaldhar Vyas.

      * 新メンテナー向け Debian パッケージング法、copyright © 1997
        Will Lowe.

        The rewrite of this tutorial document with updated contents
        and more practical examples is available as "Guide for Debian
        Maintainers". Please use this new tutorial as the primary
        tutorial document.

2025-12-16 19:30:30 UTC

---------------------------------------------------------------------

目次

1. まずは正攻法で始めよう
    1.1. Debianにおける社会ダイナミクス
    1.2. 開発に必要なプログラム
    1.3. 開発に必要な文書
    1.4. 相談するには
2. はじめの一歩
    2.1. Debian パッケージビルドのワークフロー
    2.2. プログラムの選定
    2.3. プログラムの入手と検証
    2.4. 単純なビルドシステム
    2.5. ポピュラーなポータブルなビルドシステム
    2.6. パッケージ名とバージョン
    2.7. dh_make のセットアップ
    2.8. 最初のノンネイティブ Debian パッケージ
3. ソースコードの変更
    3.1. quilt のセットアップ
    3.2. アップストリームのバグを修正する
    3.3. 指定場所へのファイルのインストール
    3.4. ライブラリーの相違
4. debian/ ディレクトリー以下に無くてはならないファイル
    4.1. control
    4.2. copyright
    4.3. changelog
    4.4. rules
        4.4.1. rules ファイルのターゲット
        4.4.2. デフォルトのrulesファイル
        4.4.3. rules ファイルのカスタマイズ
5. debianディレクトリーにあるその他のファイル
    5.1. README.Debian
    5.2. compat
    5.3. conffiles
    5.4. package.cron.*
    5.5. dirs
    5.6. package.doc-base
    5.7. docs
    5.8. emacsen-*
    5.9. package.examples
    5.10. package.init と package.default
    5.11. install
    5.12. package.info
    5.13. package.links
    5.14. {package.,source/}lintian-overrides
    5.15. manpage.*
        5.15.1. manpage.1.ex
        5.15.2. manpage.sgml.ex
        5.15.3. manpage.xml.ex
    5.16. package.manpages
    5.17. NEWS
    5.18. {pre,post}{inst,rm}
    5.19. package.symbols
    5.20. TODO
    5.21. watch
    5.22. source/format
    5.23. source/local-options
    5.24. source/options
    5.25. patches/*
6. パッケージのビルド
    6.1. 完全な（再）ビルド
    6.2. オートビルダー
    6.3. debuildコマンド
    6.4. pbuilderパッケージ
    6.5. git-buildpackageコマンドとその仲間
    6.6. 部分的な再ビルド
    6.7. コマンド階層
7. パッケージのエラーの検証
    7.1. 怪しげな変更
    7.2. インストールに対するパッケージの検証
    7.3. パッケージのメンテナースクリプトの検証
    7.4. Using lintian
    7.5. debc コマンド
    7.6. debdiff コマンド
    7.7. interdiff コマンド
    7.8. mc コマンド
8. パッケージの更新
    8.1. Debian リビジョンの更新
    8.2. 新規のアップストリームリリースの検査
    8.3. アップストリームソフトウェアの新版更新
    8.4. パッケージ化スタイルの更新
    8.5. UTF-8 変換
    8.6. パッケージをアップグレードする際の注意点
9. パッケージをアップロードする
    9.1. Debian アーカイブへアップロードする
    9.2. アップロード用orig.tar.gzの内容
    9.3. スキップされたアップロード
A. 上級パッケージング
    A.1. 共有ライブラリー
    A.2. debian/package.symbols の管理
    A.3. マルチアーチ
    A.4. 共有ライブラリーパッケージのビルド
    A.5. ネイティブ Debian パッケージ

第1章まずは正攻法で始めよう

    最新の内容とより実用的な例でこの入門書を書き換えたものが Guide
    for Debian Maintainers として入手できます。この新しい入門書を第一
    次的な入門書として使ってください。

    この文書では、一般の Debian ユーザーやデベロッパーを目指している
    人を対象に Debian パッケージのビルド方法の解説を試みます。技術用
    語はできるだけ避けて、実用的な例示を多用しています。古いラテンの
    諺にもあるように、Longum iter est per praecepta, breve et efficax
    per exempla (百聞は一見にしかず) です。

    本文書は多くの翻訳があるため Debian Buster リリースでは提供されま
    す。本文書はこれに続くリリースでは内容が陳腐化しているため提供さ
    れなくなります。^[1]

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

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

    パッケージ作成において手助けが必要な際には、「相談するには」を読
    んでください。

    この文書の最新版は常に以下の場所からネットワーク経由で入手できま
    す。http://www.debian.org/doc/maint-guide/ また、maint-guideパッ
    ケージにも含まれています。日本語訳はmaint-guide-jaパッケージに含
    まれています。本文書の内容が少々古くなっているかもしれない事に注
    意して下さい。

    本書は入門書ですので、一部の重要なトピックスは詳細なステップを個
    々説明するようにしました。あなたには不要と思われる部分があるかも
    しれません。我慢して下さい。本文書を簡潔にするように一部のコーナ
    ーケースを意識的に省略したり参照を提供するだけに止めています。

1.1. Debianにおける社会ダイナミクス

    あなたがDebian と関わる際の準備となることを望み、Debianの社会ダイ
    ナミクスの観察結果を記します:

      * 我々全員はボランティアです。

          + 他人に何をするかを押し付けてはいけません。

          + 自分自身で行う意欲を持つべきです。

      * 友好的な協力が推進力です。

          + あなたの寄与は他人にストレスを掛けすぎてはいけません。

          + あなたの寄与は他人に評価されて初めて価値があります。

      * Debian は教師の注意が自動的にあなたに注がれるあなたの学校とは
        違います。

          + 多様な案件の独学能力を持つべきです。

          + 他ボランティアに注意を払ってもらうことは貴重なリソースで
            す。

      * Debian は常に改良されています。

          + あなたには高品質パッケージを作成することが期待されていま
            す。

          + あなたは変化に自らを適合させる必要があります。

    Debian 界隈では異なる役割で色々なタイプの人が交流しています:

      * upstream author (アップストリームの作者): 元のプログラムを作
        った人です。

      * upstream maintainer (アップストリームのメンテナー): 現在プロ
        グラムをメンテナンスしている人です。

      * maintainer (メンテナー): プログラムの Debian パッケージを作成
        している人です。

      * sponsor (スポンサー): メンテナーのパッケージを、(内容をチェッ
        クした後で)公式 Debian パッケージアーカイブにアップロードする
        のを手伝う人です。

      * mentor (指導役): 新米メンテナーをパッケージを作成等で手助けす
        る人です。

      * Debian Developer (Debian デベロッパー) (DD): 公式 Debian パッ
        ケージアーカイブへの全面的アップロード権限を持っているDebian
        プロジェクトのメンバーです。

      * Debian Maintainer (Debian メンテナー) (DM): 公式 Debian パッ
        ケージアーカイブへの限定的アップロード権限持っている人です。

    技術的なスキル以外の要件があるので、一夜にして正式な Debian デベ
    ロッパー (DD) になることはできません。これでがっかりしないでくだ
    さい。あなたのパッケージが他の人にとっても有用ならば、あなたはそ
    れをメンテナーとしてスポンサーを通して、あるいは Debian メンテナ
    ーとして、アップロードすることが可能です。

    正式な Debian デベロッパーになるのに新しいパッケージの作成は必須
    ではないことに注意してください。既存のパッケージに対して貢献して
    いくことでも正式な Debian デベロッパーへの道は開かれます。多くの
    パッケージがよいメンテナーを待っています (「プログラムの選定」を
    参照)。

    本書ではパッケージングの技術面にのみフォーカスするので、Debian が
    如何にして機能し、あなたが如何にすれば関与できるのかは以下を参照
    下さい:

      * Debian: フリーソフトウェアと、"do-ocracy" (実行による支配)と
        、democracy (多数決による支配)の17年間 (紹介スライド、英語)

      * Debian に協力するには? (正規)

      * The Debian GNU/Linux FAQ, Chapter 13 - "Contributing to the
        Debian Project" (準正規)

      * Debian Wiki, HelpDebian (補足)

      * Debian New Member サイト (正規)

      * Debian Mentors FAQ (補足)

1.2. 開発に必要なプログラム

    何はさておき、開発に必要なパッケージがきちんとインストールされて
    いることを確認するべきです。以下のリストには essential または
    required なパッケージが含まれていないことに注意してください。これ
    らのパッケージは既にインストールされていることを前提としています
    。

    以下のパッケージは Debian の標準 (standard) インストール構成に含
    まれており、すでに (それらが依存する他のパッケージとともに) シス
    テムに含まれているはずです。しかし、念のために aptitude show
    package もしくは dpkg -s package を用いて確認しておきましょう。

    開発用システムにインストールする一番重要なパッケージは、
    build-essential です。これをインストールしようとすると、基本的な
    ビルド環境で必要な他のパッケージを引き込むでしょう。

    パッケージの種類によっては、必要になるのはこれが全てかもしれませ
    ん。ただ、すべてのパッケージのビルドに必須ではないにせよ、インス
    トールしておくと便利だったり、パッケージによっては必要になったり
    するパッケージ群があります:

      * autoconf と automake と autotools-dev - 多くの新しいプログラ
        ムが、これらのプログラムを使って前処理される設定スクリプトや
        Makefile を利用しています。 (詳しくは info autoconf, info
        automake を参照)。 autotools-dev には、特定の auto ファイルを
        最新版に保ち、そのようなファイルを使う最善の方法についてのド
        キュメントが含まれています。

      * debhelper と dh-make - dh-make は例示に用いられたパッケージの
        ひな型を用意するのに必要となり、またそれはパッケージの生成を
        するために debhelper ツールをいくつか使います。これらを使わな
        くてもパッケージ作成は可能ですが、初めてパッケージを作る方に
        は利用を強くお勧めします。こうすると、取り付きやすく、以後パ
        ッケージを管理するのもずっと簡単です。 (詳しくは dh_make(8)、
        debhelper(1) を参照。) ^[3]

        標準的な dh-make の代わりに、新しいdebmake が使えます。機能が
        多く種々のパッケージング例が debmake-doc 中の文書に含まれます
        。

      * devscripts - このパッケージはメンテナーにとって便利であると思
        われる有用で優れたスクリプトを含んでいますが、だからといって
        パッケージをビルドするために必須というわけではありません。こ
        のパッケージが推奨 (Recommends)、あるいは提案 (Suggests) して
        いるパッケージは、一見の価値があります。(詳しくは /usr/share/
        doc/devscripts/README.gz を参照。)

      * fakeroot - このユーティリティを使うと、ビルドの過程で何度か必
        要となる root 権限をエミュレートすることができます。(詳しくは
        fakeroot(1) を参照。)

      * file - この便利なプログラムを使うと、そのファイルがどういう形
        式のものか判定することができます。(詳しくは file(1) を参照。)

      * gfortran - GNU Fortran 95 コンパイラ。あなたのプログラムが
        Fortran 言語で書かれている場合に必要です。(詳しくは gfortran
        (1) 参照。)

      * git - このパッケージは人気のあるバージョン管理システムで、大
        規模なプロジェクトを素早く、効率的に扱えるように設計されてい
        ます。知名度の高い多数のオープンソースプロジェクトで使われて
        おり、特に有名なものとして Linux カーネルがあります。(詳しく
        は git(1)、git Manual (/usr/share/doc/git-doc/index.html) 参
        照。)

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

      * gpc - GNU Pascal コンパイラ。あなたのプログラムが Pascal 言語
        で書かれている場合に必要です。ここで注目に値するのは
        fp-compiler Free Pascal コンパイラで、こちらもまたこの作業に
        適しています。(詳しくは gpc(1)、 ppc386(1) 参照。)

      * lintian - これは Debian パッケージチェッカで、あなたがビルド
        したパッケージを調べて、その中にありがちなミスが見つかったら
        それを指摘し、その問題について説明してくれます。(詳しくは 
        lintian(1)、 Lintian User's Manual 参照。)

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

      * patchutils - このパッケージには、lsdiff、 interdiff や 
        filterdiff といったパッチを扱うユーティリティが含まれています
        。

      * pbuilder - このパッケージには chroot 環境の作成や保守に使用さ
        れるプログラムが含まれます。この chroot 環境下で Debian パッ
        ケージをビルドすることで適切なビルド依存を確認して FTBFS
        (Fails To Build From Source) バグを回避することができます。
        (詳しくは pbuilder(8) と pdebuild(1) 参照)

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

      * python - Python は Debian システムにおいてもっとも使われてい
        るもう一つのインタープリタ型スクリプト言語で、並外れたパワー
        と非常に明快な書式を兼ねそなえています。 (詳しくは python(1)
        を参照。)

      * quilt - このパッケージは、一連のパッチそれぞれの変更点を追跡
        して、その管理を補助するものです。パッチは簡単に当てたり、外
        したり、刷新したり色々することができます。(詳しくは quilt(1)
        、 /usr/share/doc/quilt/quilt.pdf.gz 参照。)

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

    上記の簡単な説明は、それぞれのパッケージが何をするのか紹介するだ
    けのものです。先に進む前にmake等のようにパッケージ依存関係でイン
    ストールされたプログラムを含むパッケージングに関連する各プログラ
    ムに付属の文書を読み、標準的な使い方だけでも理解しておいてくださ
    い。いまはきついと思われるかも知れませんが、あとになればきっと読
    んでてよかったなあと思うことでしょう。もし後日特定の疑問を持った
    場合は上記で触れた文書を読み返すことをお勧めします。

1.3. 開発に必要な文書

    以下は、この文書と合わせて読むべきとても重要な文書です:

      * debian-policy - Debian Policy Manual (Debian ポリシーマニュア
        ル)は、Debian アーカイブの構造と内容、OS の設計に関するいくつ
        かの案件、Filesystem Hierarchy Standard (FHS、個々のファイル
        やディレクトリーがどこにあるべきかを規定した文書) が含まれて
        います。さしあたって重要なのは、ディストリビューションに含ま
        れるためにそれぞれのパッケージが満たすべき必要条件の説明です
        (ローカルコピーのpolicy.pdf と /usr/share/doc/debian-policy/
        fhs/fhs-3.0.pdf.gz を参照。)
   
      * developers-reference - Debian Developer's Reference (Debian
        デベロッパーリファレンス)には、例えばアーカイブの構造、パッケ
        ージ名の変更方法、パッケージの選び方、メンテナーを降りるには
        どうしたらよいか、どうやって NMU をするか、バグとのつき合い方
        、パッケージ作成のベストプラクティス、いつどこにアップロード
        すればよいかなどなど、特に技術的な事柄以外のパッケージ化につ
        いてのありとあらゆる情報がここにあります。(ローカルコピーの /
        usr/share/doc/developers-reference/developers-reference.pdf
        を参照。)

    以下は、この文書と合わせて読むべきとても重要な文書です:

      * Autotools Tutorial は、Autoconf、Automake、Libtool や gettext
        を最も重要な構成要素としてもつ GNU Autotools として知られる
        GNU ビルドシステムの非常に好適な入門書です。

      * gnu-standards - このパッケージには、GNU プロジェクトからの文
        書が 2 つ含まれています。GNU コーディング標準と、GNU ソフトウ
        ェアのメンテナー向け情報です。Debian ではこれらに従うことは求
        められませんが、ガイドラインまたは常識としても有用です(ローカ
        ルコピーの /usr/share/doc/gnu-standards/standards.pdf.gz と /
        usr/share/doc/gnu-standards/maintain.pdf.gz を参照。)

    この文書が、上記文書の記述と矛盾している場合は、そちらが正解です
    。reportbug を使ってmaint-guide パッケージにバグレポートをしてく
    ださい。

    以下は、この文書と合わせて読める同様の入門書です:

      * Debian Packaging Tutorial

1.4. 相談するには

    公開の場で質問をすると決心する前に、以下に示す良くできた文書を読
    みましょう:

      * 全ての関与するパッケージの /usr/share/doc/package 中のファイ
        ル

      * 全ての関与するコマンドの man command の内容

      * 全ての関与するコマンドの info command の内容

      * debian-mentors@lists.debian.org メーリングリストのアーカイブ
        の内容

      * debian-devel@lists.debian.org メーリングリストのアーカイブの
        内容

    site:lists.debian.org のような検索文字列を含めてドメインを制約す
    るようなことでウェブ検索エンジンをより効率的に利用することを考え
    ましょう。

    小さなテストパッケージを作ることは、パッケージ作成の詳細を学ぶよ
    い方法です。他の人がどのようにパッケージを作成しているか学ぶには
    、既存のよく保守されているパッケージを調べるのが一番です。

    入手可能な文書やウェブのリソースからは答えを見つけられない疑問が
    残った場合には、インタラクティブに疑問を聞く事が出来ます:

      * debian-mentors@lists.debian.org メーリングリスト。 (初心者向
        けメーリングリストです。)

      * debian-devel@lists.debian.org メーリングリスト。 (上級者向け
        メーリングリストです。)

      * #debian-mentors の様な IRC。
   
      * 特定群のパッケージにフォーカスしたチーム (全リストはhttps://
        wiki.debian.org/Teamsを参照下さい)

      * debian-devel-{french,italian,portuguese,spanish}
        @lists.debian.org や debian-devel@debian.or.jp 等の特定言語の
        メーリングリスト(全リストは https://lists.debian.org/
        devel.html と https://lists.debian.org/users.html を参照下さ
        い)

    あなたがするべき努力をした後に適切に質問すれば、より経験を持った
    Debian デベロッパーは喜んで助けてくれるでしょう。

    バグレポート (そう、本物のバグレポートです！) を受けとったら、レ
    ポートを効率的に処理するために、Debian バグ追跡システムに入り込み
    、その説明文書を読む時だということがわかるでしょう。Debian デベロ
    ッパーリファレンスの 5.8. 'Handling bugs' を読むよう、強くおすす
    めします。

    すべてうまくやったとしても、これからはお祈りの時間です。なぜか？
    それは、ほんの数時間 (あるいは数日) で、世界中のユーザーがそのパ
    ッケージを使いはじめるからです。もし何か致命的なエラーをやらかし
    ていたら、膨大な数の怒った Debian ユーザーからメール爆弾を受けと
    ることになります……なんて冗談ですが :-)

    リラックスしてバグ報告に備えてください。なにしろ、そのパッケージ
    が Debian ポリシーやそのベストプラクティスに完全に沿うようになる
    までには、やらなくてはいけないことは沢山あるのですから (繰り返し
    ますが、詳細は正式の文書を読んでください)。頑張ってください！


---------------------------------------------------------------------

    ^[1] 文中では、jessie より新しいシステムを使っていると想定してい
    ます。古いシステム (古い Ubuntu システム等を含む)を使ってこの文書
    についていきたいのであれば、少なくともバックポートされた dpkg お
    よび debhelper パッケージをインストールする必要があります。

    ^[2] Debian システムの基本的な操作は Debian Reference から学べま
    す。Unix プログラミングに関しても学べるいくつかのポインターも含ま
    れています。

    ^[3] dh-make-perl、dh-make-php等のように、同様の内容で特化したパ
    ッケージもいくつかあります。

第2章はじめの一歩

    最新の内容とより実用的な例でこの入門書を書き換えたものが Guide
    for Debian Maintainers として入手できます。この新しい入門書を第一
    次的な入門書として使ってください。

    (できれば既存パッケージを引き取り) 自分のパッケージを作成しましょ
    う。

2.1. Debian パッケージビルドのワークフロー

    アップストリームのプログラムを使って Debian パッケージを作成する
    場合、Debian パッケージビルドは以下の各ステップでいくつかの特定の
    命名をされたファイルを生成することからなります:

      * 通常圧縮された tar フォーマットのアップストリームソフトウェア
        のコピーを入手します。

          + package-version.tar.gz
      * debian ディレクトリー下へ Debian 固有のパッケージ用の変更をア
        ップストリームプログラムへ追加し、3.0 (quilt) フォーマットで
        ノンネイティブのソースパッケージを作成します。(ソースパッケー
        ジとは、Debian パッケージビルドのために用いる入力ファイルセッ
        トのこと。)
   
          + package_version.orig.tar.gz
          + package_version-revision.debian.tar.gz^[4]
          + package_version-revision.dsc
      * Debian ソースパッケージから .deb フォーマット (または Debian
        のインストーラーが使う .udeb フォーマット)で提供される通常の
        インストール可能な Debian のバイナリーパッケージをビルドしま
        す。

          + package_version-revision_arch.deb

    package と version の間の文字が tar アーカイブの名前の - (ハイフ
    ン)が Debian パッケージファイルの名前では _ (下線)に変更されてい
    ることに注目して下さい。

    Debian Policy Manual に従い、上記のファイル名中の、package 部分は
    パッケージ名に置き換え、version 部分はアップストリームバージョン
    に置き換え、revision 部分は Debian リビジョンに置き換え、arch 部
    分はパッケージアーキテクチャーに置き換えます。^[5]

    以下で、このアウトラインの各ステップは後述のセクションで詳細に説
    明します。

2.2. プログラムの選定

    おそらく、作成したいパッケージを選んだことと思います。まず最初に
    しなければならないことは、ディストリビューションのアーカイブにそ
    のパッケージがすでにあるかどうかを以下を使って確認することです:

      * aptitude コマンド

      * Debian パッケージウェブページ

      * Debian Package Tracker ウェブページ

    もしパッケージが既に存在していたら、インストールしましょう! :-)
    もしそのパッケージがみなし子状態 (メンテナーが Debian QA Group に
    設定されていること)なら、そのパッケージを他人にとられていなければ
    、そのパッケージを引き取ることができるかもしれません。パッケージ
    のメンテナーが引き取り依頼 (RFA) を出しているパッケージも引きとれ
    ます。^[6]

    パッケージの所有状態の情報源がいくつかあります:

      * devscripts パッケージ中にある wnpp-alert コマンド

      * Work-Needing and Prospective Packages

      * Debian Bug report logs: Bugs in pseudo-package wnpp in
        unstable

      * Debian Packages that Need Lovin'

      * Browse wnpp bugs based on debtags

    注釈ですが、Debian にはすでにほとんどの種類のプログラムが含まれて
    いることと、Debian アーカイブにすでに含まれているパッケージの数は
    アップロード権限をもつユーザーの数よりもはるかに多いことに注意し
    ておくのは重要です。従って、すでにアーカイブに含まれているパッケ
    ージへの作業は、他のデベロッパーからはるかに喜ばれ (よりスポンサ
    ーしてもらえる見込みがあり)ます^[7]。貢献の仕方はいろいろありま
    す:

      * まだよく使われている、みなしごのパッケージを引き取る

      * パッケージ化チームに参加する
   
      * よく使われているパッケージのバグに対処する

      * QA もしくは NMU アップロードを準備する

    もしパッケージを引き取ることができるなら、(apt-get source
    packagename などの方法で) ソースを入手して、調べてみてください。
    残念ながらこの文書では、パッケージを引き取ることについて、わかり
    やすく説明してはいません。ありがたいことに、既に誰かがあなたのた
    めにパッケージを準備してくれたわけですから、そのパッケージがどの
    ように動作するのか理解することは、それほど難しくはないでしょう。
    とはいえ、そうした場合でもこの文書に書かれた多くのアドバイスはそ
    のまま通用しますから、このまま読み進めていってください。

    もしあなたの選んだプログラムがまだパッケージ化されていないもので
    、それを Debian に入れたいと決めたなら、以下のチェック項目につい
    て確認してください:

      * まず、そのプログラムが機能することを理解し、ある程度の期間使
        用してその有用性について確認するべきです。

      * 作業中のパッケージサイトを確認し、他の誰も同じパッケージに関
        して作業していないことを確かめてください。誰も作業していなけ
        れば、reportbug を使って ITP (Intent To Package) のバグレポー
        トを、wnpp 疑似パッケージに送ってください。もし既に誰かが作業
        していたら、連絡を取りたいならそうしてください。もしその気が
        無いなら、まだ誰も手をつけていない他の面白いプログラムを探し
        ましょう。

      * プログラムには、ライセンスが必須です。

          + main セクションは、Debian ポリシーにより Debian フリーソ
            フトウェアガイドライン (DFSG) に完全に準拠しなければなり
            ませんし、またコンパイル・実行時に main 以外のパッケージ
            に依存してはなりません。これが望ましいケースです。

          + contrib セクションは、DFSG に完全に準拠していなければなり
            ませんが、コンパイル・実行時に main にあるもの以外のパッ
            ケージに依存していても構いません。

          + non-free セクションは、DFSG に準拠していない部分があるか
            もしれませんが、配布可能でなければなりません。

          + どうするべきかよくわからなければ、
            debian-legal@lists.debian.org にライセンス文を送り、アド
            バイスを求めてください。

      * プログラムは、Debian システムにセキュリティーやメンテナンス上
        の懸念を招いてはいけません。

          + ちゃんとした説明書きのあるプログラムで、ソースコードが理
            解可能なもの (つまり、難読化されていないこと)。

          + プログラムの作者に連絡をとって、パッケージ化の承諾と
            Debian に友好的かどうかを確認しておきましょう。何かプログ
            ラムそのものに起因する問題が発生した際に、作者にいろいろ
            聞けるということは重要なので、メンテナンスされていないソ
            フトウェアをパッケージ化するのはやめておきましょう。

          + プログラムは root に setuid で実行されるべきではありませ
            ん。もっと言えば、どのユーザーへの setuid や setgid もす
            るべきではありません。

          + デーモンとして動作するプログラムや、*/sbin ディレクトリー
            に配置するプログラム、また root 特権を使ってポートを開く
            プログラムで無いほうが良いでしょう。

    もちろんこの最後の件は単なる安全策で、setuid デーモン等で何かミス
    して怒り狂ったユーザーから抗議殺到という事態を招くことを回避する
    ためです。パッケージ化についてもっと経験を積めば、こうしたパッケ
    ージも作れるようになるでしょう。

    新規メンテナーであるあなたには、比較的簡単なパッケージで経験を積
    むことをお勧めし、複雑なパッケージを作成することお勧めはできませ
    ん。

      * 単純なパッケージ、

          + 単一のバイナリーパッケージ、arch = all (壁紙グラフィクス
            のようなデータのコレクション)

          + 単一のバイナリーパッケージ、arch = all (POSIX のようなイ
            ンタープリタ言語で書かれた実行可能プログラム)

      * ほどほど複雑なパッケージ

          + 単一のバイナリーパッケージ、arch = all (C や C++ のような
            言語からコンパイルされた ELF バイナリーの実行可能プログラ
            ム)

          + 複数のバイナリーパッケージ、arch = all + any (ELF バイナ
            リーの実行可能プログラム + 文書のパッケージ)

          + ソースファイルの形式が、tar.gz. や tar.bz2 でないもの
   
          + 配布できない内容が含まれるアップストリームソース

      * 高度に複雑なパッケージ

          + 他のパッケージにより利用される、インタープリタのモジュー
            ルパッケージ

          + 他のパッケージにより利用される汎用 ELF ライブラリーパッケ
            ージ

          + ELF ライブラリーパッケージを含む複数バイナリーパッケージ

          + 複数のアップストリームソースからなるソースパッケージ

          + カーネルモジュールパッケージ

          + カーネルパッチパッケージ

          + 非自明なメンテナースクリプトを含むあらゆるパッケージ

    高度に複雑なパッケージをパッケージすることはそれほど難しいことで
    はありませんが、少々知識が必要です。それぞれの複雑な特徴には固有
    のガイダンスを探すべきです。例えば、いくつかの言語にはそれぞれの
    サブポリシー文書があります:

      * Perl policy

      * Python policy

      * Java policy

    もう一つの古いラテンの諺にもあるように、fabricando fit faber (習
    うより慣れろ)です。本入門書を読みながら単純なパッケージを用いて
    Debian パッケージングの全ステップを練習したり色々試したりすること
    を非常に推薦します。以下のようにして作った hello-sh-1.0.tar.gz と
    いう他愛ないアップストリームは良好なスタートポイントとなるでしょ
    う。^[8]

    $ mkdir -p hello-sh/hello-sh-1.0; cd hello-sh/hello-sh-1.0
    $ cat > hello <<EOF
    #!/bin/sh
    # (C) 2011 Foo Bar, GPL2+
    echo "Hello!"
    EOF
    $ chmod 755 hello
    $ cd ..
    $ tar -cvzf hello-sh-1.0.tar.gz hello-sh-1.0

2.3. プログラムの入手と検証

    さて、最初にすべきことは、オリジナルのソースコードを探してダウン
    ロードすることです。ここでは作者のホームページから、すでにソース
    ファイルを入手したとして話を進めます。フリーな Unix 用プログラム
    のソースは、ふつう .tar.gz 拡張子が付いた tar+gzip フォーマットや
    、.tar.bz2 拡張子が付いた tar+bzip2 フォーマットで提供されていま
    す。この中にはたいてい、すべてのソースが入った package-version と
    いうディレクトリーがあります。

    該当ソースの最新版が Git や Subversion、CVS リポジトリのような
    VCS で提供されているなら、git clone、svn co や cvs co としてソー
    スを取得してから、--exclude-vcs オプションを使って自分で tar+gzip
    フォーマットに再パックする必要があります。

    プログラムのソースが、他の種類のアーカイブ (例えば、.Zで終わるフ
    ァイル名や、.zip^[9]) の場合は、適切なツールでアンパックしてから
    再パックしてください。

    DFSGに準拠しない内容とともにあなたのプログラムのソースが提供され
    ている場合、それをアンパックし、そのような内容を削除し、dfsg を含
    むアップストリームバージョンに変更してリパックしましょう。

    さて、gentoo という X GTK+ ファイルマネージャを例に使い説明します
    。^[10]

    自分のホームディレクトリー以下に debian や deb、または何か適当な
    名前のサブディレクトリーを作りましょう (今回の場合には ~/gentoo/
    としても良いでしょう)。ダウンロードしたアーカイブをここにコピーし
    、tar xzf gentoo-0.9.12.tar.gz を実行して展開してください。この時
    、一見無関係に思えるようなものも含めて、警告メッセージが一切発生
    しないことを確認してください。アンパックする際に問題に出会わない
    ように、他の人々のシステム上で展開する際に、彼らが使っているツー
    ルがこの様な異常を無視したりしなかったりするので、警告メッセージ
    がなくなるように確実にしましょう。あなたのシェルのコマンドライン
    は、以下のように見えているでしょうか:

    $ mkdir ~/gentoo ; cd ~/gentoo
    $ wget http://www.example.org/gentoo-0.9.12.tar.gz
    $ tar xvzf gentoo-0.9.12.tar.gz
    $ ls -F
    gentoo-0.9.12/
    gentoo-0.9.12.tar.gz

    さて、gentoo-0.9.12 という別のサブディレクトリーができました。そ
    のディレクトリーに移動し、提供されているドキュメントを徹底的に読
    みましょう。通常は README* や INSTALL* や *.lsm や *.html といっ
    た名前のファイルがあります。それらの文書の中に、どうやったら正し
    くコンパイルできるのか、どうインストールすればよいのかといった情
    報が見つかるはずです (おそらく /usr/local/bin にインストールする
    ものとして説明されていますが、そうはしません。これについては「指
    定場所へのファイルのインストール」を参照してください)。

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

2.4. 単純なビルドシステム

    単純なプログラムは普通 Makefile ファイルが付属していて、単純に
    make でコンパイルできます。^[11] それらの中には同梱のセルフテスト
    を実行する make check をサポートするプログラムもあります。インス
    トール先ディレクトリーへのインストールは一般に make install によ
    って実行されます。

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

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

2.5. ポピュラーなポータブルなビルドシステム

    多数の自由なプログラムは、C や C++ 言語で書かれています。これらの
    多くは、異なるプラットフォーム間で移植を可能とするために
    Autotools や CMake を使っています。こういったツールは、Makefile
    やその他必要なソースファイルを生成するのに使われます。その後、こ
    のようなプログラムは通常どおり make; make install でビルドされま
    す。

    Autotools は Autoconf、Automake、Libtool と gettext から成る GNU
    のビルドシステムです。configure.ac、Makefile.am や Makefile.in フ
    ァイルがあれば、そういうソースであることがわかります。^[12]

    Autotools を使ったワークフローの最初の一歩は、アップストリームの
    作者がソースディレクトリーで autoreconf -i -f を実行し、生成され
    たファイルと一緒にこのソースを配布することです。

    configure.ac-----+-> autoreconf -+-> configure
    Makefile.am -----+        |      +-> Makefile.in
    src/Makefile.am -+        |      +-> src/Makefile.in
                              |      +-> config.h.in
                          automake
                          aclocal
                          aclocal.m4
                          autoheader

    configure.ac や Makefile.am ファイルを編集するには、autoconf と 
    automake についての知識が少々必要になります。info autoconf と
    info automake を参照してください。

    Autotools のワークフローの通常の次のステップは、この配布されてい
    るソースをユーザーが入手し、ソースディレクトリーで ./configure &&
    make を実行することで、プログラムを binary という実行可能コマンド
    にコンパイルします。

    Makefile.in -----+                +-> Makefile -----+-> make -> binary
    src/Makefile.in -+-> ./configure -+-> src/Makefile -+
    config.h.in -----+                +-> config.h -----+
                     |
      config.status -+
      config.guess --+

    Makefile ファイルにある内容の多くは変更することができます。例えば
    デフォルトでファイルがインストールされる場所などは、./configure
    --prefix=/usr とコマンドオプションを使って変更することができます
    。

    必須ではありませんが、autoreconf -i -f をユーザーとして実行するこ
    とで configure や他のファイルを更新すると、ソースの互換性が改善さ
    れる場合があります。^[13]

    CMake は代替のビルドシステムです。CMakeLists.txt ファイルがあれば
    、そういうソースだとわかります。

2.6. パッケージ名とバージョン

    gentoo-0.9.12.tar.gz としてアップストリームソースが提供される場合
    、パッケージ名は gentoo でアップストリームバージョンは 0.9.12 と
    なります。「changelog」で後述する debian/changelog ファイル中でも
    使われます。

    この単純なアプローチは大体うまくいくのですが、Debian Policy や従
    来の慣習に従うようにアップストリームソースをリネームすることでパ
    ッケージ名とアップストリームバージョンを調整する必要があるかもし
    れません。

    パッケージ名は、英小文字 (a-z)と数字 (0-9) と、プラス (+) やマイ
    ナス (-) 記号と、ピリオド (.) だけからなるように選ばなければいけ
    ません。少なくとも 2 文字以上で、英数字で始まり、既存のパッケージ
    と同じではいけません。30 文字以内の長さにするのが望ましいです。^
    [14]

    アップストリームのソースが test-suite のような一般的な単語をその
    名称として使う場合は、その内容を明示するようにリネームしネームス
    ペース汚染を引き起こさないのが良い考えです。^[15]

    アップストリームバージョンは、英数字 (0-9A-Za-z) とプラス (+) と
    波線 (~) とピリオド (.) からのみから選びます。それは数字 (0-9) で
    始まらなければいけません。^[16] できることならその長さを 8 文字以
    内とするのがいいです。^[17]

    アップストリームが 2.30.32 のような通常のバージョンスキームを使わ
    ずに、11Apr29 等のような日時の類や、ランダムなコードネーム文字列
    や、バージョンの一部にVCS のハッシュ値等を使う場合、アップストリ
    ームバージョンから削除するようにしましょう。そのような情報は、
    debian/changelog ファイルに記録できます。バージョン文字列を作り上
    げる必要のある際には、20110429 等のような YYYYMMDD フォーマットを
    アップストリームバージョンとして使用します。こうすると後のバージ
    ョンが正しくアップグレードと dpkg により解釈されます。将来、0.1
    等の通常のバージョンスキームへスムーズに移行する必要のある際には
    、0~110429 等のような 0~YYMMDD フォーマットをアップストリームバー
    ジョンとしてこの代わりに使用します。

    バージョン文字列^[18]は dpkg(1) コマンドを以下のように使うことで
    比較できます:

    $ dpkg --compare-versions ver1 op ver2

    バージョンの比較ルールは以下のようにまとめられます:

      * 文字列は頭から尾へと比較されます。

      * 英文字は数字よりも大きいです。

      * 数字は整数として比較されます。

      * 英文字は ASCII コード順で比較されます。

      * ピリオド (.) と、プラス (+) と波線 (~) には以下のような特殊な
        ルールがあります:

        0.0 < 0.5 < 0.10 < 0.99 < 1 < 1.0~rc1 < 1.0 < 1.0+b1 <
        1.0+nmu1 < 1.1 < 2.0

    アップストリームが gentoo-0.9.12.tar.gz のプリリリースとして
    gentoo-0.9.12-ReleaseCandidate-99.tar.gz をリリースする時には要注
    意です。アップストリームソースを gentoo-0.9.12~rc99.tar.gz と名称
    変更してアップグレードがうまく機能するように確実にする必要があり
    ます。

2.7. dh_make のセットアップ

    次のようにして、シェルの環境変数 $DEBEMAIL と $DEBFULLNAME を設定
    して、パッケージに使うあなたの email アドレスと名前を、多くの
    Debian メンテナンスツールに認識させましょう。^[19]

    $ cat >>~/.bashrc <<EOF
    DEBEMAIL="your.email.address@example.org"
    DEBFULLNAME="Firstname Lastname"
    export DEBEMAIL DEBFULLNAME
    EOF
    $ . ~/.bashrc

2.8. 最初のノンネイティブ Debian パッケージ

    標準的な Debian パッケージはアップストリームプログラムから作成さ
    れたノンネイティブ Debian パッケージです。アップストリームソース
    gentoo-0.9.12.tar.gz からノンネイティブ Debian パッケージを作りた
    い場合、dh_make コマンドを以下のように実行すると作成できます:

    $ cd ~/gentoo
    $ wget http://example.org/gentoo-0.9.12.tar.gz
    $ tar -xvzf gentoo-0.9.12.tar.gz
    $ cd gentoo-0.9.12
    $ dh_make -f ../gentoo-0.9.12.tar.gz

    当然ですが、ファイル名はあなたのオリジナルのソースアーカイブの名
    前と置き換えてください。^[20] 詳細は、dh_make(8) を参照してくださ
    い。

    情報がいくつか表示されるでしょう。どんな種類のパッケージを作ろう
    としているのかを尋ねられます。Gentoo は単一バイナリーパッケージ —
    バイナリーを一つだけ生成するので、一個の .deb ファイルです — なの
    で、s キーで最初の選択肢を選びましょう。表示された情報をチェック
    して、ENTER を押して確認してください。^[21]

    dh_make を実行した後、アップストリームの tarball のコピーを、親デ
    ィレクトリーに gentoo_0.9.12.orig.tar.gz として作成します。次に、
    それに伴ってノンネイティブ Debian ソースパッケージを
    debian.tar.gz として作成します:

    $ cd ~/gentoo ; ls -F
    gentoo-0.9.12/
    gentoo-0.9.12.tar.gz
    gentoo_0.9.12.orig.tar.gz

    この gentoo_0.9.12.orig.tar.gz ファイル名がもっている 2 つの特徴
    に注意してください:

      * パッケージ名とバージョンは _ (アンダースコア) で区切られてい
        ます。

      * .tar.gz の前に .orig と言う文字列があります。

    ソース中のdebianディレクトリーにたくさんのテンプレートファイルが
    作成されていることにも注意が必要です。これらについては、4章debian
    / ディレクトリー以下に無くてはならないファイルと 5章debianディレ
    クトリーにあるその他のファイルで説明します。パッケージ作成が自動
    的な過程ではないことも理解しておかねばなりません。3章ソースコード
    の変更のように、アップストリームソースを Debian 向けに変更する必
    要があります。こういった作業の後で、6章パッケージのビルドのように
    正しいやり方で Debian パッケージをビルドし、7章パッケージのエラー
    の検証のようにチェックし、そして 9章パッケージをアップロードする
    のようにしてアップロードする必要があります。これらすべてのステッ
    プについてこれから説明します。

    作業中にテンプレートファイルを間違って消した場合は、Debian パッケ
    ージのソースツリーで dh_make を --addmissing オプションつきで再度
    実行することで修復できます。

    既存のパッケージの更新は、古いテクニックが使われていたりして、や
    っかいな場合があります。基本を学習中は、新規パッケージの作成にと
    どめてください。8章パッケージの更新にて、追加で説明します。

    ソースファイルには「単純なビルドシステム」や「ポピュラーなポータ
    ブルなビルドシステム」で述べたようないかなるビルドシステムを含ん
    でいる必要は無いことに注意して下さい。それは単なる画像データ集等
    かもしれません。ファイルのインストールは debian/install (「
    install」参照) のような debhelper コンフィギュレーションファイル
    だけを使っても行えます。


---------------------------------------------------------------------

    ^[4] 1.0 フォーマットの古いノンネイティブの Debian パッケージに関
    しては、上記の代わりに package_version-revision.diff.gz が使われ
    ます。

    ^[5] 5.6.1 "Source", 5.6.7 "Package", and 5.6.12 "Version" を参照
    下さい。パッケージアーキテクチャーは Debian Policy Manual, 5.6.8
    "Architecture" に従い、パッケージビルドプロセスにより自動的に付与
    されます。

    ^[6] Debian Developer's Reference 5.9.5 "Adopting a package" を参
    照下さい。

    ^[7] とはいっても、パッケージ化する価値のある新しいプログラムはい
    つだって存在するでしょう。

    ^[8] Makefileがないことを心配しないで下さい。hello コマンドは「
    install」にあるようにして debhelper を単純に使用したり、3章ソース
    コードの変更にあるようにして install ターゲットがある新規の
    Makefile をアップストリームソースに追加してインストールできます。

    ^[9] ファイルの拡張子で足りなければ、file コマンドを使ってアーカ
    イブ形式を判別することができます。

    ^[10] このプログラムはすでにパッケージ化されています。その最新の
    バージョンは Autotools をそのビルド構造としており、バージョン
    0.9.12 に基づく以下の例から大きく異なります。

    ^[11] 多くの現代的なプログラムには実行するとあなたのシステム用に
    カスタム化した Makefile ファイルを作成する configure スクリプトが
    同梱されています。

    ^[12] Autotools は本入門書で扱うには大きすぎます。本セクションは
    キーワードや参照文献を提供するだけです。必要な際には、Autotools
    Tutorial と /usr/share/doc/autotools-dev/README.Debian.gz のロー
    カルコピーをしっかり読んで下さい。

    ^[13] dh-autoreconf パッケージを用いるとこれが自動化出来ます。「
    rules ファイルのカスタマイズ」を参照下さい。

    ^[14] aptitude のデフォルトのパッケージ名フィールド長は 30 です。
    90% を越えるパッケージに関し、パッケージ名は 24 文字より短いです
    。

    ^[15] Debian Developer's Reference 5.1. "New packages" の通りにす
    れば、ITP プロセスが普通この様な間違いを洗い出します。

    ^[16] この厳しい目のルールは混乱を招くファイル名を避けるのに役立
    ちます。

    ^[17] aptitude のデフォルトのバージョンフィールド長は 10 です。
    Debian リビジョンとその前のハイフンが通常 2 つを消費します。80%
    以上のパッケージはアップストリームバージョンが 8 文字より少なく、
    Debian リビジョンが 2 文字より少ないです。90% 上のパッケージはア
    ップストリームバージョンが 10 文字より少なく、Debian リビジョンが
    3 文字より少ないです。

    ^[18] バージョン文字列は、アップストリームバージョン (version) か
    、Debian リビジョン (revision) か、バージョン (version-revision)
    かもしれません。Debian リビジョンがどのように増やされるかは「
    Debian リビジョンの更新」を参照下さい。

    ^[19] 以下の文章はあなたが Bash をログインシェルとして使っている
    と仮定しています。Z シェルのような他のログインシェルを用いている
    場合 ~/.bashrcと代えてそれに対応する設定ファイルを使って下さい。

    ^[20] アップストリームのソースが debian ディレクトリーとその中身
    を提供している場合は、かわりに dh_make コマンドを --addmissing オ
    プションをつけて実行してください。新しい 3.0 (quilt) 形式のソース
    はとても堅牢なので、こういったパッケージでも壊すことはありません
    。自分の Debian パッケージ用に、アップストリームバージョンが提供
    した内容を更新する必要があるかもしれません。

    ^[21] ここでの選択肢はわずかです。s は Single binary package (単
    一バイナリーパッケージ)、i は Arch-Independent package (アーキテ
    クチャー非依存パッケージ)、m は Multiple binary package (複数バイ
    ナリーパッケージ)、l は Library package (ライブラリーパッケージ)
    、k は Kernel module package (カーネルモジュールパッケージ)、n は
    Kernel patch package (カーネルパッチパッケージ)、b は cdbs です。
    本文書は debhelper パッケージを dh コマンドとともに使うことに使う
    ことに重点を置きます。このドキュメントでは、単一バイナリーパッケ
    ージのために dh コマンドを使うことに重点を置き、アーキテクチャー
    非依存や複数バイナリーのパッケージに関する同様の事にも触れます。
    cdbs パッケージは dh コマンドに代わるパッケージスクリプトのインフ
    ラを提供し、本文書では対象外です。

第3章ソースコードの変更

    最新の内容とより実用的な例でこの入門書を書き換えたものが Guide
    for Debian Maintainers として入手できます。この新しい入門書を第一
    次的な入門書として使ってください。

    アップストリームのソースを修正する具体的なやり方について、何から
    何まで説明するにはとても紙面が足りませんが、よくあるパターンとし
    ては大体以下のようなものでしょう。

3.1. quilt のセットアップ

    quilt プログラムはアップストリームソースに対する Debian パッケー
    ジ向け修正を記録する、基本的な方法を提供します。Debian パッケージ
    で使うには、多少カスタマイズしたデフォルトを使うのが望ましいので
    、以下の行を ~/.bashrc に追加し Debian パッケージ作成用のエリアス
    dquilt を作りましょう。第 2 行目は quilt コマンドのシェル入力完了
    機能と同様の機能を dquilt コマンドに与えます:

    alias dquilt="quilt --quiltrc=${HOME}/.quiltrc-dpkg"
    . /usr/share/bash-completion/completions/quilt
    complete -F _quilt_completion -o filenames dquilt

    ~/.quiltrc-dpkg ファイルを次のように作成しましょう:

    d=. ; while [ ! -d $d/debian -a $(readlink -e $d) != / ]; do d=$d/..; done
    if [ -d $d/debian ] && [ -z $QUILT_PATCHES ]; then
        # if in Debian packaging tree with unset $QUILT_PATCHES
        QUILT_PATCHES="debian/patches"
        QUILT_PATCH_OPTS="--reject-format=unified"
        QUILT_DIFF_ARGS="-p ab --no-timestamps --no-index --color=auto"
        QUILT_REFRESH_ARGS="-p ab --no-timestamps --no-index"
        QUILT_COLORS="diff_hdr=1;32:diff_add=1;34:diff_rem=1;31:diff_hunk=1;33:diff_ctx=35:diff_cctx=33"
        if ! [ -d $d/debian/patches ]; then mkdir $d/debian/patches; fi
    fi

    quilt の使い方については、quilt(1) と /usr/share/doc/quilt/
    quilt.pdf.gz を参照してください。

3.2. アップストリームのバグを修正する

    以下のようなアップストリームの Makefile にエラーを見つけて、
    install: gentoo の部分が install: gentoo-target となっているべき
    だったとします。

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

    これを修正して、dquilt コマンドを使って fix-gentoo-target.patch
    として登録しましょう: ^[22]

    $ mkdir debian/patches
    $ dquilt new fix-gentoo-target.patch
    $ dquilt add Makefile

    Makefile ファイルを次のように変更します:

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

    パッチを更新して debian/patches/fix-gentoo-target.patch を作成す
    るように dquilt に要求し、それから説明を DEP-3: Patch Tagging
    Guidelines に準拠して追記します:

    $ dquilt refresh
    $ dquilt header -e
    ... パッチの詳細

3.3. 指定場所へのファイルのインストール

    通常、サードパーティーソフトウェアは自分自身を /usr/local サブデ
    ィレクトリーにインストールします。Debian 上ではこれはシステム管理
    者 (もしくはユーザー) の個人用に予約されているため、パッケージャ
    ーは /usr/local のようなディレクトリーを使わず、Filesystem
    Hierarchy Standard (FHS) に従って /usr/bin サブディレクトリーのよ
    うなシステムディレクトリーを使わなくてはなりません。

    プログラムのビルドを自動化するには、通常 make(1) が使われており、
    make install を実行すると、(Makefile のinstall ターゲットに従い)
    希望する場所へ直接インストールされます。Debian ではビルド済みのイ
    ンストール可能なパッケージを提供するために、実際のインストール先
    のかわりに、一時ディレクトリーの下に作成されたファイルツリーのイ
    メージへプログラムをインストールするようにビルドシステムを変更し
    ます。

    普通のプログラムインストールとDebian パッケージ作成というこれら二
    つの違いには、debhelper パッケージの dh_auto_configure と 
    dh_auto_install のコマンドを使うことで特に意識せずに対応できます:

      * Makefile ファイルが GNU の慣例に準拠し、$(DESTDIR) 変数をサポ
        ートしていること。^[23]
   
      * ソースは Filesystem Hierarchy Standard (FHS) に準拠している必
        要があります。

    GNU autoconf を使っているプログラムは、自動的に GNU 規約に準拠す
    るので、そのパッケージ作成はいとも簡単にできます。こういう事実や
    他から類推すると、debhelper パッケージはビルドシステムに立ち入っ
    た変更を加えることなく、約 90% のパッケージで使えると推定されます
    。そのため、パッケージ作成は見かけほど複雑ではありません。

    もし Makefile ファイルを変更する必要があるなら、これら $(DESTDIR)
    変数をサポートするように注意しましょう。デフォルトではアンセット
    されているとはいえ、プログラムのインストールに使われる各ファイル
    パスの前に$(DESTDIR) 変数は付与されます。パッケージ作成スクリプト
    は $(DESTDIR) を一時ディレクトリーにセットします。

    単一バイナリーパッケージを生成するソースパッケージでは、debian/
    package が dh_auto_install コマンドが使う一時ディレクトリーとして
    指定されます。^[24] 一時ディレクトリーに含まれているものはすべて
    、ユーザーがあなたのパッケージをインストールする時に、ユーザーの
    システムにインストールされます。唯一の違いは、dpkg はファイルをあ
    なたの作業ディレクトリーではなくルートディレクトリーからの相対パ
    スにインストールするということです。

    パッケージの作成時は、あなたのプログラムは debian/package にイン
    ストールされますが、.deb パッケージからルートディレクトリー下にイ
    ンストールされた場合も正しく動作する必要があることを覚えておいて
    ください。こうするためには、ビルドシステムがパッケージファイルの
    中のファイル中に /home/me/deb/package-version/usr/share/package
    といった文字列をハードコードしないようにしなければなりません。

    gentoo の Makefile で該当する部分はこれです^[25]:

    # Where to put executable commands on 'make install'?
    BIN     = /usr/local/bin
    # Where to put icons on 'make install'?
    ICONS   = /usr/local/share/gentoo

    ファイルが /usr/local 以下にインストールされるようになっているこ
    とがわかります。上記説明にあるように、そのディレクトリーヒエラル
    キーは Debian 上のローカルユーザー向けに予約されているので、これ
    らのパスを以下のように変更してください:

    # Where to put executable commands on 'make install'?
    BIN     = $(DESTDIR)/usr/bin
    # Where to put icons on 'make install'?
    ICONS   = $(DESTDIR)/usr/share/gentoo

    バイナリー、アイコン、文書など、それぞれのファイルを保存すべき正
    確な場所については、Filesystem Hierarchy Standard (FHS) 中に規定
    されています。全体に目を通して、あなたのパッケージに該当する箇所
    を読むことをお勧めします。

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

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

    $ grep -nr --include='*.[c|h]' -e 'usr/local/lib' .

    grep がソースツリーを再帰的に検索し、該当箇所を見つけたらそのファ
    イルの名前と検索対象の文字列が含まれる行番号とを表示します。

    それらのファイルを編集し、該当行の usr/local/lib を usr/lib に置
    き換えてください。これは以下の様にすると自動化出来ます:

    $ sed -i -e 's#usr/local/lib#usr/lib#g' \
            $(find . -type f -name '*.[c|h]')

    こうする代わりに、各置換を確認したい場合は、これは以下のようにイ
    ンタラクティブにできます:

    $ vim '+argdo %s#usr/local/lib#usr/lib#gce|update' +q \
            $(find . -type f -name '*.[c|h]')

    修正が終ったら、 install ターゲットを探しましょう(install: で始ま
    る行を探してください。この方法でたいていうまくいきます)。Makefile
    の先頭で定義されているものを除いて、ディレクトリーへの参照をすべ
    て変更してください。

    修正前は、gentoo の install ターゲットはこうなっています:

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

    dquilt コマンドを使って、debian/patches/install.patch としてアッ
    プストリームバグを修正して記録しましょう。

    $ dquilt new install.patch
    $ dquilt add Makefile

    Debian パッケージ用に、これをエディタで次のように変更します:

    install: gentoo-target
            install -d $(BIN) $(ICONS) $(DESTDIR)/etc
            install ./gentoo $(BIN)
            install -m644 icons/* $(ICONS)
            install -m644 gentoorc-example $(DESTDIR)/etc/gentoorc

    お気づきになったでしょうが、変更後はこのルールの他のコマンドより
    前に install -d コマンドが追加されています。make install を実行す
    るようなシステムなら /usr/local/bin やその他のディレクトリーはた
    いがい既に存在しているでしょうから、もともとの Makefile ではこの
    コマンドは使われていませんでした。しかし、私たちは独自に空っぽの
    （あるいはまだ存在さえしていない）ディレクトリーにインストールす
    るわけですから、これらの各ディレクトリーを毎回作成する必要があり
    ます。

    ルールの最後には、アップストリームの作者が省略することの多い付加
    的な資料のインストールなど、他の作業を追加することもできます:

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

    しっかりチェックをして、何も問題がないようであれば、dquilt でパッ
    チを更新して debian/patches/install.patch を作成し、パッチの説明
    を追記してください:

    $ dquilt refresh
    $ dquilt header -e
    ... パッチの詳細

    これで、一連のパッチができました。

     1. アップストリームのバグ修正： debian/patches/
        fix-gentoo-target.patch
   
     2. Debian 固有のパッケージ上の変更： debian/patches/
        install.patch

    debian/patches/fix-gentoo-target.patch のような、特に Debian パッ
    ケージだけに限定されない変更を行った場合、その内容をアップストリ
    ームのメンテナーに報告するようにしてください。そうすれば、プログ
    ラムの次版に反映してもらうことができ、他のすべての利用者にとって
    も有益な結果をもたらすことになります。また、あなたの修正を送る前
    に、Debian や Linux — あるいは Unix でさえも! — に特化した修正に
    せず、移植性をもたせることも忘れないでください。そうすれば、あな
    たの変更はずっと採用されやすくなります。

    アップストリームの作者へ debian/* ファイルを送らなくてもよいこと
    に注意してください。

3.4. ライブラリーの相違

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

    あなたのプログラムの Makefile (もしくは Makefile.in) が以下のよう
    になっていると仮定しましょう。

    LIBS = -lfoo -lbar

    foo ライブラリーが存在しないためにあなたのプログラムがコンパイル
    しないで、foo2 ライブラリーがその等価を Debian システム上で提供す
    る場合、foo を foo2 に変更する debian/patches/foo2.patch としてこ
    のビルド問題を解決できます:^[26]

    $ dquilt new foo2.patch
    $ dquilt add Makefile
    $ sed -i -e 's/-lfoo/-lfoo2/g' Makefile
    $ dquilt refresh
    $ dquilt header -e
    ... describe patch


---------------------------------------------------------------------

    ^[22] 前に説明したように dh_make を実行していれば、debian/patches
    ディレクトリーはもう存在しているはずです。この操作例では、既存の
    パッケージを更新している場合に合わせて作成しています。

    ^[23] GNU Coding Standards: 7.2.4 DESTDIR: Support for Staged
    Installs を参照下さい。

    ^[24] 複数バイナリーパッケージを生成するソースパッケージでは、
    debian/tmp を dh_auto_install コマンドが使う一時ディレクトリーと
    しますが、debian/tmp の中身を debian/package-1 や debian/
    package-2 一時ディレクトリーへと、debian/package-1.install や
    debian/package-2.install ファイルによる指定に従い dh_install コマ
    ンドが分配することで複数バイナリー *.deb パッケージを作成されます
    。

    ^[25] これは Makefile ファイルがこうなっているべきである、という
    ことを示すための例にすぎません。Makefile ファイルが ./configure
    コマンドで作成されているなら、この手の Makefile を修正する正しい
    方法は、dh_auto_configure コマンドに --prefix=/usr を含むデフォル
    トのオプションを与えて、./configure コマンドを実行させることです
    。

    ^[26] foo ライブラリーから foo2 ライブラリーへの API 変更があった
    場合、新しい API に合わせてソースコードへの必要な変更を加える必要
    があります。

第4章 debian/ ディレクトリー以下に無くてはならないファイル

    最新の内容とより実用的な例でこの入門書を書き換えたものが Guide
    for Debian Maintainers として入手できます。この新しい入門書を第一
    次的な入門書として使ってください。

    プログラムのソースディレクトリーの中に debianという名前の新しいデ
    ィレクトリーがつくられています。このディレクトリー内には、パッケ
    ージの挙動をカスタマイズするため編集するべき多くのファイルがあり
    ます。特に、 control と changelog と copyright と rules は、すべ
    てのパッケージになくてはならないファイルです。^[27]

4.1. control

    dpkg や dselect や apt-get や apt-cache や aptitude 等のパッケー
    ジ管理ツールが利用する情報は、このファイルに記載されています。こ
    のファイルは、Debian Policy Manual, 5 'Control files and their
    fields'に定義されています。

    以下は、dh_make が生成した control ファイルの雛型です:

     1 Source: gentoo
     2 Section: unknown
     3 Priority: optional
     4 Maintainer: Josip Rodin <joy-mg@debian.org>
     5 Build-Depends: debhelper (>=10)
     6 Standards-Version: 4.0.0
     7 Homepage: <insert the upstream URL, if relevant>
     8
     9 Package: gentoo
    10 Architecture: any
    11 Depends: ${shlibs:Depends}, ${misc:Depends}
    12 Description: <insert up to 60 chars description>
    13  <insert long description, indented with spaces>

    (行番号は筆者による)

    1–7 行目は、ソースパッケージの管理情報です。9–13 行目は、バイナリ
    ーパッケージの管理情報です。

    1 行目は、ソースパッケージ名です。

    2 行目は、パッケージが所属するディストリビューション内のセクショ
    ンです。

    ご存知のように、Debianアーカイブは main (完全にフリーなソフトウェ
    ア)、non-free (本当にフリーではないソフトウェア)、contrib (フリー
    だが non-free ソフトウェアに依存するソフトウェア)という複数エリア
    に分かれています。さらにそれらは、大まかなカテゴリー毎のセクショ
    ンに分類されています。例えば、管理者専用のプログラムはadmin 、プ
    ログラムツールは devel、文書作成関連は doc、ライブラリーは libs、
    メールリーダやメールデーモンは mail、ネットワーク関連のアプリケー
    ションやデーモンは net、分類ができないX11用のプログラムは x11に分
    類され、他にも様々なセクションがあります。^[28]

    ここではx11に変更してみましょう。(省略時はmain/がデフォルトとして
    設定されます)

    3行目は、ユーザーが当パッケージをインストールする重要度を示してい
    ます。^[29]

      * required、 important、standardのパッケージと競合しない新規の
        パッケージの場合は、optionalで問題ないでしょう。

    セクション (Section) と優先度 (Priority) はaptitudeのようなフロン
    トエンドがパッケージをソートする際と、デフォルトを選択する際に利
    用されます。Debian にアップロードしたパッケージのこれらの値は、ア
    ーカイブメンテナーによってオーバーライドされることがありますが、
    その場合は電子メールによって通知されます。

    このパッケージは通常の優先度で、競合もないので、 optionalにしまし
    ょう。

    4行目は、メンテナーの名前と電子メールアドレスです。バグ追跡システ
    ムは、このフィールドに記載された宛先へユーザーからのバグ報告を送
    信するので、このフィールドは有効な電子メールの To ヘッダーを含む
    ようにしましょう。コンマ「,」、アンド記号「&」、丸括弧「()」は使
    用しないでください。

    5行目のBuild-Dependsフィールドは、新規パッケージのビルドに必要な
    パッケージのリストです。必要であれば、Build-Depends-Indepフィール
    ドをここに追加できます。^[30] gccやmakeのようなbuild-essentialに
    含まれるパッケージは明示無くとも含まれています。他のツールがパッ
    ケージをビルドするのに必要な場合は、このフィールドに追加しましょ
    う。複数記載する場合は、コンマで区切ります。このフィールドの書式
    については、後述のバイナリーパッケージ依存関係でこれらの行のシン
    タクスに関してもう少し詳しく説明します。

      * debian/rulesを使用し、dhコマンドでパッケージングされたパッケ
        ージは、cleanターゲットに関するDebian ポリシーを満たすために
        、Build-Dependsフィールドにdebhelper (>=9) を記載しなければな
        りません。

      * Architecture: any のバイナリーパッケージを含むソースパッケー
        ジはオートビルダーによってリビルトされます。オートビルダーは
        debian/rules build を実行します。その際に、Build-Depends フィ
        ールド (「オートビルダー」を参照)に列挙されたパッケージしかイ
        ンストールしないので、Build-Depends フィールドには事実上必要
        なパッケージ全てを列挙しなければなりません。
        Build-Depends-indep はあまり使われません。

      * バイナリーパッケージが全て Architecture: all のソースパッケー
        ジでは、clean ターゲットに関する Debian ポリシーを満たすため
        に Build-Depends フィールドにすでに記載したパッケージ以外で必
        要なパッケージは、Build-Depends-Indepフィールドに記載すること
        もできます。

    どちらのフィールドを使えうべきかわからなければ、Build-Dependsにし
    ておきましょう。^[31]

    以下のコマンドを使えば、新規のパッケージをビルドするためにどのパ
    ッケージが必要かを調べることができます:

    $ dpkg-depcheck -d ./configure

    /usr/bin/fooの正確なビルド依存パッケージを手動でみつけるには、

    $ objdump -p /usr/bin/foo | grep NEEDED

    を実行し、表示された各ライブラリー（例えばlibfoo.so.6の場合）につ
    いて、

    $ dpkg -S libfoo.so.6

    を実行します。Build-Depends の項目に、各ライブラリーの-devバージ
    ョンを採用します。このために ldd を使用すると、間接的な依存も報告
    し、過度のビルド依存問題を引き起こします。

    gentooパッケージをビルドするにはxlibs-dev、libgtk1.2-dev、
    libglib1.2-devが必要なので、debhelperの後に記述しましょう。

    6行目は、パッケージが準拠するDebian Policy Manual のバージョンで
    す。これは、あなたがパッケージ作成の際に参照したポリシーマニュア
    ルのバージョンです。

    7行目にはソフトウェアのアップストリームホームページ URL を記載で
    きます。

    9行目はバイナリーパッケージの名前です。ソースパッケージと同名にす
    るのが通例ですが、そうでなくてもかまいません。

    10 行目にはバイナリーパッケージがコンパイルされる対象のアーキテク
    チャーを記載します。この値はバイナリーパッケージのタイプによって
    通常以下の 2 つのどちらかです: ^[32]

      * Architecture: any

          + 生成されるバイナリーパッケージが通常コンパイルされたマシ
            ンコードからなるアーキテクチャー依存パッケージである。
   
      * Architecture: all

          + 生成されたバイナリーパッケージは、通常テキストやイメージ
            やインタープリター言語のスクリプトからなる、アーキテクチ
            ャー依存の無いパッケージである。

    10行目はこれが C で書かれているのでこのままにしておきます。
    dpkg-gencontrol(1) がソースパッケージがコンパイルされたマシンに合
    わせた適正なアーキテクチャーの値で埋めてくれます。

    特定のアーキテクチャーに依存しない(例えば、シェルやPerlスクリプト
    、文書)パッケージであれば、パッケージをビルドする際に、これを all
    に変更し、binary-arch に代え binary-indep を使って後述の「rules」
    を読んでください。

    11行目からはDebianのパッケージシステムが強力なことがわかります。
    パッケージは様々な形で相互に関係することができます。Dependsの他に
    は、Recommends、 Suggests、Pre-Depends、Breaks、 Conflicts、
    Provides、Replacesなどがあります。

    パッケージ管理ツールは通常このような関係を処理するとき同様の動作
    をします。そうでない場合については、後から説明します。(dpkg(8)、
    dselect(8)、apt(8)、aptitude(1) 等を参照してください。)

    パッケージの依存関係を単純化し以下に説明します: ^[33]

      * Depends (依存)

        依存しているパッケージがインストールされない限り、パッケージ
        はインストールされません。あなたのプログラムが特定のパッケー
        ジ無しでは動かない(または深刻な破損を引き起こす)場合はこれを
        使います。

      * Recommends (推奨)

        厳密には必須ではないけれど通常一緒に使われるようなパッケージ
        の指定にこれを用います。あなたのプログラムをユーザーがインス
        トールする時、全てのフロントエンドは推奨パッケージも一緒にイ
        ンストールするかをきっと確認します。aptitude や apt-get の場
        合は、推奨パッケージもデフォルトで一緒にインストールします。
        (ユーザーはこの挙動を無効化できます。) dpkgはこのフィールドを
        無視します。

      * Suggests (提案)

        必須ではないが、一緒に使用すると便利なパッケージの指定にこれ
        を用います。あなたのプログラムをユーザーがインストールする時
        、フロントエンドが提案パッケージも一緒にインストールするかき
        っと確認します。aptitude は提案パッケージを一緒にインストール
        するように変更することが可能ですが、デフォルトではありません
        。dpkg と apt-get はこのフィールドを無視します。

      * Pre-Depends (事前依存)

        これは Depends よりも強い関係を示します。パッケージは先行依存
        のパッケージがあらかじめインストールされ、かつ適切に設定され
        ていない限りインストールされません。これは、メーリングリスト
        debian-devel@lists.debian.orgで議論を尽くした上で、とても慎重
        に扱うべきです。つまり、使わないでください。:-)

      * Conflicts (競合)

        競合しているパッケージが削除されない限り、パッケージはインス
        トールされません。あなたのプログラムが特定のパッケージと一緒
        だと動かない（または深刻な破壊の原因になる恐れがある）場合は
        これを使います。

      * Breaks (破壊)

        パッケージがインストールされると、全てのリストされたパッケー
        ジを破壊します。通常、Breaks の項目は特定の値より旧いバージョ
        ンに対して規定します。通常、上位パッケージマネジメントツール
        を用い、記載されたパッケージをアップグレードし解決します。

      * Provides (提供)

        パッケージによっては、選択の余地があるために、仮想パッケージ
        名が定義されています。仮想パッケージ名の一覧は
        virtual-package-names-list.txt.gz にあります。あなたのプログ
        ラムが既存の仮想パッケージの機能を提供する場合には、これを使
        います。

      * Replaces (置換)

        あなたのプログラムが別パッケージのファイルを置き換えたり、パ
        ッケージ全体を完全に置き換えてしまう場合（この場合は
        Conflicts も一緒に指定してください）この指定を使います。ここ
        で指定されたパッケージに含まれるファイルはあなたのパッケージ
        のファイルによって上書きされます。

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

    これらフィールドは、各指定パッケージの特定バージョン番号に適用対
    象を制限できます。各個別パッケージへの制約はパッケージ名の後に丸
    カッコの中に以下の関係式に続けバージョン番号を指定しリストします
    。使用できる関係式は、<< と <= と = と >= と >> で、それぞれ「指
    定されたものより古いバージョンのみ」、「指定されたバージョン以前
    」(指定のバージョンも当然含まれます)、「指定のバージョンのみ」、
    「指定されたバージョン以降」(指定のバージョンも当然含まれます)、
    「指定されたものより新しいバージョンのみ」を意味します。例えば、

    Depends: foo (>= 1.2), libbar1 (= 1.3.4)
    Conflicts: baz
    Recommends: libbaz4 (>> 4.0.7)
    Suggests: quux
    Replaces: quux (<< 5), quux-foo (<= 7.6)

    知っておくべき最後の特徴は ${shlibs:Depends} や ${perl:Depends}
    や ${misc:Depends} 等です。

    dh_shlibdeps(1)は、バイナリーパッケージのライブラリー依存関係を計
    算します。それは各バイナリーパッケージ毎に、ELF 実行可能ファイル
    や共有ライブラリーのリストを生成します。このようなリストは $
    {shlibs:Depends} の置換に利用されます。

    dh_perl(1)は、Perl依存関係を計算します。それは各バイナリーパッケ
    ージ毎に、perl や perlapi の依存関係リストを生成します。このよう
    なリストは ${perl:Depends} の置換に利用されます。

    一部の debhelper コマンドは、生成するパッケージが他追加パッケージ
    に依存するようにパッケージを生成します。このようなコマンド全ては
    、各バイナリーパッケージが必要とするパッケージのリストを生成しま
    す。このようなリストは ${misc:Depends} の置換に利用されます。

    dh_gencontrol(1) が ${shlibs:Depends}、${perl:Depends}、$
    {misc:Depends} 等を置換しながら各バイナリーパッケージ毎に DEBIAN/
    control を生成します。

    とは言っても、今のところ Depends フィールドはそのままにして、その
    下に Suggests: file という新たな行を追加しましょう。gentoo は
    file パッケージによって提供される機能を利用することができるからで
    す。

    9 行目はホームページの URLです。これが http://www.obsession.se/
    gentoo/ と仮定しましょう。

    12行目は手短な説明です。従来ターミナルは 1 行（半角）80 文字幅な
    ので、(半角)60字以上にならないようにしましょう。fully
    GUI-configurable, two-pane X file manager に変更します。

    13行目は詳細な説明です。これはパッケージについてより詳しく説明す
    る1つの段落であるべきです。各行の先頭は空白（スペース文字）で始め
    ます。空白行を入れてはいけませんが、 . (半角ピリオド) を1つ書くこ
    とで、空白行のように見せることができます。説明文の後にも１行以上
    の空白行を入れてはいけません。^[34]

    6行目と7行目の間に Vcs-*フィールドを追加しバージョン管理システム
    (VCS) の場所を記録しましょう。^[35] gentooパッケージがその VCS ア
    ーカイブを git://git.debian.org/git/collab-maint/gentoo.git の
    Debian Alioth Git Service に置いていると仮定しましょう。

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

     1 Source: gentoo
     2 Section: x11
     3 Priority: optional
     4 Maintainer: Josip Rodin <joy-mg@debian.org>
     5 Build-Depends: debhelper (>=10), xlibs-dev, libgtk1.2-dev, libglib1.2-dev
     6 Standards-Version: 4.0.0
     7 Vcs-Git: https://anonscm.debian.org/git/collab-maint/gentoo.git
     8 Vcs-browser: https://anonscm.debian.org/git/collab-maint/gentoo.git
     9 Homepage: http://www.obsession.se/gentoo/
    10
    11 Package: gentoo
    12 Architecture: any
    13 Depends: ${shlibs:Depends}, ${misc:Depends}
    14 Suggests: file
    15 Description: fully GUI-configurable, two-pane X file manager
    16  gentoo is a two-pane file manager for the X Window System. gentoo lets the
    17  user do (almost) all of the configuration and customizing from within the
    18  program itself. If you still prefer to hand-edit configuration files,
    19  they're fairly easy to work with since they are written in an XML format.
    20  .
    21  gentoo features a fairly complex and powerful file identification system,
    22  coupled to an object-oriented style system, which together give you a lot
    23  of control over how files of different types are displayed and acted upon.
    24  Additionally, over a hundred pixmap images are available for use in file
    25  type descriptions.
    26  .
    29  gentoo was written from scratch in ANSI C, and it utilizes the GTK+ toolkit
    30  for its interface.

    (行番号は筆者による)

4.2. copyright

    このファイルにパッケージのアップストリームソースに関する著作権や
    ライセンスなどの情報を記載します。その内容は Debian Policy
    Manual, 12.5 "Copyright information" に規定され、DEP-5:
    Machine-parseable debian/copyright がそのフォーマットのガイドライ
    ンを提供しています。

    dh_makeはcopyrightファイルのテンプレートを作成します。GPL-2でリリ
    ースされたgentooパッケージのテンプレートを入手するには、
    --copyright gpl2オプションを使用します。

    You must fill in missing information to complete this file, such
    as the place you got the package from, the actual copyright
    notice, and the license. For certain common free software
    licenses (GNU GPL-1, GNU GPL-2, GNU GPL-3, LGPL-2, LGPL-2.1,
    LGPL-3, GNU FDL-1.2, GNU FDL-1.3, Apache-2.0, 3-Clause BSD,
    CC0-1.0, MPL-1.1, MPL-2.0 or the Artistic license), you can just
    refer to the appropriate file in the /usr/share/common-licenses/
    directory that exists on every Debian system. Otherwise, you must
    include the complete license.

    つまり、gentoo パッケージの copyright ファイルは以下のようになり
    ます:

     1 Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
     2 Upstream-Name: gentoo
     3 Upstream-Contact: Emil Brink <emil@obsession.se>
     4 Source: http://sourceforge.net/projects/gentoo/files/
     5
     6 Files: *
     7 Copyright: 1998-2010 Emil Brink <emil@obsession.se>
     8 License: GPL-2+
     9
    10 Files: icons/*
    11 Copyright: 1998 Johan Hanson <johan@tiq.com>
    12 License: GPL-2+
    13
    14 Files: debian/*
    15 Copyright: 1998-2010 Josip Rodin <joy-mg@debian.org>
    16 License: GPL-2+
    17
    18 License: GPL-2+
    19  This program is free software; you can redistribute it and/or modify
    20  it under the terms of the GNU General Public License as published by
    21  the Free Software Foundation; either version 2 of the License, or
    22  (at your option) any later version.
    23  .
    24  This program is distributed in the hope that it will be useful,
    25  but WITHOUT ANY WARRANTY; without even the implied warranty of
    26  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
    27  GNU General Public License for more details.
    28  .
    29  You should have received a copy of the GNU General Public License along
    30  with this program; if not, write to the Free Software Foundation, Inc.,
    31  51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
    32  .
    33  On Debian systems, the full text of the GNU General Public
    34  License version 2 can be found in the file
    35  '/usr/share/common-licenses/GPL-2'.

    (行番号は筆者による)

    ftpmasterにより提供され debian-devel-announce に投稿された手順書
    http://lists.debian.org/debian-devel-announce/2006/03/
    msg00023.html に従って下さい。

4.3. changelog

    これは必須のファイルで、Debian Policy Manual, 4.4 "debian/
    changelog"で既定された特別な書式となっています。この書式は、dpkg
    やその他のプログラムが、パッケージのバージョン番号、リビジョン、
    ディストリビューション、緊急度 (urgency) を識別するために利用しま
    す。

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

    dh_makeがデフォルトを生成し、以下のようになっています:

    1  gentoo (0.9.12-1) unstable; urgency=medium
    2
    3   * Initial release. (Closes: #nnnn)  <nnnn is the bug number of your ITP>
    4
    5  -- Josip Rodin <joy-mg@debian.org>  Mon, 22 Mar 2010 00:37:31 +0100
    6

    (行番号は筆者による)

    1 行目はパッケージ名、バージョン、ディストリビューション、そして
    緊急度です。ここに書くパッケージ名はソースパッケージの名前と一致
    していなければなりません。またディストリビューションは unstable
    で、緊急度はlowより高くしてはいけません。:-)

    3-5 行目はログ項目で、このパッケージのリビジョンで行われた変更を
    記述します (アップストリームプログラムそのものの変更点ではありま
    せん - その目的のためには、アップストリーム作者によって作成され、
    /usr/share/doc/gentoo/changelog.gzとしてインストールされる専用の
    ファイルが存在しています)。ITP (Intent To Package) バグレポート番
    号を 12345 と仮定しましょう。新しい行は * (アスタリスク)で始まる
    最初の行の直前に挿入します。この操作は dch(1) を使うと便利ですが
    、テキストエディタを使って実行してももちろん構いません。

    パッケージの完成前にパッケージが間違ってアップロードされることを
    防ぐために、ディストリビューションの値を無効な値 UNRELEASED に変
    更するよう推奨します。

    最終的にこんなふうになります:

    1  gentoo (0.9.12-1) UNRELEASED; urgency=low
    2
    3   * Initial Release. Closes: #12345
    4   * This is my first Debian package.
    5   * Adjusted the Makefile to fix $(DESTDIR) problems.
    6
    7  -- Josip Rodin <joy-mg@debian.org>  Mon, 22 Mar 2010 00:37:31 +0100
    8

    (行番号は筆者による)

    すべての変更に満足しそれらを changelog 記録した時点で、ディストリ
    ビューションの値を UNRELEASED からターゲットディストリビューショ
    ンの値 unstable (もしくは場合に依っては experimental) へと変更す
    べきです。^[36]

    changelogの更新については、8章パッケージの更新で詳しく説明します
    。

4.4. rules

    さて、今度は dpkg-buildpackage(1) が実際にパッケージを作成するた
    めに使うルールについて見ていきましょう。このファイルは、もうひと
    つの Makefile といった存在ですが、アップストリームソースに含まれ
    るそれとは違います。debian ディレクトリーに含まれる他のファイルと
    は異なり、このファイルには実行可能属性が付与されています。

4.4.1. rules ファイルのターゲット

    他の Makefile 同様、全ての rules ファイルはいくつかのルールから成
    り立っていて、そのそれぞれにターゲットと実行方法が規定されます。^
    [37] 新規のルールは最初のカラムにそのターゲット宣言をすることで始
    まります。それに続く TAB コード (ASCII 9) で始まる数行はそのレシ
    ピを規定します。空行と # (ハッシュ) で始まる行はコメント行として
    扱われ無視されます。^[38]

    実行したいルールは、そのターゲット名をコマンドラインの引数として
    実行します。例えば、 debian/rules build や fakeroot make -f
    debian/rules binary は、それぞれ build や binary ターゲットのルー
    ルを実行します。

    ターゲットについて簡単に説明します:

      * clean ターゲット: ビルドツリー内にある、生成されたりコンパイ
        ルされたり役に立たなかったりする全てのファイルをクリーンしま
        す。(必須)

      * build ターゲット: ソースをビルドして、ビルドツリー内にコンパ
        イルしたプログラムと書式に落とし込んだドキュメントをビルドし
        ます。(必須)

      * build-arch ターゲット: ソースをビルドして、ビルドツリー内にア
        ーキテクチャーに依存したコンパイルしたプログラムをビルドしま
        す。(必須)

      * build-indep ターゲット: ソースをビルドして、ビルドツリー内に
        アーキテクチャーに依存しない書式に落とし込んだドキュメントを
        ビルドします。(必須)

      * install ターゲット: debianディレクトリー以下にある各バイナリ
        ーパッケージのファイルツリーにファイルをインストールします。
        定義されている場合は、binary*ターゲットは実質的にこのターゲッ
        トに依存します。(任意)

      * binary ターゲット: 全てのバイナリーパッケージを作ります。(実
        質的には binary-arch と binary-indep の組み合わせ)(必須)^[39]

      * binary-arch ターゲット: 親ディレクトリーにアーキテクチャーに
        依存したバイナリーパッケージ (Architecture: any)を作ります。
        (必須)^[40]

      * binary-indep ターゲット: 親ディレクトリーにアーキテクチャーに
        依存しないパッケージ (Architecture: all) を作ります。(必須)^
        [41]

      * get-orig-source ターゲット: アップストリームアーカイブのサイ
        トから最新のバージョンのオリジナルソースパッケージを取得しま
        す。(任意)

    今は少々圧倒されているかもしれませんが、dh_make がデフォルトとし
    て作成する rules ファイルを調べると、状況はとても簡単です。

4.4.2. デフォルトのrulesファイル

    最新のdh_makeはdh コマンドでシンプルかつパワフルなrulesファイルを
    作ってくれます:

     1 #!/usr/bin/make -f
     2 # See debhelper(7) (uncomment to enable)
     3 # output every command that modifies files on the build system.
     4 #DH_VERBOSE = 1
     5
     6 # see FEATURE AREAS in dpkg-buildflags(1)
     7 #export DEB_BUILD_MAINT_OPTIONS = hardening=+all
     8
     9 # see ENVIRONMENT in dpkg-buildflags(1)
    10 # package maintainers to append CFLAGS
    11 #export DEB_CFLAGS_MAINT_APPEND  = -Wall -pedantic
    12 # package maintainers to append LDFLAGS
    13 #export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed
    14
    15
    16 %:
    17         dh $@

    (筆者が行番号を追加しコメントは一部削除した。実際のrulesファイル
    では、行頭の空白はTABコードです。)

    1行目はシェルやパールスクリプトでお馴染みの表現です。オペレーティ
    ングシステムに/usr/bin/makeで処理するように指示しています。

    4 行目のコメントを外し　DH_VERBOSE 変数を 1 に設定すれば、dh コマ
    ンドがどの dh_* コマンドを実行しているかを出力するようにできます
    。必要であればここに、export DH_OPTIONS=-vという行を追加すれば、
    dh_*コマンドが、dh_*によって実行されたコマンドを出力します。この
    単純な rules ファイルが影で何をしているのかを理解し、その問題デバ
    ッグの際の助けとなるでしょう。この新しい dh がdebhelper ツールの
    中核から設計され、あなたに対して一切隠し事をしません。

    16 と 17 行目は、パターンルールを用いて非明示的ルールで全てが行わ
    れる場所です。パーセント記号「%」は「いかなるターゲット」を意味し
    、ターゲットの名前を引数に dh という単一プログラムを実行します。^
    [42] dh コマンドは、引数によって、適切なシーケンスで dh_* プログ
    ラムを走らせるラッパースクリプトです。^[43]

      * debian/rules clean は dh cleanを実行し、そしてそれは以下を実
        行します:

        dh_testdir
        dh_auto_clean
        dh_clean

      * debian/rules build は dh build を実行します。実行する順番は以
        下の通りです:

        dh_testdir
        dh_auto_configure
        dh_auto_build
        dh_auto_test

      * fakeroot debian/rules binary は^[44]、fakeroot dh binaryを実
        行します。実行する順番は以下の通りです:

        dh_testroot
        dh_prep
        dh_installdirs
        dh_auto_install
        dh_install
        dh_installdocs
        dh_installchangelogs
        dh_installexamples
        dh_installman
        dh_installcatalogs
        dh_installcron
        dh_installdebconf
        dh_installemacsen
        dh_installifupdown
        dh_installinfo
        dh_installinit
        dh_installmenu
        dh_installmime
        dh_installmodules
        dh_installlogcheck
        dh_installlogrotate
        dh_installpam
        dh_installppp
        dh_installudev
        dh_installwm
        dh_installxfonts
        dh_bugfiles
        dh_lintian
        dh_gconf
        dh_icons
        dh_perl
        dh_usrlocal
        dh_link
        dh_compress
        dh_fixperms
        dh_strip
        dh_makeshlibs
        dh_shlibdeps
        dh_installdeb
        dh_gencontrol
        dh_md5sums
        dh_builddeb

      * fakeroot debian/rules binary-arch は fakeroot dh binary-arch
        を実行します。fakeroot dh binary の全てのコマンドに -a オプシ
        ョンをつけた場合と同じことを行います。

      * fakeroot debian/rules binary-indep は fakeroot dh
        binary-indep を実行します。同様のコマンドはfakeroot dh binary
        ですが、dh_strip、dh_makeshlibs、dh_shlibdeps は実行せず、残
        りのコマンドには-i オプションを付加して実行します。

    dh_*は、名前からその機能がわかるようなものばかりです。^[45]　ここ
    では、Makefileをもとに作られたビルド環境を前提にして、(超)簡単な
    説明を行う価値がある特筆すべき項目いくつかについて述べます: ^[46]

      * dh_auto_cleanは、Makefile に distclean ターゲットがあれば以下のコ
        マンドを通常実行します。^[47]

        make distclean

      * dh_auto_configureは、./configureがあれば以下のコマンドを通常実行
        します。 (読みやすくするために引数は省略しました)

        ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var ...

      * dh_auto_buildは、 Makefileがあれば、その最初のターゲットをビルド
        するために、以下のコマンドを通常実行します。
   
        make

      * dh_auto_test は、Makefile 中に test ターゲットがあれば、以下を通
        常実行します。^[48]

        make test

      * dh_auto_install は、Makefile 中に install ターゲットがあれば、以
        下のコマンドを通常実行します。 (読みやすくするために畳み込みまし
        た)。

        make install \
          DESTDIR=/path/to/package_version-revision/debian/package

    fakeroot コマンドを必要とするターゲットは dh_testroot を含みます
    。このコマンドは、ルートのふりをしなければエラーで終了します。

    dh_make によって作成された rules ファイルについて理解すべきことは
    、これは単なる提案ということです。もっと複雑なパッケージ以外のほ
    ぼ全てに有効ですが、必要に応じてカスタマイズをすることを遠慮して
    はいけません。

    install は、必須ターゲットではありませんがサポートはされています
    。fakeroot dh install は fakeroot dh binary のように振る舞います
    が、dh_fixperms の後で停止します。

4.4.3. rules ファイルのカスタマイズ

    新しいdhコマンドで作成されたrulesファイルをカスタマイズする方法は
    何通りもあります。

    dh $@ コマンドは以下の方法でカスタマイズできます: ^[49]

      * dh_python2 コマンドのサポートを追加します。(Pythonに最適の選
        択。)^[50]

          + python パッケージを Build-Depends に含めます。

          + dh $@ --with python2を使用します。

          + これは pythonフレームワークを使用してPythonモジュールを取
            り扱います。

      * dh_pysupport コマンドのサポートを追加します。(非推奨)

          + python-support を Build-Depends に含めます。

          + dh $@ --with pysupportを使用します。

          + これでpython-supportフレームワークを使用してPythonモジュ
            ールを利用できます。

      * dh_pycentral コマンドのサポートを追加します。(非推奨)

          + Build-Depends に、python-central パッケージを含めます。

          + 代わりにdh $@ --with python-centralを使用します。

          + これでdh_pysupportコマンドも無効化されます。

          + これでpython-centralフレームワークを使用してPythonモジュ
            ールを利用できます。

      * dh_installtex コマンドのサポートを追加します。

          + Build-Depends に、tex-commonパッケージを含めます。

          + 代わりにdh $@ --with texを使用します。

          + これで、TeXによるType1フォント、ハイフネーションパターン
            、またはフォーマットが登録されます。

      * dh_quilt_patch と dh_quilt_unpatch コマンドのサポートを追加し
        ます。

          + Build-Depends に、quilt パッケージを含めます。

          + 代わりにdh $@ --with quiltを使用します。

          + 1.0 フォーマットのソースパッケージの debian/patches ディ
            レクトリー内にあるファイルを用いて、アップストリームソー
            スにパッチを当てたり外したりできます。

          + もし新規の 3.0 (quilt) ソースパッケージフォーマットを使用
            している場合、これは不要です。

      * dh_dkms コマンドのサポートを追加します。

          + Build-Depends に、dkms パッケージを含めます。

          + 代わりにdh $@ --with dkmsを使用します。

          + カーネルモジュールパッケージによる DKMS の使用を正しく処
            理します。

      * dh_autotools-dev_updateconfig と 
        dh_autotools-dev_restoreconfig コマンドのサポートを追加します
        。

          + Build-Depends に、autotools-dev パッケージを含めます。

          + 代わりに dh $@ --with autotools-dev を使用します。

          + これでconfig.subとconfig.guessをアップデートおよびレスト
            アします。

      * dh_autoreconf と dh_autoreconf_clean コマンドのサポートを追加
        します。

          + Build-Depends に、dh-autoreconf パッケージを含めます。

          + 代わりにdh $@ --with autoreconfを使用します。

          + これは、ビルド後にGNUビルドシステムのファイルのアップデー
            トおよびレストアを行います。

      * dh_girepository コマンドのサポートを追加します。

          + Build-Depends に、gobject-introspection パッケージを含め
            ます。

          + 代わりにdh $@ --with girを使用します。

          + これは GObject イントロスペクションデータを提供しているパ
            ッケージの依存関係を計算し、パッケージ依存関係用に $
            {gir:Depends} 代替変数を生成します。

      * bash 補完機能のサポートを追加します。

          + Build-Depends に、bash-completion パッケージを含めます。

          + 代わりにdh $@ --with bash-completionを使用します。

          + このコマンドを使用すると、bash 補完機能から、 debian/
            package.bash-completion の設定を使うことができるようにな
            ります。

    新しい dh コマンドにより起動される多くの dh_* コマンドは、debian
    ディレクトリー内にある対応する設定ファイルによりカスタマイズする
    ことが可能です。そのような機能のカスタマイズ方法については、 5章
    debianディレクトリーにあるその他のファイルとコマンドごとの
    manpage を参照してください。

    dhコマンドによって呼び出されるdh_*コマンドの中には、特定の引数で
    実行したり、それらを追加のコマンドとともに実行したり、スキップし
    たりする必要があることがあります。そのような場合は、変更したいdh_
    fooコマンドについて、override_dh_foo ターゲットを rules ファイル
    に追記してください。簡単に説明すると、このターゲットはかわりにこ
    のコマンドを使用するという意味です。^[51]

    ここでは簡単に説明を行いましたが、通常以外のケースを処理するため
    、dh_auto_*コマンドは、もっと複雑なことを実行することを覚えておい
    てください。そのため、override_dh_auto_cleanターゲット以外は、
    override_dh_* ターゲットを使用して、簡素化された別のコマンドで代
    用するのは感心しません。debhelper の賢い機能を骨抜きにしてしまう
    からです。

    例えば、最近の Autotools を用いた gentooパッケージに関して、その
    設定情報を通常の /etc ディレクトリーではなく、/etc/gentoo ディレ
    クトリーに置きたい場合には、dh_auto_configure コマンドが ./
    configure コマンドに与えるデフォルトの引数 --sysconfig=/etc を以
    下のようにしてオーバーライドできます:

    override_dh_auto_configure:
            dh_auto_configure -- --sysconfig=/etc/gentoo

    --以下の引数は、自動実行されるプログラムの引数に付け足されます。
    dh_auto_configure コマンドは、引数--sysconfigのみをオーバーライド
    しその他の良く配慮された ./configure 引数には触れないため、./
    configure コマンドをここに使うより優れています。

    もしも gentoo のソースをビルドするためにその Makefile に build タ
    ーゲットを指定する必要がある場合、これを有効とするため、^[52]
    override_dh_auto_build ターゲットを作らなければなりません。

    override_dh_auto_build:
            dh_auto_build -- build

    dh_auto_buildコマンドのデフォルトで与えられた引数すべてに build
    引数を加えたものとともに、$(MAKE) を確実に実行します。

    もし、Debianパッケージのためにソースをクリーンするのに gentoo の
    ソースの Makefile が、Makefile 中の distclean や clean ターゲット
    の代わりに packageclean ターゲットを指定する必要がある場合には、
    override_dh_auto_clean ターゲットを作るとそれが可能になります。

    override_dh_auto_clean:
            $(MAKE) packageclean

    もし、gentooのソースのMakefileが、testターゲットを含み、Debianパ
    ッケージをビルドする過程で実行されたくない場合は、空の
    override_dh_auto_testターゲットを作ることで、スキップできます。

    override_dh_auto_test:

    もし、gentooパッケージに、普通ではないFIXESというアップストリーム
    のチェンジログファイルがある場合、 dh_installchangelogsはデフォル
    トではそのファイルをインストールしません。このファイルをインスト
    ールするには、FIXESを引数として、dh_installchangelogsに渡してやる
    必要があります。^[53]

    override_dh_installchangelogs:
            dh_installchangelogs FIXES

    この新しい dh コマンドを使う際には、get-orig-source ターゲットを
    除き、「rules ファイルのターゲット」にあるような明示ターゲット指
    定の正確な影響が把握するのが難しいかもしれません。明示ターゲット
    は、override_dh_* ターゲットおよび完全に独立したターゲットに限定
    して下さい。


---------------------------------------------------------------------

    ^[27] 自明な場合、本章では debian ディレクトリー中のファイルは、
    前に付く debian/ を省略し簡明に表記しています。

    ^[28] Debian Policy Manual, 2.4 "Sections" と List of sections in
    sid を参照下さい。

    ^[29] Debian Policy Manual, 2.5 "Priorities" を参照下さい。

    ^[30] Debian Policy Manual, 7.7 "Relationships between source and
    binary packages - Build-Depends, Build-Depends-Indep,
    Build-Conflicts, Build-Conflicts-Indep" を参照下さい。

    ^[31] この少し変な状況はDebian Policy Manual, Footnotes 55で詳し
    く説明されている特徴です。これは、debian/rules ファイル内の dh コ
    マンドではなく、dpkg-buildpackage に起因します。同様の状況は auto
    build system for Ubuntu にも当てはまります。

    ^[32] 詳細は Debian Policy Manual, 5.6.8 "Architecture" を参照下
    さい。

    ^[33] Debian Policy Manual, 7 "Declaring relationships between
    packages" を参照下さい。

    ^[34] これらの説明は英語です。これらの説明の翻訳は The Debian
    Description Translation Project - DDTP によって提供されています。

    ^[35] Developer's Reference, 6.2.5. "Version Control System
    location" を参照下さい。

    ^[36] もし dch -r コマンドを使ってこの最終変更をする場合には、エ
    ディターにより changelog ファイルを明示的に保存して下さい。

    ^[37] Debian Reference, 12.2 "Make" から Makefile の書き方を学び
    始められます。http://www.gnu.org/software/make/manual/html_node/
    index.html もしくは non-free のアーカイブエリアにある make-doc パ
    ッケージに完全な説明書があります。

    ^[38] Debian Policy Manual, 4.9 "Main building script: debian/
    rules" に詳細に説明されています。

    ^[39] このターゲットは例えば、「完全な（再）ビルド」などで、
    dpkg-buildpackageが使用します。

    ^[40] このターゲットは例えば、「オートビルダー」などで、
    dpkg-buildpackage -Bが使用します。

    ^[41] このターゲットは、 dpkg-buildpackage -Aが使用します。

    ^[42] これは新しい debhelper v7+ の機能です。このデザインコンセプ
    トはDebConf9で debhelper アップストリームによって Not Your
    Grandpa's Debhelper として提示されました。lenny の dh_make は、必
    須となる明示されたターゲットごとに、もっと複雑な rules ファイルと
    dh_* スクリプトを量産し、最初にパッケージ化した際の状態に凍結して
    いました。新しい dh コマンドは、もっとシンプルで、旧来の「手動」
    の雑用から開放してくれます。その上、override_dh_* ターゲットがあ
    るのでカスタマイズする利便性は失われていません。詳しくは「rules
    ファイルのカスタマイズ」を参照してください。これは、debhelper パ
    ッケージがもとになっており、cdbs のようにパッケージのビルドプロセ
    スを難読化することはありません。

    ^[43] You can verify the actual sequences of dh_* programs
    invoked for a given target without really running them by
    invoking dh target --no-act or debian/rules -- 'target --no-act'.

    ^[44] 以下の例は、自動的に python サポートコマンドが起動するのを
    避けるために、あなたの debian/compat には 9 以下の値が入っている
    と仮定しています。

    ^[45] dh_*スクリプトが、実際に何をして、どのようなオプションがあ
    るのかを知りたい場合は、debhelper のマニュアルにある該当ページを
    参照してください。

    ^[46] これらのコマンドは、dh_auto_build --listを実行するとリスト
    される setup.py のような他のビルド環境もサポートします。

    ^[47] 実際には、Makefile 中の distclean、realclean、 clean のうち
    、最初に利用可能なものを探し実行します。

    ^[48] Makefile 中の test か check のうち、最初に利用可能なものを
    見つけ実行します。

    ^[49] もし、パッケージが /usr/share/perl5/Debian/Debhelper/
    Sequence/custom_name.pmファイルをインストールする場合、そのカスタ
    マイズの機能を dh $@ --with custom-nameで有効にしなければなりませ
    ん。

    ^[50] dh_pysupport や dh_pycentral コマンドよりもdh_python2コマン
    ドが好まれます。dh_pythonコマンドは使用しないでください。

    ^[51] lennyでは、dh_*スクリプトの挙動を変えたい場合、rulesファイ
    ル内の該当する行を見つけ出し、調整していました。

    ^[52] 引数なしの dh_auto_buildは、Makefile の最初のターゲットを実
    行します。

    ^[53] debian/changelog と debian/NEWS は常に自動でインストールさ
    れます。アップストリームの変更履歴は、ファイル名を小文字に変換し
    、changelog、changes、changelog.txt、changes.txtのいずれかと一致
    するものを見つけます。

第5章 debianディレクトリーにあるその他のファイル

    The dh_make command had major updates since this old document was
    written. So some parts of this document aren't applicable any
    more.

    最新の内容とより実用的な例でこの入門書を書き換えたものが Guide
    for Debian Maintainers として入手できます。この新しい入門書を第一
    次的な入門書として使ってください。

    The debmake command is used in place of the dh_make command in my
    new Guide for Debian Maintainers.

    debhelperがパッケージのビルド中に行うことは、オプションの設定ファ
    イルを debian ディレクトリーに置けばコントロールできます。この章
    では、設定ファイルの機能と書式を概説します。パッケージングのガイ
    ドラインについての詳細は Debian Policy Manual と Debian
    Developer's Reference を参照してください。

    The dh_make command will create some template configuration files
    under the debian directory. Take a look at all of them.

    自明な場合、本章では debian ディレクトリー中のファイルは、前に付
    く debian/ を省略し簡明に表記しています。

    dh_makeコマンドは、一部の debhelper用の設定テンプレートファイルを
    作らないことがあります。その場合、自分でエディターを使いそれらを
    作成しなければなりません。

    設定ファイルを有効にしたい際は、以下を実行して下さい:

      * packageの代わりに、実際のバイナリーパッケージの名前に設定ファ
        イルをリネームしてください。

      * 必要に応じて、テンプレートファイルの中身を書き換えます。
   
      * 不要なテンプレートファイルは削除してください。

      * 必要であれば、control ファイル(参照「control」)を変更します。

      * 必要ならrulesファイル(参照「rules」)を編集してください。

    package をプリフィックスとして持たない、例えば install のような
    debhelper の設定ファイルは、最初のバイナリーパッケージへ適用され
    ます。バイナリーパッケージが多数ある場合、package-1.install、
    package-2.install、等のように、パッケージ名を設定ファイルのプリフ
    ィックスとすることで指定できます。

5.1. README.Debian

    パッケージに関して、何か特別にユーザーに知らせなければならない情
    報や、オリジナルのソフトウェアと作成したDebianパッケージとの相違
    点があればここに記述します。

    以下はdh_makeがデフォルトとして生成するものです:

    gentoo for Debian
    -----------------
    <possible notes regarding this package - if none, delete this file>
     -- Josip Rodin <joy-mg@debian.org>, Wed, 11 Nov 1998 21:02:14 +0100

    もし、ドキュメントがなければこのファイルを削除してください。詳し
    くは dh_installdocs(1)を参照してください。

5.2. compat

    compat ファイルは、debhelper の互換性レベルを規定します。現段階で
    は、以下のように debhelper v10 に設定しましょう:

    $ echo 10 > debian/compat

    一定の環境下では旧システムとのコンパチビリティーのためにcompat レ
    ベル v9 を使ってよろしい。しかし、v9 以下の如何なるレベルを使うこ
    とは勧められないし、新規パッケージに用いることは避けるべきです。

5.3. conffiles

    大変な時間と労力を費やしてプログラムをカスタマイズしても、一回の
    アップグレードであなたの変更をあちこち上書きされてしまうとうんざ
    りします。このような設定ファイルを conffile と記録しておくことで
    、Debianはこの問題を解決しました。^[54] パッケージをアップグレー
    ドする際に、あなたは古い設定ファイルをキープしたいかかどうかを尋
    ねられます。

    dh_installdeb(1) は自動的に /etc ディレクトリー以下のファイルを全
    て conffiles とみなすので、あなたのプログラムが他のディレクトリー
    に conffiles を持たない場合は特に指定する必要はありません。ほとん
    どのパッケージの場合、/etc 以下にのみ conffiles がある（そうある
    べきです）ので、このファイルの存在は不要です。

    あなたのプログラムが設定ファイルを利用する場合であっても、その設
    定ファイルがプログラム自身によって頻繁に上書きされるような場合に
    は、パッケージをアップグレードするたびに dpkg によって設定ファイ
    ルの変更について確認を求められることになるので、その設定ファイル
    を conffiles に登録しないほうが良いでしょう。

    あなたのパッケージングするプログラムが、ユーザーに /etc ディレク
    トリーの中にある設定ファイルを編集することを要求する場合、dpkg を
    黙らせるために conffiles として登録しない良く使われる方法が 2 つ
    あります:

      * /etc ディレクトリー中に、メンテナースクリプトによって生成され
        た /var ディレクトリー以下のファイルにシンボリックリンクを張
        る。

      * /etc ディレクトリーの中にメンテナースクリプトによってファイル
        を生成する。

    メンテナースクリプトについての詳細は、「{pre,post}{inst,rm}」を参
    照してください。

5.4. package.cron.*

    パッケージが正しく動作するために、定期的にあるタスクを実行する必
    要がある場合は、これらのファイルで設定します。毎時間、毎日、毎週
    、または指定した時間に定期的タスクを実行するように指定することが
    できます。ファイル名は以下です:

      * cron.hourly - /etc/cron.hourly/packageとしてインストール: 1時
        間ごとに実行する。

      * cron.daily - /etc/cron.daily/packageとしてインストール: 1日に
        1度実行。

      * cron.weekly - /etc/cron.weekly/packageとしてインストール: 1週
        間に1度実行。

      * package.cron.monthly - /etc/cron.monthly/package:としてインス
        トール: 1ヶ月に1度実行。

      * package.cron.d - /etc/cron.d/packageとしてインストール: どの
        時間でも指定可能。

    上記のファイルの書式はシェルスクリプトです。package.cron.d は違い
    、crontab(5)の書式になります。

    ログローテーションの設定には明示的な cron.* は必要ありません。こ
    れについてはdh_installlogrotate(1) および logrotate(8)を参照して
    ください。

5.5. dirs

    このファイルにはパッケージが必要としているのに、なぜか通常のイン
    ストール手順 (dh_auto_install によって呼び出される make install
    DESTDIR=...) では作成されないディレクトリーを指定します。通常、こ
    れは Makefile に問題があることを示唆しています。

    installファイルに書かれてるファイルは最初にディレクトリーを作成す
    る必要はありません。「install」を参照してください。

    まずは試しにインストールしてみて、なにか問題が起きた場合にのみ使
    うべきでしょう。 dirs ファイル中のディレクトリー名の頭にスラッシ
    ュが付かない事に注意してください。

5.6. package.doc-base

    もしあなたのパッケージがマニュアルページや info 形式の文書以外に
    付属文書を含む場合、 doc-base ファイルを使ってそれらを登録し、ユ
    ーザーがそれらの付属文書を、例えばdhelp(1) や dwww(1)、あるいは 
    doccentral(1) コマンドなどで参照できるようにしましょう。

    これには通常、/usr/share/doc/packagename/の中に収められるような
    HTML、PS、およびPDFなどの形式の付属文書が含まれます。

    例えば、gentoo の gentoo.doc-base ファイルは次のようになります:

    Document: gentoo
    Title: Gentoo Manual
    Author: Emil Brink
    Abstract: This manual describes what Gentoo is, and how it can be used.
    Section: File Management
    Format: HTML
    Index: /usr/share/doc/gentoo/html/index.html
    Files: /usr/share/doc/gentoo/html/*.html

    このファイルの書式についてはinstall-docs(8)および doc-base パッケ
    ージが提供するローカルコピー　/usr/share/doc/doc-base/
    doc-base.html/index.html にある doc-base のマニュアルを参照してく
    ださい。

    追加ドキュメントのインストールについて、詳細は「指定場所へのファ
    イルのインストール」を見てください。

5.7. docs

    このファイルには、dh_installdocs(1)を使ってパッケージ生成用の一時
    的なディレクトリーにインストールするために、パッケージに付属する
    資料のファイル名を指定してください。

    デフォルトでは、ソースディレクトリーのトップレベルに存在する BUGS
    、 README*、 TODO などの名前を持つファイル全てを含みます。

    gentoo に関していくつか他のファイルが含まれます:

    BUGS
    CONFIG-CHANGES
    CREDITS
    NEWS
    README
    README.gtkrc
    TODO

5.8. emacsen-*

    パッケージをインストールする際にバイトコンパイル可能な Emacs ファ
    イルがあなたのパッケージに含まれている場合、これらの emacsen-* フ
    ァイルを利用してそれを設定することができます。

    これらのファイルはdh_installemacsen(1)によってパッケージ作成用の
    一時的なディレクトリーにインストールされます。

    不要ならこのファイルを削除してください。

5.9. package.examples

    dh_installexamples(1)コマンドはこのディレクトリーに列挙されたファ
    イルを例としてインストールします。

5.10. package.init と package.default

    もしあなたのパッケージがデーモンであり、システムの起動時に自動的
    に動作させる必要があるとしたら、私が最初に勧めたことをあなたはま
    るっきり無視してしまったわけですよね。そうでしょ ?:-)

    Please read dh_installinit(1) dh_installsystemd(1) to provide
    startup script.

    The package.default file will be installed as /etc/default/
    package. This file sets defaults that are sourced by the init
    script. This package.default file is most often used to set some
    default flags or timeouts. If your init script has certain
    configurable features, you can set them in the package.default
    file, instead of in the init script itself.

    アップストリームプログラムが init スクリプト用ファイルを提供する
    場合、それを使用するかしないかは自由です。もしアップストリームか
    らの init スクリプトを使わないのであれば package.init に新しいの
    を作成しましょう。アップストリームのinit スクリプトが問題なく正し
    い場所にインストールされるとしても、rc* シンボリックリンクの設定
    は必要です。そのためには、rules ファイルに以下を追加して、
    dh_installinit をオーバーライドしましょう:

    override_dh_installinit:
            dh_installinit --onlyscripts

    不要なら、このファイルを削除してください。

5.11. install

    パッケージにとってインストールが必要なファイルがあるにも関わらず
    、 make install ではインストールされない場合、そのファイル名とフ
    ァイルを置く目的地を install ファイルに記述します。そうすると、
    dh_install(1) によってそれらのファイルがインストールされます。^
    [55] まずは使えそうな別のツールがないかどうかを調べましょう。例え
    ば、ドキュメントはこのファイルではなくdocsファイルにあるべきです
    。

    install ファイルはインストールされるファイルごとに 1 行必要としま
    す。ファイル名（ビルドディレクトリーのトップを基点とした相対パス
    ）、スペース、インストールするディレクトリー名（インストールディ
    レクトリーを基点とした相対パス）という書式です。例えば、バイナリ
    ー src/bar のインストールを忘れた場合などに、 install ファイルの
    項目は以下のように記述します:

    src/bar usr/bin

    上記によって、パッケージがインストールされたときに、/usr/bin/bar
    というバイナリーファイルが存在することになります。

    また、この install ファイルは相対パスが変わらない場合、インストー
    ルディレクトリーの指定を省略することもできます。この書式はビルド
    した結果を、package-1.install, package-2.install などを使用し、複
    数のバイナリーパッケージに分割するような、大規模なパッケージで使
    われます。

    dh_install コマンドはもし、カレントディレクトリーでファイルが見つ
    からなかった場合は、(または、--sourcedir で探すように指示したディ
    レクトリー内で見つからなかった場合は)フォールバックして debian/
    tmp内を検索します。

5.12. package.info

    パッケージにinfoページがある場合、package.info にそれらを挙げて、
    dh_installinfo(1) を使用してインストールします。

5.13. package.links

    パッケージメンテナーとしてパッケージビルドディレクトリー中に追加
    のシンボリックリンクを作成する必要がある場合、リンク元とリンク先
    の両方のフルパスを package.links ファイル中にリストすることで 
    dh_link(1) コマンドでそれらをインストールするべきです。

5.14. {package.,source/}lintian-overrides

    ポリシーが例外を認めているにも関わらず、lintian が誤診断を報告し
    てきた場合、package.lintian-overridesかsource/lintian-overrides
    を使って黙らせることができます。Lintian User's Manual (https://
    lintian.debian.org/manual/index.html) を読み、濫用は控えてくださ
    い。

    package.lintian-overrides は package と名づけられたパッケージのた
    めのファイルで、dh_lintian コマンドによって usr/share/lintian/
    overrides/package にインストールされます。

    source/lintian-overridesはソースパッケージのためのファイルです。
    これはインストールされません。

5.15. manpage.*

    プログラムはマニュアルページが必ず必要です。もし無いなら作らなけ
    ればなりません。dh_make コマンドはマニュアルページのテンプレート
    を作成します。マニュアルページがないコマンドのために、コピー、編
    集する必要があります。不要なテンプレートファイルを削除するのを忘
    れないようにしてください。

5.15.1. manpage.1.ex

    マニュアルページは通常、nroff(1)で書かれています。manpage.1.exの
    テンプレートもnroffで書かれています。これらのファイルをどう編集す
    るのかについて、簡単な説明がman(7)にあります。

    最終的なマニュアルページのファイル名は、解説されているプログラム
    名を含めなければなりません。ここでは、ファイル名を manpage から
    gentoo に変更しましょう。ファイル名は、.1 というサフィックスも含
    みます。これは、このマニュアルページはユーザーコマンドのものだ、
    という意味です。この部分を間違わないように気をつけてください。以
    下はマニュアルページのリストです:

    
    +---------------------------------------------------------------+
    |セクショ|      内容       |               ノート               |
    |   ン   |                 |                                    |
    |--------+-----------------+------------------------------------|
    |1       |ユーザーコマンド |実行可能なコマンドやスクリプト      |
    |--------+-----------------+------------------------------------|
    |2       |システムコール   |カーネルが提供するファンクション    |
    |--------+-----------------+------------------------------------|
    |3       |ライブラリーコー |システムライブラリーが提供するファン|
    |        |ル               |クション                            |
    |--------+-----------------+------------------------------------|
    |4       |特殊ファイル     |通常 /dev にある                    |
    |--------+-----------------+------------------------------------|
    |5       |ファイルフォーマ |例えば、/etc/passwdのフォーマット   |
    |        |ット             |                                    |
    |--------+-----------------+------------------------------------|
    |6       |ゲーム           |ゲームや他の他愛ないプログラム      |
    |--------+-----------------+------------------------------------|
    |7       |マクロパッケージ |manのマクロ等                       |
    |--------+-----------------+------------------------------------|
    |8       |システム管理     |普通rootが実行するプログラム        |
    |--------+-----------------+------------------------------------|
    |9       |カーネルルーチン |非標準のコールや内部コール          |
    +---------------------------------------------------------------+

    つまり、gentoo のマニュアルページは gentoo.1 となります。オリジナ
    ルのソースファイルに gentoo.1 というマニュアルページがなければ、
    アップストリームのドキュメントと例を元にして、manpage.1.ex という
    テンプレートファイルを編集し gentoo.1 というマニュアルページを作
    らなければなりません。

    各コマンドの --helpと--version 出力から help2manコマンドを用いて
    マニュアルページを作成することも可能です。^[56]

5.15.2. manpage.sgml.ex

    もし、nroffよりSGMLのほうが好みであれば、manpage.sgml.ex のほうを
    ひな型として使うこともできます。こちらの場合には、以下の手順が必
    要です:

      * ファイル名をgentoo.sgmlのような名前に変更します。

      * docbook-to-man パッケージのインストール

      * control ファイルの Build-Depends 行へ docbook-to-man を追加
   
      * rules ファイルに override_dh_auto_build ターゲットを追加しま
        す:

        override_dh_auto_build:
                docbook-to-man debian/gentoo.sgml > debian/gentoo.1
                dh_auto_build

5.15.3. manpage.xml.ex

    SGMLよりもXMLが好みであれば、manpage.xml.exをひな形として使うこと
    もできます。こちらの場合には、以下の手順が必要です:

      * ソースファイルの名前を、gentoo.1.xmlのような名前に変更します。

      * docbook-xsl パッケージと xsltproc のような XSLT プロセッサのイン
        ストール (推奨)

      * control ファイルの Build-Depends 行へ、docbook-xsl、docbook-xml、
        xsltproc の各パッケージを追加します。

      * rules ファイルに override_dh_auto_build ターゲットを追加します:
   
        override_dh_auto_build:
                xsltproc --nonet \
                 --param make.year.ranges 1 \
                 --param make.single.year.ranges 1 \
                 --param man.charmap.use.subset 0 \
                 -o debian/ \
        http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl\
                debian/gentoo.1.xml
                dh_auto_build

5.16. package.manpages

    パッケージにマニュアルページがある場合、package.manpages ファイル
    にそれらをリストして、dh_installman(1) を使用してインストールしま
    す。

    gentoo パッケージのマニュアルページとして docs/gentoo.1 をインス
    トールするには、以下のように gentoo.manpages ファイルを作成しま
    す:

    docs/gentoo.1

5.17. NEWS

    dh_installchangelogs(1)コマンドでインストールします。

5.18. {pre,post}{inst,rm}

    postinst や preinst や postrm や prerm ファイルは^[57]メンテナー
    スクリプトと呼ばれています。これらのスクリプトは、パッケージを管
    理するエリアに置かれ、インストール、アップグレード、削除される際
    にdpkgによって実行されます。

    新米メンテナーのうちは、問題になることが多いのでメンテナースクリ
    プトを直接編集しないようにしましょう。詳しくは Debian Policy
    Manual, 6 "Package maintainer scripts and installation procedure"
    を参照し、dh_make によって生成されるサンプルファイルに目を通して
    ください。

    もし私の忠告を無視して、メンテナースクリプトを直接編集した場合は
    、インストール、アップグレードだけでなく、削除とパージのテストも
    しっかり行ってください。

    新バージョンへのアップグレードは静かであるべきで、押し付けがまし
    くてはいけません。（現行ユーザーは、バグが直されたことや新機能が
    追加されたことで気づかない限りアップグレードに気づかないのが理想
    です。)

    アップグレードが出しゃばる必要がある場合 (例えば、構造がまったく
    異なる設定ファイルがホームディレクトリーに散在する場合など)、パッ
    ケージのデフォルトを(例えばサービスを停止する等の)安全側に設定し
    たり、最後の手段としてはポリシーに要求されるきちんとしたドキュメ
    ント (README.DebianとNEWS.Debian) を提供するなどの対策を考えるべ
    きです。アップグレード際にメンテナースクリプトで debconf ノートを
    呼び出したりしてユーザーに迷惑を掛けないでください。

    ucf パッケージは、メンテナースクリプトによって管理されているよう
    な conffiles とラベルされていないファイルに関して、ユーザーによっ
    て変更されたファイルを保存する conffileのような処理をする仕組みを
    提供します。この仕組みを使うとこれらに関する問題を最小化できます
    。

    これら、メンテナースクリプトはなぜ Debian を選ぶのかという理由の
    1 つでもあります。これらの仕組みで、ユーザーが迷惑がる原因となら
    ないよう細心の注意をはらいましょう。

5.19. package.symbols

    新米メンテナーにとってはライブラリーのパッケージは容易ではないし
    、避けるべき行為です。このように言いましたが、もしあなたのパッケ
    ージがライブラリーを含む場合には、debian/package.symbols ファイル
    を作成すべきです。「debian/package.symbols の管理」を参照下さい。

5.20. TODO

    dh_installdocs(1)コマンドでインストールします。

5.21. watch

    watch ファイルの書式は uscan(1) を参照してください。watch ファイ
    ルは、uscan ( devscriptsパッケージに含まれます) を設定し、最初ソ
    ースを入手したサイトを監視します。これは Debian パッケージトラッ
    カーサービスによっても使用されています。

    以下がその内容です:

    # watch control file for uscan
    version=3
    http://sf.net/gentoo/gentoo-(.+)\.tar\.gz debian uupdate

    通常、このwatchファイルでは、http://sf.net/gentoo の URL がダウン
    ロードされ、<a href=...> フォームへのリンクを検索します。リンクさ
    れた URL のベースネーム(最後の / から後の部分のみ)は Perl の正規
    表現 (perlre(1) 参照)パターン gentoo-(.+)\.tar\.gz に照らし合わさ
    れます。一致したファイルの中から、バージョンの番号が一番大きいも
    のがダウンロードされ、その後アップデートされたソースツリーを作成
    するために uupdate プログラムを実行します。

    他のサイトでは上記の通りですが、http://sf.net の SourceForge のダ
    ウンロードサービスは例外です。watchファイルが Perl の正規表現 ^
    http://sf\.net/ に一致する URL を含む場合、uscan プログラムが代わ
    りにhttp://qa.debian.org/watch/sf.php/ を使い、このルールを当ては
    めます。http://qa.debian.org/ の URL リダイレクトは http://sf.net
    /project/tar-name-(.+)\.tar\.gzを含むwatch ファイルを対象に安定し
    たリダイレクトを提供するよう設計されています。これにより、そこで
    周期的に変化する URL に関する問題を解決しています。

    ターボールの公開鍵電子署名をアップストリームが提供している際には
    、 uscan(1) 中に記載された pgpsigurlmangle オプションを用いてその
    正統性を検証することが望ましい。

5.22. source/format

    debian/source/formatファイルでは、ソースパッケージのための理想の
    書式を示すための行があります。 (完全なリストは、dpkg-source(1)を
    参照してください。)squeeze以降は、以下のどちらかになっているべき
    です:

      * 3.0 (native)：ネイティブ Debian パッケージ
   
      * 3.0 (quilt)：　それ以外の全て。

    新しい3.0 (quilt)の書式はquiltパッチによる変更を debian/patchesに
    記録します。そして、その変更は自動的にソースパッケージを展開する
    ときに適用されます。^[58]Debianの変更は、debianディレクトリー以下
    のファイル全てを含め、debian.tar.gzアーカイブに保存されています。
    この新しい書式は、特殊な方法を用いることなく、PGNアイコンなどのパ
    ッケージメンテナーによるバイナリーファイルを含めることが可能です
    。^[59]

    dpkg-sourceが3.0 (quilt)の書式でソースパッケージを展開する際、
    debian/patches/seriesに列挙されたパッチを自動的に適用します。
    --skip-patchesオプションで、展開時にパッチを適用しないようにでき
    ます。

5.23. source/local-options

    Debianをパッケージングする活動をVCSで管理したい場合、アップストリ
    ームのソースをトラックするためのブランチ(例: upstream)とDebianパ
    ッケージをトラックするための別のブランチ(Gitでの典型例: master)を
    作成します。後者の場合、新しいアップストリームのソースとマージす
    るのを簡単にするために、通常パッチの当てていないアップストリーム
    のソースをdebian/*ファイルと一緒に持っておきます。

    パッケージをビルドした後は、ソースのパッチは通常当てたままにされ
    ます。masterブランチにコミットする前に手動で quilt pop -a を実行
    してパッチを外す必要があります。debian/source/local-optionsファイ
    ルにunapply-patchesを書いておけば、自動的にパッチを外せます。この
    ファイルは生成されたソースパッケージには含まれず、ローカルビルド
    での挙動のみを変更します。このファイルはabort-on-upstream-changes
    も含むかもしれません (dpkg-source(1) 参照)。

    unapply-patches
    abort-on-upstream-changes

5.24. source/options

    ソースツリーの中の自動生成されるファイルはパッケージングする際に
    無意味で大きなパッチファイルを生成するのでとても厄介です。「rules
    ファイルのカスタマイズ」で説明したようにdh_autoreconf のようなカ
    スタムモジュールが本問題を解消するために存在します。

    dpkg-source(1) の --extend-diff-ignore オプション引数に Perl 正規
    表現を提供すると、ソースパッケージ生成時に自動生成ファイルへの変
    更を無視できます。

    この自動生成ファイルの問題の一般的解決策としてソースパッケージの
    source/options ファイル中に dpkg-source オプション引数を保存する
    事が出来ます。以下の例では、config.sub と config.guess と
    Makefile に関してパッチファイルの生成をスキップします。

    extend-diff-ignore = "(^|/)(config\.sub|config\.guess|Makefile)$"

5.25. patches/*

    古い　1.0　のソースフォーマットは、debian　内にパッケージメンテナ
    ンスファイルと、パッチファイルを含む単一の大きな　diff.gz　ファイ
    ルを作っていました。そのようなファイルは、ソースツリーの変更を後
    から調べたり、理解するのが非常に厄介でした。これはあまりいただけ
    ません。

    新しい 3.0 (quilt) は、quilt コマンドを使って、パッチを debian/
    patches/* に置きます。debian ディレクトリー以下に含まれているパッ
    チやその他のパッケージデータは、debian.tar.gz ファイルとしてパッ
    ケージングされます。dpkg-source コマンドは、quilt 形式のパッチデ
    ータを quilt パッケージなしで 3.0 (quilt) として扱えるので、quilt
    パッケージを Build-Depends に記載する必要はありません。^[60]

    quilt コマンドについてはquilt(1) で説明されています。ソースへの変
    更は、debian/patches ディレクトリー内 -p1 パッチファイルのスタッ
    クとして記録され、debian ディレクトリーの外のソースツリーには触れ
    ません。それらのパッチの順番は debian/patches/series ファイルに記
    録されます。パッチの適用 (=push)も、外す (=pop)のも、更新(=
    refresh)も、簡単にできます。 ^[61]

    3章ソースコードの変更では、debian/patchesに 3 つのパッチを作りま
    した。

    Debian のパッチは debian/patches にあるので、「quilt のセットアッ
    プ」の説明に従い、dquilt コマンドを正しく設定してください。

    誰かが(あなた自身も含みます) foo.patch というパッチを後から提供し
    た際の、3.0 (quilt) ソースパッケージの変更はとてもシンプルです:

    $ dpkg-source -x gentoo_0.9.12.dsc
    $ cd gentoo-0.9.12
    $ dquilt import ../foo.patch
    $ dquilt push
    $ dquilt refresh
    $ dquilt header -e
    ... describe patch

    新しい 3.0 (quilt) 形式で保存されるパッチには曖昧さがあってはいけ
    ません。それを保証するために、dquilt pop -a; while dquilt push;
    do dquilt refresh; done としてください。


---------------------------------------------------------------------

    ^[54] dpkg(1) and Debian Policy Manual, "D.2.5 Conffiles" を参照
    下さい。

    ^[55] filesファイルによって、dh_movefiles(1)コマンドが設定され、
    置換されます。

    ^[56] help2man が作成する仮のマニュアルページに、詳細なドキュメン
    トが info システムにあると記載されることに注意して下さい。info ペ
    ージ中にコマンドが無い場合は、help2man コマンドが生成したページを
    手動で修正するべきです。

    ^[57] {pre,post}{inst,rm} という bash 独自の短縮形をこれらのファ
    イル名の表記としていますが、システムシェルである dash との互換性
    のために、これらのメンテナースクリプトでは純粋な POSIX シンタック
    スを使うべきです。

    ^[58] ソースの書式を 3.0 (quilt) や 3.0 (native) に移行する際の注
    意点などは、DebSrc3.0 を参照下さい。

    ^[59] この新しいフォーマットは、複数のアップストリームの tar アー
    カイブやこの他の圧縮方法もサポートしています。詳細は本稿の範疇を
    超えるため割愛します。

    ^[60] パッチセットをメンテナンスするためのいくつかの方法が提案さ
    れ、Debian パッケージで使われていますが、quilt が推奨されています
    。他には、dpatch、dbs、cdbs、などがあります。これらの方法は、大抵
    debian/patches/* ファイルでパッチを管理しています。

    ^[61] スポンサーにパッケージのアップロードを頼む時にも、あなたが
    加えた変更に対するこのような明確な分離とドキュメントは、スポンサ
    ーによるパッケージのレビューを促進させるためにも、非常に重要です
    。

第6章パッケージのビルド

    最新の内容とより実用的な例でこの入門書を書き換えたものが Guide
    for Debian Maintainers として入手できます。この新しい入門書を第一
    次的な入門書として使ってください。

    これでパッケージをビルドする準備が整いました。

6.1. 完全な（再）ビルド

    完全なパッケージの（再）ビルドを行うには、以下を確実にインストー
    ルして下さい。

      * build-essentialパッケージ

      * Build-Dependsに挙げられているパッケージ(参照「control」)

      * Build-Depends-indepに挙げられているパッケージ(参照「control」
        )

    ソースディレクトリーで以下のコマンドを実行してください:

    $ dpkg-buildpackage -us -uc

    このコマンドはバイナリーパッケージとソースパッケージをビルドする
    作業をすべて行ってくれます。これには以下の作業が含まれます:

      * ソースツリーのクリーン (debian/rules clean)

      * ソースパッケージのビルド (dpkg-source -b)

      * プログラムのビルド (debian/rules build)
   
      * バイナリーパッケージのビルド (fakeroot debian/rules binary)

      * .dsc ファイルの作成

      * dpkg-genchanges を使用し .changesファイルを作成

    満足なビルド結果の場合には、debsign コマンドを用いてあなたの秘密
    GPG 鍵で .dsc と .changes ファイルを署名します。秘密フレーズを２
    回入力する必要があります。 ^[62]

    ノンネイティブパッケージの場合、パッケージビルド後の親ディレクト
    リー (~/gentoo) に以下のファイルが生成されているはずです:

      * gentoo_0.9.12.orig.tar.gz

        これは単に Debian 標準に合わせるために名前を変更しただけで、
        中身はオリジナルなソースコードの tar アーカイブです。これは元
        来、dh_make -f ../gentoo-0.9.12.tar.gz で作成されたということ
        を覚えておいてください。

      * gentoo_0.9.12-1.dsc

        これはソースコードの内容の概要です。このファイルはあなたの
        controlファイルから生成され、dpkg-source(1)によってソースを展
        開する際に使われます。

      * gentoo_0.9.12-1.debian.tar.gz

        この圧縮された tar アーカイブには、あなたのdebianディレクトリ
        ーの中身が含まれています。オリジナルのソースコードに行った変
        更や追加などの情報は全て debian/patches 内に、quilt パッチと
        して保存されます。

        上記 3 つのファイルを使えば誰でも簡単にあなたのパッケージをス
        クラッチからビルドすることができます。3 つのファイルを任意の
        場所にコピーし、dpkg-source -x gentoo_0.9.12-1.dscを実行する
        だけです。^[63]

      * gentoo_0.9.12-1_i386.deb

        これは、あなたが生成した完全なバイナリーパッケージです。他の
        全てのパッケージと同じく、dpkgを使ってインストールしたり削除
        したりできます。

      * gentoo_0.9.12-1_i386.changes

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

        パッケージの保守管理を続けていくと、挙動の変更や新機能の追加
        をすることがあります。あなたのパッケージをダウンロードする人
        は、このファイルを見れば何が変わったのか、一目でわかります。
        また、このファイルの中身は Debian アーカイブ管理プログラムに
        よって、debian-devel-changes@lists.debian.org メーリングリス
        トへ流されます。

    Debain FTP アーカイブにアップロードする前に、~/.gnupg/ ディレクト
    リー中にあるあなたの秘密 GPG 鍵で debsign コマンドを用いて
    gentoo_0.9.12-1.dsc と gentoo_0.9.12-1_i386.changes ファイルを署
    名しなければいけません。

    以下の ~/.devscripts ファイルを用いると、debsign コマンドはあなた
    が指定した秘密 GPG キー ID (パッケージをスポンサーする際に便利)
    で署名できます:

    DEBSIGN_KEYID=Your_GPG_keyID

    .dsc と .changes ファイルに記載されている長い数字の羅列は各ファイ
    ルの MD5/SHA1/SHA256 チェックサムです。パッケージをダウンロードし
    た人は、sha1sum(1)、sha256sum(1)を使って整合性をテストすることが
    できます。もし、数字が一致しない場合には、ファイルが壊れているか
    、あるいは何者かによって改ざんされていると分かるわけです。

6.2. オートビルダー

    Debian は、様々なアーキテクチャー上で buildd デーモンを走らせてい
    るオートビルダーネットワークによって、色々な移植版をサポートして
    います。あなたがそれらを明示的に使う必要はありませんが、パッケー
    ジがどうなるのかを知っておくと良いでしょう。それでは、あなたのパ
    ッケージがどのように異なるアーキテクチャー向けに再ビルドされるの
    かを見ていきましょう。^[64]

    Architecture: any のパッケージは、オートビルダーシステムによって
    再ビルドされます。それは、以下を確実にインストールします。

      * build-essentialパッケージ
   
      * Build-Dependsに挙げられているパッケージ (参照「control」)

    そして、ソースディレクトリーで次のコマンドを実行します:

    $ dpkg-buildpackage -B

    これは、別のアーキテクチャー上で、アーキテクチャー依存のバイナリ
    ーパッケージを生成する作業をすべて行ってくれます。これには以下の
    作業が含まれます:

      * ソースツリーのクリーン (debian/rules clean)

      * プログラムのビルド (debian/rules build)

      * アーキテクチャー依存のバイナリーパッケージをビルド(fakeroot
        debian/rules binary-arch)

      * gpg を使用したソース.dscファイルへの署名

      * dpkg-genchangesおよびgpgを使用したアップロード用.changesファ
        イルの生成と署名

    あなたのパッケージが他のアーキテクチャー用にも存在するのは、この
    ためです。

    Build-Depends-indepフィールドのパッケージは、通常のパッケージの場
    合はインストールを要求されますが (参照「完全な（再）ビルド」)、オ
    ートビルダーシステムでは、アーキテクチャー依存のパッケージのみを
    ビルドするのでこれらのインストールは必須ではありません。^[65] オ
    ートビルダーを使用した場合と普通のパッケージングとのこの違いによ
    り、debian/control ファイルの Build-Depends か
    Build-Depends-indep のどちらにパッケージを記載するかが決定されま
    す。(参照「control」)

6.3. debuildコマンド

    dpkg-buildpackageによるビルドプロセス周辺は、debuildによりさらに
    自動化できます。debuild(1)を参照してください。

    debuild コマンドは、Debian パッケージをビルドのあと静的チェックを
    する lintian コマンドを実行します。lintian コマンドは ~
    /.devscripts を用いて以下のようにカスタマイズできます:

    DEBUILD_DPKG_BUILDPACKAGE_OPTS="-us -uc -I -i"
    DEBUILD_LINTIAN_OPTS="-i -I --show-overrides"

    以下のようにすれば一般ユーザーアカウントから、簡単にソースをクリ
    ーンしパッケージを再ビルドできます:

    $ debuild

    ソースツリーのクリーンも簡単です:

    $ debuild -- clean

6.4. pbuilderパッケージ

    ビルド依存を確認するためのクリーンルーム (chroot) ビルド環境とし
    て、pbuilder パッケージが非常に便利です。^[66] これを使うことで、
    異なるアーキテクチャー向けに sid 環境オートビルダーの下でのソース
    からのクリーンなビルドが保証され、常に RC (リリースクリティカル)
    に分類される重要度が serious (深刻)の FTBFS (Fails To Build From
    Source、ソースからのビルド失敗) バグを防ぎます。^[67]

    それでは、pbuilder をカスタマイズしてみましょう:

      * /var/cache/pbuilder/resultディレクトリーを、ユーザーアカウン
        トから書き込めるように設定してください。

      * フックスクリプトを置くために、ユーザーからの書き込みが可能な
        ディレクトリーを作成してください。例） /var/cache/pbuilder/
        hooks

      * ~/.pbuilderrc か /etc/pbuilderrc に以下のように設定します。

        AUTO_DEBSIGN=${AUTO_DEBSIGN:-no}
        HOOKDIR=/var/cache/pbuilder/hooks

    それでは、ローカルpbuilder の chroot システムを以下のようにして初
    期化しましょう:

    $ sudo pbuilder create

    既に完全なソースパッケージがあれば、foo.orig.tar.gzファイル、foo
    .debian.tar.gzファイル、foo.dscファイルが存在するディレクトリーで
    、ローカルの pbuilder の chrootシステムをアップデートし、バイナリ
    ーパッケージをその中でビルドしましょう:

    $ sudo pbuilder --update
    $ sudo pbuilder --build foo_version.dsc

    新しくビルドした GPG 署名の無いパッケージは非ルート所有権で /var/
    cache/pbuilder/result/ に置かれます。

    .dsc ファイルや .changes ファイルへのGPG 署名は次のようにするとで
    きます:

    $ cd /var/cache/pbuilder/result/
    $ debsign foo_version_arch.changes

    更新されたソースツリーが既にあるが一致するソースパッケージを生成
    していない場合は、この代わりに、debian ディレクトリーが存在するデ
    ィレクトリーで、以下のコマンドを発行します:

    $ sudo pbuilder --update
    $ pdebuild

    pbuilder --login --save-after-loginコマンドで、chroot環境にログイ
    ンし、好きに設定することができます。シェルプロンプトから^D
    (Control-D)で抜けると、その環境を保存しておくことができます。

    最新のlintianコマンドはchroot環境から次のように設定されたフックス
    クリプト/var/cache/pbuilder/hooks/B90lintianを使用して実行するこ
    とができます: ^[68]

    #!/bin/sh
    set -e
    install_packages() {
            apt-get -y --allow-downgrades install "$@"
            }
    install_packages lintian
    echo "+++ lintian output +++"
    su -c "lintian -i -I --show-overrides /tmp/buildd/*.changes" - pbuilder
    # use this version if you don't want lintian to fail the build
    #su -c "lintian -i -I --show-overrides /tmp/buildd/*.changes; :" - pbuilder
    echo "+++ end of lintian output +++"

    sid 環境向けのパッケージを正しくビルドするには最新の sid 環境が必
    要です。sid にはあなたの環境全てを移行するには望ましくない問題を
    抱えていることが少なくありません。pbuilder パッケージはそのような
    状況への対処の助けとなります。

    stable/updatesやstable-proposed-updatesがリリースされた後、stable
    パッケージのアップデートが必要な場合があります。^[69]そのような場
    合に、即座にアップデートしない言い訳として sid を使っているからと
    いうのは不十分です。pbuilderパッケージは、同じアーキテクチャーの
    ほぼ全ての Debian 派生であるディストリビューションへのアクセスを
    手助けします。

    http://www.netfort.gr.jp/~dancer/software/pbuilder.html と 
    pdebuild(1) と pbuilderrc(5) と pbuilder(8) を参照下さい。

6.5. git-buildpackageコマンドとその仲間

    アップストリームがソースコード管理システム (VCS) ^[70] を使ってい
    るのであれば、同様に使用することを考えるべきです。それによって、
    マージとアップストリームパッチの取捨選択がより簡単になります。各
    VCS 毎に Debian パッケージをビルドするための特別なラッパースクリ
    プトのパッケージもいくつかあります。

      * git-buildpackage: Git リポジトリ内の Debian パッケージの支援
        プログラム群です。

      * svn-buildpackage: Debian パッケージを Subversion で管理するた
        めの支援プログラム群です。

      * cvs-buildpackage: CVS ソースツリーのための Debian パッケージ
        スクリプト群です。

    Debian デベロッパーが alioth.debian.org 上の Git サーバーを用い
    Debian パッケージを管理するのに git-buildpackage を使うことがよく
    あります。^[71] このパッケージはパッケージ活動を自動化する多くの
    コマンドを提供します。

      * gbp-import-dsc(1): import a previous Debian package to a Git
        repository.

      * gbp-import-orig(1): import a new upstream tar to a Git
        repository.

      * gbp-dch(1): generate the Debian changelog from Git commit
        messages.

      * git-buildpackage(1): Debian パッケージを Git レポジトリーから
        ビルドします。

      * git-pbuilder(1): Debian パッケージを Git レポジトリーから 
        pbuilder/cowbuilder を持ちいてビルドします。

    これらのコマンドはパッケージング活動を追跡する 3 つのブランチを使
    用します:

      * Debian パッケージのソースツリーは、main 。

      * アップストリームのソースツリーは、upstream。

      * --pristine-tar オプションにより生成されるアップストリームtar
        アーカイブは、pristine-tar。^[72]

    git-buildpackage は ~/.gbp.conf で設定できます。gbp.conf(5) を参
    照下さい。 ^[73]

6.6. 部分的な再ビルド

    大規模なパッケージの場合には、debian/rules をちょっといじるたびに
    、毎回最初からパッケージの再ビルドをやりなおすのは手間です。テス
    ト目的であれば、以下の方法でアップストリームソースを再ビルドをせ
    ずに .deb ファイルを生成することができます。 ^[74]:

    $ fakeroot debian/rules binary

    また、以下の方法を使えば生成可能かどうかをチェックすることができ
    ます:

    $ fakeroot debian/rules build

    最終的にきちんとテストが完了したら、正しい手順に従ってパッケージ
    を最初から再ビルドすることを忘れないでください。この方法でビルド
    した .deb ファイルをアップロードしようとしても、おそらくうまくア
    ップロードできないでしょう。

6.7. コマンド階層

    パッケージ作成に用いる多くのコマンドが、コマンド階層の中でお互い
    いかなる関係にあるかの簡単なまとめを以下に記します。同じ事をする
    のに多くの方法があります。

      * debian/rules = パッケージビルド用のメンテナースクリプト

      * dpkg-buildpackage = パッケージビルドツールの核

      * debuild = dpkg-buildpackage + lintian (サニタイズした環境変数
        下でのビルド)

      * pbuilder = Debian の chroot 環境ツールの核

      * pdebuild = pbuilder + dpkg-buildpackage (chroot 中でビルド)

      * cowbuilder = pbuilder 実行の加速

      * git-pbuilder = pdebuild の使いやすいコマンドラインシンタック
        ス (gbp buildpackge が使用)

      * gbp = Debian ソースを git レポ下で管理

      * gbp buildpackge = pbuilder + dpkg-buildpackage + gbp

    gbp buildpackge や pbuilder 等のよりハイレベルなコマンドを用いる
    ことは完全なパッケージビルド環境を保証しますが、debian/rules や 
    dpkg-buildpackage 等のよりローレベルのコマンドがそれらの下で実行
    されるかを理解することは必須です。


---------------------------------------------------------------------

    ^[62] GPG キーは信頼の網に連結するように Debian デベロッパーによ
    って署名され、the Debian keyring に登録されていなければいけません
    。こうすることで Debian アーカイブにパッケージをアップロードして
    受け付けられるようになります。Creating a new GPG key と Debian
    Wiki on Keysigning を参照下さい。

    ^[63] 3.0 (quilt)ソースフォーマットでquiltパッチを当てないように
    するには、上記コマンドに--skip-patchesオプションをつけて実行しま
    す。または、通常の操作の後に、quilt pop -aを実行する方法もありま
    す。

    ^[64] 実際のオートビルダーシステムは、本稿の説明よりもかなり複雑
    なスキームによって実現しています。それらの詳細は、本稿の範囲を超
    えるため割愛します。

    ^[65] pbuilderパッケージとは違い、オートビルダーによって使用され
    るsbuildパッケージ下でのchroot環境では、最小システムを強制しない
    ので、多くのパッケージがインストールされたままになるかもしれませ
    ん。

    ^[66] pbuilderパッケージはまだ進化の過程なので、実際の構成は、最
    新の公式ドキュメントで確認して下さい。

    ^[67] Debian パッケージのオートビルドに関しては http://
    buildd.debian.org/ を参照下さい。

    ^[68] HOOKDIR=/var/cache/pbuilder/hooks をここで仮定しています。
    フックスクリプトのサンプルは /usr/share/doc/pbuilder/examples デ
    ィレクトリーににあります。

    ^[69] stable パッケージのそのようなアップデートには制限が課せられ
    ます。

    ^[70] 詳しくは Version control systems を参照下さい。

    ^[71] alioth.debian.org サービスの使い方は、Debian wiki Alioth に
    記載されています。

    ^[72] --pristine-tar オプションは、小さなバイナリデルタと通常 VCS
    の upstream ブランチ中に保存された tar アーカイブの内容のみを用い
    完全に元通りの手付かずの tar アーカイブを再生成する pristine-tar
    コマンドを起動します。

    ^[73] 以下は、上級者のみなさんの参考になるウェブ上で閲覧できる資
    料です。

      * git-buildpackage を使っての Debian パッケージ作成 (/usr/share
        /doc/git-buildpackage/manual-html/gbp.html)

      * debian packages in git

      * Using Git for Debian Packaging

      * git-dpm: Debian packages in Git manager

    ^[74] その場合は、通常だと正しく設定される環境変数は設定されませ
    ん。アップロード用のパッケージはこの簡易メソッドで生成しないでく
    ださい。

第7章パッケージのエラーの検証

    最新の内容とより実用的な例でこの入門書を書き換えたものが Guide
    for Debian Maintainers として入手できます。この新しい入門書を第一
    次的な入門書として使ってください。

    ここでは, 公式アーカイブにパッケージをアップロードする前に、作成
    したパッケージのエラーをあなた自身で確認するために知っておかなけ
    ればならない方法について、幾つか述べます。

    あなたのマシン以外でのテストもまた良いアイデアです。以下に述べる
    すべてのテストにおける、どんな警告とエラーについてでもしっかりと
    確認しておかなければなりません。

7.1. 怪しげな変更

    あなたの 3.0 (quilt) フォーマットのノンネイティブ Debian パッケー
    ジをビルドした後で、debian/patches ディレクトリー内に
    debian-changes-* のような新規の自動生成されたパッチファイルを見つ
    けた場合。何かの間違いで何らかのファイルを変更したか、ビルドスク
    リプトがアップストリームソースに変更を加えた可能性が大いにありま
    す。あなたの間違いなら、それを修正しましょう。ビルドスクリプトが
    引き起こした場合は、「rules ファイルのカスタマイズ」にあるように 
    dh-autoreconf を使って根本原因を修正するか、「source/options」に
    あるように source/options を使って回避策をとります。

7.2. インストールに対するパッケージの検証

    あなたのパッケージが問題なくインストールできるかどうかをテストし
    なければなりません。debi(1) コマンドはあなたが作成した全てのバイ
    ナリーパッケージのインストールテストに役立ちます。

    $ sudo debi gentoo_0.9.12-1_i386.changes

    別のシステムでインストール時に問題が起きるのを防ぐために、Debian
    アーカイブよりダウンロードした Contents-i386 ファイルを用いて、他
    の既存のパッケージと重複するファイルがないことを確認しておかなけ
    ればなりません。apt-file コマンドはこの作業において恐らく役に立つ
    でしょう。重複するファイルが存在するならば、実際に問題になること
    を回避するために、ファイルをリネームするか、複数のパッケージが依
    存する独立のパッケージに共通ファイルを移動するか、他の影響のある
    パッケージと調整しながら alternatives (update-alternatives(1) 参
    照)を用いるか、debian/controlに Conflicts 項目を宣言して下さい。

7.3. パッケージのメンテナースクリプトの検証

    全てのメンテナースクリプト (preinst、prerm、postinst そして
    postrm ファイルのこと) は、それが debhelperプログラムで自動生成さ
    れたのでない場合は、正しく書くことが非常に困難です。だからあなた
    が新米メンテナーならばこれらは使わないで下さい (「{pre,post}
    {inst,rm}」参照)。

    パッケージがこれらの重要なメンテナースクリプトを使用するならば、
    インストールだけではなく、削除、完全削除 (purge)、そしてアップグ
    レードについても確実にテストしましょう。多くのメンテナースクリプ
    トのバグは削除もしくは完全削除の場合に発生します。これらのテスト
    のためには、以下の様に dpkg コマンドを実行します:

    $ sudo dpkg -r gentoo
    $ sudo dpkg -P gentoo
    $ sudo dpkg -i gentoo_version-revision_i386.deb

    以下のような順番で実行すべきでしょう:

      * (可能な場合は)前回バージョンをインストールします。

      * 旧バージョンからアップグレードします。

      * 旧バージョンになるよう、ダウングレードします (オプション)。

      * 完全削除 (purge) します。
   
      * 新しいパッケージとしてインストールします。

      * 削除します。

      * もう一度インストールします。

      * 完全削除 (purge) します。

    これが最初に作成したパッケージならば、将来発生するかもしれない問
    題を防ぐために、異なるバージョンのダミーパッケージを作成すべきで
    す。

    あなたのパッケージが過去の Debian にてリリースされていた場合には
    、人々は大抵最新の Debian のリリース版に含まれているバージョンか
    らパッケージのアップグレードをするであろう、ということに配慮しま
    しょう。上記の手順で、そのバージョンからきちんとアップグレードで
    きることを、忘れずに確認しておいてください。

    ダウングレードは公式にはサポートされていませんが、これをサポート
    するのは友好的な態度です。

7.4. Using lintian

    lintian(1) を .changes に対して実行しましょう。lintian コマンドは
    パッケージ作成時のよくある間違いをチェックするために多くのテスト
    スクリプトを実行します。^[75]

    $ lintian -i -I --show-overrides gentoo_0.9.12-1_i386.changes

    もちろん、.changes のファイル名はあなたが作成したパッケージに置き
    換えて下さい。lintian コマンドの出力は以下のようにマークされてい
    ます:

      * E: はエラーです。確実にポリシー違反もしくはパッケージエラーで
        す。

      * W: は警告です。ポリシー違反もしくはパッケージングエラーである
        可能性があります。

      * I: は参考情報です。パッケージのとある性質について参考となる情
        報を提供します。

      * N: は覚書です。デバッグに有用な情報を詳述します。

      * O: はオーバーライド通知です。 lintian-overrides ファイルによ
        りメッセージがオーバーライドされたメッセージです。これは
        --show-overrides オプションを指定した際に表示されます。

    警告が出た場合には、パッケージを調整するか、その警告が不当である
    ことを確認して下さい。もし警告が不当である場合には「{package
    .,source/}lintian-overrides」で述べた lintian-overrides を作成し
    て下さい。

    dpkg-buildpackage によるパッケージの生成と lintian の実行は、
    debuild(1) コマンド、もしくは pdebuild(1) コマンドを用いれば一気
    に実行することができます。

7.5. debc コマンド

    debc(1) コマンドを用いるとバイナリーパッケージに含まれるファイル
    の一覧が得られます。

    $ debc package.changes

7.6. debdiff コマンド

    debdiff(1) コマンドを用いると、二つのソースパッケージに含まれてい
    るファイルを比較することができます。

    $ debdiff old-package.dsc new-package.dsc

    debdiff(1) コマンドは二つのバイナリーパッケージに含まれるファイル
    の一覧を比較することもできます。

    $ debdiff old-package.changes new-package.changes

    これらのコマンドは、ソースパッケージ中でどんな変更をしたのか、バ
    イナリーパッケージの中で意図せず削除したり配置を間違えたりしてい
    ないか、そしてバイナリーパッケージの更新時に不用意な変更をしてい
    ないかどうか、といった事柄を確認するのに便利です。

7.7. interdiff コマンド

    interdiff(1) コマンドを用いると、二つの .diff.gz ファイルを比較す
    ることができます。旧来の 1.0 ソース形式でパッケージを更新している
    場合には、メンテナーがソースに意図しない変更をしていないことを確
    認するのに便利です。

    $ interdiff -z old-package.diff.gz new-package.diff.gz

    新規の 3.0 ソースフォーマットは「patches/*」で説明したように複数
    のパッチファイル中に変更を保存します。各々の debian/patches/* フ
    ァイルの変化も interdiff を使って追いかけられます。

7.8. mc コマンド

    mc(1) の様に、*.debパッケージファイルだけではなく、*.udev,
    *.debian.tar.gz, *.diff.gz, *.orig.tar.gz の中身を閲覧することが
    できるファイルマネージャを用いると、多くのファイルの検査が直感的
    に行なえます。

    不要なファイルやサイズがゼロのファイルがバイナリーパッケージとソ
    ースパッケージに含まれていないことをよく確認して下さい。大抵は不
    要なファイルが正しく削除されずに残ってしまっています。rules を調
    整しこれを修正して下さい。


---------------------------------------------------------------------

    ^[75] /etc/devscripts.conf や ~/.devscripts において「debuildコマ
    ンド」で述べた設定をしている場合には、lintian に -i -I
    --show-overrides オプションを指定する必要はありません。

第8章パッケージの更新

    最新の内容とより実用的な例でこの入門書を書き換えたものが Guide
    for Debian Maintainers として入手できます。この新しい入門書を第一
    次的な入門書として使ってください。

    パッケージをリリースしたなら、すぐにそれを更新する必要があります
    。

8.1. Debian リビジョンの更新

    例えば仮に、#654321 という番号のバグレポートがあなたのパッケージ
    に対してファイルされ、解決可能な問題が記述されていたとしましょう
    。パッケージの新しい Debian リビジョンを作成するには、以下を実行
    する必要があります:

      * もしこれが新規のパッチとして記録される場合には、以下のように
        します:

          + dquilt new bugname.patch としてパッチ名を設定します。

          + dquilt add buggy-file として変更されるファイルを宣言しま
            す。

          + アップストリームバグに関してパッケージソース中の問題を修
            正します。

          + dquilt refresh として bugname.patch に記録します。

          + dquilt header -e としてその内容記述を追加します。

      * もし既存のパッチをアップデートする場合には、以下のようにしま
        す:

          + dquilt pop foo.patch として既存の foo.patch を呼び出しま
            す。

          + 古い foo.patch 中の問題を修正します。

          + dquilt refresh として foo.patch を更新します。

          + dquilt header -e としてその内容記述を更新します。

          + while dquilt push; do dquilt refresh; done として fuzz を
            削除しながら全てのパッチを適用します。

      * 次に Debian changelog ファイルの先頭に新しいリビジョンを追加
        します。例えばdch -iを実行するか、またはバージョンを明示した
        い場合ならdch -v version-revision を実行してあなたの好きなエ
        ディタで説明を記入すると楽にできます。^[76]

      * changelog の説明行に、このリビジョンで解決されたバグと、その
        解決方法についての簡単な説明を記載し、Closes: #54321 と続けて
        おきます。これによってあなたのパッケージが Debian アーカイブ
        中に受け入れられた時、アーカイブ管理ソフトウェアによって該当
        するバグレポートが魔法のように自動的に閉じられます。

      * 上記であなたがしたことを繰り返し、必要に応じて Debian
        changelog ファイルを dch で更新しながら、更なるバグ修正を行い
        ます。

      * 「完全な（再）ビルド」と 7章パッケージのエラーの検証で行った
        ことを繰り返して下さい。

      * 一旦満足した時点で、changelog 中のディストリビューション値を
        UNRELEASED からターゲットディストリビューション値 unstable
        (もしくは場合に依っては experimental) へと変更すべきです。^
        [77]

      * 9章パッケージをアップロードすると同様にパッケージをアップロー
        ドします。今までと違うのは、今回の場合オリジナルソースアーカ
        イブには変更が無く、同じものが既に Debian アーカイブ中に存在
        しているため、アップロードするファイルにはオリジナルのソース
        アーカイブが含まれないという点だけです。

    例えばオフィシャルのアーカイブへ 1.0.1-1 のようなノーマルのバージ
    ョンをアップロードする前にパッケージングを色々試すべくローカルパ
    ッケージを作る時には要注意です。スムースなアップグレードのために
    は、1.0.1-1~rc1 のような文字列のバージョンの項目をchangelog に作
    るのがいい考えです。オフィシャルパッケージのためには、そのような
    ローカル変更の複数項目を単一の項目にまとめて changelog をすっきり
    させてもいいです。バージョン文字列の順序に関しては「パッケージ名
    とバージョン」を参照下さい。

   

8.2. 新規のアップストリームリリースの検査

    Debian アーカイブ用の新しいアップストリームリリースパッケージの準
    備をする際は、まず、新アップストリームリリースをチェックしなけれ
    ばなりません。

    アップストリームの changelog や NEWS、その他の新しいバージョンで
    リリースされたドキュメントを読むことから始めてください

    以下のようにすれば何かおかしな事が無いかに注意を払いつつ新旧のア
    ップストリームソース間の変更検査ができます:

    $ diff -urN foo-oldversion foo-newversion

    missing や aclocal.m4 や config.guess や config.h.in や
    config.sub や configure や depcomp や install-sh や ltmain.sh や
    Makefile.in 等の Autotools によって自動生成されるファイルへの変更
    は無視していい場合があります。ソースを検査するための diff を実行
    する前に消去してもいいです。

8.3. アップストリームソフトウェアの新版更新

    もし foo パッケージが新規の 3.0 (native) や 3.0 (quilt) フォーマ
    ットで適正にパッケージされていれば、新規のアップストリームバージ
    ョンをパッケージするのは基本的に旧 debian ディレクトリーを新規ソ
    ースへと移動するのみです。これは新規に展開されたソース中で tar
    xvzf /path/to/foo_oldversion.debian.tar.gz を実行すれば出来ます。
    ^[78] もちろん当然するべき細々としたことをする必要はあります:

      * アップストリームソースのコピーを foo_newversion.orig.tar.gz
        ファイルとして作成します。

      * Debian の changelog ファイルを dch -v newversion-1 を使って更
        新します。

          + New upstream release という項目を追加します。

          + 報告のあったバグを修正する新規アップストリームリリース中
            の変更点に関して簡潔に記載しバグを Closes: #バグ番号と追
            記してクローズします。

          + 報告のあったバグを修正する、メンテナーによる新規アップス
            トリームリリースへの変更点に関して簡潔に記載しバグを
            Closes: #バグ番号と追記しクローズします。

      * while dquilt push; do dquilt refresh; done として fuzz を削除
        しながら全てのパッチを適用します。

    もしパッチやマージがクリーンに適用できない場合は、状況を精査しま
    す (.rej ファイル中にヒントがあります)。

      * もしソースにあなたが適用していたパッチがアップストリームソー
        スに統合された場合は、

          + dquilt delete として削除します。

      * もしソースにあなたが適用していたパッチが新規アップストリーム
        ソースとぶつかる場合は、

          + dquilt push -f として baz.rej としてリジェクトを強制しな
            がら古いパッチを適用します。

          + baz.rej の本来目指した効果を実現するように、baz ファイル
            を手動で編集します。

          + dquilt refresh としてパッチを更新します。

      * while dquilt push; do dquilt refresh; done まで戻り継続します
        。

    このプロセスは uupdate(1) コマンドを以下のように使うことで自動化
    できます:

    $ apt-get source foo
    ...
    dpkg-source: info: extracting foo in foo-oldversion
    dpkg-source: info: unpacking foo_oldversion.orig.tar.gz
    dpkg-source: info: applying foo_oldversion-1.debian.tar.gz
    $ ls -F
    foo-oldversion/
    foo_oldversion-1.debian.tar.gz
    foo_oldversion-1.dsc
    foo_oldversion.orig.tar.gz
    $ wget http://example.org/foo/foo-newversion.tar.gz
    $ cd foo-oldversion
    $ uupdate -v newversion ../foo-newversion.tar.gz
    $ cd ../foo-newversion
    $ while dquilt push; do dquilt refresh; done
    $ dch
    ... document changes made

    debian/watch ファイルを「watch」に記載されたように設定していれば
    、 wget コマンドをスキップすることが出来ます。foo-oldversion ディ
    レクトリー中で uupdate コマンドを実行する代わりに、単に uscan(1)
    コマンドを実行します。こうすると魔法のように更新されたソースを見
    つけ、それをダウンロードし、uupdate コマンドを実行します。^[79]

    今まで「完全な（再）ビルド」、 7章パッケージのエラーの検証、9章パ
    ッケージをアップロードするの中で実行してきたことを繰り返し、更新
    したソースをリリースできます。

8.4. パッケージ化スタイルの更新

    パッケージスタイルの更新はパッケージ更新のために必須活動ではあり
    ません。しかし、こうすることで最新の debhelper システムと 3.0 ソ
    ースフォーマットの全能力を活用できます。^[80]

      * もし何らかの理由で消去されたテンプレートファイルを追加する必
        要がある場合には、同一の Debian ソースツリーの中で
        --addmissing オプションとともに dh_make をもう一度実行しても
        いいです。そして、それらを適正に編集しましょう。

      * debian/rules ファイルに関して debhelper v7+ dh シンタックスへ
        とパッケージが更新されていない場合は dh を使うように更新しま
        しょう。debian/control ファイルもそれに合わせて変更しましょう
        。

      * コモン Debian ビルドシステム (cdbs) による Makefile 包含メカ
        ニズムで生成された rules ファイルを dh シンタックスに更新しよ
        うとする場合には、以下を参照し DEB_* 設定変数を理解して下さい
        。

          + /usr/share/doc/cdbs/cdbs-doc.pdf.gz のローカルコピー

          + The Common Debian Build System (CDBS), FOSDEM 2009

      * foo.diff.gz ファイル無しの 1.0 ソースパッケージの場合、3.0
        (native) と言う内容の debian/source/format を作成することで新
        規の 3.0 (native) ソースフォーマットに更新できます。残りの
        debian/* ファイルは単にコピーするだけです。

      * foo.diff.gz ファイルありの 1.0 ソースパッケージの場合、3.0
        (quilt) と言う内容の debian/source/format を作成することで新
        規の 3.0 (quilt) ソースフォーマットに更新できます。残りの
        debian/* ファイルは単にコピーするだけです。必要な場合、
        filterdiff -z -x '*/debian/*' foo.diff.gz > big.diff コマンド
        により生成される big.diff ファイルをあなたの quilt システムに
        インポートします。^[81]

      * -p0 や -p1 や -p2 を使う dpatch や dbs や cdbs のような他のパ
        ッチシステムを用いてパッケージされ得ている場合には、http://
        bugs.debian.org/581186にある deb3 を用いて quilt コマンドに変
        換します。

      * もし --with quilt オプション付きの dh コマンドとか、
        dh_quilt_patch と dh_quilt_unpatch コマンドを用いてパッケージ
        されている場合には、これらを削除し新規の 3.0 (quilt) ソースフ
        ォーマットを使うようにします。

    DEP - Debian エンハンスメント提案を確認し、ACCEPTED (採用) となっ
    た提案を取り入れるべきです。

    「アップストリームソフトウェアの新版更新」に記載された他の作業も
    行う必要があります。

8.5. UTF-8 変換

    アップストリームの文書が旧来のエンコーディング法にてエンコードさ
    れている場合には、それらを UTF-8 に変換するのはいいことです。

      * iconv(1) を使いプレインテキストのエンコーディングを変換します
        。

        iconv -f latin1 -t utf8 foo_in.txt > foo_out.txt

      * w3m(1) を使用して HTML ファイルを UTF-8 のプレインテキストフ
        ァイルに変換します。これを行う際には、必ず UTF-8 ロケールで実
        行して下さい。

        LC_ALL=en_US.UTF-8 w3m -o display_charset=UTF-8 \
                -cols 70 -dump -no-graph -T text/html \
                < foo_in.html > foo_out.txt

8.6. パッケージをアップグレードする際の注意点

    パッケージをアップグレードする際の注意点は以下です:

      * changelog の旧項目を保全します (自明ですが、dch -i とするべき
        時に dch とした過去事例があります。)

      * 現存の Debian による変更は再評価する必要があります。(何らかの
        形で)アップストリームが組み込んだことは捨て、アップストリーム
        が組み込まなかったことは残しましょう。

      * ビルドシステムに変更が加えられた場合には (アップストリームの
        変更を精査した際に分かっているはずですよね)、必要に応じて
        debian/rules と debian/control のビルド依存関係を更新します。

      * 現存もオープンのバグへのパッチを誰かが提供していないかを、
        Debian Bug Tracking System (BTS) で確認します。

      * 正しいディストリビューションへアップロードすること、 Closes
        フィールドに適切なバグのクローズがリストされていること、
        Maintainer と Changed-By フィールドがマッチしていること、ファ
        イルが GPG 署名されていること等を確実にするように、.changes
        ファイルの内容を確認します。


---------------------------------------------------------------------

    ^[76] 日付を要求されるフォーマットで入力するには、LANG=C date -R
    を使います。

    ^[77] もし dch -r コマンドを使ってこの最終変更をする場合には、エ
    ディターにより changelog ファイルを明示的に保存して下さい。

    ^[78] もしパッケージ foo が旧 1.0 フォーマットでパッケージされて
    いる場合は、新規に展開されたソース中で zcat /path/to/foo_
    oldversion.diff.gz|patch -p1 を実行すれば出来ます。

    ^[79] もし uscan コマンドが更新されたソースはダウンロードするが 
    uupdate コマンドを実行しない場合には、URLの最後に debian uupdate
    となるように debian/watch ファイルを修正するべきです。

    ^[80] もしあなたのスポンサーや他のメンテナーが既存のパッケージス
    タイル更新に異存がある場合には、更新することもまたその議論するこ
    とは意味がありません。他にするべきより重要なことがあります。

    ^[81] splitdiff コマンドを用いると big.diff は多くの小さな増分パ
    ッチに分割できます。

第9章パッケージをアップロードする

    最新の内容とより実用的な例でこの入門書を書き換えたものが Guide
    for Debian Maintainers として入手できます。この新しい入門書を第一
    次的な入門書として使ってください。

    Debian now requires source-only uploads for normal upload. So
    this page is outdated.

    あなたの新しいパッケージは徹底的にテストできたので、あなたはそれ
    を共有すべく公開アーカイブにリリースしたいでしょう。

9.1. Debian アーカイブへアップロードする

    正規デベロッパー^[82]になると、パッケージを Debian アーカイブにア
    ップロードできます。^[83] 手動でもできますが、 dupload(1) や dput
    (1) 等の既存の自動化ツールを用いる方が楽です。ここでは dupload を
    使ってどうするかを説明します。^[84]

    まず dupload の設定ファイルを調整しなければいけません。システム全
    体の設定ファイルである /etc/dupload.conf を編集するか、あるいはあ
    なた専用の設定ファイルである ~/.dupload.conf を使って変更したい項
    目だけをオーバーライドさせてもかまいません。

    またそれぞれのオプションが持つ意味を理解するため dupload.conf(5)
    マニュアルページを読むことができます。

    $default_host オプションはデフォルトで利用されるアップロードキュ
    ーを指定します。anonymous-ftp-masterがメインのアップロードキュー
    ですが、別のアップロードキューを利用したいこともあるでしょう。^
    [85]

    インターネットにつながった状態で、以下のようにすればあなたのパッ
    ケージをアップロード出来ます:

    $ dupload gentoo_0.9.12-1_i386.changes

    dupload は各ファイルの SHA1/SHA256 チェックサムを計算し、
    .changes ファイルの中の情報と照合します。もしそれらが一致しない場
    合には、適正にアップロードされるように「完全な（再）ビルド」の説
    明に従って最初から再ビルドをするよう警告します。

    ftp://ftp.upload.debian.org/pub/UploadQueue/へのアップロードで問
    題があった場合には、GPG 署名した *.commands ファイルを ftp を用い
    てftpで手動アップロードすることで修正出来ます。 ^[86] 例えば、
    hello.commands を使います:

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1
    Uploader: Foo Bar <Foo.Bar@example.org>
    Commands:
     rm hello_1.0-1_i386.deb
     mv hello_1.0-1.dsx hello_1.0-1.dsc
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.10 (GNU/Linux)

    [...]
    -----END PGP SIGNATURE-----

9.2. アップロード用orig.tar.gzの内容

    はじめてパッケージをアーカイブにアップロードする際は、オリジナル
    のorig.tar.gz ソースファイルを含めなければなりません。当該パッケ
    ージの Debian リビジョン番号が 1 でも 0 でも無い場合には、
    dpkg-buildpackage に -sa オプションを付けなければなりません。

    dpkg-buildpackage コマンドの場合:

    $ dpkg-buildpackage -sa

    debuildコマンドの場合:

    $ debuild -sa

    debuildコマンドの場合:

    $ pdebuild --debbuildopts -sa

    逆に、-sdオプションを付けると、オリジナルのorig.tar.gz ソースファ
    イルを強制的に除外します。

9.3. スキップされたアップロード

    アップロードをスキップすることで debian/changelog 中に複数の項目
    を作成した場合は、前回アップロード以来の全ての変更を含む適切な
    *_.changes ファイルを作成しなければいけません。 dpkg-buildpackage
    オプションの -v を、例えば 1.2 と言うバージョンに関して指定すると
    可能です。

    dpkg-buildpackage コマンドの場合:

    $ dpkg-buildpackage -v1.2

    debuildコマンドの場合:

    $ debuild -v1.2

    debuildコマンドの場合:

    $ pdebuild --debbuildopts "-v1.2"


---------------------------------------------------------------------

    ^[82] 「Debianにおける社会ダイナミクス」を参照下さい。

    ^[83] Debian アーカイブとほぼ同様に機能し、非-DD に対してアップロ
    ードエリアを提供する http://mentors.debian.net/ のような公開アー
    カイブがあります。http://wiki.debian.org/
    HowToSetupADebianRepository に列記されているツールを使い自分自身
    で同様のアーカイブを設定することも出来ます。だからこのセクション
    は非-DD にも有用です。

    ^[84] dput パッケージは、より多くの機能があり dupload パッケージ
    より人気が出てきています。それは、/etc/dput ファイルをグローバル
    設定に用い、 ~/.dput.cf ファイルをユーザー毎の設定に用います。更
    にそれは、そのままUbuntu関連のサービスもサポートします。

    ^[85] Debian Developer's Reference 5.6, "Uploading a package" を
    参照下さい。

    ^[86] ftp://ftp.upload.debian.org/pub/UploadQueue/README を参照下
    さい。dput パッケージ中にある dcut コマンドをこれに代わる方法とし
    て用いることもできます。

付録A 上級パッケージング

    最新の内容とより実用的な例でこの入門書を書き換えたものが Guide
    for Debian Maintainers として入手できます。この新しい入門書を第一
    次的な入門書として使ってください。

    あなたが出会いそうな上級パッケージング課題に関するヒントや外部参
    照をいくつか記します。ここに提案されたレファレンス全てに目を通す
    ことを切にお薦めします。

    本章で取り上げたトピックをカバーするには dh_make コマンドで生成さ
    れたパッケージ用テンプレートファイルではマニュアル編集する必要が
    あるかもしれません。より新しい debmake コマンドはこのようなトピッ
    クへの対応が優れています。

A.1. 共有ライブラリー

    共有ライブラリーをパッケージングする前に、以下の一次レファレンス
    を詳細に読むべきです:

      * Debian Policy Manual, 8 "Shared libraries"

      * Debian Policy Manual, 9.1.1 "File System Structure"

      * Debian Policy Manual, 10.2 "Libraries"

    以下はあなたが手を付け始めるための少々簡略化しすぎたヒントです:

      * 共有ライブラリーとはコンパイルされたコードを含む ELF オブジェ
        クトファイルです。

      * 共有ライブラリーは *.so ファイルとして頒布されます。(*.a ファ
        イルでも *.la ファイルでもありません)

      * 主に、共有ライブラリーは ld メカニズムを用い複数の実行プログ
        ラム間でコードを共有するのに使用されます。

      * 時々、共有ライブラリーは dlopen メカニズムを用いある実行プロ
        グラムに複数のプラグインを提供するのに使用されます。

      * 共有ライブラリーは変数や関数やクラスのようなコンパイルされた
        オブジェクトを表すシンボルをエキスポートし、リンクされた実行
        プログラムからそれらへのアクセスを可能とします。

      * 共有ライブラリー libfoo.so.1 の SONAME: objdump -p libfoo.so.
        1 | grep SONAME ^[87]

      * 共有ライブラリーの SONAME は通常ライブラリーのファイル名と一
        致します(例外もあります)。

      * /usr/bin/foo にリンクされた共有ライブラリーの SONAME: objdump
        -p /usr/bin/foo | grep NEEDED ^[88]

      * libfoo1: 共有ライブラリー libfoo.so.1 で SONAME ABI バージョ
        ンが 1 のライブラリーパッケージ。^[89]

      * ライブラリーパッケージのパッケージメンテナースクリプトは
        SONAME に必要なシンボリックリンクを作成するために特定の環境下
        で ldconfig を呼ばなければいけません。^[90]

      * libfoo1-dbg: 共有ライブラリー libfoo1 のデバッグシンボルを含
        むデバッグシンボルパッケージ。

      * libfoo-dev: 共有ライブラリー libfoo.so.1 用のヘッダーファイル
        他を含む開発用パッケージ。^[91]

      * Debian パッケージは一般的に *.la Libtool アーカイブファイルを
        含んではいけません。^[92]

      * Debian パッケージは一般的に RPATH を使うべきではありません。^
        [93]

      * 少々内容が古くなった二次的なレファレンスですが、Debian
        Library Packaging Guide はまだ有用かもしれません。

A.2. debian/package.symbols の管理

    共有ライブラリーをパッケージする際には、同一共有ライブラリーパッ
    ケージ名のライブラリーの同一 SONAME の下での後方互換性のある変更
    に関して、各シンボルと関連付けられる最小のバージョンが記された
    debian/package.symbols ファイルを作成すべきです。^[94] 以下の一次
    的レファレンスを詳細に読むべきです:

      * Debian Policy Manual, 8.6.3 "The symbols system"^[95]

      * dh_makeshlibs(1)

      * dpkg-gensymbols(1)

      * dpkg-shlibdeps(1)

      * deb-symbols(5)

    過去バージョン 1.3 のアップストリームバージョンから適切な debian/
    libfoo1.symbols ファイルを用いて libfoo1 パッケージを作成する概略
    例は以下です:

      * アップストリームの libfoo-1.3.tar.gz ファイルを用いてDebian 化し
        たソースツリーの骨子を準備します。

          + もし libfoo1 パッケージの最初のパッケージングの場合は、内容が
            空の debian/libfoo1.symbols ファイルを作成します。

          + もし以前のアップストリームバージョン 1.2 が libfoo1 パッケー
            ジとして適切な debian/libfoo1.symbols を用いてパッケージされ
            ていた場合には、それを再び使いましょう。

          + もし過去のアップストリームバージョン 1.2 が debian/
            libfoo1.symbols を用いてパッケージされていない場合には、その
            ライブラリーの同一 SONAME を含む同一共有ライブラリーパッケー
            ジ名の全ての手に入るバイナリーパッケージ、例えば 1.1-1 と
            1.2-1 バージョンから、それを symbols として生成できます。^
            [96]

            $ dpkg-deb -x libfoo1_1.1-1.deb libfoo1_1.1-1
            $ dpkg-deb -x libfoo1_1.2-1.deb libfoo1_1.2-1
            $ : > symbols
            $ dpkg-gensymbols -v1.1 -plibfoo1 -Plibfoo1_1.1-1 -Osymbols
            $ dpkg-gensymbols -v1.2 -plibfoo1 -Plibfoo1_1.2-1 -Osymbols

      * debuild や pdebuild 等のツールを使ってソースツリーのテストビルド
        をします。 (もしシンボルの欠如等でビルドがうまく行かない場合には
        、共有ライブラリーパッケージ名を libfoo1a 等と繰り上げる必要のあ
        る何らかの後方非互換な ABI 変更があったので、最初からやり直す必要
        があります。)

        $ cd libfoo-1.3
        $ debuild
        ...
        dpkg-gensymbols: warning: some new symbols appeared in the symbols file: ...
         see diff output below
        --- debian/libfoo1.symbols (libfoo1_1.3-1_amd64)
        +++ dpkg-gensymbolsFE5gzx        2012-11-11 02:24:53.609667389 +0900
        @@ -127,6 +127,7 @@
          foo_get_name@Base 1.1
          foo_get_longname@Base 1.2
          foo_get_type@Base 1.1
        + foo_get_longtype@Base 1.3-1
          foo_get_symbol@Base 1.1
          foo_get_rank@Base 1.1
          foo_new@Base 1.1
        ...

      * もし上記のように dpkg-gensymbols によって diff がプリントされるの
        を発見した場合には、生成された共有ライブラリーのバイナリーパッケ
        ージから適切な symbols ファイルを抽出しましょう。^[97]

        $ cd ..
        $ dpkg-deb -R  libfoo1_1.3_amd64.deb libfoo1-tmp
        $ sed -e 's/1\.3-1/1\.3/' libfoo1-tmp/DEBIAN/symbols \
                >libfoo-1.3/debian/libfoo1.symbols

      * debuild や pdebuild のようなツールでリリースパッケージをビルドし
        ます。

        $ cd libfoo-1.3
        $ debuild -- clean
        $ debuild
        ...

    上記の例に加えて、更に ABI 互換性を確認し、必要に応じていくつかの
    シンボルのバージョンを手作業で繰り上げる必要があります。^[98]

    二次的なレファレンスではありますが、Debian wiki UsingSymbolsFiles
    とそこからリンクされているウェブページは有用かもしれません。

A.3. マルチアーチ

    Debian wheezy で導入されたマルチアーチ機能は dpkg と apt の中での
    バイナリーパッケージのアーキテクチャー間サポート (他の組み合わせ
    もありますが、特にi386<->amd64) を統合します。以下のレファレンス
    を詳細に読んで下さい:

      * Ubuntu wiki MultiarchSpec (アップストリーム)
   
      * Debian wiki Multiarch/Implementation (Debian の状況)

    マルチアーチは共有ライブラリーのインストールパスに i386-linux-gnu
    や x86_64-linux-gnu 等のトリプレットを使います。実際のトリプレッ
    トパスは、ビルドごとに dpkg-architecture(1) によって動的に $
    (DEB_HOST_MULTIARCH) 値として設定されます。例えば、マルチアーチラ
    イブラリーをインストールするパスは以下のように変更されます: ^[99]

    
    +-------------------------------------------------------------+
    | 旧パス  | i386 マルチアーチパス  |  amd64 マルチアーチパス  |
    |---------+------------------------+--------------------------|
    |/lib/    |/lib/i386-linux-gnu/    |/lib/x86_64-linux-gnu/    |
    |---------+------------------------+--------------------------|
    |/usr/lib/|/usr/lib/i386-linux-gnu/|/usr/lib/x86_64-linux-gnu/|
    +-------------------------------------------------------------+

    以下の場合に関する典型的なパッケージ分割シナリオの例を示します。

      * ライブラリーソース libfoo-1.tar.gz

      * コンパイラー用の言語で書かれたツールのソース bar-1.tar.gz

      * インタープリター用言語で書かれたツールのソース baz-1.tar.gz

    
    +---------------------------------------------------------------+
    | パッケージ |Architecture:|Multi-Arch:|     パッケージ内容     |
    |------------+-------------+-----------+------------------------|
    |libfoo1     |any          |same       |共有ライブラリー、同時イ|
    |            |             |           |ンストール可能          |
    |------------+-------------+-----------+------------------------|
    |            |             |           |共有ライブラリーデバッグ|
    |libfoo1-dbg |any          |same       |シンボル、同時インストー|
    |            |             |           |ル可能                  |
    |------------+-------------+-----------+------------------------|
    |            |             |           |共有ライブラリーヘッダー|
    |libfoo-dev  |any          |same       |ファイル他、同時インスト|
    |            |             |           |ール可能                |
    |------------+-------------+-----------+------------------------|
    |libfoo-tools|any          |foreign    |実行時サポートプログラム|
    |            |             |           |、同時インストール不可  |
    |------------+-------------+-----------+------------------------|
    |libfoo-doc  |all          |foreign    |共有ライブラリーのドキュ|
    |            |             |           |メンテーションファイル  |
    |------------+-------------+-----------+------------------------|
    |            |             |           |コンパイルされ実行される|
    |bar         |any          |foreign    |プログラムファイル、同時|
    |            |             |           |インストール不可        |
    |------------+-------------+-----------+------------------------|
    |bar-doc     |all          |foreign    |プログラムのドキュメンテ|
    |            |             |           |ーションファイル        |
    |------------+-------------+-----------+------------------------|
    |baz         |all          |foreign    |インタープリターで実行さ|
    |            |             |           |れるプログラムファイル  |
    +---------------------------------------------------------------+

    開発パッケージは関連した共有ライブラリーへのバージョン番号無しの
    シンボリックリンクを含んでいるべきです。例えば: /usr/lib/
    x86_64-linux-gnu/libfoo.so -> libfoo.so.1

A.4. 共有ライブラリーパッケージのビルド

    dh(1) を以下のように使えばマルチアーチをサポートするようにして
    Debian のライブラリーパッケージをビルドできます:

      * debian/control を更新します。

          + ソースパッケージセクションに Build-Depends: debhelper (>=10)
            を追加します。

          + 共有ライブラリーのバイナリーパッケージごとに Pre-Depends: $
            {misc:Pre-Depends} を追加します。

          + Multi-Arch: スタンザを各バイナリーパッケージセクション毎に追
            加します。

      * debian/compat を "10" と設定します。

      * すべてのパッケージングスクリプトに関して、通常の /usr/lib/ から、
        マルチアーチの /usr/lib/$(DEB_HOST_MULTIARCH)/ へとパスを調整しま
        す。

          + 最初に debian/rules 中で DEB_HOST_MULTIARCH ?= $(shell
            dpkg-architecture -qDEB_HOST_MULTIARCH) を呼び
            DEB_HOST_MULTIARCH 変数を設定します。

          + debian/rules 中の /usr/lib/ を /usr/lib/$(DEB_HOST_MULTIARCH)
            / で置き換えます。

          + もし debian/rules 中の override_dh_auto_configure ターゲット
            の一部分として ./configure が用いられている場合には、それを
            dh_auto_configure -- と置き換えるようにしましょう。^[100]

          + debian/foo.install ファイル中にある全ての /usr/lib/ を /usr/
            lib/*/ で置き換えます。

          + debian/rules 中の override_dh_auto_configure ターゲットにスク
            リプトを追加し debian/foo.links.in から debian/foo.links を動
            的に生成します。

            override_dh_auto_configure:
                    dh_auto_configure
                    sed 's/@DEB_HOST_MULTIARCH@/$(DEB_HOST_MULTIARCH)/g' \
                            debian/foo.links.in > debian/foo.links

    共有ライブラリーパッケージが期待されるファイルのみを含み、-dev パ
    ッケージも依然として動作することを確認しましょう。

    マルチアーチパッケージとして同時に同一パスにインストールされる全
    てのファイルはファイルの内容が完全に同じあるべきです。データのバ
    イトオーダーや圧縮アルゴリズムにより生成される相違に注意すべきで
    す。

A.5. ネイティブ Debian パッケージ

    もしパッケージが Debian のためだけとか、またローカル使用のために
    保守されている場合、そのソースファイルは debian/* ファイルすべて
    をその中に含まれます。それをパッケージするのには2つの方法がありま
    す。

    debian/* ファイルを除外したアップストリームターボールを作成し、「
    Debian パッケージビルドのワークフロー」にあるようにしてノンネイテ
    ィブ Debian パッケージできます。これが一部の人に推奨される通常の
    方法です。

    この代わりの方法は、ネイティブ Debian パッケージのワークフローで
    す。

      * 全てのファイルが含まれる単一の圧縮された tar ファイルを用いる
        3.0 (native) フォーマットでネイティブの Debian ソースパッケー
        ジを作成します。

          + package_version.tar.gz
          + package_version.dsc
      * ネイティブ Debian ソースパッケージから、Debian バイナリーパッ
        ケージをビルドします。

          + package_version_arch.deb

    例えば debian/* ファイルを含まない ~/mypackage-1.0 ソースファイル
    があれば、以下のように dh_make コマンドを用いてネイティブ Debian
    パッケージが作れます:

    $ cd ~/mypackage-1.0
    $ dh_make --native

    すると、debian ディレクトリーとその内容は「最初のノンネイティブ
    Debian パッケージ」とちょうど同じように作成されます。これはネイテ
    ィブ Debian パッケージなので tar アーカイブを作りません。しかし相
    違点はこれだけです。他のパッケージング操作は実質的にまったく同じ
    です。

    dpkg-buildpackage コマンドを実行した後、親ディレクトリーに以下の
    ファイルが生成します:

      * mypackage_1.0.tar.gz

        これは、dpkg-source コマンドにより mypackage-1.0 ディレクトリ
        ーから作られたソースコードのターボールです。(そのサフィックス
        は orig.tar.gz ではありません。)

      * mypackage_1.0.dsc

        これは、ノンネイティブ Debian パッケージと同様でソースコード
        内容の要約です。(Debian リビジョンはありません。)
   
      * mypackage_1.0_i386.deb

        これは、ノンネイティブ Debian パッケージと同様で完成したバイ
        ナリーパッケージです。(Debian リビジョンはありません。)

      * mypackage_1.0_i386.changes

        これは、ノンネイティブ Debian パッケージと同様で現パッケージ
        バージョンでの全変更を記述します。(Debian リビジョンはありま
        せん。)


---------------------------------------------------------------------

    ^[87] もしくは: readelf -d libfoo.so.1 | grep SONAME

    ^[88] もしくは: readelf -d libfoo.so.1 | grep NEEDED

    ^[89] Debian Policy Manual, 8.1 "Run-time shared libraries" を参
    照下さい。

    ^[90] Debian Policy Manual, 8.1.1 "ldconfig" を参照下さい。

    ^[91] See Debian Policy Manual, 8.3 "Static libraries" and Debian
    Policy Manual, 8.4 "Development files" を参照下さい。

    ^[92] Debian wiki ReleaseGoals/LAFileRemoval を参照下さい。

    ^[93] Debian wiki RpathIssue を参照下さい。

    ^[94] 後方非互換な ABI 変更をした場合、通常、ライブラリーの
    SONAME と共有ライブラリーパッケージ名を新規なものにそれぞれアップ
    デートしないといけません。

    ^[95] C++ ライブラリーや個別シンボルを追跡するのが非常に困難な他
    の場合には、これに代えて Debian Policy Manual, 8.6.4 "The shlibs
    system" に従いましょう。

    ^[96] Debian パッケージの過去全てのバージョンは http://
    snapshot.debian.org/ から得られます。パッケージのバックポートが楽
    にできるように Debian リビジョンはバージョンから取り除きます。:
    1.1 << 1.1-1~bpo70+1 << 1.1-1 と 1.2 << 1.2-1~bpo70+1 << 1.2-1

    ^[97] Debian リビジョンはパッケージのバックポートを容易にすべく外
    します: 1.3 << 1.3-1~bpo70+1 << 1.3-1

    ^[98] Debian Policy Manual, 8.6.2 "Shared library ABI changes" を
    参照下さい。

    ^[99] 旧来の /lib32/ や /lib64/ 等の特定目的のライブラリーパスは
    使われなくなっています。

    ^[100] これに代えて、./configure に --libdir=\$${prefix}/lib/$
    (DEB_HOST_MULTIARCH) と --libexecdir=\$${prefix}/lib/$
    (DEB_HOST_MULTIARCH) 引数を追加することもできます。注意いただきた
    いのは、ユーザーではなく他のプログラムによりのみ実行される実行プ
    ログラムをインストールするデフォルトパスを --libexecdir は設定し
    ます。その Autotools のデフォルトは /usr/libexec/ ですが、Debian
    デフォルトは /usr/lib/ です。

