パッケージ作成 - 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 フィールド
フィールドを分類して解説します.
以下の一覧は完全ではありません.
:-)
初期データ関連
Field | Value |
---|---|
Package |
「パッケージ名」. 値には英小文字,数字及び ドット (.), プラス (+), ハイフン (-) を使うことができます. 下線 (_) と英大文字は使えません. 必須フィールド. このフィールドで行われるパーセント展開は %N, %{Ni}, %type_raw[] と %type_pkg[] のみです.
Fink のパッケージ作成ポリシーでは,
どのパッケージも常に同じオプションを有効にしてコンパイルされるようにします.
あるパッケージに複数の variant を設ける場合は (フィールド |
Version |
upstream のバージョン. 値にはフィールド Package と同じ制限がある. 必須フィールド.
プログラムによっては被標準的なバージョン番号の付け方をしていて,ソートや当フィールドで認められていない字を使っている場合があります.
このような状況では,上流のバージョンを適切にソートされるものに変えます.
バージョン文字列のソートのされ方がわからない場合, dpkg --compare-versions 1.2.1 lt 1.3 && echo "true"
これは "1.2.1" の方が "1.3" より小さいため "true" を出力します.
詳細は |
Revision |
Fink パッケージとしてのリビジョン. upstream のバージョンが同じパッケージのパッケージ記述を書き換えたら,ここを 1 ずつ増やします. 最初は 1 で始めます. 必須フィールド.
Fink のポリシーでは,パッケージのバイナリ (コンパイル済み) 形式 ( |
Architecture |
パッケージ (および Splitoff) が対応している CPU アーキテクチャー一覧を,コンマ区切りで記述します.
現在のところ,
gcc-4.0 以前のコンパイラを使うパッケージ
(およびこれに依存するパッケージ)
の場合に
このフィールドでは,値一覧にある値とパーセント展開を,通常の条件文法で使うことができます
(詳細については, Package: foo-pm%type_pkg[perl] Type: perl (5.8.8 5.10.0) Architecture: (%type_pkg[perl] = 5100) x86_64
によって,foo-pm5100 という variant は 上の例は、このフィールドのよくある使い方です。 10.6 の system-perl 5.10.0 は 32-bit (i386) でビルドできないものがあるので、 複数タイプの perl パッケージを特定のシステムに限定することができます。 |
Distribution |
パッケージ (およびその Splitoff パッケージ) が対応しているコンマ区切りのディストリビューション一覧。
現在、有効な値は
このフィールドは、値リスト中の値とパーセント展開を条件式に使うことができます
( 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
は、 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 |
値が
値が
値が CVS 版の Fink 0.19.2 以降では, 「プログラミング言語」または「プログラミング言語-バージョン」という記法は一般化され, メンテナの定義した任意のタイプとそれに関連するサブタイプが指定できるようになり, あるパッケージに複数のタイプを指定できるようになりました. タイプとサブタイプにはそれぞれブランク以外からなる任意の文字列が使えます. (しかし括弧,大括弧,カンマ,パーセント記号を使ってはいけません.) ここではパーセント展開は行われません. また,タイプの値は小文字に変換されます(が,サブタイプは変換されません). 複数のタイプを指定するにはカンマ区切りのリストを使います (各タイプに空白区切りのサブタイプリストが伴うことができます). これに加えて「 variant 」という概念があります. 単一のパッケージ記述が,有効なコンパイルオプションだけが違う複数のパッケージを生成するとき, これらのパッケージは「 variant 」になります. このプロセスの鍵はサブタイプリストの利用です. 単一の文字列ではなく,文字列の空白区切りリストを括弧で括ったものを使います. Fink はリスト内のサブタイプ毎にパッケージ記述をコピーし,各コピー内ではリストを単一のサブタイプに置き換えます. 例: Type: perl (5.12.3 5.12.4)
これは 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 より, 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 のバージョンです.
|
依存性関連
Field | Value |
---|---|
Depends |
そのパッケージがビルドできるようになる前にインストールされていなければいけないパッケージの一覧。 このフィールドではパーセント展開が行われる (「依存性関連」の他のフィールドでも同様: BuildDepends, RuntimeDepends, Provides, RuntimeDepends, Conflicts, Replaces, Recommends, Suggests および Enhances)。 普通、値は「パッケージ名」の単なるカンマ区切り一覧だが、 現在の Fink は、dpkgと同じ形式の「代替パッケージ」と「バージョン節」に対応している。 それらを全て盛りこんだ例: Depends: << daemonic (>= 20010902-1), emacs | xemacs <<
上のレイアウトは 本当の意味で「省略可能」な依存性を表現する方法がないことに注意. あるパッケージが別のパッケージがあってもなくても動作するとき, もう片方のパッケージが (存在するときであっても) 確かに使われていないか確かめるか, またはフィールド Depends に加えるかのどちらかを行うこと. ユーザにどちらの使い方をも提供したいときは,2 つの別々のパッケージ (例えば wget と wget-ssl) を作る.
0.18.2 CVS版以降の Fink では,条件付き依存性を記述できる.
それを指定するには「パッケージ名」の前に この機能は,複数の似通ったパッケージを管理する際に手間を省くためにも使える. 例えば elinks と elinks-ssl は次のように列挙できるが, Depends: << (%n = elinks-ssl) openssl097-shlibs, expat-shlibs << これは elinks の方で Depends: expat-shlibs とし, elinks-ssl の方で Depends: expat-shlibs, openssl097-shlibs とすることと同じである.
この他の文法として, 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 パッケージを必要とする.
このため, 以前は,必須でないパッケージは暗黙のうちに必須パッケージに依存していたが, 現在はそうなっていない. |
BuildDepends |
Fink 0.9.0 で導入:
ビルド時のみに適用される依存性のリスト.
ビルド時には必要だが,実行時には使われないツール (flexなど) を示すのに使う.
書式は Depends と同じ.
ビルドされる際にテストスイートが有効であれば,
|
RuntimeDepends |
Fink 0.32.0 で導入: ランタイム時のみに適用されインストールされる依存パッケージ一覧。 パッケージを実行中になければならないが、 ビルド時には使われないパッケージを一覧化します。 Depends と同じ書式です。 |
Provides |
そのパッケージが「提供」すると考えられる「パッケージ名」のカンマ区切りの一覧。
パッケージ pine で 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 |
当該パッケージがコンパイル中にインストールされてはいけないパッケージの一覧.
これは, |
Replaces |
Conflicts と共に使われる. そのパッケ−ジが,衝突するパッケ−ジの機能の代わりになるだけでなく,共通するファイルを持つときに使われる. このフィールドがないと、dpkg はパッケージのインストール時にエラーを出すことがある。 これは、いくつかのファイルが別の方のパッケージに属しているためである。 こうした 2 つのパッケージが純粋な意味で互いに代替物であり,どちらか好きな方を選べるようなときはこれを使うとよい。 あるパッケージがそれ自身のパッケージ記述の Conflicts に入っていると, (暗黙のうちに) そこから取り除かれる. (Fink のバージョン 0.18.2 CVS 以降で導入) 注記: Fink自身はこのフィールドを無視します。 これは dpkg に渡され、そこで適切に扱われます。 つまり、このフィールドが影響するのはビルド時でなく実行時です。 |
Recommends, Suggests, Enhances |
これらのフィールドはパッケージ同士の付加的な関係情報を指定する. 書式は他の依存情報フィールドと同じ. これら 3 つの情報は dpkg や apt-get によるインストール過程そのものには影響しないが, dselect や他のフロントエンドが,微妙な選択を行うユーザの判断を助けるのに使われる. |
Pre-Depends |
フィールド Depends の特別なもので,意味の上で厳密さが必要になる. このフィールドを使うのは,開発者用メーリングリストで議論を行い,確かに使う必要があるとの同意が得られた場合に限る. |
Essential |
必須パッケージを表す真偽値フィールド.
必須パッケージでないパッケージは必須パッケージに暗黙のうちに依存して構わない.
|
BuildDependsOnly |
Fink 0.9.9 で導入:
真偽値フィールド.
他パッケージはこのパッケージを BuildDepend に入れてもよいが, Depend に入れてはいけないことを示します.
通常の真偽値とは異なり, fink 0.20.5 より,このフィールドが設定されているか,設定されている場合その値が, パッケージがビルドされる際には .deb ファイルに記録されます. このため, BuildDependsOnly の値を変更したり,追加・削除時には Rivision 番号をあげる必要があります. |
解凍段階関連:
Field | Value |
---|---|
CustomMirror |
ミラーサイトのリスト.
各ミラーサイトは 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/ <<
大陸及び国のコードは |
Source |
ソースの tarball の URL .
HTTP または FTP でなければいけないが,Fink はそれを単に wget に渡すだけなので,実際には問題にならない.
このフィールドは,ミラーサイトを示す特別な記法に対応している.
すなわち
Fink 0.18.0 以降では
テストスイートを実行するためだけに必要なソースは, |
SourceN |
パッケージが複数の tarball から形成されている場合,それらはこの (省略可能) フィールドで指定する.
N は 2 から始まる数.
つまり最初の tarball (ある意味「メイン」になるもの) をフィールド |
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 と同じディレクトリで展開される。
それを特定のサブディレクトリ内で展開して欲しいときは,このフィールドでサブディレクトリ名を指定する.
ご想像の通り, |
SourceRename |
このフィールドを使うと,ビルド時にソースの tarball をリネームできる。
これが便利なのは,例えば,ソースのバージョンがサーバのディレクトリ名には示されているが,
tarball そのものはどのバージョンでも同じ名前のときだ。
(例えば SourceRename: %n-%v.tar.gz
この例では,ご想像の通り, tarball は |
SourceNRename |
これはフィールド |
Source-MD5 |
Fink 0.10.0 で導入: このフィールドではソースファイルの MD5 チェックサムを指定します. Fink はこの情報によりおかしなソースファイル, すなわち Fink パッケージの作成者が指定したものではない tarball を見分けられます. この問題の原因には,以下のようなものがあります: tarball のダウンロードに失敗した,upstreamのメンテナが知らないうちに tarball を更新した,トロイの木馬などの攻撃,など. このフィールドの典型的な用例は次の通り. Source-MD5: 4499443fa1d604243467afe64522abac
チェックサムの算出にはツール 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-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 $ shasum -a 256 /opt/sw/src/libexif-0.6.22.tar.xz 5048f1c8fc509cc636c2f97f4b40c293338b6041a5652082d5ee2cf54b530c56 /opt/sw/src/libexif-0.6.22.tar.xz
The |
SourceN-Checksum |
This is just the same as the |
TarFilesRename |
Fink 0.10.0 で導入: このフィールドは tar 形式を使うソースファイルにのみ適用されます.
このフィールドを使うと,任意のソース tarball の中のファイルを, tarball の展開中にリネームできます.
ファイルシステム HFS+ がケースインセンシティブである (大文字と小文字を区別しない) ことを回避するために非常に便利でしょう.
普通の Mac OS X システムでは,ファイル
このフィールドでは,単に,リネームされるファイルのリストを指定します.
ワイルドカードも使うことができます.
デフォルトでは,指定されたファイルは,いずれも元の名前に TarFilesRename: foo bar.* qux:quux Tar2FilesRename: direcory/INSTALL:directory/INSTALL.txt |
TarNFilesRename |
Fink 0.10.0 で導入:
フィールド |
パッチ段階関連:
Field | Value |
---|---|
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" にすると,サブディレクトリ
パッチの当たった |
Patch |
%n は %type_ 系で示される variant データ全てを含む文字列に展開されることに注意.
ここでは %{ni} を (場合によっては特定の %type_ の展開値と共に) 使うとよいでしょう.
単一のパッチファイルを管理し,
各 variant 固有の変更点を |
PatchFile |
|
PatchFileN |
パッケージにパッチファイルが複数ある場合、
N = 2 から始まる連番のフィールドを追加することができます。
最初のパッチファイルは |
PatchFile-MD5 |
|
PatchFileN-MD5 |
|
PatchScript |
パッチ段階で実行されるコマンドのリスト.
下記のスクリプトの注意書きを参照してください.
ここには,パッチを当てるか,またはパッケージに変更を加えるコマンドを指定します.
下記のスクリプトに関する注記もあわせて参照してください.
コマンド実行前に,パーセント展開が行われます.
patch -p1 < %{PatchFile}
もし、 patch -p1 < %{PatchFileN}
です.
|
コンパイル段階関連:
Field | Value |
---|---|
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 より,これらの既定値に例外が一つあります.
MACOSX_DEPLOYMENT_TARGET は OSX のバージョンを既定値として持ちます. これに値を指定することで (値の追加ではなく) 既定値を書き換えることができます. |
NoSet環境変数名 |
真の場合,既定値を持つ変数 (上述の CPPFLAGS, LDFLAGS, CXXFLAGS など) の既定値を使いません.
例えば,LDFLAGS を unset のままにしたい場合, |
UseMaxBuildJobs |
true が設定された場合、
CompileScript と TestScript の間、
MAKEFLAGS 環境変数に
|
BuildAsNobody |
fink >= 0.33.0 で、 これ以前の fink バージョンでは、このフィールドは何もしません。 |
ConfigureParams |
configure スクリプトに渡す付加的なパラメータ.
(詳細は CompileScript を参照)
テストスイートが有効でビルドする場合,
fink-0.22.0 より,このフィールドは条件をサポートする.
文法は Type: -x11 (boolean) ConfigureParams: --mandir=%p/share/man (%type_pkg[-x11]) --with-x11 --disable-shared
これは
このフィールドは、複数行宣言をすることで複数行に書くことができます。
このフィールドは、シェルコマンドとして扱われ、 ConfigureParams: << --mandir=%p/share/man \ (%type_pkg[-x11]) --with-x11 \ --disable-shared << 注記: 複数行で書く場合には、最後の行に条件付きパラメータを設定しないでください。 条件式が false の場合、直後のパラメータは評価されず、シェルを壊します。 |
GCC |
当フィールドは,パッケージ内の C++ コードが使用する GCC-ABI を指定します. (このフィールドは,ABI が2度変わり,C++ コードと,それがリンクするライブラリが同じ ABI でなければならないために必要である.)
値としては:
GCC フィールドはそれ自体は既定値を持たず,設定されなければ無視されます.
しかし,各ツリーには,既定の g++ コンパイラが存在し,これに対応する GCC の値が想定されています.
想定値は,10.1 ツリーでは 注記: GCC 値が既定値と異なる場合, (CC や CXX フラグを設定するなど) パッケージ内でコンパイラを指定する必要があります. また, (virtual) gcc パッケージへの依存性を指定します.
Fink 0.13.8 以降,このフラグが指定されると, gcc のバージョンは このフィールドは 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 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
ここで, |
NoPerlTests |
Fink 0.13.7 以降で導入:
真偽値フィールド.
Perl モジュールのパッケージでのみ指定します.
"true" にすると, |
テストスイート:
Field | Value |
---|---|
InfoTest |
fink 0.25 にて導入.
当フィールドは、テストスイートが有効な場合のビルド実行時にのみ使用される情報を含んだものです。
ここには他のフィールドが含まれます.
現在のところ,この中に
例: InfoTest: << TestScript: make check || exit 2 TestConfigureParams: --enable-tests << |
インストール段階関連:
Field | Value |
---|---|
UpdatePOD |
Fink 0.9.5 で導入:
真偽値フィールド.
Perl モジュールのパッケージでのみ指定します.
"true" にすると, install, postrm および postinst スクリプトに,
perl パッケージの提供する .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
タイプが 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
ここで,
パッケージが対応しているなら,代わりに |
AppBundles |
post-0.23.1 バージョンから導入:
当フィールドは,アプリケーションバンドルを AppBundles: build/*.app Foo.app |
JarFiles |
Fink 0.10.0 で導入:
このフィールドは DocFiles に似ています.
ここで指定した jar ファイルは JarFiles: lib/*.jar foo.jar:fooBar.jar こうすると,ディレクトリ lib 内の全ての jar ファイルをインストールし, foo.jar を fooBar.jar としてインストールします.
また,これらの jar ファイル (正確にはディレクトリ |
DocFiles |
このフィールドにより,ファイル README や COPYING を,
パッケージの doc ディレクトリ ( |
Shlibs |
Fink 0.11.0 で導入:
このフィールドでは,そのパッケージでインストールされる共有ライブラリを指定します.
それぞれの共有ライブラリに一つの行があります.
これには,ライブラリの |
RuntimeVars |
Fink 0.10.0 で導入:
このフィールドにより,実行時に環境変数を何らかの固定された値に設定できます.
(柔軟性が必要ならprofile.d スクリプトの節を参照.)
そのパッケージがインストールされる限り,
ここに指定した環境変数はスクリプト 環境変数の値にはブランクが使えます (値の末尾に来ると取り除かれます). また,パーセント展開が行われます. 例: 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 で導入:
これはフィールド |
Files |
Fink 0.9.9 で導入:
フィールド |
ビルド段階関連:
Field | Value |
---|---|
PreInstScript, PostInstScript, PreRmScript, PostRmScript |
これらのフィールドには,パッケージがインストール,アップグレード,または削除される時点で実行されるシェルスクリプトの断片を記述します.
Fink はシェルスクリプトのヘッダ 各スクリプトは以下のタイミングで実行されます.
補足説明: アップグレードは新バージョンの ...InstScript と,旧バージョンの ...RmScript を実行します. 詳細については Debian Policy Manual, 第6章 を参照. スクリプト内ではパーセント展開が行われます. 一般に,コマンドはフルパスを指定しなくても実行できます. |
ConfFiles |
ユーザが修正できる設定ファイルの空白区切りの一覧。
パーセント展開が行われます.
ファイルは、 |
InfoDocs |
パッケージが 注記: Info ドキュメントがスプリットされている場合、 数字のないファイルだけを使います。 例えば、パッケージに: foo.info foo.info-1 foo.info-2 があれば、 InfoDocs: foo.info と記述します。 この機能はまだ途中で、将来はよりよい制御のためのフィールドが追加されるかもしれません。 |
DaemonicFile |
|
DaemonicName |
|
付加的データ関連:
Field | Value |
---|---|
Homepage |
upstream パッケージのホームページの URL. |
DescDetail |
フィールド |
DescUsage |
パッケージを利用する上で必要になる情報を記述します. (そのパッケージはどのように使うものなのか?) 例えば「 WindowMaker を使う前に wmaker.inst を起動.」等を (訳注: 英語で) ここに記述します. 複数行に渡っても構いません. このフィールドはワードラップの恩恵に預らずに表示されるので, (可能ならば) 手動で改行を挿入して各行 79 文字以内に収めてください. |
DescPackaging |
パッケージ作成に関する注意書き. 「ファイルを適切な場所に置くために Makefile にパッチを当てる」等を (英語で) ここに記述します. 複数行も可。 |
DescPort |
パッケージを Darwin に移植する場合に特有の注意書き. 「config.guess と libtool スクリプトはアップデートする. -no-cpp-precomp が必要」等を (英語で) ここに記述します. 複数行も可。 |
6.3 スプリットオフ (SplitOff)
Fink 0.9.9 で導入.
単一の .info ファイルで複数のパッケージを作成することが可能です.
インストール段階は普通に始まり, InstallScript
と DocFiles
コマンドを実行します.
フィールド SplitOff
や SplitOffN
が存在すれば,それらに対しインストールディレクトリを作成します.
SplitOff
や SplitOffN
の中では,対応して新しく作られたインストールディレクトリは %i で,
親パッケージのインストールディレクトリは %I で参照されます.
フィールド SplitOff
や SplitOffN
には,独自のフィールドが多数あります.
完全なパッケージ記述とよく似ていますが,抜けているフィールドもあります.
以下は SplitOff
に含まれる部分パッケージ記述 (分野別)です.
-
初期データ関連:
指定する必要があるのは
Package
のみで, その他は全て親パッケージから引き継がれます.Type
とLicense
はSplitOff
やSplitOffN
の中で宣言することで変更できます. パーセント展開も使えます. 特に,親パッケージの名称を参照する %N を使用すると良いでしょう. - 依存性関連: 全てのフィールドが記述可能.
- 解凍段階, パッチ段階, コンパイル段階関連: これらのフィールドは意味がないため無視されます.
-
インストール段階, ビルド段階関連: 全てのフィールドが記述可能.
(ただし
SplitOff
やSplitOffN
を入れ子にはできません.) -
付加的データ関連: 親パッケージから引き継がれますが,
SplitOff
やSplitOffN
の中で宣言して修正することができます.
%n-%v-%r は,パッケージのユニークな識別子として扱われるため,
SplitOff
(あるいは SplitOffN
)
を用いて (同じ Version
と Revision
で) Package
を作成してはいけません.
variant を使う際は,各 variant が独立したパッケージとなるようにしてください.
つまり,以下のようなパッケージレイアウトは禁止されます:
Package: mime-base64-pm%type_pkg[perl] Type: perl (5.12.3 5.12.4) SplitOff: << Package: mime-base64-pm-bin <<
インストール段階では,まず親パッケージの InstallScript
と DocFiles
が実行されます.
次にフィールド SplitOff
や SplitOffN
の処理が行われます.
すなわち,そのそれぞれの中の Files
のコマンドが実行され,
指定されたファイルやディレクトリが親インストールディレクトリ %I から splitoff パッケージのインストールディレクトリ %i に移されます.
続いて SplitOff
や SplitOffN
の中の
InstallScript
や DocFiles
などが順に実行されます.
現在の Fink では,最初に SplitOff
が (あれば) 処理され,その後に
SplitOff2
, SplitOff3
などがさらに存在する場合,数の順に処理されます.
しかしこの順番は将来変更されるかもしれません.
よって, SplitOff
が SplitOff2
より先に処理される現状でしか正しく動作しない,次のようなコード
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 を使えばよいでしょう. このフィールドはまさにその作業を簡略化するために用意されたものです.