Fink

パッケージ作成 - 3. パッケージ化ポリシー

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

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

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

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

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

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 版です。 これは、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_name が libquux.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 とします． Conflicts と Replaces のフィールドを用いることで，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 チェックアウト (git や svn など) が使われる場合、 以下の要領で作成したソースを使用することができます:

  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. ファイルシステムのレイアウト