Fink

パッケージ作成 - 6. リファレンスマニュアル

6.1 ビルドプロセス

各フィールドの意味を理解するには, Fink のビルドプロセスに関する知識がある程度必要です. このプロセスは 5 段階になっていて,それぞれ解凍段階,パッチ段階,コンパイル段階,インストール段階,ビルド段階 と呼ばれます. 下記の例では /opt/sw にパッケージ gimp-1.2.1-1 をインストールするものとします.

解凍段階では,ディレクトリ /opt/sw/src/fink.build/gimp-1.2.1-1 が作成されてソースの tarball がそこに解凍されます. 大抵,解凍によりソースを含むディレクトリ gimp-1.2.1 が作られます. これ以降のステップはすべてこの中 (すなわち /opt/sw/src/fink.build/gimp-1.2.1-1/gimp-1.2.1) で行われます. 詳細はフィールド SourceDirectory, NoSourceDirectory や SourceNExtractDir (Nは数字) で変更できます.

パッチ段階では Darwin でビルドするためのパッチがソースに当てられます. フィールド UpdateConfigGuess, UpdateLibtool, Patch や PatchScript で指定されたアクションを,この順で実行します.

コンパイル段階ではソースの configure とコンパイルが行われます. 普通はスクリプト configure を適切な引数で起動し,コマンド make を実行することになります. 詳細はフィールド CompileScript を参照して下さい. ビルドに対しテストスイートが有効な場合 (fink 0.25 の新しい機能で,現在メンテナモードでビルド中に適用される), CompileScript の直後に TestScript が実行される.

インストール段階では,パッケージは仮ディレクトリ /opt/sw/src/fink.build/root-gimp-1.2.1-1 (%d と同じ) にインストールされます ("root-" が付いていることに注意). ディレクトリ /opt/sw にインストールされる予定のファイルは全て, /opt/sw/src/fink.build/root-gimp-1.2.1-1/opt/sw (%i すなわち %d%p に同じ) にインストールされます. 詳細はフィールド InstallScript を参照して下さい.

(Fink 0.9.9 で導入: フィールド SplitOff を用いると,単一のパッケージ記述から複数のパッケージを生成できます. インストール段階の最後のあたりでパッケージそれぞれに対して個別のインストールディレクトリが作られ, ファイルが適当なディレクトリに振り分けられます.)

ビルド段階では,仮ディレクトリからバイナリパッケージ (.deb ファイル) が作られます. この段階を直接制御することはできません. 代わりに,パッケージ記述からの様々な情報を使って dpkg 用の control ファイルが作成できます.

6.2 フィールド

フィールドを分類して解説します. 以下の一覧は完全ではありません. :-)

初期データ関連

FieldValue
Package

「パッケージ名」. 値には英小文字,数字及び ドット (.), プラス (+), ハイフン (-) を使うことができます. 下線 (_) と英大文字は使えません. 必須フィールド.

このフィールドで行われるパーセント展開は %N, %{Ni}, %type_raw[] と %type_pkg[] のみです.

Fink のパッケージ作成ポリシーでは, どのパッケージも常に同じオプションを有効にしてコンパイルされるようにします. あるパッケージに複数の variant を設ける場合は (フィールド Type の説明を参照), variant を区別する情報をフィールド Package に含めなければいけません (パーセント展開 %type_pkg[] の説明を参照). これにより,各 variant に固有の (どのオプションが有効かが分かる) 「パッケージ名」が与えられます. フィールド Package 内でパーセント展開 %type_pkg[] および %type_raw[] を使うことは最近導入されたばかりで, 古い Fink とは非互換であるため,注意が必要です. そのため,そのようなパッケージ記述はフィールド InfoN (ただし N>=2) 内に埋め込むようにします.

Version

upstream のバージョン. 値にはフィールド Package と同じ制限がある. 必須フィールド.

プログラムによっては被標準的なバージョン番号の付け方をしていて,ソートや当フィールドで認められていない字を使っている場合があります. このような状況では,上流のバージョンを適切にソートされるものに変えます. バージョン文字列のソートのされ方がわからない場合,dpkg コマンドをシェルで入力します.例えば,

 
 dpkg --compare-versions 1.2.1 lt 1.3 && echo "true"

これは "1.2.1" の方が "1.3" より小さいため "true" を出力します. 詳細は dpkg man ページを参照.

Revision

Fink パッケージとしてのリビジョン. upstream のバージョンが同じパッケージのパッケージ記述を書き換えたら,ここを 1 ずつ増やします. 最初は 1 で始めます. 必須フィールド.

Fink のポリシーでは,パッケージのバイナリ (コンパイル済み) 形式 (.deb ファイル)が変わるいかなる場合でも,Revision をあげなければなりません. 例えば,Depends や他のパッケージ一覧フィールド, Splitoff パッケージの追加・削除・名称変更, Splitoff パッケージ間でのファイルの移動など. パッケージのツリーを統合 (例えば 10.2 から 10.3) する場合,新しい方のツリーでは Revision を 10 (など,大きな数字) あげて古い方のツリーでのパッケージの更新に対応できるようにします.  

Architecture

パッケージ (および Splitoff) が対応している CPU アーキテクチャー一覧を,コンマ区切りで記述します. 現在のところ,powerpci386 が値として使用できます. このフィールドがあり,値が条件処理後にブランクでなく,ローカルマシンのアーキテクチャーが一覧にない場合,パッケージ記述は無視されます. このフィールドがない場合,あるいは値がブランクの場合は,全てのアーキテクチャーに対応していると見なされます. (0.24.11 CVS バージョン以降 の fink に導入)

gcc-4.0 以前のコンパイラを使うパッケージ (およびこれに依存するパッケージ) の場合に powerpc と宣言するのが, 現在のところの主な使用方法です.

このフィールドでは,値一覧にある値とパーセント展開を,通常の条件文法で使うことができます (詳細については,Depends フィールドを参照). これによって,特定の variant を特定のアーキテクチャーに制限することができます. 例えば:

  Package: foo-pm%type_pkg[perl]
  Type: perl (5.8.8 5.10.0)
  Architecture: (%type_pkg[perl] = 5100) x86_64

によって,foo-pm5100 という variant は x86_64 となり, foo-pm588 には値無しになります. ただし,アーキテクチャーの値が無いことは,そのアーキテクチャー用のパッケージではない,ということではありません.

上の例は、このフィールドのよくある使い方です。 10.6 の system-perl 5.10.0 は 32-bit (i386) でビルドできないものがあるので、 複数タイプの perl パッケージを特定のシステムに限定することができます。

Distribution

パッケージ (およびその Splitoff パッケージ) が対応しているコンマ区切りのディストリビューション一覧。 現在、有効な値は 10.4, 10.5, 10.6, 10.7, 10.8, 10.9, 10.10, 10.11, 10.12, 10.13, 10.14, 10.14.5, and 10.15 です。 このフィールドがあり、条件式判定で空欄でなければ、 マシンのディストリビューションが書かれていなければ、 fink はパッケージ記述を無視します。 このフィールドが無いか、あってもブランクの場合、すべてのディストリビューションが想定されます。 (fink 0.26.0 で導入。)

10.9, 10.10, 10.11, 10.12, 10.13, 10.14, 10.14.5 ディストリビューションは、 finkinfo ファイルが同じであるため、 これらのディストリビューションの一つに有効だが他ではそうでない場合が、このフィールドを使います。

このフィールドは、値リスト中の値とパーセント展開を条件式に使うことができます (Depends に詳しい情報があります)。 これを使って、variant を特定のアーキテクチャに制限することができます。例えば:

  Package: foo-pm%type_pkg[perl]
  Type: perl (5.12.3 5.12.4)
  Distribution: (%type_pkg[perl] = 5123) 10.7, (%type_pkg[perl] = 5123) 10.8

は、Distribution フィールドで foo-pm5123 は 10.7, 10.8 用で、 foo-pm5124 は空欄であることになります。

