[ 前のページ ] [ 目次 ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 次のページ ]


Debian 新メンテナガイド
第 5 章 - debianディレクトリにあるその他のファイル


debhelperがパッケージのビルド中に行うことをコントロールするためには、任意の設定ファイルをdebianディレクトリに置きます。この章では、それぞれの設定ファイルが何をして、どのような書式なのか、その概説をしていきます。パッケージングのガイドラインについての詳細はDebian Policy ManualDebian Developer's Reference を参照してください。

dh_makeコマンドは、debianディレクトリの中に設定ファイルの雛形を作成します。大抵の場合、".ex"サフェックスが付いています。ファイル名の先頭にpackageなどのように、バイナリパッケージの名前がつくものもあります。これらのファイルにはすべて目を通しておいてください。

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

以下の手順で、設定ファイルを有効にできます。

packageをプリフェックスとして持たない、例えばinstallのようなdebhelperの設定ファイルは、最初のバイナリパッケージへ適用されます。 バイナリパッケージが多数ある場合、package-1installpackage-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 V7に設定します。

     $ echo 7 > debian/compat

5.3 conffilesファイル

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

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

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

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

maintainer scriptsについて、詳細は{post|pre}{inst|rm} ファイル, 第 5.18 節を参照してください。


5.4 package.cron.*ファイル

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

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

ここではログのローテーションは扱いません。ログローテーションについてはdh_installlogrotate(1) および logrotate(8)を参照してください。


5.5 dirsファイル

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

installファイルに書かれてるファイルは最初にディレクトリを作成する必要がないファイルです。詳しくは install ファイル, 第 5.11 節 を参照してください。

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


5.6 package.doc-base ファイル

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

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

例えば、gentoogentoo.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)および /usr/share/doc/doc-base/doc-base.html/にあるdoc-base のマニュアルを参照してください。

追加ドキュメントのインストールについて、詳細は指定した場所へファイルをインストールする, 第 3.3 節を見てください。


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.initpackage.default ファイル

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

package.init ファイルは /etc/init.d/package スクリプトとしてインストールされます。その極めて標準的なテンプレートファイルはdh_makeコマンドによって提供される init.d.exです。ファイル階層標準 (詳しくは /usr/share/doc/debian-policy/fhs/を参照) に準拠するためには、おそらくファイル名を変更し、かなりの編集が必要になります。このファイルはdh_installinit(1)によって、一時的なディレクトリにインストールされます。

package.defaultファイルは/etc/default/packageにインストールされます。このファイルはinitスクリプトのデフォルト設定となります。このデフォルトファイルは大抵、デーモンを停止したり、デフォルトのフラグやタイムアウトなどの設定に使われます。もしもあなたのinitスクリプトが、特定の設定可能な機能を有しているのであれば、それは起動スクリプトではなく、このデフォルトファイルに設定しておくべきでしょう。

上流プログラムの起動ファイルを使用するか、しないかにかかわらずです。もし上流からのinit.dスクリプトを使わないのであればdebian/package.initに新しいのを作成しましょう。上流の起動スクリプトが大丈夫そうで、正しい場所にインストールされたとしても、rc* シンボリックリンクの設定は必要です。そのために、rulesファイルに以下を追加して、dh_installinitをオーバーライドしましょう。

     override_dh_installinit:
             dh_installinit --onlyscripts

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


5.11 install ファイル

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

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

     src/foo/mybin usr/bin

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

また、この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.|source/}lintian-overrides ファイル

ポリシーが例外を認めているにも関わらず、lintianが間違った診断情報を報告してきた場合、package.lintian-overridessource/lintian-overridesを使って黙らせることができます。/usr/share/doc/lintian/lintian.html/index.htmlを読み、過度な使用は控えてください。

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

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


5.14 manpage.*ファイル

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


5.14.1 manpage.1.ex ファイル

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

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

     Section |     Description     |     Notes
        1     User commands          Executable commands or scripts.
        2     System calls           Functions provided by the kernel.
        3     Library calls          Functions within system libraries.
        4     Special files          Usually found in /dev
        5     File formats           E.g. /etc/passwd's format
        6     Games                  Or other frivolous programs
        7     Macro packages         Such as man macros.
        8     System administration  Programs typically only run by root.
        9     Kernel routines        Non-standard calls and internals.

つまり、gentooのmanページはgentoo.1となります。オリジナルのソースファイルにgentoo.1というmanページがなければ、上流のドキュメントと例を元にして、manpage.1.exという雛形ファイルを編集しgentoo.1というmanページを作らなければなりません。

