pkgsrc の目玉の一つは、多くのプラットフォームで動作することです。 そのため、pkgsrc のパッケージの移植性をできるかぎり高めることが重要になります。 本章では、pkgsrc の作業に際して、 注意が必要となる具体的な事項を説明します。

pkgsrc の利用者は、MAKECONF によって参照されるファイル (標準では mk.conf) でいくつかの変数を上書きして、pkgsrc の設定をすることができます。 このような変数を make(1) のプリプロセッサーディレクティブ (たとえば .if や .for) の内部で使いたい場合は、 利用者の設定が読み込まれる場所より前で ../../mk/bsd.prefs.mk をインクルードする必要があります。

しかし、変数によっては、 まだ定義されていない変数への参照を含んでいることがあるために、 ../../mk/bsd.prefs.mk をインクルードした後では完全に定義することができないものがあります。 シェルコマンドの場合は、変数の実態はマクロであり、 使われるときにしか展開されないので、このことは問題にはなりません。 ただし、前述したプリプロセッサーディレクティブの内部や、 依存性を記した行 (target: dependencies のような形式の行) においては、読み込み時に変数が展開されます。

時々、パッケージがユーザーとの対話を必要とする場合がありますが、 そのような状況は何通りもありえます:

どの段階で対話が必要になるかをpkgsrcの機構に知らせるため、 INTERACTIVE_STAGE 定義が用意されており、 パッケージのMakefileで定義します。 たとえば以下のようにします。

INTERACTIVE_STAGE=      build
    

複数の段階を指定することもできます:

INTERACTIVE_STAGE=      configure install
    

利用者は、BATCH 変数を設定して、 この定義がおこなわれているパッケージをとばすことができます。

ソフトウェアの作者は、 そのソフトウェアをどのようなライセンスのもとでコピーすることができるかを、定めることができます。 これは著作権法にもとづくことであって、ライセンス選択の理由は pkgsrc システムの範疇外です。pkgsrc システムでは、 ライセンスのなかには、従うことに不服だったり、 従うことが困難あるいは不可能だったりする利用者がいるようなライセンスがたくさんあることを認識しています。 Free Software Foundation ではいくつかのライセンスに対して、 それが「自由」なライセンスであると表明していますし、 Open Source Initiative では「オープンソース」を定義しています。 pkgsrc では、ライセンスが「自由」あるいは「オープンソース」であるといった目印をパッケージにつけたりはしないという方針をとっています。 ただし、これらの定義にあてはまらないライセンスをもつパッケージには、 ライセンスについて記した目印がついています。 なお、ライセンスでコピーを認めていないパッケージは、 明らかに、「自由」にも「オープンソース」にも該当しません。

「自由」でも「オープンソース」でもないパッケージについては、 構築してよいということを、個々のライセンスについて利用者が pkgsrc に指定しておかない限り、 pkgsrc はパッケージを構築しません。 なお、このドキュメンテーションでは、「ライセンスに同意する」 ("accepted the license") という言いまわしを避けています。 pkgsrc システムは、単に、 フリーでないライセンスのソフトウェアを誤って構築してしまうことがないようにする仕組みを提供しているだけです。 判断や責任は、利用者に委ねています。 (現在のところ、バイナリーパッケージのインストールは、 この仕組みの対象外です。これはバグです。)

BSD ライセンスと GPL のパッケージだけをインストールし、 それ以外はインストールしたくない、ということがあるかもしれません。 標準状態では、フリーなライセンスが ACCEPTABLE_LICENSES 変数に列挙されています。 ACCEPTABLE_LICENSES 変数を "+=" ではなく "=" を使って設定すれば、 どのライセンスを許容するかを利用者が上書きできます。 標準状態で許容されているライセンスは以下のとおりです。

    public-domain
    gnu-gpl-v2 gnu-lgpl-v2
    gnu-gpl-v3 gnu-lgpl-v3
    original-bsd modified-bsd
    x11
    apache-2.0
    cddl-1.0
    open-font-license
    

ライセンスの目印の仕組みは、パッケージの構築、インストール、 および使用にまつわる著作権関連の問題を処理するためのものであって、 再配布にまつわる問題 (RESTRICTED および NO_SRC_ON_FTP などを参照) のためのものではありません。 再配布に制限のあるパッケージには、 これらの変数を使って再配布に制限があることを示す必要があります。

パッケージのコピーが特殊なライセンスのもとで認められていることを示すには、 そのライセンスを pkgsrc/licenses に置いたうえで、 LICENSE 変数をライセンスを特定する文字列に設定します。 たとえば、graphics/xv では以下のようになります。

LICENSE=        xv-license
    

構築しようとすると、利用者はそのパッケージに適用されているライセンスが ACCEPTABLE_LICENSES 変数に設定されていないことを知らされます。

% make
===> xv-3.10anb9 has an unacceptable license: xv-license.
===>     To view the license, enter "/usr/bin/make show-license".
===>     To indicate acceptance, add this line to your /etc/mk.conf:
===>     ACCEPTABLE_LICENSES+=xv-license
*** Error code 1
    

ライセンス自体は make show-license すると見ることができます。 そのライセンスのものを構築してよい場合は、 pkgsrc が今後はそのライセンスを理由に構築をやめないように、 上の表示中で指示されている行を mk.conf に追加することができます。