10.7 以降では python 2.5 がなく、 perl のバージョンがディストリビューションによって異なるため、 これらのパッケージはこのフィールドをよく使います。 参照のため、10.3 から 13.0 までの利用可能な perl バージョンを記します (太字の system はそのバージョンの system-perl です)。

    perl 5.6.0:  10.3
    perl 5.8.0:  10.3
    perl 5.8.1:  10.3, 10.4
    perl 5.8.4:  10.3, 10.4
    perl 5.8.6:  10.3, 10.4, 10.5
    perl 5.8.8:        10.4, 10.5, 10.6
    perl 5.10.0:             10.5, 10.6
    perl 5.12.3:                         10.7, 10.8, 10.9
    perl 5.12.4:                         10.7, 10.8, 10.9
    perl 5.16.2:                         10.7, 10.8, 10.9, 10.10, 10.11, 10.12, 10.13
    perl 5.18.2:                         10.7, 10.8, 10.9, 10.10, 10.11, 10.12, 10.13, 10.14, 10.14.5, 10.15, 11.0, 11.3, 12.0, 13.0, 14.0, 15.0
    perl 5.18.4:                                     10.9, 10.10, 10.11, 10.12, 10.13, 10.14, 10.14.5, 10.15, 11.0, 11.3, 12.0, 13.0, 14.0, 15.0
    perl 5.28.2:                                     10.9, 10.10, 10.11, 10.12, 10.13, 10.14, 10.14.5, 10.15, 11.0, 11.3, 12.0, 13.0, 14.0, 15.0
    perl 5.30.2:                                     10.9, 10.10, 10.11, 10.12, 10.13, 10.14, 10.14.5, 10.15, 11.0, 11.3, 12.0, 13.0, 14.0, 15.0
    perl 5.30.3:                                     10.9, 10.10, 10.11, 10.12, 10.13, 10.14, 10.14.5, 10.15, 11.0, 11.3, 12.0, 13.0, 14.0, 15.0
    perl 5.34.1:                                     10.9, 10.10, 10.11, 10.12, 10.13, 10.14, 10.14.5, 10.15, 11.0, 11.3, 12.0, 13.0, 14.0, 15.0

すべての variant をひとつの finkinfo ファイルに含める方法は、以下の通りです。

  Package: foo-pm%type_pkg[perl]
  Type: perl (5.8.8 5.10.0 5.12.3 5.12.4 5.16.2)
  Distribution: <<
    (%type_pkg[perl] = 588) 10.6,
    (%type_pkg[perl] = 5100) 10.6,
    (%type_pkg[perl] = 5123) 10.7, (%type_pkg[perl] = 5123) 10.8, (%type_pkg[perl] = 5123) 10.9,
    (%type_pkg[perl] = 5124) 10.7, (%type_pkg[perl] = 5124) 10.8, (%type_pkg[perl] = 5124) 10.9,
    (%type_pkg[perl] = 5162) 10.7, (%type_pkg[perl] = 5162) 10.8, (%type_pkg[perl] = 5162) 10.9
  <<

10.2 or 10.4-transitional などの古いディストリビューションは、対応している fink バージョンがこのフィールドを認識しないので、 省略しています。

Epoch

Fink 0.12.0 で導入: パッケージの「エポック」を指定します (指定されていない場合は 0 と見なされる). 詳細は Debian Policy Manual を参照. Fink と,元となっている Debian ツールは,name-version-revision をパッケージのユニークな識別子としています. epoch のみが異なるような複数のパッケージを作ってはいけません.

Description

パッケージの短い説明.(それが何であるか) 一覧表示に使われる1行紹介文なので,簡潔かつ分かり易く. (半角) 45文字以下が望ましい. 60文字を超えないこと. このフィールドは,「パッケージ名」と必ず一緒に表示されるので,「パッケージ名」を繰りかえす必要はありません. 必須フィールド.

Type

値が bundle の場合: バンドルパッケージは関連するパッケージをひとまとめにするために使われます. 各パッケージには,依存関係はありえますが,ソースコードにも,インストールされるファイルにも関連はありません. フィールド Source, PatchScript, CompileScript, InstallScript とそれらの関連フィールドは, バンドルパッケージでは無視されます.

値が nosource の場合: これは bundle と非常に似ています. これはソースの tarball が存在しないことを示します. よって何も取り寄せられず,解凍段階では空ディレクトリが作られます. しかしパッチ,コンパイル,インストールの各段階は通常通り実行されます. このようにして全てのソースコードをパッチと共に配布したり, または InstallScript を使ってディレクトリを作るだけのことができます. Fink 0.18.0 以降では Source: none と設定しても同じ挙動が実現できます. これにより,フィールド Type を他の目的に使えます (Type: perl など).

値が perl の場合 (Fink 0.9.5 以降): コンパイル及びインストール段階のスクリプトのデフォルト値が変わります. Fink 0.13.0 からは,この値の variant として perl $version が使えます. ここで "$version" は perl の特定のバージョンで,3つの数をピリオドで区切ったもの (perl 5.6.0 など).

CVS 版の Fink 0.19.2 以降では, 「プログラミング言語」または「プログラミング言語-バージョン」という記法は一般化され, メンテナの定義した任意のタイプとそれに関連するサブタイプが指定できるようになり, あるパッケージに複数のタイプを指定できるようになりました. タイプとサブタイプにはそれぞれブランク以外からなる任意の文字列が使えます. (しかし括弧,大括弧,カンマ,パーセント記号を使ってはいけません.) ここではパーセント展開は行われません. また,タイプの値は小文字に変換されます(が,サブタイプは変換されません). 複数のタイプを指定するにはカンマ区切りのリストを使います (各タイプに空白区切りのサブタイプリストが伴うことができます).

これに加えて「 variant 」という概念があります. 単一のパッケージ記述が,有効なコンパイルオプションだけが違う複数のパッケージを生成するとき, これらのパッケージは「 variant 」になります. このプロセスの鍵はサブタイプリストの利用です. 単一の文字列ではなく,文字列の空白区切りリストを括弧で括ったものを使います. Fink はリスト内のサブタイプ毎にパッケージ記述をコピーし,各コピー内ではリストを単一のサブタイプに置き換えます. 例:

Type: perl (5.12.3 5.12.4)

これは 2 つのパッケージ記述を生成します. 片方は Type: perl 5.12.3 と,もう片方は Type: perl 5.12.4 と同等になります. 特殊なサブタイプリスト "(boolean)" が意味するのは,(サブでない) タイプ自身とドット '.' から成るリストです. つまり以下の 2 つは同一です.

Type: -x11 (boolean)
Type: -x11 (-x11 .)

サブタイプリストの展開とそれに伴うパッケージ variant の作成は,再帰的に行われます. またサブタイプリストを持つタイプが複数ある場合は,あり得る組み合わせが全て生成されます.

Type: -ssl (boolean), perl (5.12.3 5.12.4)

Type 以外のフィールドから特定の variant のサブタイプを得るには,疑似ハッシュ %type_raw[] および %type_pkg[] を使います. 以下にパッケージ記述の例の一部を示します.

Info2: <<
Package: foo-pm%type_pkg[perl]
Type: perl (5.12.3 5.12.4)
Depends: perl%type_pkg[perl]-core
<<
Info2: <<
Package: bar%type_pkg[-x11]
Type: -x11 (boolean)
Depends: (%type_raw[-x11] = -x11) x11
CompileScript:  <<
  #!/bin/bash -ev
  if [ "%type_raw[-x11]" == "-x11" ]; then
    ./configure %c --with-x11
  else
    ./configure %c --without-x11
  fi
  make
<<
<<

fink 0.26.0 より, Type: -64bit によって新しいパーセント展開 %lib を制御することができます. また,LDFLAGS の既定値も変更になりました. こちらも新しい式 %type_num[] と用いることで,ライブラリの 32-bit バージョンと 64-bit バージョンを一つの .info ファイルから作ることが可能になりました. 以下はサンプルコードです:

Info2: <<
Package: foo%type_pkg[-64bit]
Type: -64bit (boolean)
Depends: (%type_raw[-64bit] = -64bit) 64bit-cpu
ConfigureParams: --libdir='${prefix}/%lib'
SplitOff: <<
 Package: %N-shlibs
 Files: %lib/libfoo.*.dylib
 Shlibs: <<
    %p/%lib/libfoo.1.dylib 1.0.0 %n (>= 1.0-1) %type_num[-64bit]
  <<
<<
<<
License

パッケージ配布の際にパッケージの従うライセンスの性質を表す. 値は パッケージのライセンス で示した選択肢から選ばなければいけない. それに加え,パッケージが実際にパッケージ作成・ポリシーに従うとき, すなわちライセンスのコピーがパッケージの doc ディレクトリにインストールされるときでなければ このフィールドを指定してはいけない.

Maintainer

パッケージに責任を負っている人物の名前とメールアドレス. 必須フィールド. 値は以下の形式で,名前とメールアドレスはそれぞれ一つだけとする.

名前 名字 <アカウント@ドメイン.example.com>

訳注: 名前はローマ字表記です. 順序は,特に指定はありませんが, YAMADA Taro などとするのが一般的です.

InfoN

