[ 前のページ ] [ 目次 ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 次のページ ]
debianディレクトリにあるその他のファイル
debhelperがパッケージのビルド中に行うことをコントロールするためには、任意の設定ファイルをdebianディレクトリに置きます。この章では、それぞれの設定ファイルが何をして、どのような書式なのか、その概説をしていきます。パッケージングのガイドラインについての詳細はDebian Policy
Manual と Debian Developer's
Reference を参照してください。
dh_makeコマンドは、debianディレクトリの中に設定ファイルの雛形を作成します。大抵の場合、".ex"サフェックスが付いています。ファイル名の先頭にpackageなどのように、バイナリパッケージの名前がつくものもあります。これらのファイルにはすべて目を通しておいてください。
dh_makeコマンドは、debhelper用の設定ファイルを作らないことがあります。その場合、自分でエディターを使い設定ファイルを作成しなければなりません。
以下の手順で、設定ファイルを有効にできます。
.exや.EXサフェックスがついていれば、消してください。
ファイル名を、packageの代わりに、実際のバイナリパッケージの名前に変更してください。
必要に応じて、ファイルの中身を書き換えます。
不要な雛形のファイルは削除してください。
必要であれば、controlファイル(参照 controlファイル, 第 4.1
節)を変更します。
必要ならrulesファイル(参照 rulesファイル, 第 4.4
節)を編集してください。
packageをプリフェックスとして持たない、例えばinstallのようなdebhelperの設定ファイルは、最初のバイナリパッケージへ適用されます。
バイナリパッケージが多数ある場合、package-1install、package-2.install、などのように、パッケージ名を設定ファイルのプリフェックスとすることで指定できます。
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)を参照してください。
compat ファイル
compatファイルは、debhelperの互換性レベルを規定します。現段階では、以下のようにdebhelper
V7に設定します。
$ echo 7 > debian/compat
conffilesファイル大変な時間と労力を費やしてプログラムをカスタマイズしても、一回のアップグレードで上書きされてしまうとうんざりします。Debianはこの問題を、設定ファイルを記録しておき、パッケージをアップグレードする際に古い設定をそのまま使いたいかどうかを質問することで解決しました。
debhelper V3、 dh_installdeb(1)
は自動的に/etcディレクトリ以下のファイルを全てconffilesとみなすので、あなたのプログラムが他のディレクトリにconffilesを持たない場合は特に指定する必要はありません。ほとんどのパッケージの場合、/etc以下にのみconffilesがある（そうあるべきです）ので、このファイルの存在は不要です。
あなたのプログラムが設定ファイルを利用する場合であっても、
その設定ファイルがプログラム自身によって頻繁に上書きされるような場合には、パッケージをアップグレードするたびにdpkgによって設定ファイルの変更について確認を求められることになるので、その設定ファイルをconffilesに登録しないほうが良いでしょう。
あなたのパッケージングするプログラムが、ユーザーに/etcディレクトリの中にある設定ファイルを編集することを要求する場合、dpkgを黙らせるためにconffilesとして登録するためによく使われる方法が２つあります。
/etcディレクトリ中に、maintainer
scriptsによって生成された/varディレクトリ以下のファイルにシンボリックリンクを張る方法と、
/etcディレクトリの中にmaintainer
scriptsによってファイルを生成する方法です。
maintainer scriptsについて、詳細は{post|pre}{inst|rm} ファイル, 第 5.18
節を参照してください。
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度実行。普通は日曜の早朝に実行する。
cron.monthly -
/etc/cron.monthly/packageとしてインストール:
1ヶ月に1度実行。普通は1日の早朝に実行する。
cron.d -
/etc/cron.d/packageとしてインストール:
上記以外のどの時間でも指定可能。
上記のファイルの書式はシェルスクリプトです。package.cron.dは違い、crontab(5)の書式になります。
ここではログのローテーションは扱いません。ログローテーションについてはdh_installlogrotate(1) および
logrotate(8)を参照してください。
dirsファイル
このファイルにはパッケージが必要としているのに、なぜか通常のインストール手順("dh_auto_install"によって呼び出される"make
install
DESTDIR=...")では作成されないディレクトリを指定します。通常、これはMakefileに問題があることを示唆しています。
installファイルに書かれてるファイルは最初にディレクトリを作成する必要がないファイルです。詳しくは
install ファイル, 第 5.11 節
を参照してください。
まずはインストールしてみて、なにか問題が起きた場合にのみ使うべきでしょう。ディレクトリ名の頭にスラッシュが付かない事に注意してください。
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)および
/usr/share/doc/doc-base/doc-base.html/にあるdoc-base
のマニュアルを参照してください。
追加ドキュメントのインストールについて、詳細は指定した場所へファイルをインストールする, 第 3.3 節を見てください。
docsファイル
このファイルには、dh_installdocs(1)を使ってパッケージ生成用の一時的なディレクトリにインストールするために、パッケージに付属する資料のファイル名を指定してください。
デフォルトでは、ソースディレクトリのトップレベルに存在する
"BUGS"、 "README*"、
"TODO"
などの名前を持つファイル全てを含みます。
では、gentooに付属文書をいくつか指定してみましょう。
BUGS
CONFIG-CHANGES
CREDITS
NEWS
README
README.gtkrc
TODO
emacsen-* ファイルパッケージをインストールする際にバイトコンパイル可能な Emacs ファイルがあなたのパッケージに含まれている場合、これらの emacsen-* ファイルを利用してそれを設定することができます。
これらのファイルはdh_installemacsen(1)によってパッケージ作成用の一時的なディレクトリにインストールされます。
不要ならこのファイルを削除してください。
package.examplesファイル
dh_installexamples(1)コマンドはこのディレクトリに列挙されたファイルを例としてインストールします。
package.init と package.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
不要なら、このファイルを削除してください。
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内を検索します。
package.info ファイル
パッケージにinfoページがある場合、package.infoにそれらを挙げて、dh_installinfo(1)を使用してインストールします。
{package.|source/}lintian-overrides ファイル
ポリシーが例外を認めているにも関わらず、lintianが間違った診断情報を報告してきた場合、package.lintian-overridesかsource/lintian-overridesを使って黙らせることができます。/usr/share/doc/lintian/lintian.html/index.htmlを読み、過度な使用は控えてください。
package.lintian-overridesはpackageと名づけられたパッケージのためのファイルで、dh_lintianコマンドによってusr/share/lintian/overrides/packageにインストールされます。
source/lintian-overridesはソースパッケージのためのファイルです。これはインストールされません。
manpage.*ファイル
プログラムはマニュアルページが必ず必要ですもしなければ、作らなければなりません。dh_makeコマンドはマニュアルページの雛形を作成します。マニュアルページがないコマンドのために、コピー、編集する必要があります。不要な雛形ファイルを削除するのを忘れないようにしてください。
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]
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
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
package.manpages ファイル
パッケージにマニュアルページがある場合、package.manpagesにそれらを挙げて、dh_installman(1)を使用してインストールします。
gentooパッケージのmanページとして、doc/gentoo.1をインストールするには、gentoo.manpagesファイルを以下のように作成します。
docs/gentoo.1
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です。このフィールドは、プログラムがどんなどんなインターフェースが必要かを規定します。デフォルトとして挙げられたもの（例：text や X11など）に変更してください。
次は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"
他にも、longtitle、icon、hintsなどのフィールドを追加できます。詳しくは
dh_installmenu(1)、 menufile(5)、
update-menus(1)、/usr/share/doc/debian-policy/menu-policy.html/を参照してください。
NEWS ファイル
dh_installchangelogs(1)コマンドでインストールします。
{post|pre}{inst|rm} ファイル
postinst、preinst、postrm、そして
prermファイルは [38]maintainer
scriptsと呼ばれています。これらのスクリプトは、パッケージを管理するアリアに置かれ、インストール、アップグレード、削除される際にdpkgによって実行されます。
メンテナ初心者のうちは、問題になることが多いのでmaintainer
scriptsを直接編集しないようにしましょう。詳しくはDebian
Policy Manual, 6 'Package maintainer scripts and installation
procedure'を参照し、dh_makeによって生成されるサンプルファイルに目を通してください。
もし私の忠告を無視して、maintainer scriptsを直接編集した場合は、 インストール、アップグレードだけでなく、 削除とパージのテストもしっかり行ってください。
新バージョンへのアップグレードはおとなしく、そして押し付けがましくしてはいけません。（現行のユーザは、バグが直されたことと新機能の追加以外については、アップグレードに気づかないのが理想です。)
アップグレードが出しゃばる必要がある場合(例えば構造が変わって、設定ファイルがあっちこちに散らばってしまった場合など)、パッケージのデフォルトを安全側に設定したり(例えばサービスを停止しておくなど)、最後の手段としてはポリシーに要求されるきちんとしたドキュメント(README.DebianとNEWS.Debian)を提供するなどの対策を考えるべきです。アップグレード際にmaintainer
scriptsでdebconfノートを呼び出すような嫌がらせはやめてください。
ucfパッケージは、maintainer
scriptsによって管理されているようなconffilesにされていない、ユーザによって変更されたファイルを保存し、conffileのように処理する仕組みを提供します。この仕組みによって、関連する問題を最小化しています。
これら、maintainer scriptsはなぜDebianを選ぶのかという理由の１つでもあります。これらの仕組みで、ユーザの邪魔をしないようにしましょう。
TODO ファイル
dh_installdocs(1)コマンドでインストールします。
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に関する問題を解決しています。
source/format ファイル
debian/source/formatファイルでは、ソースパッケージのための理想の書式を示すための行があります。
(完全なリストは、dpkg-source(1)を参照してください。)squeeze以降は、以下のどちらかになっているべきです。
3.0 (native)： Debianネイティブなパッケージ
3.0 (quilt)： それ以外の全て。
新しい3.0
(quilt)の書式はquiltパッチによる変更を
debian/patchesに記録します。そして、その変更は自動的にソースパッケージを展開するときに適用されます。[39]Debianの変更は、debianディレクトリ以下のファイル全てを含め、debian.tar.gzアーカイブに保存されています。この新しい書式は、特殊な方法を用いることなく、PGNアイコンなどのパッケージメンテナによるバイナリファイルを含めることが可能です。[40]
dpkg-sourceが3.0
(quilt)の書式でソースパッケージを展開する際、debian/patches/seriesに列挙されたパッチを自動的に適用します。--skip-patchesオプションで、展開時にパッチを適用しないようにできます。
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)).
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に３つのパッチを作りました。
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 UTCjoy-mg@debian.orgnabetaro@debian.or.jpyyatsuo@gmail.comuwabami@gfd-dennou.orglurdan@gmail.comosamu@debian.org