Table of Contents
本章では、pkginstall の枠組について説明します。
主な機能は以下のとおりです。
pkgsrc が扱うツリー (LOCALBASE)
以外の場所のディレクトリーやファイルの、汎用的なインストールおよび操作。
インストール時における、設定ファイルの自動処理 (パッケージが正しく設計されていればですが)。
システム起動スクリプトの作成およびインストール。
システムユーザーおよびグループの登録。
システムシェルの登録。
フォントデータベースの自動更新。
以下の各節では、上述の各機能について詳しく見てゆきます。
本章で説明する機能の多くは、パッケージのインストール後のターゲット
(post-install) を使うだけで簡単に実現できるのではないか、
とお思いになるかもしれませんが、それは正しくありません。
このターゲットのコードは、パッケージをソースから構築した場合しか実行されないからです。
バイナリーパッケージを使う場合は、(コード自体が利用できないので)
このターゲットのコードでは何もできません。したがって、上述の各機能は、
pkginstall が自動生成するインストール用スクリプトでしか実現できないのです。
すでにご存知のとおり、PLIST ファイルには、
パッケージに属するファイルとディレクトリーの一覧が書かれています。
この一覧では、インストール用のプレフィックス
(${PREFIX}) からの相対位置を使うため、
このディレクトリー以外の場所にあるファイルを書くことはできません
(絶対パス名は使えません)。この制約がある一方で、
パッケージによってはそのような場所、たとえば
${VARBASE} や
${PKG_SYSCONFDIR}
以下にファイルをインストールする必要があります。
これをおこなう唯一の方法は、インストール時にインストール用のスクリプトを使って
インストール対象のファイルを作成することです。
汎用のインストール用スクリプトは、
任意のコードを含めることのできるシェルスクリプトです。
実行するスクリプトを並べたリストを INSTALL_FILE 変数で与えます。
この変数の値は標準では INSTALL です。
パッケージの削除用としても、同様の変数があります (DEINSTALL_FILE:
標準の値は DEINSTALL)。
これらのスクリプトでは任意のコマンドを実行できるので、
ファイルシステム中のどこであってもファイルの作成や管理をすることができます。
以上のような汎用のインストール用スクリプトを使うことはおすすめしませんが、 特殊な事例では必要となることがあります。これらを使うべきでない理由のひとつは、 インストール用スクリプト内に不必要なコードや単純に誤ったコードが入っていないことについて、 利用者がパッケージ作成者を信頼する必要があるということです。 また、以前は、同じ機能のために同様のコードがたくさん使われており、 それらに共通するエラーを修正する場合は、 同様のコードをすべて探して変更する必要がありました。
pkginstall の枠組では、これとは異なる標準化された方法を提供します。
パッケージの Makefile で設定された変数にもとづき、
インストール対象のファイルやディレクトリーを操作するための汎用のスクリプトを提供します。
以下、本節では、この用途で使う変数を説明します。
以下の変数は、ファイルシステムの任意の場所へディレクトリーを作成するために、 設定することができます。
MAKE_DIRS と OWN_DIRS は、
インストール用スクリプトが作成したり、
削除を試みたりする対象のディレクトリーのリストを値として持ちます。
両変数の違いは、後者はアンインストール時に (空でなかったために)
削除できなかった各ディレクトリーを削除するよう管理者に対してうながしますが、
前者はそうしないことです。
MAKE_DIRS_PERMS と
OWN_DIRS_PERMS は、インストール用スクリプトが作成したり、
削除しようとしたりする対象のディレクトリーについて記述したタプルのリストを値として持ちます。
各タプルは、ディレクトリー名、所有者、所有グループと、
数字で表したモードの値をスペースで区切ったものからなります。
たとえば以下のようになります。
MAKE_DIRS_PERMS+= ${VARBASE}/foo/private ${ROOT_USER} ${ROOT_GROUP} 0700
両変数の違いは、PERMS
のつかない変数の違いとまったく同じです。
インストール用プレフィックス以外の場所に空でないファイルを作ることは、やりにくいことです。
なぜなら PLIST は全ファイルをインストール用プレフィックス内にあるものとして扱うからです。
この問題に対する唯一の解決策は、インストールの際に、
ファイルをいったん既知の場所 (つまり、インストール用プレフィックス内)
に展開し、それを本来の場所にコピーすることです
(pkginstall が生成するインストール用スクリプトがおこないます)。
以下、インストール用プレフィックス以外の場所のファイルを自動的かつ首尾一貫して扱うために使える変数について説明しますが、
ここではプレフィックス内にいったん展開したファイルのことを原本ファイル (master
file) ということにします。
CONF_FILES と
REQD_FILES は、
原本ファイルとコピー先ファイルの組のリストを値として持ちます。
インストール時に、コピー先ファイルが存在しなかった場合に限って、
原本ファイルがコピー先ファイルにコピーされます。アンインストール時は、
コピー先ファイルがインストールにおいて変更されていなければ、
コピー先ファイルが削除されます。
両変数の違いは、後者はアンインストール時に (空でなかったために) 削除できなかった各ファイルを削除するよう管理者に対してうながしますが、 前者はそうしないことです。
CONF_FILES_PERMS と
REQD_FILES_PERMS は、
原本ファイルとコピー先ファイルについて記述したタプルのリストを値として持ちます。
各タプルは、ファイル名のほか、両ファイルの所有者、所有グループと、
数字で表したパーミッションを、この順番で指定します。
たとえば以下のようになります。
REQD_FILES_PERMS+= ${PREFIX}/share/somefile ${VARBASE}/somefile ${ROOT_USER} ${ROOT_GROUP} 0700
両変数の違いは、PERMS
のつかない変数の違いとまったく同じです。
(個々のパッケージの) 設定ファイルは、パッケージに固有のディレクトリー
PKG_SYSCONFDIR にインストールされ、また、
インストール時には特別扱いが必要である (ほとんどのことは、pkginstall
で自動化されています) という点で、特別です。主に心がける必要があることは、
設定ファイルであるとされたファイルは、インストール時に、
そのファイルがもともと存在しなかった場合に限って、
正しい場所 (PKG_SYSCONFDIR
以下のどこか) に自動的にコピーされるということです。同様にして、
設定ファイルにローカルな変更が加わっている場合には、
アンインストール時に削除されません。こうすることで、
管理者が独自に変更をおこなっても、その変更が失われることがないようにしています。
前述のとおり、PKG_SYSCONFDIR
変数は設定ファイルのインストール先を指定します。この変数の値は、
以下の各変数をもとに設定されます。
PKG_SYSCONFBASE: 設定ディレクトリーのルートです。
指定しなかった場合は ${PREFIX}/etc となりますが、
利用者は好みの場所 (たとえば、
/etc, /etc/pkg など)
を指すよう上書きすることもできます。
パッケージがこの変数を直接使うことはできません。
PKG_SYSCONFSUBDIR: PKG_SYSCONFBASE
のサブディレクトリーで、
構築されたパッケージ用の設定ファイルはこの下に置かれます。
この変数は、パッケージの
Makefile で定義された場合にのみ意味を持ちます (つまり、
利用者がカスタマイズすることはできません)。
例としては、Apache のパッケージ
www/apache2 をご覧ください。Apache では、設定ファイルを
PKG_SYSCONFBASE のサブディレクトリー
httpd/ に置いています。この変数は、パッケージの
Makefile で設定します。
PKG_SYSCONFVAR: このパッケージの設定ディレクトリー
(PKG_SYSCONFBASE と異なる場合) を保持する変数の名前を指定します。
指定しなかった場合は、PKGBASE の値となります。
また、常に PKG_SYSCONFDIR が前につきます。
PKG_SYSCONFDIR.${PKG_SYSCONFVAR}:
PKG_SYSCONFVAR
で区別されるパッケージの設定ファイルをどのディレクトリーに置くかを保持します。
以上の各変数をもとに、pkginstall は PKG_SYSCONFDIR
の値を決めます。パッケージが設定ディレクトリーを参照するには、
この PKG_SYSCONFDIR 変数だけを使うことができます。
この値の設定に使われるアルゴリズムは、
基本的には以下のとおりです。
PKG_SYSCONFDIR.${PKG_SYSCONFVAR} が設定されている場合は、
この値が使われます。
前項の変数は定義されていないが、
PKG_SYSCONFSUBDIR がパッケージの
Makefile で設定されている場合は、
${PKG_SYSCONFBASE}/${PKG_SYSCONFSUBDIR} が使われます。
以上の場合以外は、
${PKG_SYSCONFBASE} に設定されます。
なお、${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 変数は当該パッケージに特有のものであって、
それ以外では意味を持たないことに注意してください。
システムの起動スクリプトは、OS ごとに決まった場所にインストールする必要があり、 その場所はたいていインストール用のプレフィックス以外の場所にある、という点で、 特別なファイルです。したがって、Section 15.1, “インストール用のプレフィックス以外の場所にあるファイルとディレクトリー”で説明したのと同じ方法を適用して、 同じ解決法を使うことができます。ただし、 pkginstall では起動スクリプトの処理専用の仕組みを用意しています。
システムの起動スクリプトが附属するパッケージでは、 以下のことをおこなう必要があります。
スクリプトに .sh サフィックスを付け加えて、
${FILESDIR} 内に置きます。例としては、
files ディレクトリーに cupsd.sh がある
print/cups パッケージをご覧ください。
スクリプト名から拡張子を抜いたものを RCD_SCRIPTS
変数に追加して、pkginstall がこのスクリプトを処理するようにします。
前出の例では以下のようになります。
RCD_SCRIPTS+= cupsd
以上のことをおこなえば、pkginstall は各スクリプトに対して、 以下の手順を自動的におこないます。
files ディレクトリー以下の各ファイルに対して、
FILES_SUBST
変数で示されている置換をすべて適用します。
スクリプトを、files ディレクトリーから examples
階層 ${PREFIX}/share/examples/rc.d/ にコピーします。
なお、この原本ファイルは、PLIST
に明示的に登録する必要があります。
起動スクリプトを examples 階層からシステム全体の起動スクリプト用ディレクトリーにコピーするためのコードを、 インストール用スクリプトに追加します。
パッケージのインストール時に、特別なユーザーやグループを作成する必要がある場合、 pkginstall の枠組を使って作成することができます。
PKG_USERS 変数にユーザーのエントリーを追加すると、
ユーザーを作ることができます。各エントリーは、
以下のような書式となります。
user:group
ユーザーごとに変数を設定して、
ユーザーの属性をさらに詳しく指定することができます。
PKG_UID. は、
ユーザーの数字の UID です。
userPKG_GECOS. は、
ユーザーの説明またはコメントです。
userPKG_HOME. は、
ユーザーのホームディレクトリーで、指定しなかった場合は
user/nonexistent
となります。
PKG_SHELL. は、
ユーザーのシェルで、指定しなかった場合は
user/sbin/nologin となります。
同様にして、PKG_GROUPS 変数にグループのエントリーを追加すると、
グループを作ることができます。こちらの書式は以下のようになります。
group
PKG_GID.
を定義すると、グループの数字の GID を設定することができます。group
もっと前の段階でユーザーやグループを作る必要がある場合は、
どの相の直後にユーザーやグループを作るかを表すために、
USERGROUP_PHASE を
configure または build に設定することができます。
こうした場合は、作られるユーザーやグループの数字の UID や GID は、
自動的に最終的なインストール用スクリプトにハードコードされます。
パッケージがシステムシェルをインストールする場合は、管理者の手間を減らせるよう、
インストールしたシェルをシェルデータベース /etc/shells
に登録するようにします。この登録は、どのシステム上でもバイナリーパッケージが機能するようにするため、
インストール用スクリプトでおこなう必要があります。pkginstall では、
このことを簡単に実現できる方法を用意しています。
パッケージがシェルインタープリターを提供する場合は、
PKG_SHELL 変数を、そのシェルの絶対ファイル名に設定する必要があります。
こうすると、インストール用スクリプトに、シェル登録処理用のフックを追加します。
shells/zsh から抜粋した例を以下に掲げますので、ご覧ください。
PKG_SHELL= ${PREFIX}/bin/zsh
X11 フォントをインストールするパッケージでは、 各フォントディレクトリー内のフォントの索引であるデータベースファイルを更新することが必要になります。 この更新は、pkginstall の枠組内で簡単におこなうことができます。
パッケージが X11 フォントをインストールする時には、
フォントをインストールするディレクトリーを、
FONTS_DIRS.
変数に列挙する必要があります。この typetype
は、“ttf”,
“type1”, “x11” のいずれかです。
こうすると、指定した各ディレクトリーのフォントデータベースファイルを更新するコマンドを実行するフックが、
インストール用スクリプトに追加されます。
利便のため、このディレクトリーのパスが相対パスで指定した場合は、
パッケージのインストール用プレフィックスからの相対位置として扱われるようになっています。fonts/dbz-ttf から抜粋した例を以下に掲げますので、ご覧ください。
FONTS_DIRS.ttf= ${PREFIX}/lib/X11/fonts/TTF