[ 前のページ ] [ 目次 ] [ 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として登録するためによく使われる方法が2つあります。
/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を選ぶのかという理由の1つでもあります。これらの仕組みで、ユーザの邪魔をしないようにしましょう。
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
に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 UTCjoy-mg@debian.org
nabetaro@debian.or.jp
yyatsuo@gmail.com
uwabami@gfd-dennou.org
lurdan@gmail.com
osamu@debian.org