ACCEPTABLE_LICENSES+=xv-license
    

新しいライセンスが適用されているパッケージを追加する場合、 表示用のライセンスのテキストを pkgsrc/licenses に追加します。既知のライセンスの一覧は、 このディレクトリーで見ることができます。

ライセンスが (整形以外で) 変更された場合は、 必ず、新しいライセンスの名前を以前のものと別の名前にします (たとえば、 バージョン番号があればそれを、なければ日付を末尾につけるなど)。 これは、前バージョンのライセンスのもとにあるプログラムを構築することを pkgsrc に指示している利用者が、 新しいライセンスのもとにあるプログラムを構築しないようにするためです。 もっと高度な点でいうと、 pkgsrc はライセンスの相当性を評価しません。 すなわち、個々のライセンスのテキストを、二組織のいずれかが (「自由」あるいは「オープンソース」であると) 認めているかどうかという、 機械的な検査をしているだけなのです。

LICENSE=shareware や、 LICENSE=no-commercial-use のような言いまわしは、 ライセンスの文面を特定できないので、 使わないことになりました。 また、このような言いまわしを使った場合の別の問題として、 利用者が pkgsrc に対して、同じ目印のついた複数のパッケージのうち、 ひとつのパッケージだけは構築を続行するが、 それ以外のパッケージは構築を続行しない、 といった指定ができなくなるというものもあります。

ライセンスによっては、ソフトウェアの再配布方法に制限があります。 パッケージが「自由」あるいは「オープンソース」でない限りは、 ライセンスの目印が必要なので、制限のあるパッケージにはすべてライセンスの目印がついているはずです。 その制限について記述しておくと、パッケージのツールは、 自動的に制限されたこと (たとえばバイナリーパッケージを FTP サイトに置くこと) を控えたりすることができます。

ソース (distfile) とバイナリーそれぞれについて、 置いていけないのが FTP サイトか CD-ROM かの組み合わせで、 4 種類の制限を表現することができます。どのライセンスでも、 これが厳密な文言となっていることはほとんどないことや、 フリーでない各ライセンスはお互いに異なる傾向があることから、 pkgsrc では FTP と CD-ROM を定義しています。 pkgsrc では、"FTP" を、ソースやバイナリーのファイルを、 インターネット上で料金を払わずに利用できるようにしてはいけない、 という意味で使います。 pkgsrc では、"CD-ROM" を、ソースやバイナリーを、 配布料金をとるような何らかの種類の媒体に、 他のソースやバイナリーパッケージと同梱して利用できるようにすることはできない、 という意味で使います。

このような 制限を表現するため、パッケージシステムでは以下のような制限を設定で きる5個のmake変数を定義しています:

パッケージは他のパッケージに依存するかもしれません。そして、この依存性を定 義するためのいろいろな方法があります。pkgsrc は、buildlink3.mkを使った依存関 係 (依存性の処理用としては、こちらが望ましい方法です。 この方法では以下の各変数を使っています。 さらなる情報はChapter 14, buildlink 方法論を参照してください) のほか、 BUILD_DEPENDS および DEPENDS 定義、 USE_TOOLS 定義をサポートしています。

両変数の基本的な差異は、以下の通りです: DEPENDS定義では、 その依存性がバイナリーパッケージ内に記録されるので、 後でバイナリーパッケージをインストールする時に依存性が呼び出されます。 一方、BUILD_DEPENDS定義ではバイナリーパッケージにそのような記録はされず、 パッケージの構築に際して依存性があることが示されているだけです。

つまり、あるパッケージが必要となるのが構築時だけである場合、そのパッケージ はBUILD_DEPENDSとして書きます。

BUILD_DEPENDSおよび DEPENDS定義の書式は以下の通りです:

<pre-req-package-name>:../../<category>/<pre-req-package>
    

なお、この“pre-req-package-name” のバージョン番号には、pkg_info(1) で説明され ている各ワイルドカードを含めることができます。

パッケージの構築用に別のパッケージに含まれるファイルが必要な場合は、 関連する配布ファイルを DISTFILES に追加して、 必要なファイルが自動的に展開されるようにします。例としては print/ghostscript パッケージをご覧ください。 (このパッケージは、 構築の際に jpeg のソースがソースの状態で存在することに依存しています。)

パッケージは、すでにインストール済みの別のパッケージと衝突する可能性があり ます。例えば、パッケージが、pkgsrcの中の別のパッケージと同じファイルをイン ストールするような場合です。

この場合、衝突するパッケージ(バージョン文字列を含む)のリストをスペースで区 切ってCONFLICTSにセットすることができます。

例えば、x11/Xaw3d およびx11/Xaw-Xpmは同じ共有ライブラリーをイ ンストールします。したがって、pkgsrc/x11/Xaw3d/Makefileに以下のような設定を おこなってください。

CONFLICTS=      Xaw-Xpm-[0-9]*
    

そして、pkgsrc/x11/Xaw-Xpm/Makefileには以下の設定が必要です。

CONFLICTS=      Xaw3d-[0-9]*
    

パッケージは、名前のプレフィックスが同じで、異なるバージョン文字列をもつ別 のパッケージと自動的に衝突します。例えば“Xaw3d-1.5”は、古いバージョンの “Xaw3d-1.3”と衝突するでしょう。

