Fink パッケージの作成方法

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

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

Contents

• 1 始めに
  • 1.1 パッケージとは何か?
  • 1.2 パッケージの区別
• 2 パッケージ記述
  • 2.1 ツリーレイアウト
  • 2.2 ファイル形式
  • 2.3 パーセント展開
• 3 パッケージ化ポリシー
  • 3.1 パッケージのライセンス
  • 3.2 GPL と OpenSSL
  • 3.3 基盤システムへの干渉問題
  • 3.4 共有ライブラリ
  • 3.5 Perl モジュール
  • 3.6 Emacs ポリシー
• 4 ファイルシステムのレイアウト
  • 4.1 ファイルシステム構造標準 (Filesystem Hierarchy Standard)
  • 4.2 ディレクトリ
  • 4.3 避けるべきこと
• 5 コンパイラ
  • 5.1 コンパイラバージョン
  • 5.2 g++ ABI
• 6 リファレンスマニュアル
  • 6.1 ビルドプロセス
  • 6.2 フィールド
  • 6.3 スプリットオフ (SplitOff)
  • 6.4 スクリプト
  • 6.5 パッチ
  • 6.6 Profile.d スクリプト

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 ツリーレイアウト

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

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

• ツリーは dists から始まる． dists ディレクトリは Debian ツールで必須．
• ディストリビューション． stable, unstable, local に分かれる． ディレクトリ local は各システムの管理者とユーザが管理する． ディレクトリ stable と unstable は Fink システムの一部．
• ツリー． ツリー main にはパッケージの大部分が含まれる． 暗号を使うソフトウェアは別ツリー crypto に収められ，必要であれば簡単に取り除ける．
• finkinfo または binary-darwin-powerpc． finkinfo は Fink のパッケージ記述とパッチを含み， binary-darwin-powerpc は .deb 形式のバイナリパッケージを含む．
• セクション． ツリー main は，管理しやすくするために種類別に分類されている． ツリー crypto は現在のところ分類されていない．

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 形式はネストできます． これはフィールド SplitOff や SplitOffN でよく使われます． これらのフィールドは他の (複数行の) フィールドを含むことができ， here-document 形式を使えば含まれる方のフィールドにも複数行の値が使えます． 内側でも同じ区切り << が使われます．

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

今は推奨されない旧式の記法は「RFC 822 ヘッダ折り畳み方法」を手本に作られました． 空白で始まる行を前の行からの続きと認識します． 例:

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

各行頭の空白は必須であることに注意して下さい．

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

2.3 パーセント展開

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

3 パッケージ化ポリシー

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

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

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

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

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

• GPL - GNU General Public License． ソースがバイナリと同じ場所から入手できる必要がある．
• LGPL - GNU Lesser General Public License． ソースがバイナリと同じ場所から入手できる必要がある．
• GPL/LGPL - これは特殊な場合で，パッケージの一部 (実行可能プログラムなど) が GPL で， 別の部分 (ライブラリなど) が LGPL になっているパッケージ．
• BSD - BSD形式のライセンス． これには，いわゆる「オリジナル」 BSD ライセンス，「修正」 BSD ライセンスおよび MIT ライセンスが含まれる． The Apache lisence もこの一種とみなす． ソースコードを配布することは必須でない．
• Artistic - The Artistic lisence 及びその派生型．
• Artistic/GPL - The Artistic lisence と GPL のデュアルライセンス．
• GNU Free Documentation License および Linux Documentation Project - 付属ドキュメントが明示的にこのライセンスのどちらかを採用している場合， 値に /GFDL と /LDP のいずれか，または両方を後置する． 結果として以下の組合せが可能: "GFDL", "GPL/GFDL", "LGPL/GFDL", "GPL/LGPL/GFDL", "LDP", "GPL/LGPL/LDP".
• DFSG-Approved - Debian 社会契約 のガイドラインに沿ったソフトウェア
• OSI-Approved - Open Source Initiative が承認した，その他の Open Source ライセンス． OSI はバイナリとソースの自由な配布を許可するよう要求しています． デュアルライセンスのパッケージにとりあえずこの選択肢を選ぶこともできます．
• Restrictive - 制限付きのライセンス． 作者からソース形式で free use のために入手できるが，free redistribution は許可されないパッケージに使う．
• Restrictive/Distributable - ソースとバイナリの配布を許可するが制限のあるライセンス． 当該パッケージが作者からソース形式で入手でき，ソースとバイナリの配布も許可されているが， Open Source ライセンスと認められない制限がある場合に使う．
• Commercial - 制限付きの商用ライセンス． ソースやバイナリの自由な再配布を許可しない商用パッケージ (フリーウェアやシェアウェアなど) に使う．
• Public Domain - パブリックドメインの，すなわち作者がコードに対するコピーライトを放棄したパッケージ． この場合，パッケージにはライセンスが存在せず，だれが何をしても良い．

