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 版 as modified in December, 2006 to handle 64bit libraries and from January, 2008 to handle private shared libraries. (In addition, the discussion was updated in June, 2008 to eliminate obsolete references to a transitional period for implementing the shared libraries policy.) We begin with a quick summary, and then discuss things in more detail. 最初に要点をかいつまんで述べ，後から詳細に移ります．

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

Note that a package may also install private shared libraries, which are not intended to be linked from any other package. In this case, the libraries need not go into a separate package, but a Shlibs field must still be part of the package containing shared libraries. Also, maintainers should try to avoid storing a final link from libfoo.dylib in the main library directory %i/lib (or its 64-bit equivalent), to prevent other programs from accidentally linking to this library.

このポリシーに反し，パッケージを分割しない場合には，フィールド 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 などを使えばだいじょうぶです．)

Each software package for which public shared libraries are built must have a major version number N, which is included in the shared library's filename (for example, 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

It is not be permitted for another package to depend on barN itself. (Although there may still be a few such dependencies involving packages which were in place prior to February, 2002.) This is signaled to other developers by a boolean field 

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

from the install_name path and from the linking path to the actual library. (The first will not be needed if the library is in fact installed at the install_name path, which is becoming more common.)

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

%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 の正確な「バージョン」 (これは "%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 や 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 モジュールのファイルを /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 では現在のところパッケージ emacs21, emacs22, emacs23 にのみ適用され，パッケージ xemacs には適用されません． (この点は将来変わるかも知れません．) 次に Debian のポリシーと異なり， Fink パッケージはどれもファイルを直接 /sw/share/emacs/site-lisp にインストールして構いません．

3.7 Source Policy

Sources should normally be downloaded from the location(s) that the upstream developer(s) use, and any modifications for Fink should be done through the use of a PatchFile and/or a PatchScript. Do not make changes manually and use a changed source archive as a Source in your Fink packaging.

If a VCS checkout (e.g. from git or svn) is to be used, e.g. because a project doesn't do formal releases, or a fix for a particular issue has been added between releases of a package, an acceptable source can be generated via the following method:

  1. Check out the package, preferably at a definite revision of the VCS.
  2. Make an archive from the VCS checkout (e.g. zip, tar, tar.gz, or tar.bz2).

    Give the tarball a unique version. For example, you can include the VCS revision in the archive name, e.g. foo-0svn1234.tar.gz for a package that doesn't make releases, or bar-1.2.3+svn4567.tar.bz2 for a Fink package which is between upstream releases.

  3. Use the same Version in your .info file.
  4. It is also useful to put the commands that you ran to generate the source tarball in the DescPackaging field.
  5. Upload the tarball to a public download site where users can use fink to download it. If you don't have ready access to one, ask on the Fink developers mailing list or the #fink IRC channel, and someone should be able to help.

3.8 File Download Policy

Packages are not to download any files during the unpack, patch, compile, install, or build phases of the build process. Any large patches (i.e. larger than can be accommodated conveniently in a PatchFile) that need to be applied should set up as additional Sources in accordance with the Source Policy.

Packages may download data in a PostInstScript after they have been installed on the system, under some limited circumstances:

If you are unsure, contact the Fink Core Team.

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