このフィールドにより Fink はパッケージ記述の構文の非互換な変更に対処できます. 任意のバージョンの Fink には扱える "N" (整数) の最大値が設定されています. それより大きいNを持つフィールド InfoN はいずれも無視されます. よって、この機構の利用は必要最低限に止めなければいけません. そうでないと,古いバージョンの Fink のユーザが必然性なしに仲間外れにされます. この機構を使うには,パッケージ記述全体をフィールド InfoN の値に埋め込んでください. 複数行に渡る値の記述方法については,前述の「ファイル形式」を参照してください. 以下は,各 InfoN レベルにおいて追加された機能と,最初にサポートされた fink のバージョンです.

  • Info2 (fink>=0.20.0): .info ファイル中のメインの Package フィールドでのパーセント展開の使用. SplitOff (および SplitOffN) での %type_* パーセント展開の使用.
  • Info3 (fink>=0.25.0): .info ファイル中でインデントを正しく扱うことができる. RFC-822 複数行のサポートは終了. pkglist フィールドにコメントが可能.
  • Info4 (fink>=0.26.2): %V 展開を追加, ConfigureParams フィールド内で %lib の使用が可能.

依存性関連

FieldValue
Depends

そのパッケージがビルドできるようになる前にインストールされていなければいけないパッケージの一覧。 このフィールドではパーセント展開が行われる (「依存性関連」の他のフィールドでも同様: BuildDepends, RuntimeDepends, Provides, RuntimeDepends, Conflicts, Replaces, Recommends, Suggests および Enhances)。 普通、値は「パッケージ名」の単なるカンマ区切り一覧だが、 現在の Fink は、dpkgと同じ形式の「代替パッケージ」と「バージョン節」に対応している。 それらを全て盛りこんだ例:

Depends: <<
    daemonic (>= 20010902-1), 
    emacs | xemacs
<<

上のレイアウトは Depends や類似のフィールドでの好ましい書き方です。 << を使うことで複数行に対応し、 各パッケージをアルファベット順に書きます。 値が一つだけの場合は、一行の Field: value でも構いません。

本当の意味で「省略可能」な依存性を表現する方法がないことに注意. あるパッケージが別のパッケージがあってもなくても動作するとき, もう片方のパッケージが (存在するときであっても) 確かに使われていないか確かめるか, またはフィールド Depends に加えるかのどちらかを行うこと. ユーザにどちらの使い方をも提供したいときは,2 つの別々のパッケージ (例えば wget と wget-ssl) を作る.

0.18.2 CVS版以降の Fink では,条件付き依存性を記述できる. それを指定するには「パッケージ名」の前に (string1 op string2) を付ける. パーセント記法が普通に展開され,その後オペレータ op によって2つの文字列が比較される. op には以下のものが使える: <<, <=, =, !=, >>, >=. その直後に「パッケージ名」の記されたパッケージには,比較が真を返したときのみ依存性があると判断される.

この機能は,複数の似通ったパッケージを管理する際に手間を省くためにも使える. 例えば elinks と elinks-ssl は次のように列挙できるが,

Depends: <<
    (%n = elinks-ssl) openssl097-shlibs, 
    expat-shlibs
<<

これは elinks の方で

Depends: expat-shlibs

とし, elinks-ssl の方で

Depends: expat-shlibs, openssl097-shlibs

とすることと同じである.

この他の文法として, (string) 指定をすることもできる. string が null でない場合, "true" を返す.

Package: nethack%type_pkg[-x11]
Type: -x11 (boolean)
Depends: (%type_pkg[-x11]) x11

これにより,nethack-x11 は x11 パッケージに依存するが, nethack は依存しない.

Depends/BuildDepends を,複数のメジャーバージョンを持つ共有ライブラリパッケージに使用する場合,下記のようにしてはいけない:  

  Package: foo
  Depends: id3lib3.7-shlibs | id3lib4-shlibs
  BuildDepends: id3lib3.7-dev | id3lib4-dev

どちらのライブラリとも動作するパッケージであっても,どちらか一つ (適切に動作する高い方のバージョンが望ましい) のパッケージを選び,パッケージ内で統一する.

共有ライブラリポリシーで説明したように, -dev パッケージがインストールされるのは一つだけである. 各パッケージは -shlibs パッケージに関連づけられた異なるファイル名へ同じ名前のシンボリックリンクを作成することがある. しかし,パッケージ foo をコンパイルする際には実際の (-shlibs パッケージ内の) ファイル名の方が foo バイナリにハードコードされる. パッケージは,コンパイル時にインストールされた -dev に合った -shlibs パッケージを必要とする. このため, Depends でどちらも満たすようにはできないのである.

以前は,必須でないパッケージは暗黙のうちに必須パッケージに依存していたが, 現在はそうなっていない.

BuildDepends

Fink 0.9.0 で導入: ビルド時のみに適用される依存性のリスト. ビルド時には必要だが,実行時には使われないツール (flexなど) を示すのに使う. 書式は Depends と同じ. ビルドされる際にテストスイートが有効であれば, TestDepends がこのリストに追加される.

RuntimeDepends

Fink 0.32.0 で導入: ランタイム時のみに適用されインストールされる依存パッケージ一覧。 パッケージを実行中になければならないが、 ビルド時には使われないパッケージを一覧化します。 Depends と同じ書式です。

Provides

そのパッケージが「提供」すると考えられる「パッケージ名」のカンマ区切りの一覧。 パッケージ pine で Provides: mailer となっている場合, pine がインストールされると mailer についての全ての依存性は解決したものとされる. 普通,そのようなパッケージは pine のフィールド Conflicts や Replaces にも入れるとよい.

Provides 項目には,バージョン番号に関連した情報はない. 親パッケージから取得することも,Provides フィールド自体にはバージョン番号を特定するような仕組みなどもない. バージョンを指定する依存性があっても,Provides を持つパッケージによって満たすことはできない. 結果として,同一の代理パッケージを提供する variant が多数あるのは危険である. これによってバージョンを指定した依存性ができなくなるためである. 例えば, foo-gnome と foo-nogome が "Provides: foo" を提供する場合,"Depends: foo (> 1.1)" は動作しない.

Conflicts

そのパッケージと同時にインストールしてはいけない「パッケージ名」のカンマ区切りの一覧. バーチャルパッケージでは,そのパッケージが提供する「パッケージ名」をここに指定することができ,適切に扱われます. このフィールドはフィールド Depends のようにバージョン付きの依存性情報にも対応していますが, 代替パッケージには対応していない (意味をなさない)。 あるパッケージがそれ自身のパッケージ記述の Conflicts に入っていると、(暗黙のうちに) そこから取り除かれる。 (Fink のバージョン 0.18.2 CVS 以降で導入)

注記: Fink 自身はこのフィールドを無視します. これは dpkg に渡され,そこで適切に扱われます. 要するに,このフィールドが影響するのはビルド時でなく実行時です.

BuildConflicts

当該パッケージがコンパイル中にインストールされてはいけないパッケージの一覧. これは, ./configure やコンパイラが,望ましくないライブラリヘッダを見たり, 壊れることが分かっているツール (例えば,特定のバージョンの sed にあるバグ) のバージョンを使用することを避けるために使います. ビルド時にテストスイートが有効な場合, TestConflicts フィールド内のパッケージはこの一覧に追加されます。

Replaces

Conflicts と共に使われる. そのパッケ−ジが,衝突するパッケ−ジの機能の代わりになるだけでなく,共通するファイルを持つときに使われる. このフィールドがないと、dpkg はパッケージのインストール時にエラーを出すことがある。 これは、いくつかのファイルが別の方のパッケージに属しているためである。 こうした 2 つのパッケージが純粋な意味で互いに代替物であり,どちらか好きな方を選べるようなときはこれを使うとよい。 あるパッケージがそれ自身のパッケージ記述の Conflicts に入っていると, (暗黙のうちに) そこから取り除かれる. (Fink のバージョン 0.18.2 CVS 以降で導入)

注記: Fink自身はこのフィールドを無視します。 これは dpkg に渡され、そこで適切に扱われます。 つまり、このフィールドが影響するのはビルド時でなく実行時です。

Recommends, Suggests, Enhances

これらのフィールドはパッケージ同士の付加的な関係情報を指定する. 書式は他の依存情報フィールドと同じ. これら 3 つの情報は dpkg や apt-get によるインストール過程そのものには影響しないが, dselect や他のフロントエンドが,微妙な選択を行うユーザの判断を助けるのに使われる.

Pre-Depends

フィールド Depends の特別なもので,意味の上で厳密さが必要になる. このフィールドを使うのは,開発者用メーリングリストで議論を行い,確かに使う必要があるとの同意が得られた場合に限る.

Essential

