Chapter 5. pkgsrc を設定する

Table of Contents

5.1. 全般的な設定
5.2. 構築の過程に影響を及ぼす変数
5.3. インストール過程に影響をおよぼす変数
5.4. コンパイラーの選択と設定
5.4.1. コンパイラーを選ぶ
5.4.2. コンパイラーへのフラグの追加 (CFLAGS)
5.4.3. リンカーへのフラグの追加 (LDFLAGS)
5.5. 開発者および上級者向けの設定
5.6. 構築オプションの選択

pkgsrc システム全体の設定は、ひとつのファイル (通常は mk.conf) でおこなわれます。pkgsrc がこのファイルをどのディレクトリーから探すかは、 インストールの時に決まります。NetBSD で、ベースシステムの make(1) を使う場合は、/etc/ ディレクトリーとなります。これ以外の場合はすべて、 ${PREFIX}/etc/ が標準の場所となり、これは bootstrap プログラムに指示したバイナリーパッケージのインストール先に依存します。

bootstrap の実行中に、設定ファイルの例が作成されます。 このファイルを使うには、 ${PREFIX}/etc ディレクトリーを作って、 その中にこのファイルをコピーする必要があります。

この設定ファイルの書式は、通常の BSD 形式の Makefile の書式です。pkgsrc 全体の設定は、 このファイルで変数を設定することでおこなわれます。なお、 ここではあらゆる種類の変数を定義することができ、また、 特別なエラーの検査 (たとえば、綴りの誤り) はおこなわれないので、 設定が有効かどうか調べるには、 いろいろ試す必要があるということに注意してください。

5.1. 全般的な設定

本節では、pkgsrc の全パッケージに影響する変数をいくつか掲げます。 ユーザーが設定可能な変数の完全な一覧は、 mk/defaults/mk.conf にあり、 各変数の目的もコメントで説明されています。

  • LOCALBASE: パッケージをどこにインストールするか。標準では /usr/pkg になります。異なる LOCALBASE をもつバイナリーパッケージを混在させないでください。

  • CROSSBASE: cross カテゴリーのパッケージをどこにインストールするか。 標準では ${LOCALBASE}/cross になります。

  • X11BASE: 当該システムで X11 がどこにインストールされているか。標準では /usr/X11R6 になります。

  • DISTDIR: pkgsrc のパッケージ構築用にダウンロードしたままの状態の ソース配布物をどこに置くか。標準では ${PKGSRCDIR}/distfiles になります。

  • PKG_DBDIR: インストールされたパッケージに関する データベースをどこに置くか。標準では /var/db/pkg になります。

  • MASTER_SITE_OVERRIDE: 設定した場合、その値でパッケージの MASTER_SITES が上書きされます。

  • MASTER_SITE_BACKUP: 配布ファイルおよびパッチファイルが、ローカルにも、 ${MASTER_SITES}${PATCH_SITES} にもなかった場合のための予備の場所 (複数可)。 標準では ftp://ftp.NetBSD.org/pub/pkgsrc/distfiles/${DIST_SUBDIR}/ftp://ftp.freebsd.org/pub/FreeBSD/distfiles/${DIST_SUBDIR}/ になります。

  • BINPKG_SITES: バイナリーパッケージの配布サイトのリストです。rel および arch は、それぞれ OS リリース (2.0 など) およびアーキテクチャー (mipsel など) で置き換えられます。

  • ACCEPTABLE_LICENSES: 受け入れ可能なライセンスのリストです。ライセンス名は、大文字・小文字を区別します。 このリストにないライセンスが適用されるパッケージを構築しようとするたびに、 エラーメッセージが表示されます。 簡便な変更でライセンスを受け入れるようにできる場合は、 エラーメッセージでこの値の変更方法の説明も表示されます。

5.2. 構築の過程に影響を及ぼす変数

XXX

  • PACKAGES: バイナリーパッケージ用のディレクトリーの最上層。 標準では ${PKGSRCDIR}/packages になります。

  • WRKOBJDIR: 設定した場合、この値を最上層として、 別に分離された作業ディレクトリーが作られて ${WRKDIR} (前述) からシンボリックリンクされます。 これは、複数のアーキテクチャー用のパッケージを構築する際に便利です。 さらに、${PKGSRCDIR} を NFS マウントして、 ${WRKOBJDIR} は各アーキテクチャーのローカルに置くということができます。(なお、 PKGSRCDIR は利用者が設定するようなものではないことを断っておきます —これは pkgsrc ツリーのルートを参照する内部的な定義です。 ここでいう pkgsrc ツリーは、多くの文脈がありえます。)

  • LOCALPATCHES: pkgsrc に含まれていないローカルなパッチ用のディレクトリーです。 さらなる情報は、Section 11.3, “patches/*” をご覧ください。

  • PKGMAKECONF: パッケージの BSD 形式の Makefile が使用する mk.conf ファイルの場所です。この変数が設定されていない場合は、 /usr/src 以下の構築用の設定を見ることのないようにするために、 MAKECONF/dev/null に設定されます。

  • DEPENDS_TARGET: 標準では、依存するパッケージはインストールされるだけで、 バイナリーパッケージの作成まではおこなわれません。 この変数を package に設定して、 依存パッケージのインストール後にバイナリーパッケージを自動的に作成することができます。

5.3. インストール過程に影響をおよぼす変数

ほとんどのパッケージは、WRKDIR のサブディレクトリーへのインストールに対応しています。そのようにインストールをすれば、 本番のファイルシステムに手を加えずにパッケージを構築することができます。 DESTDIR への対応には、以下の二通りの形態があります。

  • 基本的な (basic) DESTDIR 対応。 パッケージのインストールや、バイナリーパッケージ作成は、 通常と同じく root で実行します。

  • 完全な (full) DESTDIR 対応。 完全な構築、インストール、バイナリーパッケージ作成を、 通常ユーザー権限でおこなうことができます。root 権限が必要なのは、 パッケージを追加するときだけです。

現在では、標準状態で DESTDIR へ対応するようになっています。 USE_DESTDIR=no を設定すれば 以前のような DESTDIR を使わない挙動に戻すことができますが、この設定は廃止予定ですので、 パッケージを DESTDIR 対応にするほうが望ましいでしょう。

DESTDIR への対応によって、各種ターゲットの挙動が少し変わります。 パッケージを構築してからインストールする場合は、 package-install を使ってください。package および install の各ターゲットは、何もしてくれません。 package-install は、 DEPENDS_TARGET にすることができます。 bin-install は、インストール用に root のパスワードを尋ねてきますが、 その後に失敗し、 package-install があらためてパスワードを尋ねてきます。

基本的な DESTDIR 対応を使う場合、make clean は root で実行する必要があります。

foo/bar パッケージに対して、 DESTDIR に完全に対応できているかどうか、以下のコマンドでテストすることができます。

$ id
uid=1000(myusername) gid=100(users) groups=100(users),0(wheel)
$ mkdir $HOME/packages
$ cd $PKGSRCDIR/foo/bar

DESTDIR に完全に対応しているか確認します。 root 権限は必要ないはずです。

$ make USE_DESTDIR=yes install

root 権限なしでパッケージを作ってみます。

$ make USE_DESTDIR=yes PACKAGES=$HOME/packages package

以下のコマンドでは、 su(1) を使って root 権限を得られることが必要です。

$ make USE_DESTDIR=yes PACKAGES=$HOME/packages package-install

あとは、通常のユーザーで以下のコマンドを実行します。

$ make clean

5.4. コンパイラーの選択と設定

5.4.1. コンパイラーを選ぶ

pkgsrc は、標準では GCC を使ってパッケージを構築します。 これは /etc/mk.conf で以下の変数を設定して変えることができます。

PKGSRC_COMPILER:

パッケージ構築時に使われる一連のコンパイラーを指定する値を並べたものです。 以下の値を使うことができます。

  • distcc: 分散 C/C++ コンパイラー (連鎖可能)

  • ccache: コンパイラーキャッシュ (連鎖可能)

  • gcc: GNU C/C++ コンパイラー

  • mipspro: Silicon Graphics, Inc. MIPSpro (n32/n64)

  • mipspro: Silicon Graphics, Inc. MIPSpro (o32)

  • sunpro: Sun Microsystems, Inc. WorkShip/Forte/Sun ONE Studio

標準では gcc になります。 PKGSRC_COMPILER の設定には、適切なコンパイラー本体とともに、 ccachedistcc のいずれかまたは両方を併用することができます。 たとえば ccache gcc のようにします。 この変数の設定では、コンパイラー本体を示す値を最後に置くようにします。 なお、コンパイラー本体はただ一つだけ掲げるようにします (たとえば、 sunpro gcc などとすることはできません)。

GCC_REQD:

パッケージの構築用として、最低限必要な GCC のバージョンを指定します。システム附属の GCC がこの条件を満たさない場合、pkgsrc はそのかわりに使うため、 GCC のパッケージを構築してインストールします。

5.4.2. コンパイラーへのフラグの追加 (CFLAGS)

CFLAGS 変数を設定したい場合は、 = 演算子は使わずに、 かならず += 演算子を使ってください。

CFLAGS+=        -your -flags

CFLAGS= のようにする (つまり、+を付けない) と、 独自のフラグを追加する必要があるパッケージで問題を起こすことがあります。 CPU に特化した最適化に関心がある場合は、 devel/cpuflags パッケージを見ておくとよいでしょう。

5.4.3. リンカーへのフラグの追加 (LDFLAGS)

configure および build の各段階において、リンカーにフラグを渡したい場合、 二通りの方法を使うことができます。すなわち、 LDFLAGS または LIBS のいずれかを設定します。 両者の違いは、LIBS はコマンドラインに付け加えられますが、 LDFLAGS はそれより早く現れます。 LDFLAGS はあらかじめ読み込まれ、 USE_IMAKE の設定や mk/x11.buildlink3.mk のインクルードの有無に応じた ELF マシン向けの rpath の設定が追加されます。 CFLAGS と同様に、この設定を上書きしたいわけでなければ、 += 演算子を使います。

LDFLAGS+=        -your -linkerflags

5.5. 開発者および上級者向けの設定

XXX

  • PKG_DEVELOPER: パッケージ開発者向けに、いくつかの正当性検査を実行します。

    • パッチが曖昧さゼロで適用できることを確認する

    • check-shlibs を実行して、 すべてのバイナリーパッケージが共有ライブラリーを見つけられることを確認する。

  • PKG_DEBUG_LEVEL: パッケージの構築およびインストールの際に表示される、 デバッグ用出力の水準です。標準の値は 0 です。この場合、コマンドは (通常の、標準状態で、静粛な操作で) 実行されるだけで、表示されません。 値が 1 の場合、すべてのシェルコマンドを実行前に表示します。 値が 2 の場合、すべてのシェルコマンドを実行前に表示するほか、 実際に実行される経過を set -x により表示します。

5.6. 構築オプションの選択

パッケージのなかには、構築時にオプションがあるものがあります。 通常は、数通りの依存性からいずれかを選択、大きな依存性を伴うオプション対応の有効化、 実験的な機能の有効化などです。

パッケージがどんなオプションに対応しているか (対応している場合)、 また、どのオプション同士が排他的かを調べるには、make show-options を実行します。結果は、たとえば以下のようになります。

    The following options are supported by this package:
        ssl      Enable SSL support.
    Exactly one of the following gecko options is required:
        firefox  Use firefox as gecko rendering engine.
        mozilla  Use mozilla as gecko rendering engine.
    At most one of the following database options may be selected:
        mysql    Enable support for MySQL database.
        pgsql    Enable support for PostgreSQL database.

    These options are enabled by default: firefox
    These options are currently enabled: mozilla ssl

以下の変数を mk.conf で定義して、 パッケージに対してどのオプションを有効にするかを選んでおくことができます: PKG_DEFAULT_OPTIONS は、対応している全パッケージを対象に、 オプションを選択または無効化するために使うことができます。 PKG_OPTIONS.pkgbase は、特定のパッケージ pkgbase を対象に、 オプションを選択または無効化するために使うことができます。 この両変数で列挙された各変数が選択され、- が先頭についた変数は無効化されます。いくつか例を示します。

$ grep "PKG.*OPTION" mk.conf
PKG_DEFAULT_OPTIONS=    -arts -dvdread -esound
PKG_OPTIONS.kdebase=    debug -sasl
PKG_OPTIONS.apache=     suexec 

ここで重要なことは、 パッケージのメンテナーがこの方法を使って標準状態のオプションを提示している場合、 そのオプションを選択したくなければ明示的に削除する必要があるということです。 よくわからない場合は、make show-options を使ってオプションの設定状況を調べることができます。

以下の各設定は、以下に掲げた順に適用されます。 このため、あるオプションは、 それが最後に選択または無効化された設定に従って選択または無効化されます。

  1. パッケージのメンテナーが提示した、 標準状態のオプション

  2. 旧式の変数 (後述) の設定から導かれるオプション

  3. PKG_DEFAULT_OPTIONS

  4. PKG_OPTIONS.pkgbase

互いに排他的なオプション群からは、 最後に選択されたオプションが使われ、それ以外のオプションは自動的に無効化されます。 オプション群のあるオプションが明示的に無効化された場合は、 その前に選択されたオプションがあれば、それが使われます。 必須のオプション群からどのオプションも選択されなかった場合は、 エラーとなり、パッケージの構築は失敗します。

このオプションの枠組が導入される前は、 構築オプションは mk.conf で各オプションごとの変数 (たいていは USE_FOO という名前) を設定することで選択していました。 利用者が現在のオプションの枠組に容易に移行できるようにするため、 このような旧式の変数は、適切なオプションの設定 (PKG_OPTIONS.pkgbase) に自動的に変換されます。利用者に対しては、 mk.conf を更新してオプションの枠組を直接使うよう促す警告が表示されます。 旧式の変数への対応は、いずれ打ち切られる予定です。