"--help"と"--version"からhelp2manコマンドを用いてmanページを作成することも可能です。 [36]


5.14.2 manpage.sgml.ex ファイル

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


5.14.3 manpage.xml.ex ファイル

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


5.15 package.manpages ファイル

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

gentooパッケージのmanページとして、doc/gentoo.1をインストールするには、gentoo.manpagesファイルを以下のように作成します。

     docs/gentoo.1

5.16 menu ファイル

X Window System のユーザーは、大抵ウィンドウマネージャを使っており、好きなプログラムを起動できるようにメニュー機能をカスタマイズしています。menu パッケージをインストールしていれば、システムにある全プログラムのメニュー項目が作成され、menu に対応したウィンドウマネージャから利用できます。

以下が dh_make によって生成されたデフォルトの menu.ex ファイルです。

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

コロン (:) の後の最初のフィールドはneedsです。このフィールドは、プログラムがどんなどんなインターフェースが必要かを規定します。デフォルトとして挙げられたもの(例:textX11など)に変更してください。

次はsection、プログラムのエントリーが表示されるメニューやサブメニューの指定です。現在のセクションの一覧は[37]/usr/share/doc/debian-policy/menu-policy.html/ch2.html#s2.1に記載されています。

titleフィールドはプログラムの名称です。そうしたければ、大文字ではじめても大丈夫です。ただ、短くするようにしましょう。

最後の command フィールドは、実際にプログラムを実行するコマンドです。

それでは、ファイル名をmenuに変更し、メニューのエントリーを以下のように変更しましょう。

     ?package(gentoo): needs="X11" \
             section="Applications/Tools" \
             title="Gentoo" command="gentoo"

他にも、longtitleiconhintsなどのフィールドを追加できます。詳しくは dh_installmenu(1)menufile(5)update-menus(1)/usr/share/doc/debian-policy/menu-policy.html/を参照してください。


5.17 NEWS ファイル

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


5.18 {post|pre}{inst|rm} ファイル

postinstpreinstpostrm、そして prermファイルは [38]maintainer scriptsと呼ばれています。これらのスクリプトは、パッケージを管理するアリアに置かれ、インストール、アップグレード、削除される際にdpkgによって実行されます。

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

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

新バージョンへのアップグレードはおとなしく、そして押し付けがましくしてはいけません。(現行のユーザは、バグが直されたことと新機能の追加以外については、アップグレードに気づかないのが理想です。)

アップグレードが出しゃばる必要がある場合(例えば構造が変わって、設定ファイルがあっちこちに散らばってしまった場合など)、パッケージのデフォルトを安全側に設定したり(例えばサービスを停止しておくなど)、最後の手段としてはポリシーに要求されるきちんとしたドキュメント(README.DebianNEWS.Debian)を提供するなどの対策を考えるべきです。アップグレード際にmaintainer scriptsdebconfノートを呼び出すような嫌がらせはやめてください。

ucfパッケージは、maintainer scriptsによって管理されているようなconffilesにされていない、ユーザによって変更されたファイルを保存し、conffileのように処理する仕組みを提供します。この仕組みによって、関連する問題を最小化しています。

これら、maintainer scriptsなぜDebianを選ぶのかという理由の1つでもあります。これらの仕組みで、ユーザの邪魔をしないようにしましょう。


5.19 TODO ファイル

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


5.20 watch ファイル

watchファイルの書式はuscan(1)を参照してください。watchファイルは、uscan ( devscriptsパッケージに含まれます)を設定し、ソースをどこから入手したのかを監視しています。Debian External Health Status (DEHS)によっても使用されています。

今回は以下のようにしました。

     # 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に関する問題を解決しています。


5.21 source/format ファイル

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

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

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


5.22 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)).


5.23 patches/* ファイル群

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

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

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

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

Debianのパッチはdebian/patchesにあるので、quilt のセットアップ, 第 3.1 節を参照し、quiltコマンドを正しく設定してください。

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

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

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


[ 前のページ ] [ 目次 ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 次のページ ]


Debian 新メンテナガイド

version 1.2.25, 2010-12-21 14:06:56 UTC

Josip Rodin joy-mg@debian.org

翻訳:倉澤 望 nabetaro@debian.or.jp
翻訳:八津尾 雄介 yyatsuo@gmail.com
翻訳:佐々木 洋平 uwabami@gfd-dennou.org
翻訳:倉敷 悟 lurdan@gmail.com
翻訳:青木 修 osamu@debian.org