必須パッケージを表す真偽値フィールド. 必須パッケージでないパッケージは必須パッケージに暗黙のうちに依存して構わない. dpkg は,このフィールドの指示に優先する特別なフラグを使わない限り,必須パッケージをシステムから取り除くことを拒む. 以前は,必須でないパッケージは暗黙のうちに必須パッケージに依存していたが,現在はそうではない.

BuildDependsOnly

Fink 0.9.9 で導入: 真偽値フィールド. 他パッケージはこのパッケージを BuildDepend に入れてもよいが, Depend に入れてはいけないことを示します. 通常の真偽値とは異なり,BuildDependsOnly は3つの状態があります. 未定義 (何も指定しない) の場合と明示的に False を指定するのとは異なります. 詳細は共有ライブラリポリシーを参照してください.

fink 0.20.5 より,このフィールドが設定されているか,設定されている場合その値が, パッケージがビルドされる際には .deb ファイルに記録されます. このため, BuildDependsOnly の値を変更したり,追加・削除時には Rivision 番号をあげる必要があります.

解凍段階関連:

FieldValue
CustomMirror

ミラーサイトのリスト. 各ミラーサイトは <場所>: <url> という書式に従って 1 行ずつ記述する. 場所 には大陸コード (例えば nam) や国コード (例えば nam-us) など (何でもよい) を使う. ミラーサイトはここに記述した順に試される. 例:

CustomMirror: <<
nam-US: ftp://ftp.fooquux.com/pub/bar
asi-JP: ftp://ftp.qiixbar.jp/pub/mirror/bar
eur-DE: ftp://ftp.barfoo.de/bar
Primary: ftp://ftp.barbarorg/pub/
<<

大陸及び国のコードは  /opt/sw/lib/fink/mirror/_keys にある. これは, fink および fink-mirrors パッケージの一部である.

Source

ソースの tarball の URL . HTTP または FTP でなければいけないが,Fink はそれを単に wget に渡すだけなので,実際には問題にならない. このフィールドは,ミラーサイトを示す特別な記法に対応している. すなわち mirror:<ミラー名称>:<相対パス> だ. こうすると Fink に ミラー名称 として設定された URL を探し, その後ろに 相対パス を付け加え,それを実際の URL として使う. Fink の認識する ミラー名称 の一覧は /opt/sw/lib/fink/mirror/_list (パッケージ fink または fink-mirrors の一部) に記される. または ミラー名称custom と書くことで, Fink にフィールド CustomMirror を使わせることもできる. URL が wget に渡される前に,パーセント記法の展開が行われる. %n は %type_ 系で示される variant データ全てを含む文字列に展開されることに注意. ここでは %{ni} を (場合によっては特定の %type_ の展開値と共に) 使うとよい.

Fink 0.18.0 以降では Source: none は特殊な意味を持ち,取り寄せるべきソースは存在しないことを表す. 詳細についてはフィールド Type の説明を参照. gnu という値は mirror:gnu:%n/%n-%v.tar.gz の, gnome という値は mirror:gnome:stable/sources/%n/%n-%v.tar.gz の省略形. デフォルト値は %n-%v.tar.gz (すなわちマニュアル・ダウンロード) になっている. 暗示的に Source を指定するのは廃止予定である (明示的に簡単なファイル名指定/手動ダウンロードするのは可).

テストスイートを実行するためだけに必要なソースは,TestSource および InfoTest 内の関連フィールドを使ってください.

SourceN

パッケージが複数の tarball から形成されている場合,それらはこの (省略可能) フィールドで指定する. N は 2 から始まる数. つまり最初の tarball (ある意味「メイン」になるもの) をフィールド Source に, 2 番目の tarball をフィールド Source2 に,という風になる. 値の書式は Source と共通だが, gnugnome という省略形は展開されない (結局,意味をなさない). バージョン 0.19.2 以降の CVS 版 Fink では, 2 以上の任意の (つまり,必ずしも連続しない) 整数を N に使える. しかし,重複はやはり許されない.

SourceDirectory

tarball が単一のディレクトリに展開されはするが, そのディレクトリ名が tarball のファイル名から拡張子を除いたものと異なる場合には,これを設定しなければいけない. つまり,普通なら "foo-1.0.tar.gz" という tarball は "foo-1.0" というディレクトリを生成する. しかし生成されるディレクトリ名がそれと異なる場合,そのディレクトリ名をこのフィールドで指定する. パーセント展開が行われる.

NoSourceDirectory

真偽値フィールド. tarball が単一のディレクトリに展開されないときにこのフィールドを設定する。 つまり、普通なら "foo-1.0.tar.gz" という tarball は "foo-1.0" というディレクトリを生成する。 しかし tarball を展開したときにファイルがカレントディレクトリで展開される場合は、 このフィールドを "true" に設定する.

SourceNExtractDir

普通、補助的な tarball は「メイン」の tarball と同じディレクトリで展開される。 それを特定のサブディレクトリ内で展開して欲しいときは,このフィールドでサブディレクトリ名を指定する. ご想像の通り, Source2ExtractDirSource2 で指定した tarball に対応する. 用例についてはパッケージ ghostscript, vim や tetex を参照.

SourceRename

このフィールドを使うと,ビルド時にソースの tarball をリネームできる。 これが便利なのは,例えば,ソースのバージョンがサーバのディレクトリ名には示されているが, tarball そのものはどのバージョンでも同じ名前のときだ。 (例えば http://www.foobar.org/coolapp/1.2.3/source.tar.gz というとき) このことで起きる問題を回避するためには次のようにすればよい.

SourceRename: %n-%v.tar.gz

この例では,ご想像の通り, tarball は /opt/sw/src/coolapp-1.2.3.tar.gz として格納されることになる.

SourceNRename

これはフィールド SourceRename と同じだが, SourceN で指定された N 番目の tarball のリネームに使う. 用例についてはパッケージ context や hyperref を参照.

Source-MD5

Fink 0.10.0 で導入: このフィールドではソースファイルの MD5 チェックサムを指定します. Fink はこの情報によりおかしなソースファイル, すなわち Fink パッケージの作成者が指定したものではない tarball を見分けられます. この問題の原因には,以下のようなものがあります: tarball のダウンロードに失敗した,upstreamのメンテナが知らないうちに tarball を更新した,トロイの木馬などの攻撃,など.

このフィールドの典型的な用例は次の通り.

Source-MD5: 4499443fa1d604243467afe64522abac

チェックサムの算出にはツール md5sum を使います. tarball /opt/sw/src/apache_1.3.23.tar.gz のチェックサムが知りたいときには, 次のコマンドを実行します (出力も一緒に示した).

fingolfin% md5sum /opt/sw/src/apache_1.3.23.tar.gz
4499443fa1d604243467afe64522abac  /opt/sw/src/apache_1.3.23.tar.gz

左に表示された値がここで必要なものです.

SourceN-MD5

Fink 0.10.0 で導入: フィールド Source-MD5 と同様ですが, フィールド SourceN に対応する N 番目の tarball の MD5 チェックサムを指定します.

Source-Checksum

Alternative method to list the checksum for a source file. This field takes a hash type, followed by the actual checksum. For example:

Source-Checksum: SHA256(5048f1c8fc509cc636c2f97f4b40c293338b6041a5652082d5ee2cf54b530c56)

Current valid checksums are MD5, SHA1, and SHA256. The shasum tool can be used to calculate SHA checksums:

$ shasum -a 256 /opt/sw/src/libexif-0.6.22.tar.xz 
5048f1c8fc509cc636c2f97f4b40c293338b6041a5652082d5ee2cf54b530c56  /opt/sw/src/libexif-0.6.22.tar.xz

The Source-Checksum field should only be used once per .info file. If both the Source-MD5 and Source-Checksum fields are present, Source-Checksum takes precedence.

SourceN-Checksum

This is just the same as the Source-Checksum field, except that it is used to specify the checksum of the tarball specified by the corresponding SourceN field.

TarFilesRename

Fink 0.10.0 で導入: このフィールドは tar 形式を使うソースファイルにのみ適用されます.

このフィールドを使うと,任意のソース tarball の中のファイルを, tarball の展開中にリネームできます. ファイルシステム HFS+ がケースインセンシティブである (大文字と小文字を区別しない) ことを回避するために非常に便利でしょう. 普通の Mac OS X システムでは,ファイル installINSTALL は衝突してしまいます. このフィールドを使うと, tarball をわざわざ再パッケージしなくとも (以前はこのような場合に行われていた), こういった問題を回避することができます.

このフィールドでは,単に,リネームされるファイルのリストを指定します. ワイルドカードも使うことができます. デフォルトでは,指定されたファイルは,いずれも元の名前に _tmp を後置したファイル名にリネームされます. デフォルト値に優先する指定をするには, フィールド FilesDocFiles と同様の書式を使います. すなわち 元のファイル名,コロン (:),新ファイル名,という順です. 例:

TarFilesRename: foo bar.* qux:quux
Tar2FilesRename: direcory/INSTALL:directory/INSTALL.txt
TarNFilesRename

Fink 0.10.0 で導入: フィールド TarFilesRename と同様ですが, フィールド SourceN に対応する N 番目の tarball に対して機能します.

パッチ段階関連:

FieldValue
UpdateConfigGuess

真偽値フィールド. "true" にすると,ビルド用ディレクトリ内のファイル config.guess と config.sub が Darwin に対応したバージョンに置き換えられます. その動作は,パッチ段階の,PatchScript が実行される前に行われます. これが必要だと分かっているとき, すなわち configure スクリプトが "unknown host" というメッセージで失敗するときのみ使うこと.

UpdateConfigGuessInDirs

0.9.0 CVS バージョン以降で導入: サブディレクトリのリストを指定します. これは UpdateConfigGuess と同じことを行いますが, ソースツリー中の複数のディレクトリに古い config.guess が入っているパッケージで便利でしょう. 以前はコピーや移動を行うよう PatchScript に手動で指定する必要がありましたが, この新フィールドを使えばディレクトリを単に列挙するだけでよくなりました. ビルド用ディレクトリ自身のファイルの更新には . とします.

UpdateLibtool

真偽値フィールド. "true" にすると,ビルド用ディレクトリ内のファイル ltconfig と ltmain.sh が Darwin に対応したバージョンに置き換えられます. その動作は,パッチ段階の, PatchScript が実行される前に行われます. これが必要だと分かっているときのみ使うこと. libtool 関連のスクリプトをバージョンの合わないものに取り換えると壊れるパッケージもあります。 詳細についてはlibtool のページを参照.

UpdateLibtoolInDirs

0.9.0 CVS バージョン以降で導入: サブディレクトリのリストを指定します. これは UpdateLibtool と同じことを行いますが, ソースツリー中の複数のディレクトリに古い libtool 1.3.x 系列のスクリプトが入っているパッケージで便利でしょう. 以前はコピーや移動を行うよう PatchScript に手動で指定する必要がありましたが, この新フィールドを使えばディレクトリを単に列挙するだけでよくなりました. ビルド用ディレクトリ自身のファイルの更新には . とします.

UpdatePoMakefile

真偽値フィールド. "true" にすると,サブディレクトリ po 内のファイル Makefile.in.in が,パッチの当たったものと取り換えられます. その動作は,パッチ段階の, PatchScript が実行される前に行われます.

パッチの当たった Makefile.in.in は DESTDIR の指定を優先し,メッセージカタログを, /opt/sw/lib/locale ではなく,確実に /opt/sw/share/locale に格納します. このフィールドを利用する前に,入れ換えによってパッケージを破壊していないこと,また入れ換えが本当に必要かどうかを確認すること. diff を実行すれば,パッケージ付属のものと Fink 向けのもの (/opt/sw/lib/fink/update 内にある) との違いが分かります.

Patch

patch -p1 <パッチファイル として適用されるパッチのファイル名. ここにはファイル名のみを指定します. 適切なパス (.infoのあるディレクトリ) は自動的に前置されます. このフィールドではパーセント展開が行われるので,典型的な値は単に %f.patch または %n.patch となります. PatchScript が指定されている場合,パッチはその後に別のステップとして実行されます.

%n は %type_ 系で示される variant データ全てを含む文字列に展開されることに注意. ここでは %{ni} を (場合によっては特定の %type_ の展開値と共に) 使うとよいでしょう. 単一のパッチファイルを管理し, 各 variant 固有の変更点を PatchScript に記述する方が, 各 variant 毎にパッチファイルを作るより手間が少ないでしょう.

PatchFile

Patch フィールドと同じ文法. このファイルへのフルパスは, %{PatchFile} パーセント展開で利用することができます. Patch と異なり, PatchFilePatchScript の一部分として適用されます. Fink は,そのアイルが存在し,読み取り可能であり,チェックサムが PatchFile-MD5 フィールドと適合していることを確認します.

PatchPatchFile を,ひとつのパッケージ記述中に同時に使うことはできません. PatchFile を使うパッケージは,BuildDepends: fink (>= 0.24.12) を宣言しなければなりません. 他の理由があればこれより大きいバージョン番号を使ってもかまいません.

PatchFileN

パッケージにパッチファイルが複数ある場合、 N = 2 から始まる連番のフィールドを追加することができます。 最初のパッチファイルは PatchFile、 2番目のパッチファイルは PatchFile2 となります。 PatchFileN を使うパッケージは、 BuildDepends: fink (>= 0.30.0) を設定する必要があります。 他の理由で必要があれば、より高いバージョン番号を設定してもかまいません。

PatchFile-MD5

PatchFile フィールドで与えられたファイルの MD5 チェックサム. PatchFile を使用する際には必須. (fink-0.24.12 で導入)

PatchFileN-MD5

PatchFileN の MD5 チェックサムです。 PatchFileN がある場合は必須です。 (fink-0.30.0 で導入。)

PatchScript

パッチ段階で実行されるコマンドのリスト. 下記のスクリプトの注意書きを参照してください. ここには,パッチを当てるか,またはパッケージに変更を加えるコマンドを指定します. 下記のスクリプトに関する注記もあわせて参照してください. コマンド実行前に,パーセント展開が行われます. PatchFile フィールドが存在する場合, PatchScript の既定値は:

patch -p1 < %{PatchFile}

もし、PatchFileN が設定された場合、

patch -p1 < %{PatchFileN}

です. PatchFile がない場合の既定値はブランクとなります. PatchScript を明示的に用いる場合, PatchFile を明示しなければなりません.

コンパイル段階関連:

FieldValue
Set環境変数名

コンパイルおよびインストールの段階の間,環境変数を設定します. コンパイラフラグなどを configure スクリプトや Makefile に渡すために使われます. 現在,対応している変数は次の通り: CC, CFLAGS, CPP, CPPFLAGS, CXX, CXXFLAGS, DYLD_LIBRARY_PATH, JAVA_HOME, LD, LDFLAGS, LIBRARY_PATH, LIBS, MACOSX_DEPLOYMENT_TARGET, MAKE, MFLAGS, MAKEFLAGS. 指定した値の中では前節で説明したパーセント展開が行われます. よく使われる例:

SetCPPFLAGS: -Wl,-strip_dead_dylibs

環境変数には,既定値を持つものもあります. この場合に値を指定すると,既定値に追加されます. 既定値を持つ変数とその値は:

CPPFLAGS: -I%p/include
LDFLAGS: -L%p/lib

fink 0.26.0 より,これらの既定値に例外が一つあります. Type: -64bit-64bit と定義されている場合, LDFLAGS-L%p/%lib -L%p/lib となります.

MACOSX_DEPLOYMENT_TARGET は OSX のバージョンを既定値として持ちます. これに値を指定することで (値の追加ではなく) 既定値を書き換えることができます.

NoSet環境変数名

真の場合,既定値を持つ変数 (上述の CPPFLAGS, LDFLAGS, CXXFLAGS など) の既定値を使いません. 例えば,LDFLAGS を unset のままにしたい場合, NoSetLDFLAGS: true とします.

UseMaxBuildJobs

true が設定された場合、 CompileScript と TestScript の間、 MAKEFLAGS 環境変数に -jN を 追加します。 N は、fink.conf の MaxBuildJobs から得られます。 NoSetMAKEFLAGS: true が使われても MAKEFLAGS に渡されます。 fink > 0.31.2 では、このフィールドが無いあるいは空欄の場合、デフォルト値は true です。

BuildAsNobody

fink >= 0.33.0 で、false が設定された場合、 fink は 権限のない fink-bld の代わりに、 root でビルドします。 このフィールドが無い場合、デフォルト値は true で、 fink-bld としてビルドします。

これ以前の fink バージョンでは、このフィールドは何もしません。

ConfigureParams

configure スクリプトに渡す付加的なパラメータ. (詳細は CompileScript を参照) Type: Perl となっていないパッケージに関しては, パラメータ --prefix=%p が,この値の前に追加されます. fink > 0.13.7 からは,このフィールドは perl モジュール Type: Perl にも適用されます; 既定の perl Makefile.PL 文字列が, ConfigureParams に与えられる値の前に追加されます.

テストスイートが有効でビルドする場合,TestConfigureParams の値が 通常の ConfigureParams の後に追加されます.

fink-0.22.0 より,このフィールドは条件をサポートする. 文法は Depends や他のパッケージ一覧フィールドと同様です. 条件は,スペースデリミティッドな "word" の直後に記述します. 例えば:

Type: -x11 (boolean)
ConfigureParams: --mandir=%p/share/man (%type_pkg[-x11]) --with-x11 --disable-shared

これは--mandir--disable-shared フラグを送り, -x11 variant の場合のみ --with-x11 を送ります.

このフィールドは、複数行宣言をすることで複数行に書くことができます。 このフィールドは、シェルコマンドとして扱われ、\ で行を分けることができます:

ConfigureParams: <<
    --mandir=%p/share/man \
    (%type_pkg[-x11]) --with-x11 \
    --disable-shared
<<

注記: 複数行で書く場合には、最後の行に条件付きパラメータを設定しないでください。 条件式が false の場合、直後のパラメータは評価されず、シェルを壊します。

GCC

当フィールドは,パッケージ内の C++ コードが使用する GCC-ABI を指定します. (このフィールドは,ABI が2度変わり,C++ コードと,それがリンクするライブラリが同じ ABI でなければならないために必要である.)

値としては: 2.95.2 (or 2.95), 3.1, 3.3 および 4.0 があります. 我々の知る限り,GCC の作者は,ある時点で GCC-ABI を固定するものと思われます. これ以上変わらないことを期待しましょう.

GCC フィールドはそれ自体は既定値を持たず,設定されなければ無視されます. しかし,各ツリーには,既定の g++ コンパイラが存在し,これに対応する GCC の値が想定されています. 想定値は,10.1 ツリーでは 2.95, 10.2 ツリーでは 3.1, 10.2-gcc3.3, 10.3, および 10.4-transitional ツリーでは 3.3, 10.4 と 10.7 ツリーでは 4.0 となります.

注記: GCC 値が既定値と異なる場合, (CC や CXX フラグを設定するなど) パッケージ内でコンパイラを指定する必要があります. また, (virtual) gcc パッケージへの依存性を指定します.

Fink 0.13.8 以降,このフラグが指定されると, gcc のバージョンは gcc_select によって調べられ, 誤ったバージョンのものが存在すると Fink はエラー終了します.

このフィールドは gcc コンパイラ間の移行をメンテナが知ることができるように Fink に加えられました。 gcc では, C++ コードの関わるライブラリ間で,実行可能・ファイル同士の (バージョン名に反映されない) 非互換が生じることがあります.

CompileScript

コンパイル段階で実行されるコマンドのリスト. 下記のスクリプトの注意書きを参照してください. パッケージの configure およびコンパイルを行うコマンドをここに指定します. 下記のスクリプトに関する注記もあわせて参照してください. コマンド実行前に,パーセント展開が行われます. 通常は以下の通り.

./configure %c
make

これは GNU autoconf を利用するパッケージには適切でしょう. Perl タイプ (フィールド Type で指定される) のパッケージのうち perl のバージョン指定がないものでは, 通常,次のようになります (0.13.4) .

perl Makefile.PL PREFIX=%p \
 INSTALLPRIVLIB=%p/lib/perl5 \
 INSTALLARCHLIB=%p/lib/perl5/darwin \
 INSTALLSITELIB=%p/lib/perl5 \
 INSTALLSITEARCH=%p/lib/perl5/darwin \
 INSTALLMAN1DIR=%p/share/man/man1 \
 INSTALLMAN3DIR=%p/share/man/man3 \
 INSTALLSITEMAN1DIR=%p/share/man/man1 \
 INSTALLSITEMAN3DIR=%p/share/man/man3 \
 INSTALLBIN=%p/bin \
 INSTALLSITEBIN=%p/bin \
 INSTALLSCRIPT=%p/bin
make
make test

タイプが perl $version となっていて,バージョンが指定されているものでは (例えば $version は 5.6.0 とする), デフォルト値は次のようになります.

perl$version Makefile.PL \
 PERL=perl$version PREFIX=%p \
 INSTALLPRIVLIB=%p/lib/perl5/$version \
 INSTALLARCHLIB=%p/lib/perl5/$version/$perlarchdir \
 INSTALLSITELIB=%p/lib/perl5/$version \
 INSTALLSITEARCH=%p/lib/perl5/$version/$perlarchdir \
 INSTALLMAN1DIR=%p/share/man/man1 \
 INSTALLMAN3DIR=%p/share/man/man3 \
 INSTALLSITEMAN1DIR=%p/share/man/man1 \
 INSTALLSITEMAN3DIR=%p/share/man/man3 \
 INSTALLBIN=%p/bin \
 INSTALLSITEBIN=%p/bin \
 INSTALLSCRIPT=%p/bin
make
make test

ここで, $perlarchdir はバージョン 5.8.0 以前では "darwin" であり, バージョン 5.8.1 以降では "darwin-thread-multi-2level" となります.

NoPerlTests

Fink 0.13.7 以降で導入: 真偽値フィールド. Perl モジュールのパッケージでのみ指定します. "true" にすると, CompileScript のうち make test の部分が, その perl モジュールのパッケージでは無視されます.

テストスイート:

FieldValue
InfoTest

fink 0.25 にて導入. 当フィールドは、テストスイートが有効な場合のビルド実行時にのみ使用される情報を含んだものです。 ここには他のフィールドが含まれます. 現在のところ,この中に TestScript がなければなりません. 他のフィールドはオプションです. 以下のフィールドが InfoTest にて許可されています:

  • TestScript: テストスイートを実行するスクリプト. このスクリプトは,スイートが終了するときは status を返します. 0 の場合は通ったことを示し, 1 の場合は警告があり, 他の値の場合は致命的と考えられる重大な問題があったことを示します. この3状態のため,スクリプト内で終了値を明示的に設定しなければなりません. 例えば, make check は悪いスクリプトです. これは終了時に,check のターゲットが存在しなければ status 1 を返すからです. make check || exit 2 は比較的良いスクリプトです.
  • TestConfigureParams: テストスイートを実行するために必要な追加ソースです. 関連する全てのフィールドもサポートされています. TestSource-MD5 または TestSource-Checksum は指定されなければなりませんTestSourceN や対応する TestSourceN-MD5 , TestSourceN-Checksum , TestTarFilesRename などを追加することも可能です.
  • TestSuiteSize: テストスイートどの程度かかるかのおよその時間を示します. 値は,small, medium, と large です. このフィールドは現在のところ無視されます.
  • その他のフィールド.InfoTest 内と外で定義されるフィールドに関して, スイートが有効な場合,InfoTest 内の値が他の値を書き換えます.

例:

InfoTest: <<
    TestScript: make check || exit 2
    TestConfigureParams: --enable-tests
<<

インストール段階関連:

FieldValue
UpdatePOD

Fink 0.9.5 で導入: 真偽値フィールド. Perl モジュールのパッケージでのみ指定します. "true" にすると, install, postrm および postinst スクリプトに, perl パッケージの提供する .pod ファイルを管理するためのコードを追加します. これには,中央のファイル /opt/sw/lib/perl5/darwin/perllocal.pod に .pod ファイルのデータを追加したり, そこから削除することも含まれます. (perl $version のように,5.6.0 などの perl の特定のバージョンと共にタイプが指定された場合は, それらのスクリプトが扱う中央 .pod ファイルは /opt/sw/lib/perl5/$version/perllocal.pod になる.)

InstallScript

インストール段階におけるコマンドの一覧. ここでコマンドを指定することで,必要な全てのファイルを一時 dpkg ディレクトリにコピーします. 下記のスクリプトに関する注記もあわせて参照してください. コマンド実行前に,パーセント展開が行われます. 通常,デフォルトでは:

make install prefix=%i

となります. このデフォルト値は GNU autoconf を利用するパッケージには適切です. Perl タイプ (フィールド Type で指定される) のパッケージのうち perl のバージョン指定がないものでは, デフォルト値は次のようになります.

make install INSTALLPRIVLIB=%i/lib/perl5 \
INSTALLARCHLIB=%i/lib/perl5/darwin \
INSTALLSITELIB=%i/lib/perl5 \
INSTALLSITEARCH=%i/lib/perl5/darwin \
INSTALLMAN1DIR=%i/share/man/man1 \
INSTALLMAN3DIR=%i/share/man/man3 \
INSTALLSITEMAN1DIR=%i/share/man/man1 \
INSTALLSITEMAN3DIR=%i/share/man/man3 \
INSTALLBIN=%i/bin \
INSTALLSITEBIN=%i/bin \
INSTALLSCRIPT=%i/bin

タイプが perl $version となっていて,バージョンが指定されているものでは (例えば $version は 5.6.0 とする), デフォルト値は次のようになります.

make install INSTALLPRIVLIB=%i/lib/perl5/$version \
INSTALLARCHLIB=%i/lib/perl5/$version/$perlarchdir \
INSTALLSITELIB=%i/lib/perl5/$version \
INSTALLSITEARCH=%i/lib/perl5/$version/$perlarchdir \
INSTALLMAN1DIR=%i/share/man/man1 \
INSTALLMAN3DIR=%i/share/man/man3 \
INSTALLSITEMAN1DIR=%i/share/man/man1 \
INSTALLSITEMAN3DIR=%i/share/man/man3 \
INSTALLBIN=%i/bin \
INSTALLSITEBIN=%i/bin \
INSTALLSCRIPT=%i/bin

ここで, $perlarchdir はバージョン 5.8.0 以前では "darwin" であり, バージョン 5.8.1 以降では "darwin-thread-multi-2level" である.

パッケージが対応しているなら,代わりに make install DESTDIR=%d を使うことが望ましい.

AppBundles

post-0.23.1 バージョンから導入: 当フィールドは,アプリケーションバンドルを %p/Applications にインストールし, /Applications/Fink にシンボリックリンクを作成します. 例:

AppBundles: build/*.app Foo.app
JarFiles

Fink 0.10.0 で導入: このフィールドは DocFiles に似ています. ここで指定した jar ファイルは %p/share/java/%n にインストールされます. 例:

JarFiles: lib/*.jar foo.jar:fooBar.jar

こうすると,ディレクトリ lib 内の全ての jar ファイルをインストールし, foo.jar を fooBar.jar としてインストールします.

また,これらの jar ファイル (正確にはディレクトリ %p/share/java/%n 内にある .jar で終わるファイル) は環境変数 CLASSPATH に確実に追加されませ. このフィールドにより, configure や ant といったツールが,インストールされた jar ファイルを適切に認識できるようになります.

DocFiles

このフィールドにより,ファイル README や COPYING を, パッケージの doc ディレクトリ (%p/share/doc/%n) に容易にインストールできます. 値にはスペース区切りでファイルのリストを指定します. ビルド用ディレクトリのサブディレクトリからファイルをコピーすることはできますが, それらのファイルは doc ディレクトリそのものに入れなければいけません (そのサブディレクトリに入れてはいけない). シェルのワイルドカードが利用できます. 単一のファイルを,実行時にリネームすることもできます. 新ファイル名はコロンで区切って後置してください. 例: libgimp/COPYING:COPYING.libgimp. このフィールドは InstallScript に適切な install コマンドを追加することで動作します.

Shlibs

Fink 0.11.0 で導入: このフィールドでは,そのパッケージでインストールされる共有ライブラリを指定します. それぞれの共有ライブラリに一つの行があります. これには,ライブラリの-install_nameと compatibility に関する情報は含まれます. 「パブリック」な共有ライブラリ (つまり,他のパッケージに使われる) の場合, ファイル名の後に,空白区切りで,-compatibility_version, この compatibility version の Fink パッケージ, ライブラリのアーキテクチャ (値は "32", "64", または "32-64", あるいは空欄; 空欄時の既定値は "32" .) 依存情報は foo (>= バージョン-リビジョン) という型式で指定しなければいけません。 ここで バージョン-リビジョン は、 (互換性バージョンの同じ) そのライブラリを利用可能にしてくれる Fink パッケージの一番古いバージョンを指します。 フィールド Shlibs の設定は「この名前がついていて compatibility_version がこれ以上のライブラリは, その Fink パッケージの今後のバージョンでも必ず含まれている」というメンテナからの保証に相当します. 「プライベート」な共有ライブラリは,ファイル名の前にビックリマークをつけ,代わりに compatibility やバージョン情報は書きません. 詳細は 共有ライブラリのポリシー を参照してください.

RuntimeVars

Fink 0.10.0 で導入: このフィールドにより,実行時に環境変数を何らかの固定された値に設定できます. (柔軟性が必要ならprofile.d スクリプトの節を参照.) そのパッケージがインストールされる限り, ここに指定した環境変数はスクリプト /opt/sw/bin/init.[c]sh によって設定されます.

環境変数の値にはブランクが使えます (値の末尾に来ると取り除かれます). また,パーセント展開が行われます. 例:

RuntimeVars: <<
SomeVar: %p/Value
AnotherVar: foo bar
<<

これは2つの環境変数 'SomeVar' および 'AnotherVar' を, それぞれ '/opt/sw/Value' (環境のインストールディレクトリの値による) および 'foo bar' に設定します.

このフィールドは InstallScript に適切なコマンドを追加することで機能します. それらのコマンドは,各環境変数に対してパッケージの profile.d スクリプトに setenv/export を追加します. よってパッケージメンテナ独自の環境変数は上書きされないので,自由に追加できます. これらの行はスクリプトに前置されるので,これらの環境変数をスクリプト内で利用できます.

SplitOff

Fink 0.9.9 で導入: 1 回のコンパイル/インストール操作で第 2 のパッケージを生成する. 詳細については,個別に書かれたsplitoff の節を参照.

SplitOffN

Fink 0.9.9 で導入: これはフィールド SplitOff と同様ですが, 1 回のコンパイル/インストール操作で第 3 ,第 4 のパッケージを生成するために使われます. バージョン 0.19.2 以降の CVS 版 Fink では, 2 以上の任意の (つまり,必ずしも連続しない) 整数を N に使うことができます. しかし,重複はやはり許されていません.

Files

Fink 0.9.9 で導入: フィールド SplitOff または SplitOffN の内部のみで使われます. ここでは,splitoff したパッケージのインストールディレクトリ %i に親パッケージのインストールディレクトリ %I から どのファイルやディレクトリを移動するかを指定します. 注記: これが実行されるタイミングは,親パッケージの InstallScript や DocFiles のコマンドの実行後で, splitoff したパッケージの InstallScript や Docfiles の実行前です。

ビルド段階関連:

FieldValue
PreInstScript, PostInstScript, PreRmScript, PostRmScript

これらのフィールドには,パッケージがインストール,アップグレード,または削除される時点で実行されるシェルスクリプトの断片を記述します. Fink はシェルスクリプトのヘッダ #!/bin/sh を自動的に追加します. また set -e で実行するので,どのコマンドが実行に失敗しても,スクリプトはその時点で停止します. また Fink は末尾に exit 0 を追加します. エラーの発生を示すには,非ゼロの終了コードでスクリプトから exit します. 第 1 実引数 ($1) は,どのアクションが実行されているかを示す値に設定されます. 値としては install, upgrade, remove および purge が使用できます. ただしこれらの他にも使われる値があることに注意してください. エラー回復や,別パッケージのインストールによりパッケージを取り除くことを表す値などがあります.

各スクリプトは以下のタイミングで実行されます.

  • PreInstScript: パッケージが初めてインストールされたときと,パッケージをそのバージョンにアップグレードする前.
  • PostInstScript: パッケージを解凍し,設定する前.
  • PreRmScript: パッケージが削除される前,または新しいバージョンにアップグレードされる前.
  • PostRmScript: パッケージが削除された後,または新しいバージョンにアップグレードされた後.

補足説明: アップグレードは新バージョンの ...InstScript と,旧バージョンの ...RmScript を実行します. 詳細については Debian Policy Manual, 第6章 を参照.

スクリプト内ではパーセント展開が行われます. 一般に,コマンドはフルパスを指定しなくても実行できます.

ConfFiles

ユーザが修正できる設定ファイルの空白区切りの一覧。 パーセント展開が行われます. ファイルは、%p/etc/%n.conf のように絶対パスで指定しなければいけません。 dpkg はここで指定されたファイルを以下のように特別な扱いをします. パッケージがアップグレードされたとき,新設定ファイルが提供され,しかもユーザが旧パッケージの設定ファイルが修正していた場合は, ユーザはどちらのバージョンを使うか尋ねられ,設定ファイルのバックアップが作られます. パッケージを "remove" しても,設定ファイルは削除されずにディスク上に残ります. 設定ファイルも削除されるのは "purge" を命じたときのみです。

InfoDocs

パッケージが %p/share/info にインストールする Info 文書のリスト. この設定により,Info ディレクトリ・ファイル dir を管理するための適切なコードが postinst および prerm スクリプトに追加されます.

注記: Info ドキュメントがスプリットされている場合、 数字のないファイルだけを使います。 例えば、パッケージに:

foo.info
foo.info-1
foo.info-2

があれば、

InfoDocs:  foo.info

と記述します。 この機能はまだ途中で、将来はよりよい制御のためのフィールドが追加されるかもしれません。

DaemonicFile

daemonic のサービスの説明を記述します. Fink は daemonic を使ってデーモン・プロセス (web サーバなど) のための StartupItems を生成したり削除します. 説明は %p/etc/daemons/名前.xml という名前のファイルとしてパッケージに追加されます. ここで 名前 はフィールド DaemonicName で指定される (デフォルト値は「パッケージ名」). このフィールドの値ではパーセント展開が行われます. パッケージが daemonic を利用するなら,それを依存性リストに加えなければいけないことに注意.

DaemonicName

daemonic サービスの記述ファイルの名前. 詳細はフィールド DaemonicFile を参照.

付加的データ関連:

FieldValue
Homepage

upstream パッケージのホームページの URL.

DescDetail

フィールド Description よりも詳しい説明. (それが何であるか,何のために使うものか?) 複数行に渡っても構いません. このフィールドは自動改行されずに表示されるので, (可能ならば) 手動で改行を挿入して各行 79 文字以内に収めてください.

DescUsage

パッケージを利用する上で必要になる情報を記述します. (そのパッケージはどのように使うものなのか?) 例えば「 WindowMaker を使う前に wmaker.inst を起動.」等を (訳注: 英語で) ここに記述します. 複数行に渡っても構いません. このフィールドはワードラップの恩恵に預らずに表示されるので, (可能ならば) 手動で改行を挿入して各行 79 文字以内に収めてください.

DescPackaging

パッケージ作成に関する注意書き. 「ファイルを適切な場所に置くために Makefile にパッチを当てる」等を (英語で) ここに記述します. 複数行も可。

DescPort

パッケージを Darwin に移植する場合に特有の注意書き. 「config.guess と libtool スクリプトはアップデートする. -no-cpp-precomp が必要」等を (英語で) ここに記述します. 複数行も可。

6.3 スプリットオフ (SplitOff)

Fink 0.9.9 で導入. 単一の .info ファイルで複数のパッケージを作成することが可能です. インストール段階は普通に始まり, InstallScriptDocFiles コマンドを実行します. フィールド SplitOffSplitOffN が存在すれば,それらに対しインストールディレクトリを作成します. SplitOffSplitOffN の中では,対応して新しく作られたインストールディレクトリは %i で, 親パッケージのインストールディレクトリは %I で参照されます.

フィールド SplitOffSplitOffN には,独自のフィールドが多数あります. 完全なパッケージ記述とよく似ていますが,抜けているフィールドもあります. 以下は SplitOff に含まれる部分パッケージ記述 (分野別)です.

%n-%v-%r は,パッケージのユニークな識別子として扱われるため, SplitOff (あるいは SplitOffN) を用いて (同じ VersionRevision で) Package を作成してはいけません. variant を使う際は,各 variant が独立したパッケージとなるようにしてください. つまり,以下のようなパッケージレイアウトは禁止されます:

Package: mime-base64-pm%type_pkg[perl]
Type: perl (5.12.3 5.12.4)
SplitOff: <<
  Package: mime-base64-pm-bin
<<

インストール段階では,まず親パッケージの InstallScriptDocFiles が実行されます. 次にフィールド SplitOffSplitOffN の処理が行われます. すなわち,そのそれぞれの中の Files のコマンドが実行され, 指定されたファイルやディレクトリが親インストールディレクトリ %I から splitoff パッケージのインストールディレクトリ %i に移されます. 続いて SplitOffSplitOffN の中の InstallScriptDocFiles などが順に実行されます.

現在の Fink では,最初に SplitOff が (あれば) 処理され,その後に SplitOff2, SplitOff3 などがさらに存在する場合,数の順に処理されます. しかしこの順番は将来変更されるかもしれません. よって, SplitOffSplitOff2 より先に処理される現状でしか正しく動作しない,次のようなコード

SplitOff: <<
  Description: Some header files
  Files: include/foo.h include/bar.h
<<
SplitOff2: <<
  Description: All other header files
  Files: include/*
<<

を避け,それぞれの中で明示的なファイル名を使うか,より精密なファイルグロブ (いわゆるワイルドカード) を使う方がよいでしょう.

ビルド段階では,各パッケージの pre/post install/remove スクリプトをビルド段階コマンドを使って作成します.

ビルドされるパッケージは,ライセンス条項を %i/share/doc/%n に明記する必要があります (%n の値は当然パッケージ毎に異なる). DocFiles はファイルを移動ではなくコピーすることに注意. よって DocFiles を使えば同一のドキュメントを各 splitoff パッケージ向けに複数回インストールできます.

6.4 スクリプト

フィールド PatchScript, CompileScript, InstallScript には,実行させたいシェルコマンドを記述できる. 形式は 2 種類ある.

このフィールドには単にコマンドを列挙すれば,シェルスクリプトと同様です. しかし,コマンドが一行ごとに system() によって実行される点が異なります. よって変数の設定やディレクトリの移動はその行内でのみ有効になります. 0.18.2 以降の CVS 版 Fink では, 通常のシェルスクリプトと同様に長い行を改行できます. 行末にバックスラッシュ (\) を置くと次の行は継続行になります.

または,任意のスクリプト処理系の完全なスクリプトを記述することもできます. その場合,他の Unix のスクリプトファイルと同様,第1行目は #! にインタプリタのフルパス名を続け, さらに必要なフラグを続けたものでなければいけない (#!/bin/csh, #!/bin/bash -ev など). その場合,フィールド *Script の値全体が一時ファイルにダンプされ,実行されます.

6.5 パッチ

パッケージを Darwin でコンパイルするために (または Fink と協調して動作するようにするために) パッチが必要な場合, パッチにはパッケージ記述の拡張子 ".info" を ".patch" に変えたファイル名を使い, .info ファイルと同じディレクトリに入れます. パッケージファイル名に完全名を使っている場合は,次のどちらかを使います (どちらも同等).

PatchFile: %n.patch

( variant がある場合、 %{ni}.patch の方がよいでしょう。) また、パッチファイルの MD5 サムを PatchFile-MD5 に指定し、 BuildDepends: fink (>= 0.24.12) (またはより新しい fink バージョン) を指定しなければなりません。

PatchFileN が使われている場合、 %n-purpose-of-patch.patch というようにわかりやすい名前をつけます。 PatchFileN-MD5 も使い、 BuildDepends: fink (>= 0.24.12) (またはより新しい fink バージョン) を指定しなければなりません。

PatchFile がある場合、 PatchScript のデフォルトは:

PatchScript: patch -p1 < %{PatchFile}

PatchFileN を使う場合、以下のものが上の PatchScript に追加されます:

patch -p1 < %{PatchFileN}

(パッチファイルを適用する前に書き換えるなど)PatchScript を指定すると、 これらのデフォルトは書き換えられます。

パッチファイルに、ユーザの選択した prefix を含める必要がある場合、 /opt/sw をパッチで使うのではなく、 @PREFIX@ などを使い:

PatchScript: sed 's|@PREFIX@|%p|g' < %{PatchFile} | patch -p1

とします。 パッチは unidiff 形式で、以下のように作成します:

diff -urN <originalsourcedir> <patchedsourcedir>

emacs でファイルを編集した場合、 diff コマンドに -x'*~' と追加すると、自動的に生成されるバックアップファイルを除くことができます。

もう一つの注意点は、巨大すぎるパッチを cvs に入れないことです。 ウェブか FTP サーバにおき、SourceN: フィールドで指定します。 ウェブサイトを持っていない場合、 fink プロジェクトの管理者が fink サイトから提供できるようにします。 パッチが約 30Kb をこえるなら、別々にダウンロードすることを検討してください。

6.6 Profile.d スクリプト

パッケージが実行時に何らかの初期化 (環境変数の設定など) を必要とするなら, profile.d スクリプトを使えばよいでしょう. これらのスクリプト断片はスクリプト /opt/sw/bin/init.[c]sh によって読み込まれます. 通常,全ての Fink ユーザがシェルのスタートアップファイル (.cshrc またはそれと互換なファイル) でそれを読み込むようになっています. パッケージの方では,どのスクリプトにも2種類を用意しなければいけません: sh 互換シェル (sh, zsh, bash, ksh, ...) 用と, csh 互換シェル (csh, tcsh) 用です. 両スクリプトとも /opt/sw/etc/profile.d/%n.[c]sh としてインストールされる必要があります. (ここで %n は,他と同様に「パッケージ名」を表す.) また,正しく読み込まれるためには,それらのパーミッションは実行,読み込みが共に可能でなければいけません. (すなわち,それらのインストールには引数 -m 755 を付ける.)

環境変数をいくつか設定したいだけなら (QTDIR を '/opt/sw' にする,など),フィールド RuntimeVars を使えばよいでしょう. このフィールドはまさにその作業を簡略化するために用意されたものです.