環境によってはパッケージを構築しないよう指示するような理由がいくつかありま す。パッケージが、ほとんどのプラットフォームで構築および実行できる場合は、 NOT_FOR_PLATFORMとして例外を記述します。逆に、パッケージが一部のプラットフォー ムでしか構築および実行できない場合は、ONLY_FOR_PLATFORMを設定します。 ONLY_FOR_PLATFORM と NOT_FOR_PLATFORM の値はいずれも、OS triples (OS-version-platform) であり、 グロブ形式のワイルドカードを使うことができます。

パッケージのなかには、あるオペレーティングシステムの特定のバージョンに強く依存するものがあります。 たとえば、LKM や sysutils/lsof などです。 このようなバイナリーパッケージは、同じ OS の別バージョンと後方互換ではないので、 FTP サーバーでは対象バージョン専用のディレクトリーにアップロードするようにします。 OSVERSION_SPECIFIC を “yes” に設定して、 パッケージに印をつけてください。この変数は、現在のところ、 パッケージシステム内部のどこでも使われませんが、 将来は使われることになるかもしれません。

パッケー ジをとばすべき場合(たとえば、そのパッケージが提供する機能が、すでにシステム で提供されている場合)は、 PKG_SKIP_REASONにそのことを説明するメッセージを設 定します。必要な条件が満たされていないせいでパッケージの構築が失敗するであ ろう場合は、PKG_FAIL_REASONにそのことを説明するメッセージを設定します。

あるパッケージを、一旦インストールしたら削除できないようにするためには、 そのパッケージの Makefile で PKG_PRESERVE 定義を設定します。この定義を設定した pkgsrc エントリーから作られたバイナリーパッケージには、その旨が記録されます。 “preserved” 付きのパッケージは、 pkg_delete(1) を使っても、 “-f” オプションを付けない限りは削除されません。

脆弱性が発見された場合、そのことを localsrc/security/advisories/pkg-vulnerabilitiesに記載してcommitしてくださ い。このファイルを commit した後、同じディレクトリーで make upload して、ftp.NetBSD.org 上のファイルを更新してください。

脆弱性の修正を、パッチの適用によっておこなった場合は、修正後に PKGREVISION を上げます (もちろん、問題の修正を、 新しくリリースされたソフトウェアを使っておこなった場合は、 これは必要ありません)。

また、修正を安定版 pkgsrc 枝に適用したほうがよい場合は、 pullup 要求を提出してください。

ftp.NetBSD.org 上にすでに置かれているバイナリーパッケージは、 週次の cron ジョブによって半自動的に対処されます。

既存のパッケージに修正を加えたときに、PKGNAMEのバージョン番号を変えると便利 な場合があります。元の作者による将来のバージョンと衝突しないようにするため、 PKGREVISION=1 (2, ...)を設定して、パッケージのバージョンに “nb1”, “nb2”, ... という接尾辞をつけることができます。この“nb”は、パッケージのツール群からは“.”と 同様の扱いを受けます。たとえば、

DISTNAME=       foo-17.42
PKGREVISION=    9
    

とすると、PKGNAMEは“foo-17.42nb9”になります。 たとえば DIST_SUBDIR の設定用などに、 PKGNAME に接尾辞 “nbX” がつかない、 元の値を使いたい場合は、PKGNAME_NOREV を使います。

このパッケージの新しいリリース版が出た際には、 PKGREVISIONは消してください。 たとえば、上で例示したパッケージの新しいマイナーリリースに際しては、以下の ようにします。

DISTNAME=       foo-17.43
    

バイナリーパッケージに対して自明でない変化をおよぼす場合は、すべて、 PKGREVISION を上げるようにします。 PKGREVISION を上げないと、 変更前のバージョンをインストールしている人が、 そのパッケージが古くなったことを知るすべがなくなってしまいます。 したがって、PKGREVISION を上げない変更とは、本質的に 「誰もアップグレードする必要のない自明な変更」ということであり、 これが PKGREVISION を上げるべきか否かを大雑把に判断する方法です。 PKGREVISION を上げる意味のない変更には、たとえば以下のようなものがあります。

PKGREVISION を上げる価値のある変更には、 たとえば以下のようなものがあります。

依存するパッケージの ABI が変更された場合にも、 PKGREVISION を上げる必要があります。

複数のファイルに含まれる同じテキストを置換したい場合や、 テキストの置換方法を変化させたい場合には、パッチだけでは実現できません。 そこで SUBST の枠組の出番です。この枠組では、 ファイル内のテキストを置換するために簡単に使えるインターフェースを用意しています。 たとえば以下のように使います。