3.2 GPL と OpenSSL

(2005年４月より施行)

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 版 (及び 64bit ライブラリを扱うために2006年12月の変更) について説明します． 最初に要点をかいつまんで述べ，後から詳細に移ります．

共有ライブラリをビルドするパッケージで， (1) ツリー stable に入っているか，または (2) 新規のパッケージである場合， Fink ポリシーに従って共有ライブラリを扱う必要があります． すなわち以下の約束に従わなければいけません．

• コマンド otool -L (64bit ライブラリの場合は otool64 -L) を使い，各ライブラリの install_name ，互換性，バージョンが適切か確認する．
• 共有ライブラリを別パッケージとし (例外は libfoo.dylib から install_name へのリンク) ， さらに，そうしてできた別パッケージにフィールド Shlibs を設ける．
• ヘッダと， libfoo.dylib からの最終的リンクを BuildDependsOnly: True となっているパッケージに入れ， 他のパッケージが一切そのパッケージに依存しないようにする．

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

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

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

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

選択肢 2 を選ぶと，既存のパッケージのアップグレードに手間がかかります． アップグレードと同時に， Depends: foo との記述のある全てのパッケージに BuildDepends: foo-dev を加える必要があるのです． 注意すべき点は他にもあります． (中間に別のパッケージを経由して) 間接的に当該パッケージに依存するパッケージのアップグレードを確かに成功させるためには， そのようなパッケージに BuildDepends: foo あるいは BuildDepends: foo-dev を加える必要があるかもしれません． 当該パッケージのメンテナには，他のパッケージに BuildDepends が追加されるのを確認する責任があります．

詳細なポリシー

以下ではさらに詳しく解説します． まず新規にソフトウェアを Fink に移植する際のポリシーを解説し，次に既存 Fink パッケージのアップグレードに移ります． ポリシーが実際に適用された例としては Fink パッケージ libpng, libjpeg や libtiff を参照して下さい．

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

共有ライブラリを伴うソフトウェアパッケージには， 「メジャーバージョン」 N がなければいけません． 「メジャーバージョン」は，ライブラリの 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 自体に依存するようにしてはいけません． (後方互換性のため，既存のパッケージは barN に依存して構いません．) 以上を他の開発者がわかるように，barN のパッケージ記述の中に次の真偽値フィールドを設けます．

BuildDependsOnly: True

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

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

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

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

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

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

%i/lib/bar.a

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

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

