Available Languages: | Deutsch | English | Français | 日本語 (Nihongo) | 中文 (简) (Simplified Chinese) |

Fink パッケージの作成方法

このマニュアルではパッケージ管理システム Fink 用のパッケージ記述 (Package Description) の作成方法を解説します. また Fink ディストリビューションのポリシーとガイドラインも解説します. パッケージ記述の書式もディストリビューションのポリシーも共に発展途上です. "Last changed" (最終更新) 情報とこのページの CVS タグを確認することで,更新されているかがわかります. ここで扱うのはパッケージ管理システム Fink の「0.9.0 以降の開発版」で使われる書式とポリシーの説明です.

Fink 用にパッケージを作成した場合,メーリングリスト fink-devel を購読するとよいでしょう. Fink に貢献する方法を探していて,関連分野のスキルをお持ちなら,是非とも 現在メンテナのいないパッケージ のメンテナンスをお願いいたします.

Contents

1 始めに

1.1 パッケージとは何か?

パッケージとは,基本的単位を構成するソフトウェアのまとまりを指します. 典型的なパッケージには,例えば実行可能プログラム,それが必要とするデータファイル, 国際化のためのメッセージカタログ,そしてドキュメントが含まれます. Fink のパッケージには2種類の形式があります. すなわちパッケージ記述情報と,そのままインストール可能なバイナリパッケージファイルです.

パッケージ記述情報は人でも読めるテキストファイルで, パッケージをビルドするために必要な (つまりバイナリパッケージファイルを作るのに必要な) 全ての情報を含みます. それにはメタデータ (パッケージ名や目的を記した文章) やソースコードの URL の他, パッケージの configure ,コンパイルやバイナリパッケージの生成に必要な命令が書かれています.

バイナリパッケージファイルとは,パッケージを実際に構成する各ファイルのアーカイブを指し, 中には実行可能プログラム,データファイル,メッセージカタログ,ライブラリ,インクルードファイルなどが含まれます. また,そのパッケージに関するメタデータも含まれます. バイナリパッケージは既にそのまま使用できる形式ですので,インストールとは主に中身の展開です. Finkはパッケージ管理システム dpkg の上に構築されたシステムですので, バイナリパッケージには dpkg の形式が使われ,拡張子は .deb です.

1.2 パッケージの区別

パッケージは3つの文字列で区別されます. すなわちパッケージ名,version と revision です. これらのいずれにも英小文字 (a から z),数字 (0 から 9), ダッシュ (-; 註: revision 中には使えません),プラス (+),ドット (.) のみが使えます. この他の字は使えません. 特に,大文字と下線 (_) が使えないことに注意して下さい.

「パッケージ名」にはソフトウェアの名前 (openssh など) をそのまま使います. version は「upstream バージョン」とも呼ばれますが,これには元となるソフトウェアパッケージのバージョンを使います. version には (2.9p1 のように) 数字以外を使っても構いません. Fink も dpkg もそれらを認識してソートできます. revision はカウンタで,最初は 1 で始まり,パッケージ記述情報への変更回数に応じて 1 ずつ増加します. 「upstream バージョン」が変化すると再び 1 に戻ります. revision にダッシュを使ってはいけません. Fink パッケージの正式名称はパッケージ名,version と revision をダッシュでつないだもので, "openssh-2.9p1-2" などという形式になります.

2 パッケージ記述

2.1 ツリーレイアウト

パッケージ記述はディレクトリ /opt/sw/fink/dists 下のディレクトリ finkinfo から読み込まれます. 「ツリー」の設定はファイル /opt/sw/etc/fink.conf にあり,これでどのディレクトリを読むかを指定します. パッケージ記述ファイルの名前は,Fink パッケージの正式名称に拡張子 ".info" を付けたものです. Fink 0.13.0 以降では,パッケージのアップデートの手間を省くための, 「パッケージ名」に拡張子 ".info" を付けただけの簡略形式が便利です. fink 0.26.0 の時点で,ファイル名を特定するにはいくつかの方法があります: 推奨されるのは,他の必要なパッケージファイルと整合性のとれる最も短いものです. ファイル名の形式は: variant のないパッケージ名,オプションとして architecture,オプションとして distribution,オプションとして version または version-revision を ハイフンでつなぎ,".info" で終えます. "architecture" と "distribution" は,対応するフィールドが定義され,値を一つだけ持つ場合に限ります.

パッケージ記述ツリーはいくつかの階層のディレクトリにまとめられています. 最上段から順の説明:

2.2 ファイル形式

パッケージ記述ファイルはキーと値の組 (別名「フィールド」) の単純なリストです. 次のように,各行はキーで始まり,コロン (:) 以降が値になります:

Key: Value

複数行に渡らざるを得ないフィールドには 2 通りの記法があります.

1 つ目はシェルスクリプトで言う "here-document" 風の形式で,こちらの方が望ましいです. この方式では,第1行は,キー,コロンの次に値として << が続くものになります. その後の行が全て実質的な値となり,行頭に << を置いた行が値の終端区切りです. 例:

InstallScript: <<
mkdir -p %i/share/man
make install prefix=%i mandir=%i/share/man
mkdir -p %i/share/doc/%n
install -m 644 COPYING %i/share/doc/%n
<<

この形式ではインデントを付けて構いません. その方が読みやすくなるでしょう.

here-document 形式はネストできます. これはフィールド SplitOffSplitOffN でよく使われます. これらのフィールドは他の (複数行の) フィールドを含むことができ, here-document 形式を使えば含まれる方のフィールドにも複数行の値が使えます. 内側でも同じ区切り << が使われます.

SplitOff: <<
    Package: %N-shlibs
    InstallScript: <<
        ln -s %p/lib/libfoo.2.dylib %i/lib/libfoo.%v.dylib
    <<
<<

この形式では,空行と,シャープ (#) で始まる行は無視されます. キー (フィールド名) では大文字と小文字の区別がないので, InstallScriptinstallscriptINSTALLSCRIPT とも書けますが, 最初の InstallScript という方式が読み易いのでこれを使いましょう. 真偽値を取るフィールドでは "true", "yes", "on", "1" (大文字,小文字の区別なし) のいずれも「真」となり,それ以外は全て「偽」になります.

2.3 パーセント展開

簡便のため, Fink はいくつかのフィールドで以下の文字列展開をサポートします. 曖昧さをさけるため,波括弧を使ってどの文字までがパーセント展開を受けるのかを明示できます. 例えば %{n}%n と同義です.

%n

name.「パッケージ名」.

%N

Name.親パッケージの「パッケージ名」. (SplitOff 内部以外では %n と同じ)

%e

epoch.パッケージの「エポック」.

%v

version.「バージョン」.

%V

パッケージの完全な Version で, Epoch がある場合にはこれも自動的に追加されます. InfoN レベルが 4 以上の場合のみパーセント展開されるので,注意してください.

%r

revision.パッケージの「リビジョン」.

%f

full package name.%n-%v-%r と等価. エポックは %f に含まれない.

%p, %P

prefix.Fink のインストール場所.例: /opt/sw. 全てのユーザーが /opt/sw に Fink をインストールしているわけではない. %p で正しいパスを取得する.

%d

destination.パッケージ化するツリーのビルド先. 例:/opt/sw/src/fink.build/root-gimp-1.2.1-1 この一時ディレクトリはパッケージをコンパイルする際のインストール段階でルートディレクトリの役を果たす. root-%f%p/src の中にあることを当てにしてはいけない. ユーザが設定ファイル /opt/sw/etc/fink.conf でフィールド Buildpath を指定すればこの場所は変わってしまう.

%D

Destination. 親パッケージのビルド先 (SplitOff 内部以外では %d と同じ).

%i

完全な install-phase prefix.インストール段階での一時インストールディレクトリの完全名. %d%p と等価.

%I

Install prefix. 親パッケージのインストール段階での一時インストールディレクトリの完全名. %D%Pと等価 (SplitOff 内部以外では %i と同じ).

%a

patches. パッチを検索するディレクトリパス.

%b

build. ビルドディレクトリ.例: /opt/sw/src/fink.build/gimp-1.2.1-1/gimp-1.2.1 %f%p/src の中にあることを当てにしてはいけない. ユーザが設定ファイル /opt/sw/etc/fink.conf でフィールド Buildpath を指定すればこの場所は変わってしまう. 最も内側のディレクトリ名は, Source ファイル名か, (もしあれば) SourceDirectory フィールドの値となります. ただし, NoSourceDirectorytrue であれば使用されません.

注記: %b は使わざるを得ないときだけ使用して下さい. ビルドディレクトリはスクリプトが実行されるときのカレントディレクトリです. コマンドでは相対パス名を使わなければいけません.

%c

configure に渡すパラメータ: --prefix=%p の他,フィールド ConfigureParams で指定したもの全て. (Type: perl を持つパッケージについては,挙動が異なる; この場合,%c 中の --prefix=%p の代わりに,perl パッケージをビルドする既定フラグが用いられる.)

%m

machine architecture. マシンアーキテクチャーを示す記号で,uname -p の出力. 現在のところ, PPC マシンでは 'powerpc' , x86 マシンでは 'i386' という値になる (0.12.1 CVS版以降の Fink で導入).

%%

パーセント記号そのもの (これ以降にどの文字が続いても展開されない). 展開は厳密に左から右に行われるので, %%n はパッケージ名とは一切関係なく,単なる文字列 %n を表すことになる. (fink-0.18.0 で導入)

%type_raw[タイプ], %type_pkg[タイプ], %type_num[タイプ]

指定された タイプ のサブタイプを返す疑似ハッシュ. 詳細は後述のフィールド Type の解説を参照. _raw 形式はサブタイプの文字列をそのまま返すが, _pkg 形式はドット (.) を 全て取り除いた文字列を返す. (Fink のパッケージ命名規約の「プログラミング言語-バージョン」方式に使う.他にもうまい使い方があるかも). (0.19.2 CVS 版以降の Fink で利用可能) _num 式 は fink-0.26.0 より導入. Type から数字以外を全て除く.

%{ni}, %{Ni}

"name invariant". %n や %N と似ているが, %type_pkg[] と %type_raw[] に当たる部分は全て空白に変わる. (0.19.2 CVS 版以降の Fink で利用可能) %n や %N を使った際の混乱を避けるためには %{ni} や %{Ni} を使うこと.

%{default_script}

PatchScript, CompileScript および InstallScript フィールドでのみ有効で, デフォルトの値. 値は Type に依存するが,常に存在する(または空欄). SplitOff (または SplitOffN) 中の InstallScript で使われる場合, SplitOff パッケージの InstallScript デフォルトが空欄であっても, この展開はのデフォルトになる.

%{PatchFile}

PatchFile フィールドで示されたファイルのフルパス. (fink-0.24.12 にて導入)

%{PatchFileN}

PatchFileN フィールドで示されたファイルのフルパス. (fink-0.30.0 にて導入)

%lib

Type: -64bit が -64bitと定義されている場合, powerpc マシン上では lib/ppc64 と展開され, intel マシン上では lib/x86_64 と展開される (64-bit ライブラリの正しい保存場所). それ以外は, lib と展開される. (fink-0.26.0 で導入)

InfoN レベルが 4 以上でないと, ConfigureParams フィールド内での使用はできませんので,注意してください.

3 パッケージ化ポリシー

3.1 パッケージのライセンス

Fink に含まれるパッケージのライセンスは多岐に渡ります. 大部分は,ソース全体の再配布と,特に実行可能ファイルの配布に何らかの制限を課します. パッケージの中には,ライセンスのために Fink でバイナリ配布を行えないものもあります. そのため,パッケージのメンテナがライセンスを注意深くチェックすることが大変に重要です.

バイナリ・パッケージとして配布される全てのパッケージは,ライセンスのコピーも含んでいなければいけません. ライセンスは doc ディレクトリすなわち %p/share/doc/%n にインストールされます. (InstallScript では,当然ながら %p でなく %i を使う必要があります. フィールド DocFiles ににより細部は自動的に処理されます.) 元のソースに明示的なライセンスが存在しない場合,パッケージの状態を記した短いテキストを代わりとします. 大半のライセンスは,ライセンスが配布物に必ず含まれるよう定めています. Finkのポリシーは「ライセンスを含めるよう明示的に要求されなくとも,常にライセンスを含める」ことです.

バイナリディストリビューションのメンテナンスを自動化するため, 配布されるどのパッケージにもフィールド License がなければいけません. このフィールドはライセンスの性質に関するもので, 当該パッケージをバイナリディストリビューションに含めるかどうかを決定する際に参照されます. このフィールドは実際のライセンス条項が上記のようにバイナリパッケージに含まれているときのみ存在できます.

フィールド License を有効に使用するため,値は以下の既定の選択肢からのみ選べます. 下記の選択肢に当てはまらないパッケージの場合,開発用メーリングリストへ質問を投げかけて下さい.

3.2 GPL と OpenSSL

(2005年4月より施行)

OpenSSL ライセンスが GPL と LPGL ライセンスが明らかに整合性を欠いていることから, openssl にリンクをしている fink パッケージのうち, GPL または LGPL ライセンスを使用しているものは "Restrictive" となります. Fink プロジェクトはこれらのパッケージをバイナリ配布しないことになりますが,利用者は自己判断でコンパイルすることができます.

パッケージメンテナは,元のパッケージライセンスを DescPackaging に記述してください.

3.3 基盤システムへの干渉問題

Finkは基盤システムから分離したディレクトリにインストールされるアドオン・ディストリビューションです. パッケージは Fink のディレクトリ外にファイルをインストールしてはしてはいけません.

他に方法がないときには例外が設けられます (XFree86 など). この場合,パッケージはインストール前に既存のファイルを調べ,上書きの恐れがある場合はインストールを中止する必要があります. そのようなパッケージは, Fink ディレクトリ外にインストールしたファイルはそのパッケージが取り除かれるときに全て削除されること, あるいはそのようなファイルは残しても問題がないことを保証しなければいけません (すなわち,実行可能ファイルを呼び出す前にそれが存在するかどうか調べるなどする必要があります).

3.4 共有ライブラリ

Fink は共有ライブラリに関して新しいポリシーを定め, 2002 年 2 月から施行しています. 以下では Fink 0.5.0 と共に公布された,共有ライブラリについてのポリシー第 4 版です。 これは、2006年12月の時点で、 64 bit ライブラリを扱うために、 2008年1月時点で、プライベートな共有ライブラリを扱うために修正されています。 (さらに、2008年6月に共有ライブラリを実行する暫定期間への参照を削除しました。) 最初に要点をかいつまんで述べ,後から詳細に移ります.

共有ライブラリをビルドするパッケージは, Fink ポリシーに従って共有ライブラリを扱う必要があります. すなわち以下の約束に従わなければいけません.

パッケージはプライベートな共有ライブラリをインストールすることがあることに注意してください。 これは、他のパッケージからリンクされることを意図しています。 この場合、ライブラリは別パッケージになる必要があります。 共有ライブラリを含むパッケージは、Shlibs がなければなりません。 また、他のプログラムが誤ってリンクしないように、 メンテナは %i/lib (またはその 64 bit 版) 内にある主要ライブラリが libfoo.dylib からの最終的なリンクを保存しないよう努めてください。

このポリシーに反し,パッケージを分割しない場合には,フィールド DescPackaging に理由を記述しなければいけません.

パッケージによっては,主パッケージと -shlib パッケージを作成するだけで済みます. しかしさらに別のパッケージが必要な場合もあります. 新設されたフィールド SplitOff を使うとこの作業の手間が省けます.

3つのパッケージに分ける必要があるとき,それらの命名法は, パッケージの実質的な中身がライブラリなのか (選択肢 1) 実行可能プログラムなのか (選択肢 2) によって変わります. 選択肢 1 では次の構成を使います.

PackageContents
foo-shlibs

共有ライブラリ

foo

ヘッダ

foo-bin

実行可能プログラムなど

選択肢 2 では次の構成を使います.

PackageContents
foo-shlibs

共有ライブラリ

foo-dev

ヘッダ

foo

実行可能プログラムなど

詳細なポリシー

以下ではさらに詳しく解説します. ポリシーが実際に適用された例としては Fink パッケージ libpng, libjpeg や libtiff を参照して下さい.

Darwin にポートされたソフトウェアは可能な限り共有ライブラリをビルドしなければいけません. (パッケージメンテナが,必要に応じて共有ライブラリの他に静的ライブラリもビルドすることは自由です. または,静的ライブラリのみを含むパッケージを登録することも問題ありません.) 他のパッケージで使われると想定される共有ライブラリをビルドする場合,ふたつの相互関連する Fink パッケージを作成しなければいけません. それらの名称は例えば foo と foo-shlibs となります. 共有ライブラリは foo-shlibs に,ヘッダは foo に入ります. これら 2 つのパッケージを単一の .info ファイルから作れます. それには後述のフィールド SplitOff を使います. (現実には3つ以上のパッケージに分割する必要がある場合も多いですが, この場合は SplitOff2, SplitOff3 などを使えばだいじょうぶです.)

共有ライブラリがビルドされるソフトウェアパッケージは、 メジャーバージョン番号 N がなければなりません。 これは、共有ライブラリのファイル名にも含まれています (例 libbar.N.dylib)。 「メジャーバージョン」は,ライブラリの API にパッケージ間で非互換な変更が加えられたときのみ変わることになっています. Fink では,名称は以下の要領で作成されます. すなわち, upstream パッケージ名が bar なら,そのFinkパッケージの名前は barN と barN-shlibs になります. (この規則が厳密に適用されるのは新規に作られるパッケージと「メジャーバージョン」が変わったパッケージのみです.) 例えば既存の Fink パッケージ libpng の「メジャーバージョン」は 2 でしたが,最近, 3 に変わりました. そこで当面は libpng に関わる Fink パッケージは4種類あることになります: libpng, libpng-shlibs, libpng3, libpng3-shlibs です. libpng と libpng3 はどちらか片方しか同時にインストールできませんが, libpng-shlibs と libpng3-shlibs は同時にインストールできます. (これら 4 つのパッケージのビルドに必要な .info ファイルは 2 つだけであることに注意してください.)

共有ライブラリ自身とそれに関わるファイルは,パッケージ barN-shlibs に入ります. また「インクルード」ファイルとその他のファイルはパッケージ barN に入ります. これら 2 つに重複して含まれるファイルがあってはならず,また barN-shlibs に含まれるどのファイルのパス名にも, 何らかの形で「メジャーバージョン」 N が含まれなくてはいけません. 多くの場合,パッケージは,典型的には %i/lib/bar%i/share/bar/ にインストールされるようなファイルを実行時に必要とします. そのときはインストール先パスを %i/lib/bar/N%i/share/bar/N/ に修正しなければいけません.

「メジャーバージョン」が N であるようなパッケージ bar に依存するパッケージは,全て次の依存情報を使うことになります.

Depends: barN-shlibs
BuildDepends: barN

他のパッケージが、barN 自体に依存することは許されていません。 (2002年2月以前からあるパッケージについては、まだそのような依存性になっているかもしれません。) これは、他の開発者には真偽値で連絡されます。

BuildDependsOnly: True

共有ライブラリと実行可能プログラムの両方を含むパッケージの場合,実行可能プログラムが (ビルド時だけでなく) 実行時に必要であれば, それらの実行可能プログラムは barN-bin という名の第 3 のパッケージに分離されます. 他のパッケージが barN-shlibs の他に barN-bin に依存しても構いません.

「メジャーバージョン」が N の共有ライブラリをビルドするとき,その共有ライブラリの "install_name" が %p/lib/libbar.N.dylib になることが重要です. (install_name は,ライブラリに対し otool -L,64bit ライブラリの場合は otool64 -L を実行すれば分かります.) 実際のライブラリファイルのインストール先は,

%i/lib/libbar.N.x.y.dylib

でなければならず,パッケージ側では次のようにシンボリックリンクを貼らなければいけません.

%i/lib/libbar.N.dylib -> %p/lib/libbar.N.x.y.dylib
%i/lib/libbar.dylib -> %p/lib/libbar.N.x.y.dylib

install_name パスからと、リンクパスからの実際のライブラリ。 (ライブラリが実際に install_name パスにインストールされる場合は、最初のものは不要です。こちらのほうが普通です。)

静的ライブラリもビルドする場合,次の場所にインストールされることになります.

%i/lib/libbar.a

パッケージが libtool を利用する場合,上記のことはほぼ自動的に処理されますが, どの段階でも処理が適切に行われたか確認する必要があります. また,共有ライブラリの current_version と compatibility_version が適切に定義されているかどうかも確認して下さい. (これらも otool -L または 64bit ライブラリの場合 otool64 -L で表示されます.)

次に,ファイルを以下のように 2 つのパッケージに分類します.

どちらのパッケージにもライセンスに関する何らかの文書が必要ですが,それらを格納するディレクトリは異なることに注意して下さい.

このことはフィールド SplitOff を使えば実際には非常に簡単です. 以下に上の例を実現するためにどのように記述するか (の一部) を示します.

Package: barN
Version: N.x.y
Revision: 1
License: GPL
Depends: barN-shlibs (= %v-%r)
BuildDependsOnly: True
DocFiles: COPYING
SplitOff: <<
  Package: barN-shlibs
  Files: lib/libbar.N.x.y.dylib lib/libbar.N.dylib lib/bar/N
  DocFiles: COPYING
<<

フィールド SplitOff の処理により,指定されたファイルとディレクトリが, メインパッケージのインストールディレクトリ %I から splitoff パッケージのインストールディレクトリ %i に移動します. (これは命名法とも似ています. すなわち,%N がメインパッケージの「パッケージ名」で,%n が splitoff パッケージの「パッケージ名」でしたね.) 次に DocFiles によりドキュメントファイルが %i/share/doc/barN-shlibs にコピーされます.

barN-shlibs の正確な「バージョン」 を親パッケージ barN の依存情報に含めたことに注意して下さい (これは "%N-shlibs (= %v-%r)" と略記できます). これにより「バージョン」が確かに適合するようになり, さらにパッケージ barN がパッケージ barN-shlibs の依存情報を自動的に「継承する」ことを保証します.

フィールド BuildDependsOnly:

ライブラリがアップグレードされる場合,移行期に二つのバージョンのヘッダファイルが必要になる時もあるでしょう. 一つのバージョンはコンパイル時に使われ,もう一つは他のコンパイルに使われるような場合です. このため,ヘッダファイルを含むパッケージの作成には注意が必要となります. foo-dev と bar-dev が重複するヘッダを含む場合, foo-dev で,

   Conflicts: bar-dev
   Replaces: bar-dev

と宣言し,同様に bar-dev では foo-dev を Conflicts/Replaces として宣言します.

さらに,両方のパッケージで

   BuildDependsOnly: True 

を宣言します. これにより,foo-dev または bar-dev に依存してパッケージを記述することを防ぐことができます. このような依存性が Conflicts/Replaces 手段を実行することを防ぐためです.

ヘッダファイル付きのパッケージで, BuildDependsOnly を True にするのが適切ではないものもあります. この場合,そのパッケージでは

   BuildDependsOnly: False

と宣言し,その理由を DescPackaging に記述します.

BuildDependsOnly フィールドは,パッケージがヘッダファイルを含み /opt/sw/include にインストールされる場合, パッケージの .info ファイルに記述されていなければなりません.

fink 0.20.5 の時点で, "fink validate" とすることで, ヘッダファイルと,最低一つの dylib を含み, BuildDependsOnly 値で真偽を宣言していない .deb ファイルに警告を出します. (将来のバージョンでは,この機能をヘッダファイルと静的ライブラリに対応するように拡張する可能性もある.)

共有ライブラリのポリシーのゴールは,共有ライブラリを提供したパッケージと,それを使う別のパッケージとの互換性を保証することです. パッケージによっては,共有ライブラリが他のパッケージに使われることを想定せずに設計されていることもあります. 一般的な例としては,プログラムスイートの裏方のライブラリや, 機能を追加するためのプラグインのあるようなプログラムです. これらのライブラリは,そのパッケージにとって「プライベート」なので, -shlibs や BuildDependsOnly といった SplitOff は必要ありません.

フィールド Shlibs:

共有ライブラリを適切なパッケージに分類する他にも, Fink ポリシー第4版では, 共有ライブラリ全てをフィールド Shlibs を使って宣言することが求められています. このフィールドでは,各共有ライブラリに対して 1 行ずつ, ライブラリの -install_name, ライブラリがパブリックである場合、その Shlibs には -compatibility_version のリスト, そのライブラリを提供する Fink パッケージを指定するバージョン付き依存性情報 (ただし -compatibility_version が同じでなければならない), そしてライブラリのアーキテクチャ (値は "32", "64", または "32-64", あるいは空欄; 空欄時の既定値は "32" .) を記します. 依存性情報は foo (>= バージョン-版) という形式で示します. ここで バージョン-版 にはこの (-compatibility_version が同じ) ライブラリを利用可能にしてくれる Fink パッケージの最初の「バージョン」を使います. 例えば次の宣言は,

Shlibs: <<
%p/lib/libbar.1.dylib 2.1.0 bar1 (>= 1.1-2) 32
<<

-install_name が %p/lib/libbar.1.dylib で -compatibility_version が 2.1.0 の (32bit) ライブラリが, Fink パッケージ bar1 の「バージョン」1.1-2 以降でインストールされることを示します. それに加え,この宣言は「この名前がついていて compatibility_version が少なくとも 2.1.0 のライブラリは, Fink パッケージ bar1 の今後のバージョンには必ず含まれている」というメンテナからの保証にも相当します.

ライブラリの名称には %p を使用するよう注意して下さい. これによって, Fink ユーザはインストールディレクトリに関係なく,正しい -install_name を検索できます.

パッケージが更新されたとき, 普通は次の「バージョン」または「版」のパッケージ記述にフィールド Shlibs をコピーするだけで構いません. 例外は -compatibility_version が増加したときです. その場合,依存性情報の中の「バージョン-版」は新しい「バージョン」または「版」に従って更新されなければいけません. (新しい「バージョン」または「版」とは, 新しい compatibility_version のライブラリを提供する最初の「バージョン」または「版」のことです.)

プライベートなライブラリの Shlibs は,文法が異なります:

  Shlibs: <<
    !%p/lib/%N/libbar.1.dylib
  <<

最初のビックリマークが,これはプライベートなライブラリであることを示しています. この場合,他の情報は関係がないので,省略されています.

この例では,プライベートなライブラリが %i/lib 内の %N というサブディレクトリに保存されています. これはパッケージ名で,他のパッケージが誤ってこのライブラリにリンクしないようにするものです.

メジャーバージョン番号が変わるとき:

「メジャーバージョン」が N から M に変化したときは, 2 つの新しいパッケージ barM と barM-shlibs を作ることになります. パッケージ barM-shlibs と barN-shlibs に重複するファイルがあってはいけません. これは,多くのユーザにとって両方を同時にインストールする必要があるからです. パッケージ barM には以下の依存性情報を指定しなければいけません.

Conflicts: barN
Replaces: barN

同様に barN の方も次の依存性情報を含むように改訂しなければいけません.

Conflicts: barM
Replaces: barM

これにより,問題の共有ライブラリの片方のバージョンに依存する他の様々なパッケージがビルドされるときに barN と barM が入れ替わり入ってくるのを目にするでしょうが, barN-shlibs と barM-shlibs はいつまでもインストールしたままでいられます.

実行可能プログラムとライブラリの両方を含むパッケージ:

upstream パッケージが実行可能プログラムとパブリックライブラリの両方を含む場合, Fink パッケージを作成する際にいくつかの注意が必要です. 唯一の実行可能プログラムが (恐らくビルド時のみに使われ,普段は使われない) foo-config のようなものという場合もあります. その場合,実行可能プログラムはヘッダファイルと共にパッケージ foo に入れて構いません.

そうでない場合,実行可能プログラムは実行時に他の Fink パッケージから必要とされることになりますが, それらは foo-bin などの名前の個別の Fink パッケージに split off しなければいけません. パッケージ foo-bin はパッケージ foo-shlibs に依存しなければいけません. 他パッケージのメンテナは,次のようにすることで

Depends: foo-bin
BuildDepends: foo

明示せずに foo-shlibs を処理します.

しかしこの場合,アップグレードは問題を起こします. ユーザは foo-bin をインストールするよう指示されないからです. この問題の回避のため,パッケージ foo に依存している全てのパッケージのメンテナがパッケージを上記のように改訂するまで, foo で次のようにして構いません.

Depends: foo-shlibs (= 正確な.バージョン), foo-bin

こうすると, foo に依存する他のパッケージのメンテナが改訂を済ませるまで, ユーザのシステムでは大抵 foo-bin のインストールが要求されます.

fink-0.28.0 (released in January 2008) より,Shlibs の「プライベート」なライブラリの記述方法が変わりました. (上述のパブリックライブラリとプライベートライブラリの議論を参照) 共有ライブラリのポリシーでは,常にすべての共有ライブラリを一覧化するよう定められています. ここで変わったのは,Shlibs フィールドの書き方だけです. プライベートなライブラリは,他のパッケージによって使われることを想定していないので, compatibility や他のバージョン情報は不要です. その代わりに先頭にビックリマークをつけます. 例えば,あるプライベートな共有ライブラリの install_namelibquux.3.dylib である場合, 以下のようになります.

  Shlibs: <<
    !%p/lib/libquux.3.dylib
  <<

3.5 Perl モジュール

2003 年 5 月以来, Fink には Perl モジュールに対する新しいポリシーがあります. これは 2004 年 4 月に見直されました.

伝統的に,perl モジュールの Fink パッケージには -pm が後置され, ディレクティブ Type: perl を使ってビルドされていました. このディレクティブは Perl モジュールのファイルを /opt/sw/lib/perl5 及び/または /opt/sw/lib/perl5/darwin に格納していました. 現在のポリシーでは,それらのディレクトリには,コンパイルに使われる Perl のバージョンに依存しない (また,このバージョン非依存性を欠いた Perl モジュールに依存しない) Perl モジュールのみを格納します.

バージョンに依存する Perl モジュールはいわゆる XS モジュールであり, しばしば純粋な Perl コードの他に C コードからコンパイルされたファイルを含みます. このことを区別する方法はいくつもありますが,例えば拡張子 .bundle を持つファイルがあるかどうか調べる方法があります.

Perl のバージョンに依存する Perl モジュールは該当バージョンの付いた Perl の実行可能プログラム (perl5.6.0 など) を使ってビルドされなければいけません. また,モジュールの含むファイルは,標準の Perl のディレクトリ内の,バージョンの付いたサブディレクトリ (/opt/sw/lib/perl5/5.12.3/opt/sw/lib/perl5/5.12.3/darwin など) に格納しなければいけません. 命名規約により,バージョン 5.12.3 に依存する Perl モジュールに -pm5123 を後置します. 格納場所と命名方法に関する同様の規約が他のバージョンの Perl に対しても有効で, perl 5.10.0 (10.6 ツリーのみ), perl 5.12.4 (10.7 ツリーのみ), perl 5.16.2 (10.7 ツリーのみ) でもそのように対応されます.

ディレクティブ Type: perl 5.6.0 は自動的にバージョンの付いた Perl の実行可能ファイルを使い, できたファイルを適切なサブディレクトリに格納します. (このディレクティブは Fink 0.13.0 で導入されました.)

-pm の付くパッケージも作成できます. これは本質的には「バンドル」パッケージで, -pm560 などの付く同等なパッケージなどをロードします. 2004 年 4 月より,この方式は順次廃止されていきます (bootstrap に必要な storable-pm は例外です).

fink 0.20.2 の時点で, system-perl バーチャルパッケージは, システムに 5.8.0 以降の Perl がある場合,自動的に Perl モジュールを提供 (Provides) します. 提供中の perl モジュール一覧を生成しているコードは、 fink パッケージの中の VirtPackage.pm というファイルにあります。

システム perl が異なると、提供するモジュールも変わります。 パッケージメンテナは、提供されている perl モジュールを利用する場合には、 正しい一覧を想定しているか確認することを勧めます。

Fink 0.13.0 から利用可能になったコマンド fink validate を .deb ファイルに適用すると, その Fink パッケージが XS モジュールで,バージョンの付かないディレクトリにインストールされるかチェックし,そうなら警告を発します.

ユーザーは,同時に複数のバージョンの perl をインストールしておくことができます. このため, perl バージョン番号の指定されたモジュールは,複数のバージョンが共存できるようにインストールされなければなりません. manpage やバイナリ,その他のスクリプトなど,これらのパッケージでのファイル名の重複を避けるよう, 注意を払わねばなりません. -pmXYZ で終わるパッケージのどのファイルも,XYZ 値のことなる他のパッケージと同じパスを使用してはいけません. Replaces を用いることで,同名のファイルがあっても異なる perl バージョンの perl モジュールは,以前は許可されていましたが,今後は許可されません. manpage に関する解決として,2005年3月より,それぞれの perl-X.Y.Z に %p/lib/perl5/X.Y.Z/man という MANPATH を定義しました. このため,-man や -doc といった SplitOff を作って対処する必要はなくなりました. 例えば, uri-pm5124 と uri-5162 のコンフリクトの場合,どちらにもある URI.3pm という manpage は, それぞれ %p/lib/perl5/5.12.4/man/man3/URI.3pm%p/lib/perl5/5.16.2/man/man3/URI.3pm にインストールされます. ただし,Type: perl X.Y.Z によるスクリプトは変更されていないので, InstallScript にてどこに mapnage をインストールするのかを記述する必要があります. もし複雑なスクリプトを記述していないのであれば,既存のものを用い,ファイルを移動させるだけで済みます.

%{default_script}
mv %i/share/man %i/lib/perl5/5.12.4

これにより,全ての manpage が移動します. もし manpage のうち一つのセクションを以上させたい場合 (例えばセクション3とモジュールの manpage を移し,セクション1のスクリプト manpage は移さない),同様に:

%{default_script}
mkdir -p %i/lib/perl5/5.12.4/man
mv %i/share/man/man3 %i/lib/perl5/5.12.4/man

デモ用やユーティリティ的なスクリプトなどが %p/bin にある場合は,いくつかの解決方法があります. 一つ目の例は,これらのファイル (およびその manpage や 関連ファイル) を %N-bin という Splitoff とします. ConflictsReplaces のフィールドを用いることで,perl バージョンの異なる,同じファイルを含んでいる複数のパッケージが,相互に排他的になります. 利用者は,異なる perl バージョンのモジュールを複数インストールしておき,スクリプトに関しては一つの perl バージョンのものだけを選択することになります. 例えば,Tk.pm は ptksh と共に来ますが,tk-pm* パッケージは以下のように作られます:

Info2: <<
Package: tk-pm%type_pkg[perl]
Type: perl (5.12.3 5.12.4 5.16.2)
InstallScript: <<
  %{default_script}
  mkdir -p %i/lib/perl5/%type_raw[perl]/man
  mv %i/share/man/man3 %i/lib/perl5/%type_raw[perl]/man
<<
SplitOff: <<
  Package: %N-bin
  Depends: %N
  Conflicts: %{Ni}5.12.3, %{Ni}5.12.4, %{Ni}5.16.2
   Replaces: %{Ni}5.12.3, %{Ni}5.12.4, %{Ni}5.16.2
  Files: bin share/man/man1
<<
<<

この他の方法としては,スクリプトの名称と,関連する manpage を,perl バージョン番号を示すように変更することがあります. これでコンフリクトを回避できるので,相互排他的な %N-bin の Splitoff を作る必要はありません:

Info2: <<
Package: tk-pm%type_pkg[perl]
Type: perl (5.12.3 5.12.4 5.16.2)
InstallScript: <<
  %{default_script}
  mkdir -p %i/lib/perl5/%type_raw[perl]/man
  mv %i/share/man/man3 %i/lib/perl5/%type_raw[perl]/man
  mv %i/bin/ptksh %i/bin/ptksh%type_raw[perl]
  mv %i/share/man/man1/ptksh.1 %i/share/man/man1/ptksh%type_raw[perl].1
<<
<<

利用者は,どのバージョンの perl 用の ptksh も持っておくことができます. update-alternatives を使用すると,利用者は一般的な (perl バージョンのない) 名前でもアクセスすることができ,便利です.

2005年3月の時点で,fink パッケージの perl 自体 (Apple が提供する perl バージョン以外の perlXYZ や perlXYZ-core) としては,manpage とモジュールの位置が変わりました. このため,上位バージョンのコア perl モジュールを提供するパッケージは,perlXYZ や perlXYZ-core パッケージを Replaces フィールドに記述しないでください.

3.6 Emacs ポリシー

Fink プロジェクトでは Emacs について Debian プロジェクトのポリシーに従うことに決定しましたが,小さな違いもあります. (Debian プロジェクトのポリシーについては http://www.debian.org/doc/packaging-manuals/debian-emacs-policy を参照) Fink ポリシーとの違いは 2 点です. まず,このポリシーは Fink では現在のところパッケージ emacs21, emacs22, emacs23 にのみ適用され,パッケージ xemacs には適用されません. (この点は将来変わるかも知れません.) 次に Debian のポリシーと異なり, Fink パッケージはどれもファイルを直接 /opt/sw/share/emacs/site-lisp にインストールして構いません.

3.7 Source ポリシー

ソースは、通常であれば upstream の開発者がつかっている場所からダウンロードされるべきであり、 Fink 用の変更は、PatchFile または PatchScript の使用でする必要があります。 Fink のパッケージでは、 ソースを変更して、変更済みソースアーカイブを Source に設定してはいけません。

もし、プロジェクトは公式リリースを行っていない、 あるいはリリース間に特定の修正のための追加など、 CVS チェックアウト (gitsvn など) が使われる場合、 以下の要領で作成したソースを使用することができます:

  1. パッケージをチェックアウトする。できる限り VCS の限定リビジョンを使用。
  2. VCSチェックアウトからアーカイブ作成 (zip, tar, tar.gz, tar.bz2 など)。

    アーカイブは、固有のバージョンをつける。たとえば、アーカイブ名に VCS リビジョンをいれて、 リリースしないパッケージであれば foo-0svn1234.tar.gz とし、 upstream リリース間の Fink パッケージであれば bar-1.2.3+svn4567.tar.bz2 とする。

  3. 同じ Version を、 .info ファイルでも使う。
  4. DescPackaging フィールドに、ソースアーカイブを生成するために実行したコマンドを書いておくと便利です。
  5. ユーザが fink を使ってダウンロードできる公開ダウンロードサイトにアーカイブをアップロードする。 もし、そのようなサイトがない場合は、 Fink 開発者メーリングリスト または #fink IRC チャンネル, に連絡してください。だれかが助けてくれるでしょう。

3.8 ファイルダウンロードのポリシー

パッケージは、 ビルドプロセス の unpack, patch, compile, install, build どの段階でもファイルをダウンロードしません。 巨大なパッチ (例えば、PatchFile で扱うには大きすぎるもの) は、 ソースポリシー に従ってソースとして設置してください。

パッケージは、以下の条件下で、PostInstScript でシステムにインストール後にデータをダウンロードしても構いません。

もし不安があるなら、Fink Core Teamに相談してください。

4 ファイルシステムのレイアウト

以下はファイルシステムのレイアウトのガイドラインで, Fink のパッケージ作成ポリシーの一部です.

4.1 ファイルシステム構造標準 (Filesystem Hierarchy Standard)

Fink は ファイルシステム構造標準 (Filesystem Hierarchy Standard, 略して FHS ) の精神に従います. しかし従えるのは飽くまでも精神のみです. それは FHS が / 以下と /usr 以下の階層を管理できるシステムベンダ向けに作られたからです. Fink はインストールディレクトリ (別名「プリフィクス」) 以下のみを管理するアドオン・ディストリビューションです. 以降の例ではデフォルトの「プリフィクス」 /opt/sw を使います.

4.2 ディレクトリ

ファイルは以下のサブディレクトリに保存します:

FieldValue
/opt/sw/bin

一般的な実行可能プログラム用. サブディレクトリはなし.

/opt/sw/sbin

管理者のみが使うことを意図した実行可能プログラム用. バックグラウンドで動くデーモンもここに入る. サブディレクトリはなし.

/opt/sw/include

C と C++ のヘッダファイル用. 必要に応じてサブディレクトリを作成してよい. 標準の C ヘッダファイルと混同しそうなヘッダファイルをインストールする場合は必ずサブディレクトリに入れること.

/opt/sw/lib

アーキテクチャ依存のデータファイルやライブラリ用. 静的および共有ライブラリは,避ける理由が特にない限り /opt/sw/lib 直下に置きます. ユーザが直接起動することのない実行可能プログラム (普通なら libexec 下に置かれるはずのもの) もここに置きます.

パッケージは,固有のデータやロード可能モジュールを保存するサブディレクトリを自由に作成できます. 必ず互換性を考慮したディレクトリ名を使って下さい. 賢明な方法は,そのサブディレクトリの名前にパッケージの「メジャーバージョン」を含めたり, 「メジャーバージョン」をディレクトリ名にしたさらに深い階層を作ることです (/opt/sw/lib/perl5/opt/sw/lib/apache/1.3 など). ディレクトリにホストの種類を使うときには注意が必要です. powerpc-apple-darwin1.3.3 は,互換性の観点から問題があります. powerpc-apple-darwin1.3 または単に powerpc-apple-darwin とします.

/opt/sw/lib/ppc64 /opt/sw/lib/x86_64

このディレクトリは 64-bit ライブラリ用で, powerpc アーチテクチャーでは /opt/sw/lib/ppc64 が, i386 アーチテクチャーでは /opt/sw/lib/x86_64 が用いられます. 'fat' としてビルドされたライブラリは, /opt/sw/lib に保存されます.

/opt/sw/share

アーキテクチャに依存しないデータファイル用で, /opt/sw/lib と同じルールが当てはまります. よく使われるサブディレクトリについては後述します.

/opt/sw/share/man

man ページ用. この中は man のセクションに従って分類されます. /opt/sw/bin/opt/sw/sbin の中の全てのプログラムには, 対応した man ページがここになければいけません.

/opt/sw/share/info

Texinfo ソースから生成される Info 形式のドキュメント用. 索引ファイル dir のメンテナンスは Debian 版 install-info (パッケージ dpkg の一部) が自動的に行う. パッケージ記述のフィールド InfoDocs を使って, パッケージスクリプト PostInst 及び PreRm で使うための適切なコードを自動生成する. Fink は,それぞれのパッケージが勝手に dir ファイルを作成しないことを保証する. サブディレクトリはなし.

/opt/sw/share/doc

man でも Info でもないドキュメント用. README, LICENSE, COPYING はここに保存する. 全てのパッケージは,ここに各「パッケージ名」に対応したサブディレクトリを作らなければいけない. 名前には (「パッケージ名」そのものの一部でない限り) 「バージョン」を含めてはいけない. 単に %n を使うとよいでしょう.

/opt/sw/share/locale

国際化で使うメッセージカタログ用.

/opt/sw/var

ディレクトリ var には変化するデータを保存する. (スプールディレクトリ,ロックファイル,状態のデータベース,ゲームのハイスコアやログファイルなど)

/opt/sw/etc

設定ファイル用. 複数のファイルを使用するパッケージは,ここにサブディレクトリを作らなければいけない. 区別のため,そのサブディレクトリにはパッケージまたはその中のプログラムの名前を付けなければいけない.

/opt/sw/src

ソースコードを保存,ビルドするディレクトリ. パッケージはここに何もインストールしてはいけない.

/opt/sw/Applications

このディレクトリには,コマンドラインから実行するのではなく,ダブルクリックで実行する OS X 型のアプリケーションを保存する.

/opt/sw/Library/Frameworks

このディレクトリには,OS X 型のアプリケーションが使用する,OS X 型のフレームワークを保存する.

4.3 避けるべきこと

/opt/sw 下には,上述のもの以外ディレクトリを作ってはいけません. 特に以下のディレクトリを作らないこと: /opt/sw/man, /opt/sw/info, /opt/sw/doc, /opt/sw/libexec, /opt/sw/lib/locale

5 コンパイラ

Fink は,Apple Developer Connection によってアップルコンピュータから提供される gcc コンパイラを使用しています. バージョンはいくつかあり, Mac OS X システムでも通常は複数のバージョンが存在します.

より詳しい解説がメーリングリスト中にあります.

5.1 コンパイラバージョン

GCC の発展に伴い,fink は "ディストリビューション" をつくって変化に対応してきました.

各 Fink ディストリビューションには,ソースからコンパイルするユーザー全員がもっていると想定されている 既定の gcc と g++ コンパイラがあります. パッケージ中で直接 "gcc" や "g++" を使用すると,この既定値が使われます. これと違う値を使用する必要がある場合,(例えば,ディストリビューションの移行中に) パッケージ .info ファイルは Apple 提供の特定バージョンのバイナリを指定しなければなりません. どのように指定するかは,ソフトウェアのビルドシステムによりますが,多くの場合 SetCCSetCXX のフィールドを使用します. 例えば,g++コンパイラのバージョンを 3.3 にするには,SetCXX: g++-3.3 とします. 正しいコンパイラが使われているか,ビルド時の出力を確認してください.

10.1 ディストリビューションは,コンパイラに 2.95 の使用を前提とします. 10.2 ディストリビューションは,コンパイラに 3.1 の使用を前提とします. 10.2-gcc と 10.3 ディストリビューションは,コンパイラに 3.3 の使用を前提とします. 10.4-transitional ディストリビューションは複雑で,これは g++-3.3 と gcc-4.0 を使用しています. 10.4 と 10.5 ディストリビューションでは,gcc-4.0 と g++-4.0 を使用しています. 10.6 ディストリビューションでは,gcc-4.2 を使用しています. 10.7 から 10.9 ディストリビューションでは,clang と clang++ をデフォルトコンパイラとして使用しています. 10.9 では、さらに、libstdc++ から libc++ へ統合という変化があります。

正しい g++ コンパイラが使用されるよう新手法が 10.4-transitional ディストリビューションから採用されました. コンパイル時に,/opt/sw/var/lib/fink/path-prefix-g++-XXX (XXX はバージョン番号) ディレクトリが PATH に追加されます. このディレクトリには正しいコンパイラと正しいバージョンの g++ が使われるようなシェルスクリプトが入っています.

5.2 g++ ABI

OS X の歴史の中で,g++ ABI は3度変わってきました: ABI は バージョン 2.95, 3.1, 3.3, 4.0 で異なります. ABI の相違は互換性がなく,C++ コードを用いたライブラリにリンクする場合は,同じ ABI でコンパイルしなければなりません.

Fink では,g++ ABI は GCC フィールドで扱っています. g++ あるいは c++ コンパイラを呼び出すパッケージは,GCC フィールドを定義しなければなりません (逆に,呼び出さないパッケージには定義してはいけません). ABI が更新された場合,パッケージ依存性に GCC フィールドも確認しなければいけません. 依存するパッケージ全てがアップグレードされて,始めてそのパッケージもアップグレードすることができます. ユーザーがパッケージをビルドするより前に正しく更新された依存性を持つためには,依存パッケージのバージョンを変える必要があります.

ある範囲内でのみ依存されているパッケージは,アップグレードの準備ができない場合, ディストリビューション変更時に旧バージョンの ABI を使用することもできます. アップグレードされる場合は,範囲内の全てのパッケージを同時に正しいバージョンにアップグレードする必要があります. このため,ほとんどのパッケージにとって,アップグレードはディストリビューションの変更時にするのがよいでしょう.

Fink は GCC フィールドを使って,ユーザーが正しいコンパイラを使うよう確認します. GCC フィールドがパッケージによって定義されている場合, その値が OS X バージョンにあっているか確認します。 (10.2 と 10.3 での正しい値は 3.3 で, 10.4 から 10.9 までの正しい値は 4.0 です.)

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, 14.4, 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, 14.4, 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, 14.4, 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, 14.4, 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, 14.4, 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, 14.4, 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 を使えばよいでしょう. このフィールドはまさにその作業を簡略化するために用意されたものです.


Copyright Notice

Copyright (c) 2001 Christoph Pfisterer, Copyright (c) 2001-2024 The Fink Project. You may distribute this document in print for private purposes, provided the document and this copyright notice remain complete and unmodified. Any commercial reproduction and any online publication requires the explicit consent of the author.


Generated from $Fink: packaging.ja.xml,v 1.63 2024/12/20 6:46:11 nieder Exp $