SUBST_CLASSES+=                 fix-paths
SUBST_STAGE.fix-paths=          pre-configure
SUBST_MESSAGE.fix-paths=        Fixing absolute paths.
SUBST_FILES.fix-paths=          src/*.c
SUBST_FILES.fix-paths+=         scripts/*.sh
SUBST_SED.fix-paths=            -e 's,"/usr/local,"${PREFIX},g'
SUBST_SED.fix-paths+=           -e 's,"/var/log,"${VARBASE}/log,g'
    

SUBST_CLASSES は、ここで定義する SUBST の塊を区別するための識別子を並べたリストです。 SUBST の枠組は pkgsrc で多用されているので、この変数には常に += 演算子を使うことが重要です。 そうしないと、一部の置換がおこなわれなくなることがあります。

各 SUBST の塊の残りの変数は、 最初の行の識別子 (この例では fix-paths) を使ってパラメーター化されています。 これらは、関数呼び出しの引数とみなすことができます。

SUBST_STAGE.* は、 この置換をどの期におこなうかを指定します。 実際に使われるものは限られていますが、相の名前と pre-, do-, post- のあらゆる組合せを使うことができます。 もっともよく使われるのは post-patch と pre-configure です。このふたつのうち、 pre-configure を使うと、 bmake patch を実行することで、 パッチを適用したほかは一切変更されていない状態にすることができるため、 こちらのほうが好まれます。このことは、 新しいパッチを作成するためにパッケージのデバッグをする際に、 特に便利です。これと同様に、pre-install よりも post-build のほうが好まれます。 これは、一般的に install 相は極力簡素なものにするほうがよいからです。 post-build を使った場合、 後にインストールされるものと同じファイルが作業ディレクトリーにできあがるので、 正しく置換がおこなわれたかを確認することができます。

SUBST_MESSAGE.* は、 置換がおこなわれる直前に表示するテキストで、省略可能です。

SUBST_FILES.* は、置換の対象となるファイルを、 シェルのグロブパターンで指定したものを並べたリストです。 このパターンは、WRKSRC ディレクトリーからの相対位置として解釈されます。

SUBST_SED.* は置換の内容を sed(1) への引数の形で指定したものを並べたリストです。 各 sed コマンドの前には -e をつけて、 SUBST の塊全体が一様に見えるようにします。

以上のほかにも変数がいくつかありますが、 それらはほとんど使われないものなので、 mk/subst.mk ファイル内でのみ文書化されています。

動的なURLからダウンロードする必要がある場合は、 DYNAMIC_MASTER_SITES を設定す ることができます。すると、make fetchは、ダウンロードすべき各ファイルを引 数としてfiles/getsite.shを呼び出します。このスクリプトは、ファイルをダウン ロードするディレクトリーのURLを出力することが前提となっています。 graphics/ns-cult3dが、 この使い方の例となっています。

パスワード用に個人情報の登録が必要だったり、ソースに代金を払う必要があった り、その他もろもろの理由により、ダウンロードが自動化できない場合は、 FETCH_MESSAGE を、 構築中止前にユーザーに表示する説明文を行ごとに並べたリストに設定することができます。 たとえば以下のようにします。

FETCH_MESSAGE=  "Please download the files"
FETCH_MESSAGE+= "    "${DISTFILES:Q}
FETCH_MESSAGE+= "manually from "${MASTER_SITES:Q}"."
    

時々、ソフトウェアパッケージの作者がソフトウェアのリリース後に変更を加え、 変更後のdistfileを、バージョン番号を変えずに公開することがあります。このと き、pkgsrcにそのパッケージがすでに入っていると、チェックサムが一致しない ことになります。distfileの更新が意図されたものであって、 トロイの木馬などが仕込まれたのではないことを確認するため、 新しい distfile の内容と変更前の古い distfile の内容と比較してください。 新旧の distfile を比較したことと、何が変わったのかを、 commit メッセージに含めてください。 確認後、この問題の正しい回避策は、DIST_SUBDIR を一意な (普通は PKGNAME_NOREV にもとづく) ディレクトリー名に設定することです。 これを設定すると、このパッケージの DISTFILES と PATCHFILES はすべて、 distfiles ディレクトリー以下の、設定した名前のサブディレクトリーに置かれます。 (詳細は、Section 19.1.11, “既存パッケージ修正時に、バージョンを上げるにはどうするか”をご覧ください。) この問題がよく起きる場合は、ディレクトリー名に PKGNAME を使ったり (これにより nbX サフィックスが含まれる)、 ${PKGNAME_NOREV}-YYYYMMDD のように日付を付けたりすることができます。 設定後は、distinfo ファイルを作り直すのを忘れないでください。 このファイルでは、ファイル名のなかに DIST_SUBDIR パスが含まれているからです。 この変更によって、インストールされるパッケージが以前のものと異なるものになる場合は、 PKGREVISION も上げます。 さらに、パッケージの正当な作者にメールを出して、 リリース後に、ファイル名を変えずに distfile の内容を変えるのはよろしくないやり方だと伝えてください。

pkgsrcはさまざまな種類のマシンをサポートします。それらはa.outとELFのような 異なるオブジェクトフォーマットを使い、共有ライブラリー、ダイナミックローディ ングの有無すらも異なります。これに対応するためにコマンドそのもの、およびオ プションがコンパイラー、リンカーなどに渡される必要があります。すべてのマシ ンで正しく動作させることは非常にむずかしく、テストのためにすべてのマシンを 持っていない場合は特にそうでしょう。 devel/libtoolパッケージはこれを助けます。 devel/libtoolはプラットフォームによらずに、 ソースファイルから、静的、動的なライブラリー両方を構築する方法 を“知って”いるからです。

以下に、libtoolをパッケージで使用するための7つの手順を記述します。

USE_LIBTOOL=yes をパッケージの Makefile に追加します。こうするとほとんどの場合、パッケージ固有の libtool を無視します。古い libtool を使っているパッケージでは、 libtool はdo-configureターゲットでltconfigスクリプトにより作られます。make configure; find work*/ -name libtool のようにして、libtool スクリプトの場所を確認することができます。

LIBTOOL_OVERRIDE で、どの libtool スクリプトを無視するかを、WRKSRC からの相対位置で指定します。 指定しなかった場合、“libtool */libtool */*/libtool” に設定されますので、パッケージ固有の libtool スクリプトの場所がこのいずれとも異なる場合は、適宜設定してください。

静的ライブラリー *.a の構築やインストールが必要ない場合は、かわりに SHLIBTOOL_OVERRIDE を使います。

パッケージが動的共有オブジェクトのロードに、libtool (libltdl)のプラットフォー ム独立なライブラリーを使う場合は、 devel/libltdl/buildlink3.mkをインクルードしてください。

パッケージによっては、環境により動作や構築ができなくなるような、正しくない libtoolの使い方をしているものがあります。ありがちな間違いは以下のようなもの です。

パッケージが、configureスクリプトやmakefileの雛型Makefile.inを再生成するた めにGNU autoconfまたはautomakeを実行する必要がある場合、これらの実行は pre-configureターゲットでおこないます。

autoconfのみを必要とするパッケージでは以下のようになります:

AUTOCONF_REQD=  2.50            # if default version is not good enough
USE_TOOLS+=     autoconf        # use "autoconf213" for autoconf-2.13
...

pre-configure:
        cd ${WRKSRC} && autoconf

...
    

また、automakeとautoconfを必要とするパッケージでは以下のようになります:

AUTOMAKE_REQD=  1.7.1           # if default version is not good enough
USE_TOOLS+=     automake        # use "automake14" for automake-1.4
...

pre-configure:
        set -e; cd ${WRKSRC}; \
        aclocal; autoheader; automake -a --foreign -i; autoconf

...
    

GNU Automake を使うパッケージは、ほぼ確実に GNU Make を必要とします。

生成されたファイルに対して、configureプロセスがさらに変更を加える時がありま すが、この時には構築プロセスが一連のautomakeの手順を再実行しようとします。 configureの段階でさまざまなファイルに手を加えると、この挙動は止められます。 この挙動が問題が起こす場合は、そのパッケージのMakefileで AUTOMAKE_OVERRIDE=NOを設定することができます。

C, C++ および Fortran 言語用のコンパイラーは、 NetBSD の基本システムに附属しています。標準では、 pkgsrc はパッケージが C で書かれていると仮定し、それ以外のコンパイラーをすべて隠します (ラッパーの枠組による。Chapter 14, buildlink 方法論参照)。

パッケージがどの言語のコンパイラーを必要としているかを表すには、 USE_LANGUAGES 変数を設定します。使うことのできる値は、 現在のところ、“c”, “c++”, “fortran” (および、これらの任意の組合せ) です。標準では “c” になります。GNU の configure スクリプトを使うパッケージでは、 C++ で書かれているものであっても、通常は configure 相で C コンパイラーを必要とします。

プログラムが Java で書かれている場合は、pkgsrc における Java の枠組を使います。パッケージは ../../mk/java-vm.mk をインクルードする必要があります。 この Makefile の断片は、以下の変数を用意してくれます。

perl スクリプトがパッケージに含まれる場合は、 USE_TOOLS 変数に “perl” を追加し、 適切なインタープリターへのパスが設定されるようにするために REPLACE_PERL を設定します。 REPLACE_PERL の値には、パスを調節する対象のスクリプトを WRKSRC からの相対位置として並べたリストを含めるようにします。 対象のスクリプト内に現れる */bin/perl はすべて、 perl の実行ファイルへのフルパスに置き換えられます。

特定のバージョンの perl が必要な場合は、 PERL5_REQD 変数をバージョン番号に設定します。 標準では “5.0” になります。

perl モジュールの扱いについては、 Section 19.6.6, “perl モジュールをインストールするパッケージ”をご覧ください。

現在のところ、pkgsrc では、他のプログラミング言語に対する特別な扱いはありません。 その言語のコンパイラーのパッケージに buildlink3.mk ファイルがある場合は、 このファイルをインクルードします。このファイルがない場合は、 適切なコンパイラーのパッケージへの (構築時) 依存性を追加するだけです。

パッケージに最初から GNU configure スクリプトが附属している場合は、 構築の障害の修正方法としては、コードを変更せずに configure スクリプトを変更するのが望ましい方法です。configure スクリプトが附属しない場合は、 コンパイル対象のオペレーティングシステムやハードウェアアーキテクチャーに応じて必要なマクロを定義している C プリプロセッサーを役立てることができます。このマクロは、たとえば #if defined(__i386) のようにして調べることができます。 ほとんどすべてのオペレーティングシステム、ハードウェアアーキテクチャー、 およびコンパイラーには、独自のマクロがあります。 たとえば、__GNUC__, __i386__, __NetBSD__ の各マクロがすべて定義されている場合は、i386 互換 CPU 上の NetBSD を使っていることと、 コンパイラーが GCC であることがわかります。

以下に列挙するハードウェアおよびオペレーティングシステム用のマクロは、 使っているコンパイラーに依存します。 たとえば、Solaris 上でコードを条件付きコンパイルしたい場合、 __sun__ は SunPro コンパイラーでは定義されていないので使ってはいけません。 かわりに __sun を使います。

#include <sys/param.h>
#if (defined(BSD) && BSD >= 199306)
/* BSD-specific code goes here */
#else
/* non-BSD-specific code goes here */
#endif

FreeBSD     __FreeBSD__
DragonFly   __DragonFly__
Interix     __INTERIX
IRIX        __sgi (TODO: 出典の確認)
Linux       linux, __linux, __linux__
NetBSD      __NetBSD__
OpenBSD     __OpenBSD__
Solaris     sun, __sun

i386        i386, __i386, __i386__
MIPS        __mips
SPARC       sparc, __sparc

GCC         __GNUC__ (メジャーバージョン), __GNUC_MINOR__
MIPSpro     _COMPILER_VERSION (MIPSpro 7.41 なら 0x741)
SunPro      __SUNPRO_C (Sun C 5.7 なら 0x570)
SunPro C++  __SUNPRO_CC (Sun C++ 5.8 なら 0x580)

ソースファイルのなかには、コンパイラーのバージョンとアーキテクチャーの組合 せによって、また、ほとんどの場合は、最適化を有効にしたことも関係して、コン パイラーのバグを発現させるものがあります。よくある症状は、gccの内部エラーや、 ファイルのコンパイルが完了しないというものです。

たいていは、回避策として、MACHINE_ARCH とコンパイラーのバージョンを確認し、 問題のあるファイル・MACHINE_ARCH・コンパイラーの組合せに対して最適化を無効に し、そのことをpkgsrc/doc/HACKSに文書化しておくことが必要となります。 このファイルに多くの例が載っているので、参照してください。

このエラーメッセージは、しばしば、 パッケージが必要な共有ライブラリーにリンクしていないことを表します。 以下の関数は、このエラーメッセージを何度も出すことがわかっているものです。

このようなリンカーのエラーの修正は、多くの場合、 パッケージの Makefile に LIBS.OperatingSystem+= -lfoo を追加してから bmake clean; bmake を実行すれば十分です。

extern int extern_func(int);

static inline int
inline_func(int x)
{
        return extern_func(x);
}

int main(void)
{
        return 0;
}

時には、コンパイラーの実行でオペレーティングシステム固有のソフトリミットに達するために、 パッケージの構築に失敗することがあります。 UNLIMIT_RESOURCES 変数を設定して、 pkgsrc に資源の制限を解除するよう伝えることができます。 現在のところ、使うことのできる値は、 “datasize” と “stacksize” (あるいは両方) です。 この変数を設定すると、シェル組み込みの ulimit コマンドを実行した場合と同様に、それぞれ、 データセグメントのサイズとスタックのサイズの上限を、 ハードリミットまで引き上げます。

一部のプラットフォームに附属する BSD 互換の install は、 一度に複数のディレクトリーを作成することができません。 このため、 ${INSTALL_*_DIR} を使うときは、以下のようにします。

${INSTALL_DATA_DIR} ${PREFIX}/dir1
${INSTALL_DATA_DIR} ${PREFIX}/dir2
    

こうするかわりに、単に “dir1 dir2” を INSTALLATION_DIRS 変数に追加するという方法もあります。 こうすると、適切な処理が自動的におこなわれます。

一般的には、ドキュメンテーションは ${PREFIX}/share/doc/${PKGBASE} または ${PREFIX}/share/doc/${PKGNAME} (後者は、 パッケージのバージョン番号を含んでいます) 以下にインストールします。

GNU autoconf を使っている最近のパッケージの多くは、 HTML のドキュメンテーションのインストール先を、 “--with-html-dir” オプションを使って設定することができます。 時には、このフラグを使わないとドキュメンテーションが ${PREFIX}/share/doc/html や他の場所にインストールされるために、 このフラグを使う必要があることがあります。

例外は、textproc/gtk-doc ツールによって生成される、 ライブラリーの API のドキュメンテーションです。このドキュメンテーションは、 専用のブラウザー (devhelp) から使うものであり、ブラウザーが標準で使う場所である ${PREFIX}/share/gtk-doc に置くようにします。 このようなドキュメンテーションは、ファイル名の末尾が .devhelp または .devhelp2 であることから区別できます。 (これらのファイルを ${PREFIX}/share/doc/${PKGBASE} または ${PREFIX}/share/doc/${PKGNAME} にインストールしても使うことができます。この場合、 これらのディレクトリーの直下に .devhelp* ファイルを置く必要があり、 サブディレクトリー階層を追加することはできません。通常は、 “--with-html-dir=${PREFIX}/share/doc” を使えばそのようにすることができます。 ${PREFIX}/share/gtk-doc のほうが好ましいのですが。)

パッケージによっては (ほとんどは games カテゴリーのもの)、 システム上の各ユーザーが最高得点を記録できるように、 得点ファイルをインストールします。これを実現するために、 バイナリーは setgid してインストールし、得点ファイルは グループとオーナーのいずれかまたは両方を当該グループやオーナー (伝統的には "games" ユーザーおよびグループ) の所有とする必要があります。 SETGIDGAME, GAMEDATAMODE, GAMEGRP, GAMEMODE, GAMEOWN の各変数でこの挙動を制御します。詳細は mk/defaults/mk.conf に書かれています。