• パッケージ barN-shlibs:

  %i/lib/bar.N.x.y.dylib
  %i/lib/bar.N.dylib -> %p/lib/bar.N.x.y.dylib
  %i/lib/bar/N/*
  %i/share/bar/N/*
  %i/share/doc/barN-shlibs/*
  

• パッケージ barN:

  %i/include/*
  %i/lib/bar.dylib -> %p/lib/bar.N.x.y.dylib
  %i/lib/bar.a
  %i/share/doc/barN/*
  必要に応じて，他のファイルも含める
  

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

このことはフィールド 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/bar.N.x.y.dylib lib/bar.N.dylib lib/bar/N
  DocFiles: COPYING
<<

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

barN-shlibs の正確な「バージョン」 (これは "%N-shlibs (= %v-%r)" と略記できます) を親パッケージ barN の依存情報に含めたことに注意して下さい． これにより「バージョン」が確かに適合するようになり， さらにパッケージ 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 フィールドは，パッケージがヘッダファイルを含み /sw/include にインストールされる場合， パッケージの .info ファイルに記述されていなければなりません．

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

フィールド Shlibs:

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

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

-install_name が %p/lib/bar.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 のライブラリを提供する最初の「バージョン」または「版」のことです．)

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

「メジャーバージョン」が 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 はいつまでもインストールしたままでいられます．

既存の Fink パッケージをアップグレードする方法:

共有または静的ライブラリをインストールする既存のFinkパッケージについては， アップグレードの最良の方法は，問題のパッケージ foo の新しい「バージョン」を作り， 上のポリシーを満たす新しいパッケージ foo-shlibs を付属させることです． 共有ライブラリ (または foo-shlibs に含まれる任意のファイル) が以前からインストールされていたら， それらの新パッケージで次のように指定します．

Replaces: foo (<< 同等な.旧式パッケージの.バージョン)

これはアップグレードをユーザに意識させないためです． ("Conflicts: foo" ではアップグレードが阻害されるので，使用しないで下さい．)

アップグレード後，"Depends: foo" となっているパッケージは普通に機能し続けます． しかし，そのようなFinkパッケージのメンテナ全てに連絡し， できる限り早くそれらのパッケージで "Depends: foo-shlibs, BuildDepends: foo" とするよう要請しなければいけません． メンテナ全員がその措置を終えるまで， 新しい「メジャーバージョン」の共有ライブラリを提供する新パッケージ fooM と fooM-shlibs を作ることはできません．

既存のパッケージで， install_name の名称や，共有ライブラリの名称やシンボリックリンクの名称を正しく使っていない場合， 注意してケースバイケースで対処することになります． パッケージを新ポリシーに従ってアップグレードする方法を決定することが困難であれば，メーリングリスト fink-devel で議論して下さい．

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

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 のインストールが要求されます．

3.5 Perl モジュール

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

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

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

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

ディレクティブ 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 モジュールを提供します． system-perl-5.8.1-1 の場合， attribute-handlers-pm581, cgi-pm581, digest-md5-pm581, file-spec-pm581,  file-temp-pm581, filter-simple-pm581, filter-util-pm581, getopt-long-pm581,  i18n-langtags-pm581, libnet-pm581, locale-maketext-pm581, memoize-pm581,  mime-base64-pm581, scalar-list-utils-pm581, test-harness-pm581,  test-simple-pm581, time-hires-pm581. です． (この一覧は 0.20.1 から若干変更されています． パッケージメンテナは正しい一覧を使用しているか必ず確認してください．)

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-pm581 と uri-586 のコンフリクトの場合，どちらにもある URI.3pm という manpage は，それぞれ %p/lib/perl5/5.8.1/man/man3/URI.3pm と %p/lib/perl5/5.8.6/man/man3/URI.3pm にインストールされます． ただし，Type: perl X.Y.Z によるスクリプトは変更されていないので， InstallScript にてどこに mapnage をインストールするのかを記述する必要があります． もし複雑なスクリプトを記述していないのであれば，既存のものを用い，ファイルを移動させるだけで済みます．

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

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

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

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

Info2: <<
Package: tk-pm%type_pkg[perl]
Type: perl (5.8.1 5.8.4 5.8.6)
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.8.1, %{Ni}5.8.4, %{Ni}5.8.6
  Replaces: %{Ni}5.8.1, %{Ni}5.8.4, %{Ni}5.8.6
  Files: bin share/man/man1
<<
<<

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

Info2: <<
Package: tk-pm%type_pkg[perl]
Type: perl (5.8.1 5.8.4 5.8.6)
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 では現在のところパッケージ emacs20 と emacs21 にのみ適用され，パッケージ xemacs には適用されません． (この点は将来変わるかも知れません．) 次に Debian のポリシーと異なり， Fink パッケージはどれもファイルを直接 /sw/share/emacs/site-lisp にインストールして構いません．

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

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

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

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

4.2 ディレクトリ

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

4.3 避けるべきこと

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

5 コンパイラ

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

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

5.1 コンパイラバージョン

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

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

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

5.2 g++ ABI

OS X の歴史の中で，g++ ABI は３度変わってきました: 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 フィールドがパッケージによって定義されている場合，fink は gcc_select コマンドが正しい値に設定されているかを確認します． (10.2 と 10.3 での正しい値は　3.3 で， 10.4 での正しい値は　4.0 です． OS X 10.2 以前には gcc_select はありません．)

6 リファレンスマニュアル

6.1 ビルドプロセス

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

解凍段階では，ディレクトリ /sw/src/fink.build/gimp-1.2.1-1 が作成されてソースの tar ボールがそこに解凍されます． 大抵，解凍によりソースを含むディレクトリ gimp-1.2.1 が作られます． これ以降のステップはすべてこの中 (すなわち /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 が実行される．

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

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

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

6.2 フィールド

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

初期データ関連

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

  Package: foo-pm%type_pkg[perl]
  Type: perl (5.8.1 5.8.4 5.8.6)
  Architecture: (%type_pkg[perl] = 581) powerpc

Type: perl (5.6.0 5.8.1)

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

Type: -ssl (boolean), perl (5.6.0 5.8.1)

Info2: <<
Package: foo-pm%type_pkg[perl]
Type: perl (5.6.0 5.8.1)
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
<<
<<

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]
  <<
<<
<<

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

依存性関連

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

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

Depends: expat-shlibs

Depends: openssl097-shlibs, expat-shlibs

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

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

解凍段階関連:

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/
<<

SourceRename: %n-%v.tar.gz

Source-MD5: 4499443fa1d604243467afe64522abac

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

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

パッチ段階関連: