pkgsrc のあらゆるファイルの一次配布元は ftp://ftp.NetBSD.org/pub/pkgsrc/ です。 目的別に多数のサブディレクトリーがありますが、 それについては Appendix C, pkgsrc FTP サーバーのディレクトリー配置 で詳しく説明しています。

current 枝の tar ファイルは、 current ディレクトリー内にあり、ファイル名は pkgsrc.tar.gz です。 このファイルは、毎日、自動生成されます。

安定版の 2009Q1 枝の tar ファイルは、 pkgsrc-2009Q1 ディレクトリー内にあり、ファイル名は同じく pkgsrc-2009Q1.tar.gz です。

安定版 pkgsrc の tarball をダウンロードするには、以下のコマンドを実行します。

$ ftp ftp://ftp.NetBSD.org/pub/pkgsrc/pkgsrc-20xxQy/pkgsrc-20xxQy.tar.gz

ここで、pkgsrc-20xxQy は、 ダウンロードする安定版の枝名にします。たとえば、 “pkgsrc-2009Q1” になります。

ダウンロードしたら、以下のようにして展開します。

$ tar -xzf pkgsrc-20xxQy.tar.gz -C /usr

こうすると、/usr/ に pkgsrc/ ディレクトリーが作られ、 /usr/pkgsrc/ 以下に全パッケージのソースが置かれます。

pkgsrc-current をダウンロードするには、以下のコマンドを実行します。

$ ftp ftp://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc.tar.gz

pkgsrc の stable 枝名を指定して取得するためには、以下のコマンドを実行します。

$ cd /usr && cvs -q -z3 -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout -r pkgsrc-20xxQy -P pkgsrc

ここで、pkgsrc-20xxQy は、 チェックアウトする stable 枝名にします。たとえば “pkgsrc-2009Q1” になります。

こうすると、/usr/ ディレクトリーに pkgsrc/ ディレクトリーが作られ、 /usr/pkgsrc/ 以下に全パッケージのソースが置かれます。

pkgsrc current を取得するには、以下のコマンドを実行します。

$ cd /usr && cvs -q -z3 -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout -P pkgsrc

利用可能な CVS ミラーサイト一覧から、もっとも速いものを選んで使ってください。

rsh のエラーメッセージが出た場合は、たとえば以下のようにして、環境変数 CVS_RSH を設定する必要があります。

$ cd /usr && env CVS_RSH=ssh cvs -q -z3 -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout -P pkgsrc

CVS_RSH=ssh の設定を今後も有効なままにする方法は、お使いのコマンドシェルのドキュメンテーションをご覧ください。 Bourne シェルの場合は、この設定を以下のとおりユーザーの .profile に、 またはより大域的に /etc/profile に書くことができます。

# set CVS remote shell command
CVS_RSH=ssh
export CVS_RSH

CVS は、標準状態では、多くの人の望む挙動をしてくれません。 しかし、 以下の内容の .cvsrc というファイルをホームディレクトリーに置いておけば、 標準での挙動を変えることができます。このファイルを置いておけば、 あなたの悩みや、余計なバグ報告もなくなるでしょうから、 そうすることを強くおすすめします。 このファイルに関する説明は、 CVS のドキュメンテーションにあります。

# recommended CVS configuration file from the pkgsrc guide
cvs -q -z3
checkout -P
update -dP
diff -upN
rdiff -u
release -d

なお、distfile とバイナリーパッケージは、標準ではいずれも pkgsrc ツリー内に置かれますので、pkgsrc ツリーを更新する前に退避させておくことを忘れないでください。 DISTDIR と PACKAGES を設定して、標準のディレクトリーとは別の場所を pkgsrc が使うような構成にすることもできます。 詳細はChapter 5, pkgsrc を設定するをご覧ください。

tar ファイルを使って pkgsrc を更新するためには、 初回の入手時と同様に、tar ファイルをダウンロードします。 次に、pkgsrc ディレクトリーに独自の変更を何も加えていないことを確認します。 pkgsrc ディレクトリーを削除してから、新しい tar ファイルを展開します。これで完了です。

CVS を使って pkgsrc を更新するためには、pkgsrc ディレクトリーへ移動して cvs を実行します:

$ cd /usr/pkgsrc && cvs update -dP

rsh がエラーメッセージを出す場合は、前述の新規取得時と同様に、環境変数 CVS_RSH を設定する必要があります。たとえば以下のようにします。

$ cd /usr/pkgsrc && env CVS_RSH=ssh cvs up -dP

対応は、 Darwin 5.x 以上に対しておこなわれています。 始める前に、Apple Developer Connection から Mac OS X Developer Tools をダウンロードしてインストールする必要があります。詳細は http://developer.apple.com/macosx/ をご覧ください。また、X11 Window System を使うパッケージを構築したい場合は、 X11 (Developer Tools に附属するオプションパッケージ) をインストールしておくことも必要です。

確認および対応は、 FreeBSD 4.7 および 5.0 に対しておこなわれています。 これら以外のバージョンでも動くかもしれません。

ブートストラップキットのインストールに際しては、 FreeBSD のユーザーランドのツールと衝突することがないように注意を払ってください。以下のような複数の事項があります。

Interix は Windows NT カーネルの POSIX 準拠のサブシステムで、 Cygwin よりも密接にカーネルと統合された Unix 風の環境を提供します。 Interix は Windows Services for Unix パッケージの一部であり、 ライセンスされた Windows 2000, XP (XP Home は含まず), 2003 のコピー用として、 無料で使うことができます。SFU は、http://www.microsoft.com/windows/sfu/ からダウンロードできます。

確認は、Services for Unix 3.5 に対しておこなわれています。 3.0 や 3.1 でも動作するかもしれませんが、公式には対応していません。 (3.0/3.1 の主な違いは、 pthreads がないことですが、このほかにも libc に欠けているものがあるかもしれません。)

Services for Unix Applications (別名 SUA) は、Windows Server 2003 R2 (5.2), Windows Vista および Windows Server 2008 (6.0), Windows 7 および Windows Server 2008 R2 (6.1) に統合されている構成要素です。本稿執筆時点において、 SUA の Interix 6.0 (32 ビット) および 6.1 (64 ビット) サブシステムで確認がおこなわれています。 これら以外のバージョンでも動作するかもしれません。 Interix 5.x サブシステムで、pkgsrc を使った確認はまだおこなわれていません。

interix:kP=\E[S:kN=\E[T:kH=\E[U:dc@:DC@:tc=pcansi:
	

# chmod -R g+w $PKG_DBDIR
	

機能する C コンパイラー、つまり、 gcc または SGI の MIPS および MIPSpro コンパイラー (cc/c89) が必要です。 CC 環境変数を、 使用するコンパイラーに応じて設定してください。 MIPSpro コンパイラースイートのライセンスがない場合は、http://freeware.sgi.com/ から gcc の tar 配布ファイルをダウンロードすることができます。

IRIX 6.5.17 以上が必要です。 このバージョンの IRIX で if_indextoname(3), if_nametoindex(3) などへの対応がおこなわれたからです。

現在のところ、pkgsrc は同時には一つの ABI にしか対応しません。つまり、 古い 32 ビット ABI、新しい 32 ビット ABI、64 ビット ABI を切り替えることはできません。 最初に "abi=n32" を使って始めた場合は、 すべてのパッケージがこれを使って構築されることになります。

このため、環境変数または mk.conf の CFLAGS が衝突しないようにしてください。 特に、 n32 オブジェクトファイルに lib64 を、また、その逆の組合せを、 リンクしないようにしてください。 /etc/compiler.defaults を確認してください。

pkgsrc ツリーの実体を別ホストから NFS を使ってマウントしている場合は、必ず WRKOBJDIR をローカルのディレクトリーに設定しておいてください。 IRIX のリンカーは、ネットワーク経由でマウントされたファイルシステム越しにリンクするときに 問題を起こすことが時々あるからです。

事前準備の過程では、imake(1) などのプログラムにすべて正しいオプションが設定されるはずですが、 ローカルの設定に依存するオプションを設定したい場合があるかもしれません。 詳細は、pkgsrc/mk/defaults/mk.conf をご覧ください。 そしてもちろん、お使いのコンパイラーのマニュアルページもご覧ください。

SGI の MIPSPro コンパイラーを使っている場合は、 mk.conf で

PKGSRC_COMPILER=        mipspro
      

を設定してください。これを設定しないと、 pkgsrc は gcc を使っていることを仮定するので、コンパイラーに不適切なフラグを渡すことがあります。 なお、標準状態では、bootstrap は適切な mk.conf.example を作成するはずです。

gcc と MIPSPro コンパイラーチェインの両方をインストールしているが、 必ず MIPSPro を使うようにしたい場合は、PATH に gcc の場所 (ありがちなのは /usr/freeware/bin) を含めないでください。さらに (重要)、 '--preserve-path' フラグを bootstrap に渡してください。

Linux のなかには、libtermcap と libcurses (libncurses) のいずれかを必要とするものがあります (たとえば Debian GNU/Linux など)。そのようなディストリビューションでは libncurses-dev パッケージ (または相当品) をインストールすれば問題なくなるはずです。

pkgsrc は gcc (GNU Compiler Collection) と icc (Intel C++ Compiler) のどちらにも対応しています。gcc が標準で使われます。 icc は i386 上の icc 8.0 と 8.1 で確認がおこなわれています。

icc を使って bootstrap をおこなうには、以下のようにします (icc は標準のディレクトリーにインストールされているものとします)。

env CC=/opt/intel_cc_80/bin/icc LDFLAGS=-static-libcxa \
ac_cv___attribute__=yes ./bootstrap
      

icc は __attribute__ に対応していますが、GNU configure のテストではネストした関数を使っており、 icc はネストした関数に対応していません。__attribute__ を #undef してしまうと、 Linux の多くのヘッダーファイルが __attribute__ なしでは正しくコンパイルできず、 壊れてしまうという副作用があります。このため、テストは、コンパイラーが __attribute__ に対応しているとしたもので上書きする必要があります。

bootstrap した後に、mk.conf で PKGSRC_COMPILER を設定します。

PKGSRC_COMPILER=        icc
      

icc がインストールされるディレクトリーは標準では /opt/intel_cc_80 であり、pkgsrc でもこのディレクトリーを標準としています。これ以外のディレクトリーに icc をインストールしている場合は、mk.conf で ICCBASE を設定してください。

ICCBASE=                /opt/icc
      

pkgsrc は、icc が提供する実行時ライブラリーを静的リンクするので、 作られたバイナリーはその共有ライブラリーがインストールされていないシステムでも 動かすことができます。

ただし、libtool は、C++ の共有ライブラリーをリンクして記録する時に実行された (ライブラリーごとに -Bstatic や -Bdynamic オプションの指定がまちまちな) ld(1) コマンドをもとにライブラリーの一覧を展開します このことから、libtool でリンクされた C++ の共有ライブラリーは、libtool が修正されない限り、 icc のライブラリーに対して実行時依存性を持った状態になります。

確認および対応は、 OpenBSD 3.0 および 3.2 に対しておこなわれています。

ブートストラップキットのインストールに際しては、 OpenBSD のユーザーランドのツールと衝突することがないように注意を払ってください。以下のような複数の事項があります。

対応は x86 と sparc それぞれの Solaris 2.6 から 9 までに対しておこなわれています。 機能する C コンパイラーが必要です。 gcc 2.95.3 および Sun WorkShop 5 の両者で確認がおこなわれています。

Solaris 8 でのブートストラップ過程およびパッケージの構築では、 以下の各パッケージが必要になります。

なお、2006 年 6 月現在、Solaris 上では GNU binutils はサポートされていません。

どのコンパイラーを使うにせよ、コンパイラーツールと $prefix を、必ず PATH に含めてください。 これは、/usr/ccs/{bin,lib} や、たとえば /usr/pkg/{bin,sbin} などです。

CC=     cc
CXX=    CC
CPP=    cc -E
CXXCPP= CC -E

PKGSRC_COMPILER=        sunpro
ABI=                    64

CONFIG_SHELL=   ${LOCALBASE}/bin/bash
WRAPPER_SHELL=  ${LOCALBASE}/bin/bash
      

バイナリーパッケージをインストールするためには、 まず、バイナリーパッケージがどこで入手できるか知っている必要があります。 最初に調べる場所は、pkgsrc の主たる FTP サーバーの /pub/pkgsrc/packages ディレクトリーです。

このディレクトリーには、複数のプラットフォーム用の バイナリーパッケージがあります。 最初に、お使いのオペレーティングシステムのディレクトリーを選んでください。 (バージョン番号がついているディレクトリーは、 歴史的な理由で残っているだけですので、無視してください。) 次に、ハードウェアアーキテクチャーを選び、 その次に、OS のバージョンと pkgsrc の“バージョン”の組合せを選びます。

多くの場合、このディレクトリーには、 パッケージ管理ツールが入った bootstrap.tar.gz というファイルがあります。このファイルがない場合は、 お使いのオペレーティングシステムにパッケージ管理ツールがもともとあるのでしょう。 このファイルをダウンロードして / ディレクトリーに展開します。 展開すると、/usr/pkg (この下には、 バイナリーパッケージ管理用のツールがある) および /var/db/pkg (インストールされたパッケージのデータベース用) の各ディレクトリーが作られます。

前節で説明したディレクトリーには、 All というサブディレクトリーがあり、 当該プラットフォーム向けのバイナリーパッケージがすべて置かれています。 ただし、FTP または CDROM (利用しているメディアによって異なります) 経由での配布ができないパッケージは、 除かれています。

パッケージを FTP または HTTP サーバーから直接インストールするには、 Bourne シェルと互換のシェルで、以下のコマンドを実行します (最初に su して root になっておくことを忘れずに)。

# PATH="/usr/pkg/sbin:$PATH"
# PKG_PATH="ftp://ftp.NetBSD.org/pub/pkgsrc/packages/OPSYS/ARCH/VERSIONS/All"
# export PATH PKG_PATH

CDROM, DVD または NFS でマウントされた置き場所からインストールする場合などは、 URL のかわりに、ローカルのパスを使うこともできます。 複数の置き場所からパッケージをインストールしたい場合は、 それらをセミコロンで区切って PKG_PATH に設定することができます。

以上の準備ができれば、 パッケージのインストールは非常に簡単です。

# pkg_add openoffice2
# pkg_add kde-3.5.7
# pkg_add ap2-php5-*

なお、インストールしようとするパッケージを実行するために必要となるパッケージも、 すべて一緒にインストールされますが、 この必要なパッケージも同じ置き場所に用意されていると仮定されます (訳註: 必要なパッケージがすべて揃うように PKG_PATH を設定する必要があるということ)。

パッケージをインストールすると、脆弱性のあるパッケージがインストールされることもありえます。 このため、pkg_admin audit を定期的に (特に、パッケージを新たにインストールした後には) 実行して、 脆弱性の影響がある構成となっているかどうかを確認するようにしてください。

パッケージをインストールした後に、PATHに /usr/pkg/bin と /usr/pkg/sbin が含まれている事を確 認してください。これで、インストールされたプログラムを実際に使い始めること ができます。

パッケージをアンインストールする方法は、そのパッケージを、 ソースコードからインストールしたかバイナリーパッケージからインストールしたかにかかわらず同じです。 どちらの方法でインストールされたかは、pkg_delete コマンドは一切関知しません。 パッケージの削除は、pkg_delete package-name を実行するだけでおこなうことができます。 パッケージ名はバージョン番号をつけてもつけなくてもかまいません。 一連のパッケージをアンインストールするために、 たとえば *emacs* のようにワイルドカードを使うこともできます。 この場合、ワイルドカードが pkg_delete に渡る前にシェルに展開されないようにするため、 ワイルドカードはかならずクォートするようにします。

-r オプションは非常に強力です。これを使うと、 指定したパッケージに依存しているパッケージをすべて削除してから、 指定したパッケージそのものを削除します。たとえば、

# pkg_delete -r jpeg
    

は、jpeg および jpeg を使うすべてのパッケージを削除します。これにより、 jpeg パッケージをアップグレードすることが可能になります。

pkg_info は、インストールされているパッケージや、 バイナリーパッケージのファイルに関する情報を表示します。

NetBSD セキュリティーオフィサーとパッケージグループでは、 pkgsrc に含まれる (あるいは含まれていた) パッケージの既知の脆弱性のリストを 保守しています。このリストは、 NetBSD FTP サイトの ftp://ftp.NetBSD.org/pub/pkgsrc/distfiles/vulnerabilities から入手できます

pkg_admin fetch-pkg-vulnerabilities を使うと、 このリストを自動的にダウンロードし、 システムにインストールされているパッケージすべてについて セキュリティー検証をすることができます。

このセキュリティー検証は、ふたつの部分からできています。 ひとつめの段階は pkg_admin fetch-pkg-vulnerabilities で、 NetBSD FTP サイトから 脆弱性のリストをダウンロードするものです。 ふたつめは pkg_admin audit で、インストールされているパッケージに脆弱性が ないかどうか検証するものです。脆弱性のあるパッケージがあった場合、 次のように出力してくれます:

Package samba-2.0.9 has a local-root-shell vulnerability, see
    http://www.samba.org/samba/whatsnew/macroexploit.html

vulnerabilities ファイルを毎日ダウンロードして、常に最新の状態にしておきたいという方もいらっしゃることでしょう。 root ユーザーの crontab(5) エントリーを適切に書いておけば、そういうこともできます。 たとえば、

# vulnerabilities ファイルをダウンロード
0 3 * * * /usr/sbin/pkg_admin fetch-pkg-vulnerabilities >/dev/null 2>&1
      

というエントリーを書けば、毎日午前 3 時に vulnerability リストを更新することになります。 この例は一日一回ですが、もっと頻繁に更新することもできます。 さらに、パッケージの検証を daily security script でおこないたい方もいらっしゃるでしょう。 これは、以下のような行を /etc/security.local に書いておけば実現できます。

/usr/sbin/pkg_admin audit
      

インストール済パッケージが最新かどうかを確認するには、 pkgtools/lintpkgsrc をインストールして、 lintpkgsrc に “-i” を付けて実行します。たとえば以下のようになります。

% lintpkgsrc -i
...
Version mismatch: 'tcsh' 6.09.00 vs 6.10.00
    

このようになった場合、パッケージを更新し、そのパッケージに依存しているパッケージをすべて再構築するために、 make update を使うことができます。

pkg_admin は、パッケージシステムにおける、 各種の管理用機能を実行します。

pkg_add(1) マニュアルページで警告されている、自分自身で作ったものでないバイナリー パッケージをインストールすることが孕む危険性、無思慮にこのようなファイルを インストールすることにより、あなたのシステムにセキュリティーホールが生じる 事についてよく注意してください。

もちろん、パッケージ、パッケージの構築用のコンパイラー、 その他、呼び出されるすべてのツールのソースコードを完全に読んで理解したわけではない場合は、 ソースからインストールしたパッケージにもすべて、 同じ警告があてはまります。

ソースからパッケージを構築するためには、機能する C コンパイラーが必要です。NetBSD の場合は、 “comp” および “text” 配布物一式をインストールしておく必要があります。X11関連のパッケージを 構築する場合は、さらに“xbase”および“xcomp” 配布物一式も必要です。

パッケージを構築するうえで最初にすることは、配布ファイル (未変更のソース) のダウンロードです。配布ファイルがまだダウンロードされていない場合、 pkgsrc は自動的に配布ファイルを取得します。

distfiles ディレクトリー に必要なファイルが すでに存在していれば、インターネットに接続する必要はありません。 CD-ROMなどにdistfilesがある場合には、CD-ROMを /cdrom にmountし、

DISTDIR=/cdrom/pkgsrc/distfiles

を mk.conf に加えて、使うことができます。

標準状態では、人気のあるパッケージを置いているサーバー (たとえば SourceForge.net のミラー) に過大な負荷をかけないようにするため、 配布サイトのリストの順序はランダムに入れ換えられます。 このため、別の distfile を取得する必要が生ずるたびに、 すべてのミラーからの取得を、新たな (ランダムな) 順序で試みます。 この機能は、MASTER_SORT_RANDOM=NO を設定して止めることができます (PKG_DEVELOPER が設定されている場合は、すでに無効化されています)。

主要な配布サイトをあなたのところに近いサイトで上書きす ることができます。 変数をひとつかふたつ設定すると、 マスターサイトにアクセスする順序を変えることができます。 MASTER_SORT には、 ドメインの接尾辞を空白で区切ったリストが含まれます。 MASTER_SORT_REGEX はこれより柔軟なもので、 正規表現を空白で区切ったリストが含まれます。 これは MASTER_SORT より高い優先度を持ちます。 pkgsrc/mk/defaults/mk.confの例を参照してください。これにより、帯域幅 と時間が節約できるかもしれません。

これらの設定は、シェルの環境変数でも変更できますし、その設定を今後も有効に したければ、 mk.conf ファイルにその定義を書き加えておくこともできます。

パッケージが他のパッケージ(例えば meta-pkgs/kde3 など) に依存している場合、 ダウンロードとコンパイルを交互に繰り返すことがあります。 最初に必要なすべてのソースを確実にダウンロードするには、 次のコマンドを使用します:

% make fetch-list | sh

このコマンドは必要なファイルを取ってきてdistfiles ディレクトリー に保存するためのシェルコマンドを出力、実行します。必要なファイルを手動で ダウンロードするという方法もあります。

ソフトウェアがダウンロードされると、パッチが適用された上で、 コンパイルされます。それにかかる時間はあなたのコンピューターによりますし、 そのソフトウェアが依存している他のパッケージの数とそれらのコンパイルに かかる時間にもよります。

たとえば、パッケージの各構成要素を構築するには、シェルプロンプトで

% cd misc/figlet
% make
    

とします。

次は新たにコンパイルされたプログラムを、 実際にあなたのシステムにインストールします。 インストールしようとしているパッケージのディレクトリーにいる間に

% make install
    

と入力してください。

パッケージをシステムにインストールするには root 権限が必要なことがあります。 ただし、pkgsrc には必要な時のみ su する機能があり、 実際のインストール時にのみ root になることができます。

そのソフトウェアは今まさにインストールされ、 使用できるようにセットアップされたことになります。 もうこれ以上コンパイル後の作業ファイルは必要とされないので、

% make clean
    

と入力し作業ディレクトリー内のファイルを削除してしまってもかまいません。 もし、プログラムをコンパイルするときに、 依存関係により他のパッケージがコンパイル/インストールされたならば、 それらも次のコマンドにより、きちんと削除することができます。

% make clean-depends
    

figlet ユーティリティーを例にあげると、Appendix B, 構築のログのように構築することに より、システムにインストールすることができます。

プログラムはパッケージツリーのデフォルトルート- /usr/pkgにインストール されます。もし、このディレクトリーが趣味にあわないのであれば、環境変数 LOCALBASE を設定してください。この値はパッケージツリーのルートとして使用さ れます。例えば、/usr/localを使う場合、 LOCALBASE=/usr/local と設定してください。 なお、これにはパッケージ専用のディレクトリーを使い、他のプログ ラムと共有させないようにします(つまり、 LOCALBASE=/usr などとしてはいけませ ん)。また、LOCALBASEツリー内には、独自のファイルやディレクトリー (src/, obj/, pkgsrc/ のようなもの)は一切追加しないようにしてください。これは、パッ ケージシステムがインストールするプログラムなどのファイルが、そこにインストー ルされているかもしれない別のファイルと衝突することがないようにするためです。

いくつかのパッケージは、構築時にいくつかのコンフィギュレーションオプション を変えるためにmk.confを参照します。デフォルトの設定項目については、 pkgsrc/mk/defaults/mk.confをのぞいてみてください。LOCALBASE といっ た環境変数は、pkgsrc使用時に毎回使えるようにmk.confで設定しておくこと ができます。

時々、 パッケージの構築やインストールの際に、“水面下”で何が起きているかを 見たいことがあります。これは、デバッグのためなのかもしれませんし、好奇心が 高じたものかもしれません。このような用途に使うための変数がいくつも用意され ています。

自分で作った(次章参照)、手動でpkgsrc/packagesに置いた、またはリモートFTPサー バーに置かれたバイナリーパッケージをインストール したい場合は、"bin-install"ターゲットを使うことができます。このターゲットは、 - もし可能ならば - pkg_add(1)を使ってバイナリーパッケージをインストールするほ か、make packageをおこないます。検索先リモートFTPサーバーのリストは BINPKG_SITES変数に保持され、デフォルトはftp.NetBSD.orgです。pkg_add(1)に与え るべきフラグはすべて、BIN_INSTALL_FLAGS変数で保持することができます。詳細は pkgsrc/mk/defaults/mk.confをご覧ください。

最後に警告: 標準でないLOCALBASE の設定をしたシステムの場合は、 各パッケージのインストール前にこれらを設定するようにしてください。複数のディ レクトリーを同じ目的用に分散して使うことはできないからです。そのようなこと をすると、pkgsrcはインストール済みのパッケージを正しく検出することができず、 無惨に失敗することになるでしょう。また、コンパイル済バイナリーパッケージは、 通常はデフォルトのLOCALBASEである /usr/pkgを使って構築されているので、標準で ないLOCALBASEを使っている場合は、とにかくコンパイル済バイナリーパッケージを インストールしてはいけません。

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

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

CFLAGS+=        -your -flags

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

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

LDFLAGS+=        -your -linkerflags

/usr/pkgはバルクビルド開始時に完全に削除されるので、ログインシェルが別の場 所にあることを確認してください。ログインシェルを/usr/local/binに移して(それ に合わせて passwd ファイルも修正して)おくか、/etc/rc.localでpkg_add(1)を使っ て(再)インストールするようにしておきます。これでリブート後もログインできま す(パッケージが削除されてもシェルのプロセスは死なず、シェルを新たに起動でき なくなるだけです)。また、1.5より前のNetBSDを使っていたり、何らかの 理由でpkgsrc版のsshを使いたい場合は、rc.localでsshdが起動する前にsshをイン ストールするようにしておきます:

(cd /usr/pkgsrc/security/ssh && make bulk-install)
if [ -f /usr/pkg/etc/rc.d/sshd ]; then
  /usr/pkg/etc/rc.d/sshd
fi

こうしておかないと、バルクビルド終了後や、あるいはマシンがリブートやクラッ シュした場合にsshでログインできなくなります。警告しておきましたよ! :)

すでにインストールされているどのパッケージも必要ない状態にしてください。

その他、 構築の妨げになりうるもの(/usr/localにインストールされているライブラリーなど) もすべて削除しておいてください。root になって、以下のようにタイプします:

# cd /usr/pkgsrc
# sh mk/bulk/build
      

何らかの理由で前回の構築が完了していない場合(電源断、システムパニックなど) は、以下を実行すると、その続きをすることができます:

# sh mk/bulk/build restart

バルクビルドが終わると、その要約がメールで届きます。また、build.conf ファイルのFTPで指定したディレクトリーに、構築ログがあります。

バルクビルドは三つの段階からなります:

構築中、壊れているパッケージの一覧が/usr/pkgsrc/.broken (OBJMACHINE が設定されている場合は .../.broken.${MACHINE}) に作られ、構築が壊れているものの個々の 構築ログは、各パッケージのディレクトリーに置かれます。これらのファイルは、 壊れているパッケージを再度構築しようとするような無駄をなくすために、bulk-ター ゲットが構築が壊れていることを記録するのに使われます。また、壊れているパッ ケージを後でデバッグするためにも使えます。

現在、 NetBSD 2.0/i386 ではおおむね以下の容量が必要です:

各パッケージは、バイナリーパッケージ作成直後にアンインストールされた上、 ソースも削除されます。このため、莫大なディスク容量は必要ありません。後 になって、このパッケージがまた必要となった場合は、再度構築することなく pkg_add(1) でインストールされるので、 無駄な再コンパイルの繰り返しは発生しません。

バルクビルドによってパッケージを全部消される(マシンがパッケージのコンパイル 以外に無用なものになってしまう)のが嫌な場合は、chroot環境下でパッケージをバ ルクビルドすることもできます。

最初にすることは、chrootされた砂場を、 たとえば/usr/sandboxに用意することです。 これは null マウントを使って、または手動でおこなうことができます。

pkgsrc/mk/bulk/mksandbox というシェルスクリプトがあり、 null マウントを使った砂場の環境を用意してくれます。このスクリプトは、 砂場の環境のルートに sandbox というスクリプトも作ります。 これは、sandbox mount コマンドで null マウントをした状態にしたり、 sandbox umount コマンドでアンマウントした状態にしたりすることができるものです。

砂場の環境を手動で用意するには、 NetBSDのインストール配布物をすべて展開するか、/usr/src/etcで make distribution DESTDIR=/usr/sandboxを実行した後、以下のものを用意して 適切に設定された状態にします。

chroot砂場の用意ができれば、 以下の手順で構築を開始できます:

# cd /usr/sandbox/usr/pkgsrc
# sh mk/bulk/do-sandbox-build
      

このコマンドは、砂場内に移動して、構築を開始するものです。構築が終わ ると、構築の結果がメールで送信されます。できあがったバイナリーパッケージは、 /usr/sandbox/usr/pkgsrc/packages (の指す/マウントされた先/元)に置かれます。

pkgsrc/mk/bulk/build スクリプトは、 pkgsrc の全パッケージの一式の構築のほか、 pkgsrc に含まれるパッケージの部分集合の構築にも使うことができます。 mk.conf で SPECIFIC_PKGS を定義すると、

の各変数で構築対象のパッケージを定義できるようになります。 構築対象として定義されたパッケージの依存関係によって必要となるパッケージも、 バルクビルドのコードが構築対象に追加します。

この使い方のひとつに、 サイトで必要なバイナリーパッケージをすべて用意するために、 SPECIFIC_PKGS を使ったバルクビルドを chroot 環境で定期的に実行するというものがあります。 こうすれば、不要なパッケージまで構築するような余計な負荷はかかりません。

本節では、pkgsrc 開発者がバルクビルドで構築したバイナリーパッケージを ftp.NetBSD.org へアップロードする方法を説明します。

アップロードしようとしているバイナリーパッケージの チェックサムファイルを自動生成したい場合は、 mk/bulk/build.conf で MKSUMS=yes を忘れずに設定してください。

チェックサムファイルに PGP 署名をしたい場合 (そうすることを強くおすすめします)は、 mk/bulk/build.conf で SIGN_AS=username@NetBSD.org を忘れずに設定してください。 こうしておくと、ファイルをアップロードする前には常に、そのファイルに署名するため、 GPG パスワードの入力を促すようになります。

次に、mk/bulk/build.conf ファイルで RSYNC_DST が適切に設定された状態にします。 つまり、この変数値を以下のような形式に調節します。

RSYNC_DST=ftp.NetBSD.org:/pub/pkgsrc/packages/NetBSD/arch/a.b.c-20xxQy/upload

このなかの "20xxQy" (枝), "a.b.c" (OS のバージョン), "arch" を、適切な値にしてください。 ftp.NetBSD.org でのログイン名がローカルのログイン名と異なる場合は、 そのログイン名を直接指定します。たとえば、 筆者のローカルアカウントは "feyrer" ですが、ログイン名は "hubertf" なので、以下のようにします。

RSYNC_DST=hubertf@ftp.NetBSD.org:/pub/pkgsrc/packages/NetBSD/arch/a.b.c-20xxQy/upload

ここでは、アップロードの最中はディレクトリーを公開しないようにするため、 独立した upload ディレクトリーにアップロードします。 そうするために、ftp.NetBSD.org で以下のコマンドを実行しておきます。

nbftp% mkdir -p -m 750 /pub/pkgsrc/packages/NetBSD/arch/a.b.c-20xxQy/upload

バイナリーパッケージをアップロードする前に、以下のような ssh の認証が必要となります。以下の例は、砂場内における root アカウント用の一時的な鍵を使うようにする方法です。 (同じ鍵を常時使うことはしないものとします)。

# chroot /usr/sandbox
chroot-# rm $HOME/.ssh/id-dsa*
chroot-# ssh-keygen -t rsa
chroot-# cat $HOME/.ssh/id-rsa.pub
      

ここで出力した id-rsa.pub の内容を、 ftp.NetBSD.org の ~/.ssh/authorized_keys ファイルに追加します。パッケージのアップロードが終わったら、 この鍵は削除してください。

次に、ssh でうまく接続できることを確認します。

chroot-# ssh ftp.NetBSD.org date 

ここでは、適宜 "-l yourNetBSDlogin" を使ってください。

すべて順調にいけば、 砂場から抜けて、アップロードを始めることができます。

chroot-# exit
# cd /usr/sandbox/usr/pkgsrc
# sh mk/bulk/do-sandbox-upload
      

アップロードにはそれなりに時間がかかるかもしれません。 FTP サーバーで ls(1) や du(1) して、アップロードの過程を見てください。 アップロード用スクリプトは、制限つきのパッケージはアップロードしないように 処理してくれます。

アップロードが終わった後に、最初にすることは、ssh でアクセスして以下のようにすることです。

nbftp% vi ~/.ssh/authorized_keys
      Gdd:x! 

アップロード用に事前に追加しておいた鍵はすべて削除してください。 最後に、アップロードしたパッケージを upload ディレクトリーの外に出して、 公開された状態にします。

nbftp% cd /pub/pkgsrc/packages/NetBSD/arch/a.b.c-20xxQy
nbftp% mv upload/* .
nbftp% rmdir upload
nbftp% chgrp -R netbsd .
nbftp% find . -type d | xargs chmod 775
      

最初に、pbulk 基盤を作るための pkgsrc 基盤を作る必要があります。プラットフォームが何であっても (NetBSD であっても)、専用のディレクトリーを用意してそこに対して bootstrap をしてください。このディレクトリーは /usr/pbulk または $HOME/pbulk としましょう。bootstrap すると、バルクビルドに必要なツールがインストールされます。

$ cd /usr/pkgsrc
$ ./bootstrap/bootstrap --prefix=/usr/pbulk --varbase=/usr/pbulk/var --workdir=/tmp/pbulk-bootstrap
$ rm -rf /tmp/pbulk-bootstrap

これで、pbulk 基盤のための基本的な環境がインストールされましたが、いくつかのツールはまだありません。ここで、pkgsrc の設定ファイル /usr/pbulk/etc/mk.conf を pbulk 向けに編集しましょう。ここでの典型的な設定内容は以下のとおりです。

これで、pbulk 基盤の残りの部分を構築する準備ができました。

$ cd pkgtools/pbulk
$ /usr/pbulk/bin/bmake install
$ rm -rf /tmp/pbulk-outer

これで、pbulk 基盤が構築・インストールされました。この基盤を設定したうえで、さらなる準備が必要です。そうした後に、実際のバルクビルドを始めることができるようになります。

TODO; さらなる情報は pkgsrc/doc/HOWTO-pbulk をご覧ください。

TODO: つづきを書く

cdpackの完全なドキュメンテーションはcdpack(1)マニュアルページにあります。 以下の短い例では、 バイナリーパッケージが/usr/pkgsrc/packages/Allに置いてあり、ISO 9660イメー ジ用の十分なディスク容量が/u2にあるものとします。

# mkdir /u2/images
# pkg_add /usr/pkgsrc/packages/All/cdpack
# cdpack /usr/pkgsrc/packages/All /u2/images
      

各CDに共通ファイル(COPYRIGHT, README, など)を含めたい場合は、そのファイルを 含むディレクトリーを作る必要があります。たとえば以下のようにします。

# mkdir /tmp/common
# echo "This is a README" > /tmp/common/README
# echo "Another file" > /tmp/common/COPYING
# mkdir /tmp/common/bin
# echo "#!/bin/sh" > /tmp/common/bin/myscript
# echo "echo Hello world" >> /tmp/common/bin/myscript
# chmod 755 /tmp/common/bin/myscript
      

ここで、以下のようにしてイメージを作成します。

# cdpack -x /tmp/common /usr/pkgsrc/packages/All /u2/images

こうすると、各イメージのルートディレクトリーにREADME, COPYINGおよび bin/myscriptが含まれるようになります。

簡単な Perl モジュールは、url2pkg を使って、依存性も含めて自動的に処理することができます。

KDE アプリケーションは、かならず meta-pkgs/kde3/kde3.mk をインクルードしてください。 これには、KDE パッケージでよくある設定が多数含まれています。

Python のモジュールとプログラムは、 あらかじめ用意された変数を使って、簡単にパッケージを作ることができます。

ほとんどの Python パッケージは、“distutils” または easy-setup (“eggs”) のいずれかを使っています。 ソフトウェアが “distutils” を使っている場合は、 pkgsrc がこの枠組を使うようにするため、 PYDISTUTILSPKG 変数を “yes” に設定します。 “distutils” では、setup.py という名前のスクリプトを使いますが、 “distutils” ドライバーが setup.py という名前でない場合は、 PYSETUP 変数をスクリプト名に設定します。

ソフトウェアが既定の Python バージョンに対応していない場合は、 PYTHON_VERSIONS_ACCEPTED 変数を、 そのソフトウェアが動作する Python バージョンに設定します。 バージョンは新しいものから古いものの順に並べます。たとえば以下のようにします。

PYTHON_VERSIONS_ACCEPTED=       25 24

パッケージにするソフトウェアが Python モジュールである場合は、 “../../lang/python/extension.mk” をインクルードします。 この場合は、パッケージのディレクトリー名を “py-software” という形式にし、 PKGNAME を “${PYPKGPREFIX}-${DISTNAME}” に設定します。たとえば以下のようにします。

DISTNAME=   foopymodule-1.2.10
PKGNAME=    ${PYPKGPREFIX}-${DISTNAME}

パッケージにするソフトウェアがアプリケーションである場合は、 “extension.mk” をインクルードする前に “../../lang/python/application.mk” もインクルードします。

パッケージにするソフトウェア (アプリケーションでもモジュールでも) が egg に対応している場合、必要なことは、 “../../lang/python/egg.mk” をインクルードすることだけです。

Python インタープリターへのパスを適切に設定するために、 REPLACE_PYTHON 変数を使います。この変数に、 パスの修正が必要なファイルのリストを設定します。たとえば以下のようにします。

REPLACE_PYTHON=   ${WRKSRC}/*.py

問題を避けるため、patch-*ファイルは diff -buフォーマットとし、かつ、曖昧 さなしで適用できるようにします。(曖昧さがあっても強制的にパッチを適用させる ため、PATCH_FUZZ_FACTOR=-F2を設定することができます)。 さらに、各パッチファイルは一つのファイルに対する修正だけを含むようにし、 また、一つのファイルを複数のパッチファイルによって修正するようなことはしないようにします。 こうすることで、将来の変更が簡単になります。

各パッチファイルは、以下のような構造となっています: 最初の行には パッチそのものの RCS Id があります。2 行目は、見栄えをよくするため、 空にします。これより後には、そのパッチによる各変更についてのコメントを書きます。 これには標準的な事例がいくつもあります。

あらゆる事例において、 そのアプリケーションのコードを理解している開発者がパッチを利用できるようにするため、 パッチにはコメントを書くようにします。上流の開発者に対しては特に注意が必要です。 たいていの場合、私たちの将来の作業を減らすために、 上流の開発者にパッチを採用してもらいたいからです。

一つ重要なこととして、NetBSD CVSツリーにチェックインした後に問題を引き起こ すので、パッチファイルにRCS IDを含ませないように注意してください。 この問題を避けるため、 pkgtools/pkgdiff パッケージの pkgdiff コマンドを使ってください。

さらに自動化するため、同パッケージのmkpatchesを使ってパッチ一式を作ることを おすすめします。あなたがやらねばならないことは、ファイルの編集前に cp -p filename filename.origのようにするか、あるいはさらに簡単に、同パッケージの pkgviを使って、元のファイルをfilename.origの名前でバックアップしておくだ けです。この方法でパッケージをアップグレードした場合、patchdiffを使って、新 しいパッチと既存のパッチを簡単に比較することができます。 patches 以下のファイルは新しいファイルに置き換えられますので、 変更点が適切かどうかをしっかり確認してください。

パッケージを作り終えたとき、忘れずにmake makepatchsumコマンドでパッチファ イルのチェックサムを生成するようにしてください。Section 11.2, “distinfo”を参照してくだ さい。

(たとえば、マニュアルページのインストール先を pkgsrc の流儀に合わせて変えるといったものではなく) distfile の問題を正すパッチを追加した場合は、 そのパッチをバグ報告としてメンテナーに送ってください。 こうすることで、pkgsrc を使っていない利用者も幸せになれますし、 通常は、将来のバージョンでパッチを削除することができるようになります。

パッチファイルのファイル名は、通常は patch-path_to_file__with__underscores.c という形式です。 多くのパッケージでは、以前使われていた patch-[a-z][a-z] という形式をまだ使っていますが、 パッチを新たに作る場合は、ファイル名を含んだ形式にしてください。pkgtools/pkgdiff に含まれている mkpatches は、 パッチファイルのファイル名を自動で処理します。

pkgsrc の複数のパッケージが同じ distfile を使っているなどの理由で、 複数のパッケージの間でパッチを共有したい場合は、 PATCHDIR をパッチファイルのある場所へのパスに設定します。 たとえば以下のようにします。

PATCHDIR= ${.CURDIR}/../xemacs/patches

作者その他のメンテナーが配布しているパッチファイルは、 PATCHFILES に列挙することができます。

置いておきたいパッチがあるがpkgsrcにcommitすべきものではない場合、それを pkgsrcツリーの外の $LOCALPATCHES ディレクトリーに置いておくことができます。こ のディレクトリーツリーはpkgsrcと同様の “category/package”の構造を持つように し、パッチを各パッケージのディレクトリー(すなわち$LOCALPATCHES/$PKGPATH)に 置くようになっています。たとえば、 pkgsrc/graphics/pngに私的なパッチを適用す るようにしたい場合は、そのパッチを $LOCALPATCHES/graphics/png/mypatchに置き ます。このディレクトリーにあるファイルはすべてパッチファイルとして扱われ、 pkgsrcのパッチが適用された後に、このパッチが適用されます。

コードの移植性に関する問題を修正する場合は、 プリプロセッサーの細工を使ってオペレーティングシステムやプラットフォームを判別するようなことはしてはいけません。 そのような方法では、各 OS 固有性の詳細が適切に抽象化できないため、 他のオペレーティングシステムに対する移植性を損なってしまいます。

一般的な決めごとは、 アプリケーションを構築しているオペレーティングシステムそのものを検査するのではなく、 必要としている特有の機能を検査する、というものです。 たとえば、kqueue は NetBSD において利用可能であると仮定して __NetBSD__ マクロを kqueue 対応の条件として使う、 ということはせずに、kqueue 自体を検出するようにするのです。 そしてこれは、一般的には configure スクリプトにパッチを適用することになります。 ある OS が他の OS (たとえば kqueue を実装した Linux) のインターフェースを採用してはいけない理由はまったくありませんが、 前述のようにオペレーティングシステムそのものを検査してしまうと、 そのような状況に対応することができません。

もちろん、機能を検査することは、 一般的に、開発者側の負担が多くなります。しかし、 機能を検査するようにすれば、その結果はきれいな変更となり、 他の多くのプラットフォームで動作させられる可能性があります。 また、本家のソースに統合される可能性が高くなることはいうまでもありません。 正しくない限り動かないの哲学を忘れないでください。

典型的な例としては、以下のようなものがあります。

case ${target_os} in
netbsd*) have_kvm=yes ;;
*)       have_kvm=no  ;;
esac

AC_CHECK_LIB(kvm, kvm_open, have_kvm=yes, have_kvm=no)

#if defined(__NetBSD__)
#  include <sys/event.h>
#endif

#if defined(HAVE_SYS_EVENT_H)
#  include <sys/event.h>
#endif

int
monitor_file(...)
{
#if defined(__NetBSD__)
        int fd = kqueue();
        ...
#else
        ...
#endif
}

int
monitor_file(...)
{
#if defined(HAVE_KQUEUE)
        int fd = kqueue();
        ...
#else
	...
#endif
}

さらなる情報は、Making packager-friendly software の記事 (第 1 部、第 2 部) をお読みください。この記事では、ソフトウェアをパッケージ化しやすくする方法について、 複数の点での詳細をまとめています。ここで述べられている提案は、いずれも、 私たちが pkgsrc の作業をした経験から集められたものですので、 パッチの作成に際しても役に立つかもしれません。

常に、常に、常に、 パッケージに施したあらゆる移植性に関する修正や改良点を、 本家の開発者に還元するようにしてください。 彼らに移植性についての注意を喚起して、将来のバージョンが無修正で NetBSD で構築できるようにするためには、そうするしかないのです。 また、将来のバージョンの配布ファイルの利用者は、 フィードバックされた修正をパッケージのコードから直接利用することができるようになります。

フィードバックをする方法は、一般的には、 パッチをきれいに書き直し (pkgsrc で追加されたパッチは、 時にはクイックハックであることがあるからです)、 フィードバック先のプロジェクト用の適切な追跡システムに対してバグ報告をし、 変更が受け入れられるよう本家の作者とともに作業する、というものです。 フィードバックをすることで、pkgsrc のパッケージを単純なものとし、 さほど労力を割かずに将来の変更ができるようにするということが、 特に重要です。

フィードバックをしたら、上流のバグレポートの URL を パッチのコメントに追加してください。

フリーソフトウェアの理念をサポートして下さい。

STRING=                 foo * bar `date`
INT_LIST=               # empty
ANOTHER_INT_LIST=       apache-[0-9]*:../../www/apache
EXT_LIST=               # empty
ANOTHER_EXT_LIST=       a=b c=d

INT_LIST+=              ${STRING}               # 1
INT_LIST+=              ${ANOTHER_INT_LIST}     # 2
EXT_LIST+=              ${STRING:Q}             # 3
EXT_LIST+=              ${ANOTHER_EXT_LIST}     # 4

文字列を外部リストに追加する場合 (例 3) は、 その文字列をクォートする必要があります。それ以外の場合は、 クォートを追加してはいけません。内部リストと外部リストは、 その各要素がどちらのリストでも適切に処理されることが確実な場合をのぞき、 統合してはいけません。

EXT_LIST=       # empty
.for i in ${INT_LIST}
EXT_LIST+=      ${i:Q}""
.endfor

このコードは、内部リスト INT_LIST を外部リスト EXT_LIST に変換します。内部リストの要素はクォートされていないので、 変換に際してはクォートする必要があります。 "" を追加する理由は後述します。

時には、任意の文字列を出力したいことがあるかもしれません。 不具合を起こす方法はたくさんありますが、 どんな複雑なものも扱えるような方法は少ししかありません。

STRING=         foo bar <    > * `date` $$HOME ' "
EXT_LIST=       string=${STRING:Q} x=second\ item

all:
        echo ${STRING}                  # 1
        echo "${STRING}"                # 2
        echo "${STRING:Q}"              # 3
        echo ${STRING:Q}                # 4
        echo x${STRING:Q} | sed 1s,.,,  # 5
        printf "%s\\n" ${STRING:Q}""    # 6
        env ${EXT_LIST} /bin/sh -c 'echo "$$string"; echo "$$x"'

例 1 は、シェルで構文エラーを起こします。 各文字がそのままコピーされるだけだからです。

例 2 も構文エラーを起こします。また、${STRING} の末尾の " 文字を除いた場合は、date(1) が実行されてしまいます。 また、$HOME シェル変数も評価されるでしょう。

例 3 は、echo(1) コマンドの実装によって、 各空白文字の前にバックスラッシュが出力されたり、 されなかったりします。

例 4 は、最初の文字がダッシュでない文字列はすべて適切に処理します。 文字列の最初の文字がダッシュの場合、結果がどうなるかは echo(1) コマンドの実装に依存します。 入力される文字列の最初の文字がダッシュにならないことを保証できる限りは、この形式は適切です。

例 5 は、たとえ文字列がダッシュで始まっていたとしても、 適切に処理します。

例 6 も、あらゆる文字列を適切に処理できますし、 それ自体に問題のあるパイプを使わないので、 より軽い方法です。

EXT_LIST はクォートする必要はありません。 なぜなら、リストに要素を追加した時に、 すでにクォートされているからです。

内部リストはシェルに渡されないものなので、 例示はありません。

変数が不適切にクォートされたソースは、多くありえます。 本節では、よく知られている例をいくつか掲げます。

pkgsrc の bmake プログラムは、以下のような代入を適切に処理することができません。 _othervar_ が ``-'' 文字を含んでいる場合、 以下のコードを実行すると、閉じ中括弧のひとつが ${VAR} に含まれてしまいます。

VAR:=   ${VAR:N${_othervar_:C/-//}}

もっと複雑なコードの断片と回避策については、 regress/make-quoting パッケージのテストケース bug1 をご覧ください。

以下に掲げるのは、 pkgsrc/graphics/tiff における buildlink3.mk の実例です。

# $NetBSD: buildlink3.mk,v 1.16 2009/03/20 19:24:45 joerg Exp $

BUILDLINK_TREE+=	tiff

.if !defined(TIFF_BUILDLINK3_MK)
TIFF_BUILDLINK3_MK:=

BUILDLINK_API_DEPENDS.tiff+=	tiff>=3.6.1
BUILDLINK_ABI_DEPENDS.tiff+=	tiff>=3.7.2nb1
BUILDLINK_PKGSRCDIR.tiff?=	../../graphics/tiff

.include "../../devel/zlib/buildlink3.mk"
.include "../../graphics/jpeg/buildlink3.mk"
.endif # TIFF_BUILDLINK3_MK

BUILDLINK_TREE+=	-tiff

ヘッダーとフッターで、 BUILDLINK_TREE の値を操作しています。 この変数は、パッケージの依存関係を辿るために、 すべての buildlink3.mk ファイルの間で、 共通に使われます。

本体の節では、多重のインクルードを防いだうえで、 pkg への依存性をどのように追加するかを制御しています。 いくつもの重要な変数がこの節で設定されます。

以下の各変数はすべて、二つ目の (多重のインクルードを防いでいる) 節において、 任意に定義されるものであり、どのパッケージのファイルを ${BUILDLINK_DIR} からシンボリックリンクするか、および、 シンボリックリンクによってファイル名をどのように変換するか、 を制御します。

この節では、 pkg のライブラリー依存性として必要な buildlink3.mk をすべてインクルードすることができます。 ここで buildlink3.mk ファイルをインクルードすると、 pkg の buildlink3.mk ファイルがインクルードされる場合はいつも、 これらへの依存性のためのヘッダーやライブラリーも、 ${BUILDLINK_DIR} からシンボリックリンクされることになります。 依存性が追加されるのは、 buildlink3.mk ファイルを直接インクルードした場合だけです。

パッケージを更新した際に BUILDLINK_API_DEPENDS.pkg に列挙されている依存性のバージョンを上げる必要があるのは、 その更新で API やヘッダーファイルへのインターフェースが変わった場合です。

このような場合は、 BUILDLINK_API_DEPENDS.pkg を調節して、最低限、新しいパッケージのバージョンを要するようにします。 場合によっては、新しいバージョンに依存するパッケージの PKGREVISION を上げる必要があることがあります。 また、依存しているパッケージに buildlink3.mk ファイルがある場合は、 BUILDLINK_API_DEPENDS.pkg も調節します。これは、pkgsrc が適切なパッケージの依存性を求めるようにして、 ソースからの構築時に古いパッケージに依存したりしないようにするために、 必要なことです。

BUILDLINK_ABI_DEPENDS.pkg を上げるのは、バイナリーインターフェースや、 インストールされている共有ライブラリーのいずれかの soname (ライブラリーのバージョンのメジャー番号) が変わった場合です。 これは、これらを使うバイナリーパッケージが、 適切なパッケージの依存性を求めるようにして、 必要な共有ライブラリーをもたない古いパッケージに依存したりしないようにするために、 必要なことです。

BUILDLINK_ABI_DEPENDS および ABI_DEPENDS の定義を含めた、 他のパッケージへの依存性について、さらなる情報は、 Section 19.1.6, “依存性の処理”をご覧ください。

なお、必要もないのにパッケージを削除したり再構築したりするようなことのないよう、 BUILDLINK_API_DEPENDS.pkg や BUILDLINK_ABI_DEPENDS.pkg の調節は、事前に熟考するようにしてください。 多くの場合、新しいバージョンのパッケージは、 従前の依存性のままでも問題なく動作します。

また、 BUILDLINK_ABI_DEPENDS.pkg は、 BUILDLINK_API_DEPENDS.pkg と同じ値となる場合には設定する必要はありません。

以下に掲げるのは、builtin.mk ファイルの推奨テンプレートです。

.if !defined(IS_BUILTIN.foo)
#
# IS_BUILTIN.foo is set to "yes" or "no" depending on whether "foo"
# genuinely exists in the system or not.
#
IS_BUILTIN.foo?=        no

# BUILTIN_PKG.foo should be set here if "foo" is built-in and its package
# version can be determined.
#
.  if !empty(IS_BUILTIN.foo:M[yY][eE][sS])
BUILTIN_PKG.foo?=       foo-1.0
.  endif
.endif  # IS_BUILTIN.foo

.if !defined(USE_BUILTIN.foo)
USE_BUILTIN.foo?=       ${IS_BUILTIN.foo}
.  if defined(BUILTIN_PKG.foo)
.    for _depend_ in ${BUILDLINK_API_DEPENDS.foo}
.      if !empty(USE_BUILTIN.foo:M[yY][eE][sS])
USE_BUILTIN.foo!=                                                       \
        ${PKG_ADMIN} pmatch '${_depend_}' ${BUILTIN_PKG.foo}            \
        && ${ECHO} "yes" || ${ECHO} "no"
.      endif
.    endfor
.  endif
.endif  # USE_BUILTIN.foo

CHECK_BUILTIN.foo?=     no
.if !empty(CHECK_BUILTIN.foo:M[nN][oO])
#
# Here we place code that depends on whether USE_BUILTIN.foo is set to
# "yes" or "no".
#
.endif  # CHECK_BUILTIN.foo

最初の節では、pkg がベースシステムに実際に存在するかどうかに応じて、 IS_BUILTIN.pkg を設定しています。これは、ベースシステムに pkg 相当の機能のソフトウェアが存在するかどうかではありません。 この変数を “yes” にするのは、 このパッケージそのものがベースシステムの一部として附属する場合だけです。 この変数は、builtin.mk ファイルの内部でのみ使われます。

二つ目の節では、pkg がベースシステムに存在する場合 (つまり IS_BUILTIN.pkg が “yes” の場合)、 BUILTIN_PKG.pkg をそのバージョンに設定しています。この変数は、builtin.mk ファイルの内部でのみ使われます。

三つ目の節では、 USE_BUILTIN.pkg を設定しており、これはすべての builtin.mk ファイルで必須です。 この節のコードは、ベースシステム附属のソフトウェアが、 BUILDLINK_API_DEPENDS.pkg で列挙されている依存性を満たすのに十分かどうかを判別する必要があります。 この判別は、たいていは、 BUILTIN_PKG.pkg を、 BUILDLINK_API_DEPENDS.pkg の各依存性と比較することでおこなわれます。 USE_BUILTIN.pkg は、builtin.mk ファイルの終わりまでに、 適切な値に設定する必要があります。なお、たとえ IS_BUILTIN.pkg が “no” であっても、 USE_BUILTIN.pkg は “yes” にすることができます。なぜなら、 ベースシステム附属のソフトウェアが依存パッケージに十分似ており、 代替可能であるという判断もできるからです。

最後の節は CHECK_BUILTIN.pkg に守られており、前の節で設定された USE_BUILTIN.pkg の値を使うコードをインクルードします。たいていの場合、ここでインクルードするのは、 たとえば依存性への制約の追加や、${BUILDLINK_DIR} からシンボリックリンクされるファイルのリストの (BUILDLINK_FILES.pkg を使った) 追加などです。

パッケージの構築時に、 依存性を満たすソフトウェアとして組み込み (ネイティブ) のものを使うか pkgsrc のものを使うかを、 大域的な設定に応じて切替えることができます。 この制御は、PREFER_PKGSRC および PREFER_NATIVE を設定することでおこないます。 この両変数は、“yes”, “no” またはパッケージのリストを値として持ちます。 PREFER_PKGSRC は pkgsrc 版のソフトウェアを使うことを、 PREFER_NATIVE で組み込み版を使うことを、 それぞれ指示します。この設定は、 対象パッケージではどちらを使うのがもっとも適当かに応じて、 PREFER_PKGSRC か PREFER_NATIVE のいずれかで指定します。 あるパッケージがどちらにも設定されていない場合、 または両方で設定されている場合は、 PREFER_PKGSRC が PREFER_NATIVE より優先します。たとえば、 NetBSD システムの最も基本的な要素を除き、 すべて pkgsrc 版のソフトウェアを使うこととする場合、 以下のように設定することができます。

PREFER_PKGSRC=  yes
PREFER_NATIVE=  getopt skey tcp_wrappers

あるパッケージを PREFER_NATIVE のリストに加えるには、そのパッケージに builtin.mk ファイルがある必要があります。 このファイルがない場合は、リストに加えても単に無視されます。

以下の変数は、ファイルシステムの任意の場所へディレクトリーを作成するために、 設定することができます。

インストール用プレフィックス以外の場所に空でないファイルを作ることは、やりにくいことです。 なぜなら PLIST は全ファイルをインストール用プレフィックス内にあるものとして扱うからです。 この問題に対する唯一の解決策は、インストールの際に、 ファイルをいったん既知の場所 (つまり、インストール用プレフィックス内) に展開し、それを本来の場所にコピーすることです (pkginstall が生成するインストール用スクリプトがおこないます)。 以下、インストール用プレフィックス以外の場所のファイルを自動的かつ首尾一貫して扱うために使える変数について説明しますが、 ここではプレフィックス内にいったん展開したファイルのことを原本ファイル (master file) ということにします。

前述のとおり、PKG_SYSCONFDIR 変数は設定ファイルのインストール先を指定します。この変数の値は、 以下の各変数をもとに設定されます。

以上の各変数をもとに、pkginstall は PKG_SYSCONFDIR の値を決めます。パッケージが設定ディレクトリーを参照するには、 この PKG_SYSCONFDIR 変数だけを使うことができます。 この値の設定に使われるアルゴリズムは、 基本的には以下のとおりです。

なお、${PKG_SYSCONFDIR} は自動的に OWN_DIRS に追加されることを断っておきます。この意味については、Section 15.1.1, “ディレクトリーの操作”をご覧ください。 ただし、${PKG_SYSCONFDIR} のサブディレクトリーは追加されませんので、 OWN_DIRS または MAKE_DIRS を使って作成する必要があります。

pkgsrc (とユーザーも) が、設定ファイルを既知の場所に置くことを前提としている場合は、 設定ファイルをインストールする場所を各パッケージに教えてやる必要があります。 場合によっては、パッケージの Makefile を修正する必要があります。 この修正は、運がよければ、 コンフィギュレーションスクリプトに渡すフラグを追加する程度ですみます。 これは、GNU Autoconf が生成したファイルの場合が該当します。

CONFIGURE_ARGS+= --sysconfdir=${PKG_SYSCONFDIR}

なお、ここで指定しているのは、 パッケージが設定ファイルを探す必要のある場所であって、 設定ファイルのもともとのインストール先ではありません (困った事に、 両者ははっきり区別できませんが)。

前述のとおり、pkginstall は設定ファイルを自動的に処理します。 つまり、パッケージ本体側では、 ${PKG_SYSCONFDIR} の内容を直接いじってはいけない ことになります。まずいことに、多くのソフトウェアのインストール用スクリプトは、 そのまま実行すると、このディレクトリーの内容に手を加えてしまいます。では、 この問題を適切に直すにはどうすればいいのでしょうか?

パッケージに対して、すべての設定ファイルを examples 階層 share/examples/${PKGBASE}/ 以下にインストールするように (ふつうは、手でパッチを当てて) 指示する必要があります。こうすると、 PLIST はこれらを登録します。 また、管理者はインストールされたままの設定ファイルを常に使うことができます。

必要な設定ファイルを適切な場所 (つまり、examples 階層の下) に置けば、 pkginstall の枠組は、このファイルを、パッケージのインストール時に ${PKG_SYSCONFDIR} 以下のファイルを更新するための原本として使うことができます。これをおこなうために、 CONF_FILES および CONF_FILES_PERMS の各変数が使われます。この各変数の書式と使い方は、 Section 15.1.2, “ファイルの操作”でご確認ください。 mail/mutt パッケージから抜粋した例を以下に掲げます。

EGDIR=        ${PREFIX}/share/doc/mutt/samples
CONF_FILES=   ${EGDIR}/Muttrc ${PKG_SYSCONFDIR}/Muttrc

なお、EGDIR 変数は当該パッケージに特有のものであって、 それ以外では意味を持たないことに注意してください。

設定ファイルの自動コピーは、パッケージをインストールする前に環境変数 PKG_CONFIG を設定しておけば、 おこなうかどうかを切替えることができます。

設定ファイルの自動コピーは、パッケージをインストールする前に環境変数 PKG_RCD_SCRIPTS を設定しておけば、 おこなうかどうかを切替えることができます。なお、起動スクリプトは常に examples 階層 ${PREFIX}/share/examples/rc.d/ にコピーされますが、これはこの変数値の影響を受けません。

シェルインタープリターの自動登録は、管理者が PKG_REGISTER_SHELLS 環境変数を NO に設定すれば、無効化することができます。

フォントデータベースの自動更新は、管理者が PKG_UPDATE_FONTS_DB 環境変数を NO に設定すれば、無効化することができます。