なお、games に setgid されたインストールは、標準では有効になっていません。 SETGIDGAME=YES を設定すると、 これに応じて他の各変数が設定されます。

このため、パッケージではファイルの所有やアクセス許可属性を決してハードコードせずに、 INSTALL_GAME および INSTALL_GAME_DATA の設定に応じて適切に設定されるようにします。

パッケージが DESTDIR に対応しているというのは、 ファイルを最終的な置き場所にインストールせずに、 足場となるディレクトリーにインストールするということです。 その後、通常の方法でインストール可能なバイナリーパッケージが作成されます。 この対応には、二つの方法があります。 パッケージを root としてインストールする必要がある場合 (“destdir”)と、root 以外のユーザーでインストール可能な場合 (“user-destdir”) です。

パッケージには perl 以外のインタープリターへのパスがハードコードされていることもあります。 スクリプトのインタープリターへのフルパスを適切なものにするため、 当該パッケージの Makefile で、 以下のような定義をする必要があります (ここでは例として tclsh を使います)。

REPLACE_INTERPRETER+=   tcl
REPLACE.tcl.old=        .*/bin/tclsh
REPLACE.tcl.new=        ${PREFIX}/bin/tclsh
REPLACE_FILES.tcl=      # パスを修正する必要がある tcl スクリプトを列挙します
# REPLACE_PERL と同様に、${WRKSRC} からの相対位置とします
    

perl5モジュールを提供するパッケージでは、MakefileにMakefileの断片 ../../lang/perl5/module.mkをインクルードしてください。このファイルには、perl5モ ジュール用の標準的なperlの構成をするdo-configureターゲットのほか、その構成 を調整するためのさまざまなフックが含まれています。詳細は、このファイル中の コメントをご覧ください。

perl5 のモジュールがインストールされる場所は、構築プロセスで使われるperl の バージョンに応じて変わります。これを扱うために、pkgsrc は、 インストールされた.packlistファイル(ほとんどの perl5 モジュールが生成します) に列挙された各ファイルに対応する行を、PLIST に追加します。これは、packlist ファイルへのパスをスペースで区切ったリストをPERL5_PACKLISTとして定義するこ とで行なわれるようになります。たとえば以下のように定義します。

PERL5_PACKLIST= ${PERL5_SITEARCH}/auto/Pg/.packlist
    

PERL5_SITELIB, PERL5_SITEARCH, PERL5_ARCHLIBの各変数は、perl5モジュールがイ ンストールされうる三つの場所を表すもので、packlistを持たないperl5パッケージ で使うことができます。この3変数の置換は、PLISTでもおこなわれます。

パッケージによっては、infoファイルをインストールしたり、“makeinfo”または “install-info”コマンドを使ったりします。 このようなパッケージでは、パッケージの Makefile で INFO_FILES を定義するようにします。 これを定義しておくと、info ファイルを Info ディレクトリーファイルに登録するために、INSTALL および DEINSTALL スクリプトが作られるようになります。 info ファイルの登録用の “install-info” コマンドは、 システム附属のものが使われるか、 または、必要があればそれ用のパッケージが自動的に追加されて使われます。

PKGINFODIR は ${PREFIX} 以下のディレクトリーで、 info ファイルが置かれる主な場所です。 PKGINFODIR は標準では “info” となっており、利用者が上書きすることができます。

info ファイルは、そのパッケージの PLIST に列挙します。ただし、分割された info ファイルは列挙する必要はありません。

構築時に “makeinfo” コマンドが必要なパッケージは、 Makefile で USE_TOOLS 変数に “makeinfo” を追加する必要があります。 あるバージョン以上の“makeinfo”コマンドが必要な場合は、 パッケージの Makefile で TEXINFO_REQD 変数を必要な最低バージョンに設定します。 デフォルトでは、 3.12 が最低限必要なバージョンとなります。 makeinfo コマンドがシステムにないか、 最低限必要なバージョンを満たさない場合は、 devel/gtexinfo パッケージへの構築時の依存関係が自動的に追加されます。

パッケージで提供されるソフトウェアの構築やインストールの過程では、 install-info コマンドを使ってはいけません。 info ファイルの登録は INSTALL スクリプトの仕事であって、 適切な makeinfo コマンドを使う必要があるからです。

pkgsrc の基盤は、以上のことを実現するため、 PATH のはじめのほうにあるディレクトリーに、 install-info や makeinfo を上書きするスクリプトを作成します。

install-info を上書きするスクリプトは、メッセージを記録すること以外、 何の効果もありません。makeinfo を上書きするスクリプトは、 メッセージを記録し、TEXINFO_REQD の値に従って、適切な makeinfo コマンドを実行するか、 または異常終了します。

マニュアルページをインストールするパッケージはすべて、 マニュアルページを同じディレクトリー内にインストールして、 マニュアルページを共通のひとつの場所から探せるようにします。 pkgsrc では、この場所は ${PREFIX}/${PKGMANDIR} であり、パッケージ内ではこの表記を使うようにします。 PKGMANDIR の値は標準では “man” です。これ以外によく使われる値は、 “share/man” です。

PLIST ファイル内では、 マニュアルページのファイルの最上層ディレクトリーを、 単に man/ と書くことができます。 これは pkgsrc の枠組みが必要に応じて変換してくれます。 これ以外の場所の場合は、正確な PKGMANDIR を使って書く必要があります。

GNU_CONFIGURE が “yes” に設定されているパッケージでは、 標準では ./configure --mandir スイッチを使って、マニュアルページをどこにインストールするかを設定します。 このパスは GNU_CONFIGURE_MANDIR で、 標準では ${PREFIX}/${PKGMANDIR} になります。

パッケージが GNU_CONFIGURE を使うが、 --mandir は使わない場合は、CONFIGURE_HAS_MANDIR を “no” に設定することができます、 また、./configure スクリプトが標準的ではない --mandir の使い方をする場合は、 必要に応じて GNU_CONFIGURE_MANDIR を設定することができます。

圧縮したマニュアルページのインストールに関する情報は、 Section 13.5, “マニュアルページの圧縮” をご覧ください。

パッケージが、 GConf が使用する .schemas または .entries ファイルをインストールする場合は、 これらが確実にデータベースに登録されるようにするために、 いくつか特別な手順を踏む必要があります。

パッケージが、 scrollkeeper/rarian が使用する .omf ファイルをインストールする場合は、これらが確実にデータベースに登録されるようにするために、 いくつか特別な手順を踏む必要があります。

パッケージがフォントファイルをインストールする場合は、 インストール時とアンインストール時に、 フォントのインストール先ディレクトリーにあるフォントデータベースを再構築する必要があります。 この処理は pkginstall の枠組を使って自動的におこなうことができます。

フォントのインストール先ディレクトリーを FONTS_DIRS.type 変数に列挙することができます。変数名中の type は、 “ttf”, “type1”, “x11” のいずれかです。 また、データベースファイル fonts.dir は PLIST に含めてはいけません。

なお、フォント用のディレクトリーを新たに作らないようにしてください。 X サーバーがフォントを見つけるための設定をユーザーが手動でおこなう必要がないようにするため、 新しいディレクトリーではなく標準的なディレクトリーを使うようにします。

パッケージが GTK2 の IM モジュールやローダーをインストールする場合は、 これらが確実に GTK2 のデータベースに登録されるようにするために、 いくつか特別な手順を踏む必要があります。

パッケージが、システム全体で使われるカタログへ登録する必要のある SGML または XML のデータファイル (DTD, sub-catalog など) をインストールする場合は、 いくつか特別な手順を踏む必要があります。

パッケージが、.xml ファイルを ${PREFIX}/share/mime/packages 以下にインストールすることで MIME データベースを拡張する場合は、 データベースがこの新規ファイルについて確実に整合性を持つようにするために、 いくつか特別な手順を踏む必要があります。

パッケージが構築時に intltool を使う場合は、 intltool を USE_TOOLS に追加します。 こうすると、パッケージの配布ファイルに附属する intltool ではなく、 pkgsrc の intltool を強制的に使うようになります。

この仕組みは、intltool 構築時の依存関係を追跡して、 利用可能な最新版を使います。この方法を使うことで、 リリース後にできたバグ修正も適用することができます。

パッケージに rc.d スクリプトが附属する場合、このスクリプトは、 標準では起動ディレクトリーにコピーされませんが、 mk.conf にオプション PKG_RCD_SCRIPTS=YES を追加指定すると、 パッケージのインストール時に、スクリプトが /etc/rc.d 以下にコピーされます。 また、パッケージのアンインストール時には、 自動的にスクリプトが削除されます。

パッケージが、TeX パッケージを texmf ツリーにインストールする場合は、 texmf ツリーの ls-R データベースを更新する必要があります。

パッケージのなかには、あるオペレーティングシステム用のバイナリーを (エミュレーションに対応した) 別のオペレーティングシステム上で実行するための、 ライブラリーや実行ファイルを提供するものがあります。 例としては、NetBSD 上で Linux のバイナリーを実行するものがあげられます。

pkgtools/rpm2pkg は、Linux の rpm パッケージの展開やパッケージ化を補助するものです。

CHECK_SHLIBS を no に設定して、 インストールされた実行ファイル用のライブラリーを動的リンカーがすべて見つけられることを検査する check-shlibs ターゲットを抑止することができます。 この検査では標準の動的リンカーを実行するので、 エミュレーションパッケージに対しては検査が失敗します。 エミュレーションで使われるライブラリーは、 標準のディレクトリーには置かれていないからです。

パッケージが、 share/icons/hicolor 以下に画像をインストールするか share/icons/hicolor/icon-theme.cache データベースを更新するかあるいはその両方をおこなう場合は、 テーマ用の共有ディレクトリーを適切に扱い、キャッシュデータベースを確実に再構築するために、 以下の手順を踏む必要があります。

後の 2 点について、 PLIST がこれらを守っていることを確認する最良の方法は、 make print-PLIST を使って作り直すことです。

パッケージが、.desktop ファイルを share/applications 以下にインストールし、そのファイルに MIME 情報が含まれている場合は、それらが MIME データベースに確実に登録されるようにするために、 以下の手順を踏む必要があります。

最後の点について、 PLIST がこれらを守っていることを確認する最良の方法は、make print-PLIST を使って作り直すことです。