[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Documentation/pkgsrc/features/chapter.xml: 1.4 -> 1.5



以下のページの更新をしました。ツッコミをお願いします。

Documentation/pkgsrc/features/chapter.xml: 1.4 -> 1.5

月曜日までに異議がなければ、 commit します。

> revision 1.5
> date: 2003/05/24 04:59:06;  author: grant;  state: Exp;  lines: +166 -119
> add a bunch of markup

マークアップの変更のほか、以下の点が変更されています。

- NO_BIN_ON_FTP の説明で、ftp が FTP になった
- USE_PKGLOCALEDIR の説明で、"See also section 5.1" に XXX がついた

以下、訳と原文の差分です。

--- Documentation/pkgsrc/features/chapter.xml.orig	2006-03-25 22:59:53.000000000 +0900
+++ Documentation/pkgsrc/features/chapter.xml	2006-03-25 22:59:53.000000000 +0900
@@ -1,6 +1,6 @@
-<!-- $NetBSD: chapter.xml,v 1.4 2003/05/24 04:24:40 grant Exp $ -->
+<!-- $NetBSD: chapter.xml,v 1.5 2003/05/24 04:59:06 grant Exp $ -->
 <!-- Based on english version: -->
-<!-- NetBSD: chapter.xml,v 1.4 2003/05/24 04:24:40 grant Exp   -->
+<!-- NetBSD: chapter.xml,v 1.5 2003/05/24 04:59:06 grant Exp   -->
 
 <chapter id="features"> <?dbhtml filename="features.html"?>
 <title>FAQとパッケージシステムの特徴</title>
@@ -16,7 +16,7 @@
 <programlisting>GNU_CONFIGURE= yes</programlisting>
 
 <para>
-この設定がCONFIGURE_ARGSに--prefix=${PREFIX}を追加することに注意してくださ
+この設定が<varname>CONFIGURE_ARGS</varname>に<quote>--prefix=${PREFIX}</quote>を追加することに注意してくださ
 い。したがって、あなた自身でこれを追加する必要はありません。そして、これは
 あなたの望む設定とは異なるかもしれません。
 </para>
@@ -169,7 +169,7 @@
 <title>/etc/mk.confから変数を捕まえる方法</title>
 
 <para>
-MAKECONFや<filename>/etc/mk.conf</filename>で上書き可能な、パッケージで定義された変数には問題が
+<varname>MAKECONF</varname>や<filename>/etc/mk.conf</filename>で上書き可能な、パッケージで定義された変数には問題が
 あります。それは、変数はmake(1)がそれを使う時に展開されるが、プリプロセッサー
 風の文(.if、.ifdefそして.ifndef)は読み込み時に評価される事です。したがって、
 .if*文内で変数(<filename>/etc/mk.conf</filename>でセットされる可能性のある)を使う時は、その.if*
@@ -177,7 +177,7 @@
 </para>
 
 <para>
-<filename>/etc/mk.conf</filename>やMAKECONFが存在したら、それらをインクルードするというad-hocな
+<filename>/etc/mk.conf</filename>や<varname>MAKECONF</varname>が存在したら、それらをインクルードするというad-hocな
 方法をとらずに、すべてのプリプロセッサー風の.if、.ifdef、または.ifndef文の
 前で、<filename>pkgsrc/mk/bsd.prefs.mk</filename>をインクルードしてください。
 </para>
@@ -207,7 +207,7 @@
 
 <para>
 distfileの取得にどのユーティリティーを使っているかによります。<filename>bsd.pkg.mk</filename>は、
-以下のリストのなかで利用可能なコマンドのうち、最初のものをFETCH_CMDに割り当
+以下のリストのなかで利用可能なコマンドのうち、最初のものを<varname>FETCH_CMD</varname>に割り当
 てます:
 </para>
 
@@ -219,7 +219,8 @@
 NetBSDのデフォルトのインストールでは、<filename>/usr/bin/ftp</filename>となり、これは自動的に、
 最初はパッシブ接続を試みます。そして、サーバーがパッシブ接続を拒否した場合
 は、アクティブ接続に切り替わります。これ以外のツールの場合は、
-<filename>/etc/mk.conf</filename>に以下の設定を追加してください。PASSIVE_FETCH=1
+<filename>/etc/mk.conf</filename>に以下の設定を追加してください。
+<varname>PASSIVE_FETCH=1</varname>
 </para>
 
 <para>
@@ -235,21 +236,23 @@
 <para>
 パッケージは他のパッケージに依存するかもしれません。そして、この依存性を定
 義するためのいろいろな方法があります。NetBSDは、<filename>buildlink2.mk</filename>を使った依存関
-係(<xref linkend="buildlink2"/>参照)のほか、BUILD_DEPENDS、DEPENDS定義をサポートしています。
+係(<xref linkend="buildlink2"/>参照)のほか、
+<varname>BUILD_DEPENDS</varname>、<varname>DEPENDS</varname>定義をサポートしています。
 </para>
 
 <para>
-両定義の基本的な差異は、以下の通りです: DEPENDS定義では、その依存性がバイナ
-リーパッケージ内に記録されますが、BUILD_DEPENDS定義では記録されません。
+両定義の基本的な差異は、以下の通りです: <varname>DEPENDS</varname>定義では、その依存性がバイナ
+リーパッケージ内に記録されますが、<varname>BUILD_DEPENDS</varname>定義では記録されません。
 </para>
 
 <para>
 つまり、あるパッケージが必要となるのが構築時だけである場合、そのパッケージ
-はBUILD_DEPENDSとして書きます。
+は<varname>BUILD_DEPENDS</varname>として書きます。
 </para>
 
 <para>
-BUILD_DEPENDSおよびDEPENDS定義の書式は以下の通りです:
+<varname>BUILD_DEPENDS</varname>および
+<varname>DEPENDS</varname>定義の書式は以下の通りです:
 </para>
 
 <programlisting>&lt;pre-req-package-name&gt;:../../&lt;category&gt;/&lt;pre-req-package&gt;</programlisting>
@@ -263,7 +266,7 @@
 
 <listitem>
 <para>
-パッケージを構築するために他のパッケージが必要なら、BUILD_DEPENDS定義を
+パッケージを構築するために他のパッケージが必要なら、<varname>BUILD_DEPENDS</varname>定義を
 使ってください。
 </para>
 
@@ -272,8 +275,9 @@
 
 <listitem>
 <para>
-もし、パッケージがリンクのためのライブラリーを必要とするなら、DEPENDS定
-義を使ってください。たとえば、pkgsrc/print/lyxパッケージは、作成のためにxpm
+もし、パッケージがリンクのためのライブラリーを必要とするなら、<varname>DEPENDS</varname>定
+義を使ってください。たとえば、
+<pkg>print/lyx</pkg>パッケージは、作成のためにxpm
 ライブラリーのバージョン3.4jを使用します。
 </para>
 
@@ -293,7 +297,8 @@
 </para>
 
 <para>
-tk-postgresqlがtk-*というDEPENDにマッチするなどの曖昧なマッチの可能性を排除
+tk-postgresqlがtk-*という
+<varname>DEPENDS</varname>にマッチするなどの曖昧なマッチの可能性を排除
 するため、-*ではなく-[0-9]*を使うことをおすすめします。
 </para>
 </listitem>
@@ -301,7 +306,7 @@
 <listitem>
 <para>
 もし、パッケージを実行するために、いくつかの実行可能ファイルが必要なら、
-DEPENDS定義を使ってください。<pkg>print/lyx</pkg>パッケージを実行する時には、
+<varname>DEPENDS</varname>定義を使ってください。<pkg>print/lyx</pkg>パッケージを実行する時には、
 teTeXパッケージ由来のlatex のバイナリーが実行可能でなければなりません。これ
 は、以下のように指定します。
 </para>
@@ -337,7 +342,8 @@
 	cd ${_PKGSRCDIR}/../../graphics/jpeg &amp;&amp; ${MAKE} clean</programlisting>
 
 <para>
-また、便利に使うことができるBUILD_USES_MSGFMTおよびBUILD_USES_GETTEXT_M4定
+また、便利に使うことができる<varname>BUILD_USES_MSGFMT</varname>および
+<varname>BUILD_USES_GETTEXT_M4</varname>定
 義にも注意してください。前者は、基本システムにmsgfmt(1)があるかどうか調べて、
 ない場合は<pkg>devel/gettext</pkg>パッケージをインストールします。後者は、構築
 の際に、旧バージョンのgettextパッケージがインストールされていることに依存す
@@ -358,7 +364,7 @@
 
 <para>
 この場合、衝突するパッケージ(バージョン文字列を含む)のリストをスペースで区
-切ってCONFLICTSにセットすることができます。
+切って<varname>CONFLICTS</varname>にセットすることができます。
 </para>
 
 <para>
@@ -387,9 +393,10 @@
 <title>WWWホームページがあるソフトウェア</title>
 
 <para>
-NetBSDパッケージシステムは、HOMEPAGE変数をサポートしています。もし、パッケー
+NetBSDパッケージシステムは、
+<varname>HOMEPAGE</varname>変数をサポートしています。もし、パッケー
 ジ化されたソフトウェアのホームページが存在するのであれば、そのページのURLを
-MakefileのHOMEPAGE変数に設定します。この変数はMAINTAINER変数のすぐ後に定義
+Makefileの<varname>HOMEPAGE</varname>変数に設定します。この変数は<varname>MAINTAINER</varname>変数のすぐ後に定義
 してください。
 </para>
 </sect1>
@@ -422,7 +429,7 @@
 
 <para>
 このpkg_installパッケージの事例は、環境変数か<filename>/etc/mk.conf</filename>のどちらかで
-NOMAN=YESを設定して回避することもできます。
+<varname>NOMAN=YES</varname>を設定して回避することもできます。
 </para>
 </sect1>
 
@@ -432,9 +439,9 @@
 </title>
 
 <para>
-既存のパッケージに修正を加えたときに、PKGNAMEのバージョン番号を変えると便利
+既存のパッケージに修正を加えたときに、<varname>PKGNAME</varname>のバージョン番号を変えると便利
 な場合があります。元の作者による将来のバージョンと衝突しないようにするため、
-PKGREVISION=1 (2,. ..)を設定して、パッケージのバージョンに'nb1' ('nb2',
+<varname>PKGREVISION=1</varname> (2,. ..)を設定して、パッケージのバージョンに'nb1' ('nb2',
 ...)という接尾辞をつけることができます。この<quote>nb</quote>は、pkgツール群からは"."と
 同様の扱いを受けます。たとえば、
 </para>
@@ -443,11 +450,12 @@
 PKGREVISION=	9</programlisting>
 
 <para>
-とすると、PKGNAMEは<quote>foo-17.42nb9</quote>になります。
+とすると、<varname>PKGNAME</varname>は<quote>foo-17.42nb9</quote>になります。
 </para>
 
 <para>
-このパッケージの新しいリリース版が出た際には、PKGREVISIONは消してください。
+このパッケージの新しいリリース版が出た際には、
+<varname>PKGREVISION</varname>は消してください。
 たとえば、上で例示したパッケージの新しいマイナーリリースに際しては、以下の
 ようにします
 </para>
@@ -486,7 +494,7 @@
 <itemizedlist>
 
 <listitem>
-<para>RESTRICTED</para>
+<para><varname>RESTRICTED</varname></para>
 <para>
    なにか制限がある場合は常に、(制限の種類にかかわらず)この変数を設定します。
    この変数を、その制限の理由を含む文字列に設定してください。
@@ -494,45 +502,46 @@
 </listitem>
 
 <listitem> 
-<para>NO_BIN_ON_CDROM</para>
+<para><varname>NO_BIN_ON_CDROM</varname></para>
 <para>
    バイナリーをCD-ROMに収録してはいけません。バイナリーパッケージを
-   CD-ROMに含めることができない場合は常に、この変数を${RESTRICTED}に設定
+   CD-ROMに含めることができない場合は常に、この変数を<varname>${RESTRICTED}</varname>に設定
    してください。
 </para>
 </listitem>
 
 <listitem> 
-<para>NO_BIN_ON_FTP</para>
+<para><varname>NO_BIN_ON_FTP</varname></para>
 <para>
-   バイナリーをftpサーバーに置いてはいけません。バイナリーパッケージをイ
+   バイナリーをFTPサーバーに置いてはいけません。バイナリーパッケージをイ
    ンターネット上で公開することができない場合は常に、この変数を
-   ${RESTRICTED}に設定してください。
+   <varname>${RESTRICTED}</varname>に設定してください。
 </para>
 </listitem>
 
 <listitem>
-<para>NO_SRC_ON_CDROM</para>
+<para><varname>NO_SRC_ON_CDROM</varname></para>
 <para>
    distfileをCD-ROMに収録してはいけません。ソースコードやその他の
    distfileのCD-ROMによる再配布が許可されていない場合は、この変数を
-   ${RESTRICTED}に設定してください。
+   <varname>${RESTRICTED}</varname>に設定してください。
 </para>
 </listitem>
 
 <listitem> 
-<para>NO_SRC_ON_FTP</para>
+<para><varname>NO_SRC_ON_FTP</varname></para>
 <para>
    distfileをFTPに置いてはいけません。ソースコードやその他のdistfileのイ
    ンターネット経由での再配布が許可されていない場合は、この変数を
-   ${RESTRICTED}に設定してください。
+   <varname>${RESTRICTED}</varname>に設定してください。
 </para>
 </listitem>
 
 </itemizedlist>
 
 <para>
-NO_PACKAGE, IGNORE, NO_CDROMなど、制限を意味する上記以外の汎用make変数は使
+<varname>NO_PACKAGE</varname>,
+<varname>IGNORE</varname>, <varname>NO_CDROM</varname> など、制限を意味する上記以外の汎用make変数は使
 わないようにしてください。これらは、ユーザーのバイナリーパッケージ作成を、
 無条件にできないようにするからです。
 </para>
@@ -548,10 +557,12 @@
 </para>
 
 <para>
-パッケージのMakefileで<filename>../../devel/ncurses/buildlink2.mk</filename>をインクルードすると、
+パッケージの<filename>Makefile</filename>で
+<filename>../../devel/ncurses/buildlink2.mk</filename>をインクルードすると、
 pre-configure時に、cursesライブラリーとncurses機能用のヘッダーが
-${BUILDLINK_DIR}内にリンクされます。ncursesが本当に必要な場合は、パッケージ
-のMakefileでUSE_NCURSESを定義してください。
+<varname>${BUILDLINK_DIR}</varname>内にリンクされます。ncursesが本当に必要な場合は、パッケージ
+の<filename>Makefile</filename>で
+<varname>USE_NCURSES</varname>を定義してください。
 </para>
 </sect1>
 
@@ -637,9 +648,10 @@
 
 <para>
 パッケージ特有のグループやユーザーをpre-install時に作成するよう制御するため、
-二つのmake変数があります。一つ目はPKG_GROUPSで、group[:groupid]という要素
+二つのmake変数があります。一つ目は
+<varname>PKG_GROUPS</varname>で、group[:groupid]という要素
 (グループIDはあってもなくてもかまいません)を列挙したものです。二つ目は
-PKG_USERSで、以下のような形式の要素を列挙したものです:
+<varname>PKG_USERS</varname>で、以下のような形式の要素を列挙したものです:
 </para>
 
 <programlisting>user:group[:[userid][:[description][:[home][:shell]]]]</programlisting>
@@ -663,7 +675,9 @@
 
 <para>
 ユーザーのホームディレクトリーやログインシェルを指定しなかった場合の、デフォ
-ルトのホームディレクトリーは/nonexistent、ログインシェルは/sbin/nologinです。
+ルトのホームディレクトリーは
+<filename>/nonexistent</filename>、ログインシェルは
+<filename>/sbin/nologin</filename>です。
 </para>
 
 <para>
@@ -671,7 +685,7 @@
 ドする前に<filename>../../mk/bsd.pkg.install.mk</filename>をインクルードする必要があります。こ
 れにより、pre-install時にユーザーとグループが作成されるようになり、
 post-deinstall時にはこのユーザーとグループの削除を管理者に促すようになりま
-す。パッケージのインストールの前に環境変数 PKG_CREATE_USERGROUPをonかoffに
+す。パッケージのインストールの前に環境変数 <varname>PKG_CREATE_USERGROUP</varname>をonかoffに
 設定しておくと、ユーザーとグループを自動で作成するかどうかを切替えることが
 できます。
 </para>
@@ -689,7 +703,8 @@
 </para>
 
 <para>
-たいていは、回避策として、MACHINE_ARCHとコンパイラーのバージョンを確認し、
+たいていは、回避策として、<varname>MACHINE_ARCH</varname>
+とコンパイラーのバージョンを確認し、
 問題のあるファイル/MACHINE_ARCH/コンパイラーの組合せに対して最適化を無効に
 し、そのことを<filename>doc/HACKS</filename>に文書化しておくことが必要となります。例については
 <filename>doc/HACKS</filename>を参照してください。
@@ -701,13 +716,13 @@
 <title>infoファイルが附属するパッケージ</title>
 
 <para>
-パッケージによっては、infoファイルをインストールしたり、makeinfoまたは
-install-infoコマンドを使ったりします。この場合、パッケージのMakefileで、
+パッケージによっては、infoファイルをインストールしたり、<command>makeinfo</command>または
+<command>install-info</command>コマンドを使ったりします。この場合、パッケージの<filename>Makefile</filename>で、
 <filename>mk/bsd.pkg.mk</filename>をインクルードする前に、makefileの断片<filename>mk/texinfo.mk</filename>をインクルー
 ドする必要があります。texinfoの新しいバージョン(バージョン4以上)は、困った
 ことに、それより前のバージョンとコマンド行のレベルで互換性がありません。ま
 た、TeXinfoマクロセットに拡張がいくつか導入されています。このため、パッケー
-ジ作者は、シェルのPATH変数の内容に依存したりせずに、適切なバイナリーが選ば
+ジ作者は、シェルの<varname>PATH</varname>変数の内容に依存したりせずに、適切なバイナリーが選ば
 れるようにしてください。
 </para>
 
@@ -715,7 +730,9 @@
 主たるinfoディレクトリーファイルは、infoファイルがインストールされたことを
 反映するために更新する必要があります。パッケージによっては、インストール過
 程でこの更新をおこなってくれます。そうしてくれないパッケージでは、NetBSDパッ
-ケージコレクションのINFO_FILES定義を、この更新用に使うことができます。パッ
+ケージコレクションの
+<varname>INFO_FILES</varname>
+定義を、この更新用に使うことができます。パッ
 ケージのMakefileで、
 </para>
 
@@ -728,7 +745,8 @@
 
 <para>
 パッケージ作者は、パッケージの構築とインストールのプロセスが、適切なバージョ
-ンのmakeinfoおよびinstall-infoコマンドを使うようにするよう、注意を払ってく
+ンの<command>makeinfo</command>および
+<command>install-info</command>コマンドを使うようにするよう、注意を払ってく
 ださい。最近のソフトウェアパッケージに附属するMakefilesやconfigureスクリプ
 トのなかには、<quote>makeinfo</quote>および<quote>install-info</quote>コマンドへのパス名を含めているもの
 があります。残念ながら、古いソフトウェアパッケージは、そのようにはしない傾
@@ -744,12 +762,12 @@
 
 <para>
 あるバージョン以上の<quote>makeinfo</quote>および<quote>install-info</quote>コマンドが必要な場合は、パッ
-ケージのMakefileで、 TEXINFO_REQDを必要な最低バージョンに設定します。
+ケージのMakefileで、 <varname>TEXINFO_REQD</varname>を必要な最低バージョンに設定します。
 </para>
 
 <para>
 パッケージが適切な挙動をしない(つまり、configureやbuildの際に環境変数
-MAKEINFOやINSTALL_INFOを参照しない) 場合は、以下のいずれか適切な方をおこな
+<varname>MAKEINFO</varname>や<varname>INSTALL_INFO</varname>を参照しない) 場合は、以下のいずれか適切な方をおこな
 うようにします:
 </para>
 
@@ -758,15 +776,17 @@
 <listitem>
 <para>
     パッケージのファイルにパッチを当てて、configureやbuildの際に、makeinfo
-    やinstall-infoがPATH中にあることを前提にするのではなく、環境変数
-    MAKEINFOやINSTALL_INFOを使うようにする;
+    やinstall-infoが
+    <varname>PATH</varname>中にあることを前提にするのではなく、環境変数
+    <varname>MAKEINFO</varname>や
+    <varname>INSTALL_INFO</varname>を使うようにする;
 </para>
 </listitem>
 
 <listitem>
 <para>
-    パッケージのMakefileにTEXINFO_OVERRIDE=YESを書いておき、パッケージのソー
-    スファイルの内容を置換するようにする(mk/texinfo.mkの内容を参考にしてく
+    パッケージのMakefileに<varname>TEXINFO_OVERRIDE=YES</varname>を書いておき、パッケージのソー
+    スファイルの内容を置換するようにする(<filename>mk/texinfo.mk</filename>の内容を参考にしてく
     ださい)。
 </para>
 </listitem>
@@ -779,7 +799,9 @@
 <title>distfileのダウンロードが単純にできないパッケージ</title>
 
 <para>
-動的なURLからダウンロードする必要がある場合は、DYNAMIC_MASTER_SITESを設定す
+動的なURLからダウンロードする必要がある場合は、
+<varname>DYNAMIC_MASTER_SITES</varname>
+を設定す
 ることができます。すると、<command>make fetch</command>は、ダウンロードすべき各ファイルを引
 数として<filename>files/getsite.sh</filename>を呼び出します。このスクリプトは、ファイルをダウン
 ロードするディレクトリーのURLを出力することが前提となっています。
@@ -789,9 +811,10 @@
 <para>
 パスワード用に個人情報の登録が必要だったり、ソースに代金を払う必要があった
 り、その他もろもろの理由により、ダウンロードが自動化できない場合は、
-_FETCH_MESSAGEに、説明文を表示するマクロを設定することができます。
-_FETCH_MESSAGEは、説明文そのものではなく、実行可能なシェルコマンドである必
-要があります。(一般的には、${ECHO}を実行します)。本稿執筆時点で、この方法を
+<varname>_FETCH_MESSAGE</varname>に、説明文を表示するマクロを設定することができます。
+<varname>_FETCH_MESSAGE</varname>は、説明文そのものではなく、実行可能なシェルコマンドである必
+要があります。(一般的には、
+<varname>${ECHO}</varname>を実行します)。本稿執筆時点で、この方法を
 使っているパッケージは、<pkg>audio/realplayer</pkg>,
 <pkg>cad/simian</pkg>, <pkg>devel/ipv6socket</pkg>,
 <pkg>emulators/vmare-module</pkg>,
@@ -805,17 +828,19 @@
 <title>設定ファイルの処理および配置</title>
 
 <para>
-大域変数PKG_SYSCONFBASE(とその他の変数)を、システム管理者が<filename>/etc/mk.conf</filename>で設
+大域変数<varname>PKG_SYSCONFBASE</varname>(とその他の変数)を、
+システム管理者が<filename>/etc/mk.conf</filename>で設
 定すると、設定ファイルのインストール場所を定義することができます。このため、
 各パッケージはこの機能に対応する必要があります。この変数で定義される設定ファ
 イル用ディレクトリーには、本当に必要なファイルだけをインストールするようにし、
-$PREFIX/shareに置いてもよいファイルはそちらにインストールするよう
+<filename>$PREFIX/share</filename>に置いてもよいファイルはそちらにインストールするよう
 注意してください。
 </para>
 
 <para>
 まず、利用可能な変数をお見せします(<filename>bsd.pkg.mk</filename>に、さらに詳しい情報があります)。
-PKG_SYSCONFDIRが、パッケージの設定ファイルが置かれる場所になります(これはフ
+<varname>PKG_SYSCONFDIR</varname>が、
+パッケージの設定ファイルが置かれる場所になります(これはフ
 ルパスです。たとえば、<filename>/etc</filename>や<filename>/usr/pkg/etc</filename>になります)。この変数値は、さまざま
 な方法によってカスタマイズすることができます:
 </para>
@@ -824,17 +849,18 @@
 
 <listitem>
 <para>
-    PKG_SYSCONFBASEは主たる設定ディレクトリーで、パッケージ用の設定ファイル
+    <varname>PKG_SYSCONFBASE</varname>は主たる設定ディレクトリーで、パッケージ用の設定ファイル
     すべてがこれ以下に置かれます。ユーザーは普通はPKG_SYSCONFBASEを/etcに設
-    定するか、デフォルトの場所の${PREFIX}/etcのままにするでしょう。
+    定するか、デフォルトの場所の
+    <filename>$PREFIX/etc</filename>のままにするでしょう。
 </para>
 </listitem>
 
 <listitem>
 <para>
-    PKG_SYSCONFSUBDIRは
-    PKG_SYSCONFBASEのサブディレクトリーで、個々のパッケージ用の設定ファイ
-    ルはこの下に置かれます。デフォルトでは$SYSCONFBASEになります。
+    <varname>PKG_SYSCONFSUBDIR</varname> は
+    <varname>PKG_SYSCONFBASE</varname> のサブディレクトリーで、個々のパッケージ用の設定ファイ
+    ルはこの下に置かれます。デフォルトでは<varname>${SYSCONFBASE}</varname>になります。
 </para>
 </listitem>
 
@@ -850,14 +876,16 @@
 
 <listitem>
 <para>
-    PKG_SYSCONFDIR.${PKG_SYSCONFVAR}は、同じPKG_SYSCONFVARを持つパッケージ
-    の${PKG_SYSCONFDIR}を上書きします。
+    <varname>PKG_SYSCONFDIR.${PKG_SYSCONFVAR}</varname>は、同じ<varname>PKG_SYSCONFVAR</varname>を持つパッケージ
+    の
+    <varname>${PKG_SYSCONFDIR}</varname>を上書きします。
 </para>
 
 <para>
-    たとえば、KDE関連の各パッケージでは、PKG_SYSCONFVARを"kde"に設定すると
+    たとえば、KDE関連の各パッケージでは、
+    <varname>PKG_SYSCONFVAR</varname>を<quote>kde</quote>に設定すると
     よいでしょう。こうしておくと、管理者が<filename>/etc/mk.conf</filename>で
-    ${PKG_SYSCONFDIR.kde}を設定して、KDEの設定ファイルのインストール場所を
+    <varname>PKG_SYSCONFDIR.kde</varname>を設定して、KDEの設定ファイルのインストール場所を
     定義できるようになります。
 </para>
 </listitem>
@@ -866,25 +894,30 @@
 
 <para>
 プログラムの設定ディレクトリーは、configureの段階で定義します。GNU autoconf
-を使うパッケージでは、通常は--sysconfdirのパラメーターを使って定義すること
+を使うパッケージでは、通常は
+<quote>--sysconfdir</quote>のパラメーターを使って定義すること
 ができますが、この方法は問題を起こすことがわかっています。このパス名をパッ
 ケージ側で変更する場合は、ファイルをディレクトリーに直接インストールしない
-ようにします。そうするかわりに、ファイルをshare/examples/${PKGNAME}以下にイ
-ンストールして、PLISTにそちらを登録できるようにする必要があります。
+ようにします。そうするかわりに、ファイルを<filename>share/examples/${PKGNAME}</filename>以下にイ
+ンストールして、
+<filename>PLIST</filename>にそちらを登録できるようにする必要があります。
 </para>
 
 <para>
 必要な設定ファイルを適切な場所(<filename>share/examples</filename>ディレクトリー以下)に一旦置い
-てから、この設定ファイルをPKG_SYSCONFDIRにコピーするために、CONF_FILES変数
+てから、この設定ファイルを<varname>PKG_SYSCONFDIR</varname>にコピーするために、
+<varname>CONF_FILES</varname>変数
 を設定します。この変数の値は、ファイル名を二個組み合わせたものを並べたもの
-です; 組合せの一つ目で、examplesディレクトリー内のファイル(PLISTに登録され
+です; 組合せの一つ目で、examplesディレクトリー内のファイル(<filename>PLIST</filename>に登録され
 ているもの)を指定し、二つ目で、それをコピーする先のファイルを指定します。こ
-れにより、バイナリーパッケージが、自動生成されるINSTALL/DEINSTALLスクリプト
+れにより、バイナリーパッケージが、自動生成される
+<filename>INSTALL</filename>/<filename>DEINSTALL</filename>スクリプト
 を使って、ファイルを正しいディレクトリーに配置することが可能になります。ま
-た、この自動生成されるスクリプトを使うために、パッケージのMakefileで
+た、この自動生成されるスクリプトを使うために、パッケージの<filename>Makefile</filename>で
 <filename>bsd.pkg.mk</filename>をインクルードする前に<filename>../../mk/bsd.pkg.install.mk</filename>をインクルード
 しなければなりません。設定ファイルの自動コピーは、パッケージをインストール
-する前に環境変数PKG_CONFIGを設定しておくことで、おこなうかどうかを切替える
+する前に環境変数
+<varname>PKG_CONFIG</varname>を設定しておくことで、おこなうかどうかを切替える
 ことができます。
 </para>
 
@@ -896,8 +929,11 @@
 CONF_FILES=	${EGDIR}/Muttrc ${PKG_SYSCONFDIR}/Muttrc</programlisting>
 
 <para>
-ご覧のとおり、このパッケージは設定ファイルをEGDIRにインストールし、この場所
-がPLISTに登録されます。その後、CONF_FILES変数に、はじめにインストールされた
+ご覧のとおり、このパッケージは設定ファイルを
+<varname>EGDIR</varname>にインストールし、この場所
+が
+<filename>PLIST</filename>に登録されます。その後、
+<varname>CONF_FILES</varname>変数に、はじめにインストールされた
 ファイルと、そのコピー先ファイルを列挙します。ファイルがこの方法でインストー
 ルされる時には、パッケージの利用者にメッセージを自動的に表示します。
 </para>
@@ -908,9 +944,12 @@
 <title>ログインシェルを提供するパッケージ</title>
 
 <para>
-パッケージの目的がログインシェルの提供である場合は、PKG_SHELL変数を、このパッ
+パッケージの目的がログインシェルの提供である場合は、
+<varname>PKG_SHELL</varname>変数を、このパッ
 ケージでインストールされるシェルの実行ファイルのフルパス名とします。また、
-自動生成されるINSTALL/DEINSTALLスクリプトを使うために、パッケージのMakefile
+自動生成される
+<filename>INSTALL</filename>/<filename>DEINSTALL</filename>スクリプトを使うために、パッケージの
+<filename>Makefile</filename>
 で、<filename>bsd.pkg.mk</filename>をインクルードする前に、
 <filename>../../mk/bsd.pkg.install.mk</filename>をインクルードする必要も
 あります。
@@ -925,9 +964,9 @@
 
 <para>
 インストールされたシェルは、post-installの段階で、
-bsd.pkg.install.mkが生成したINSTALLスク
+<filename>bsd.pkg.install.mk</filename>が生成した<filename>INSTALL</filename>スク
 リプトによって自動的に<filename>/etc/shells</filename>ファイルに登録されます。また、deinstallの
-段階で、DEINSTALLスクリプトによって<filename>/etc/shells</filename>から削除されます。
+段階で、<filename>DEINSTALL</filename>スクリプトによって<filename>/etc/shells</filename>から削除されます。
 </para>
 </sect1>
 
@@ -937,9 +976,9 @@
 
 <para>
 パッケージに、そのパッケージ用のロケールのカタログが附属する場合は、変数
-USE_PKGLOCALEDIRを定義します。これにより、パッケージのMakefile雛型ファイル
+<varname>USE_PKGLOCALEDIR</varname>を定義します。これにより、パッケージの<filename>Makefile</filename>雛型ファイル
 が必要に応じて修正され、適切なロケールディレクトリー(OSにより異なることがあ
-ります)を使うようになります。${PKGLOCALEDIR}に関して詳しくは、5.1節も参照し
+ります)を使うようになります。<varname>PKGLOCALEDIR</varname>に関して詳しくは、5.1節 XXX も参照し
 てください。この機能はbuildlink2限定です。
 </para>
 </sect1>
@@ -967,8 +1006,8 @@
 <para>
 perlスクリプトがパッケージに含まれる場合は、
 インタープリターのパスが適切に設定されるようにするために、
-REPLACE_PERLを設定します。
-REPLACE_PERLの設定値は、調整の対象となるスクリプトをWRKSRCからの相対位置で列挙したものにします。
+<varname>REPLACE_PERL</varname>を設定します。
+<varname>REPLACE_PERL</varname>の設定値は、調整の対象となるスクリプトを<varname>WRKSRC</varname>からの相対位置で列挙したものにします。
 </para>
 </sect1>
 
@@ -979,16 +1018,17 @@
 <para>
 環境によってはパッケージを構築しないよう指示するような理由がいくつかありま
 す。パッケージが、ほとんどのプラットフォームで構築および実行できる場合は、
-NOT_FOR_PLATFORMとして例外を記述します。逆に、パッケージが一部のプラットフォー
-ムでしか構築および実行できない場合は、ONLY_FOR_PLATFORMを設定します。パッケー
+<varname>NOT_FOR_PLATFORM</varname>として例外を記述します。逆に、パッケージが一部のプラットフォー
+ムでしか構築および実行できない場合は、<varname>ONLY_FOR_PLATFORM</varname>を設定します。パッケー
 ジをとばすべき場合(たとえば、そのパッケージが提供する機能が、すでにシステム
-で提供されている場合)は、PKG_SKIP_REASONにそのことを説明するメッセージを設
+で提供されている場合)は、
+<varname>PKG_SKIP_REASON</varname>にそのことを説明するメッセージを設
 定します。必要な条件が満たされていないせいでパッケージの構築が失敗するであ
-ろう場合は、PKG_FAIL_REASONにそのことを説明するメッセージを設定します。
+ろう場合は、<varname>PKG_FAIL_REASON</varname>にそのことを説明するメッセージを設定します。
 </para>
 
 <para>
-IGNOREは、構築失敗の理由を特定するために十分な情報を提供しないので、使わな
+<varname>IGNORE</varname>は、構築失敗の理由を特定するために十分な情報を提供しないので、使わな
 いでください。
 </para>
 </sect1>
Index: Documentation/pkgsrc/features/chapter.xml
===================================================================
RCS file: /cvsroot/htdocs/Documentation/pkgsrc/features/Attic/chapter.xml,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- Documentation/pkgsrc/features/chapter.xml	24 May 2003 04:24:40 -0000	1.4
+++ Documentation/pkgsrc/features/chapter.xml	24 May 2003 04:59:06 -0000	1.5
@@ -1,4 +1,4 @@
-<!-- $NetBSD: chapter.xml,v 1.4 2003/05/24 04:24:40 grant Exp $ -->
+<!-- $NetBSD: chapter.xml,v 1.5 2003/05/24 04:59:06 grant Exp $ -->
 
 <chapter id="features"> <?dbhtml filename="features.html"?>
 <title>FAQs &amp; features of the package system</title>
@@ -14,7 +14,8 @@
 <programlisting>GNU_CONFIGURE= yes</programlisting>
 
 <para>
-Note that this appends --prefix=${PREFIX} to CONFIGURE_ARGS, so you don't
+Note that this appends <quote>--prefix=${PREFIX}</quote> to
+<varname>CONFIGURE_ARGS</varname>, so you don't
 have to do that yourself, and this may not be what you want.
 </para>
 </sect1>
@@ -171,7 +172,7 @@
 
 <para>
 The problem with package-defined variables that can be overridden via
-MAKECONF or <filename>/etc/mk.conf</filename> is that make(1) expands a variable as it is
+<varname>MAKECONF</varname> or <filename>/etc/mk.conf</filename> is that make(1) expands a variable as it is
 used, but evaluates preprocessor like statements (.if, .ifdef and
 .ifndef) as they are read.  So, to use any variable (which may be set
 in <filename>/etc/mk.conf</filename>) in one of the .if* statements, the file
@@ -182,7 +183,7 @@
 <para>
 Rather than have a number of ad-hoc ways of including
 <filename>/etc/mk.conf</filename>,
-should it exist, or MAKECONF, should it exist, include the
+should it exist, or <varname>MAKECONF</varname>, should it exist, include the
 <filename>pkgsrc/mk/bsd.prefs.mk</filename> file in the package Makefile before any
 preprocessor-like .if, .ifdef, or .ifndef statements:
 </para>
@@ -212,8 +213,8 @@
 
 <para>
 This depends on which utility is used to retrieve distfiles. From
-<filename>bsd.pkg.mk</filename>, FETCH_CMD is assigned the first available command from the
-following list:
+<filename>bsd.pkg.mk</filename>, <varname>FETCH_CMD</varname> is assigned
+the first available command from the following list:
 </para>
 
 <programlisting>/usr/bin/fetch
@@ -225,7 +226,8 @@
 <filename>/usr/bin/ftp</filename>, which automatically
 tries passive connections first, and falls back to active connections if the
 server refuses to do passive. For the other tools, add the following to your
-<filename>/etc/mk.conf</filename> file: PASSIVE_FETCH=1
+<filename>/etc/mk.conf</filename> file:
+<varname>PASSIVE_FETCH=1</varname>.
 </para>
 
 <para>
@@ -242,23 +244,25 @@
 <para>
 Your package may depend on some other package being present - and there are
 various ways of expressing this dependency. NetBSD supports the
-BUILD_DEPENDS and DEPENDS definitions, as well as dependencies via
+<varname>BUILD_DEPENDS</varname> and <varname>DEPENDS</varname> definitions,
+as well as dependencies via
 <filename>buildlink2.mk</filename> (see <xref linkend="buildlink2"/>).
 </para>
 
 <para>
 The basic difference between the two definitions is as follows: The
-DEPENDS definition registers that pre-requisite in the binary package,
-whilst the BUILD_DEPENDS definition does not.
+<varname>DEPENDS</varname> definition registers that pre-requisite in the binary package,
+whilst the <varname>BUILD_DEPENDS</varname> definition does not.
 </para>
 
 <para>
 This means that if you only need a package present whilst you are building,
-it should be noted as a BUILD_DEPENDS.
+it should be noted as a <varname>BUILD_DEPENDS</varname>.
 </para>
 
 <para>
-The format for a BUILD_DEPENDS and a DEPENDS definition is:
+The format for a <varname>BUILD_DEPENDS</varname> and a
+<varname>DEPENDS</varname> definition is:
 </para>
 
 <programlisting>&lt;pre-req-package-name&gt;:../../&lt;category&gt;/&lt;pre-req-package&gt;</programlisting>
@@ -273,7 +277,7 @@
 <listitem>
 <para>
 If your package needs to use another package to build itself, this
-is specified using the BUILD_DEPENDS definition.
+is specified using the <varname>BUILD_DEPENDS</varname> definition.
 </para>
 
 <programlisting>BUILD_DEPENDS+=  autoconf-2.13:../../devel/autoconf</programlisting>
@@ -282,7 +286,8 @@
 <listitem>
 <para>
 If your package needs a library with which to link, this is specified
-using the DEPENDS definition.  An example of this is the pkgsrc/print/lyx
+using the <varname>DEPENDS</varname> definition.  An example of this is
+the <pkg>print/lyx</pkg>
 package, which uses the xpm library, version 3.4j to build.
 </para>
 
@@ -303,14 +308,15 @@
 
 <para>
 The -[0-9]* should be used instead of -* to avoid potentially
-ambiguous matches such as tk-postgresql matching a tk-* DEPEND.
+ambiguous matches such as tk-postgresql matching a tk-*
+<varname>DEPENDS</varname>.
 </para>
 </listitem>
 
 <listitem>
 <para>
 If your package needs some executable to be able to run correctly, this
-is specified using the DEPENDS definition. The
+is specified using the <varname>DEPENDS</varname> definition. The
 <pkg>print/lyx</pkg> package needs
 to be able to execute the latex binary from the teTeX package when it runs,
 and that is specified:
@@ -348,7 +354,8 @@
 	cd ${_PKGSRCDIR}/../../graphics/jpeg &amp;&amp; ${MAKE} clean</programlisting>
 
 <para>
-Please also note the BUILD_USES_MSGFMT and BUILD_USES_GETTEXT_M4 definitions,
+Please also note the <varname>BUILD_USES_MSGFMT</varname> and
+<varname>BUILD_USES_GETTEXT_M4</varname> definitions,
 which are provided as convenience definitions.  The former works out whether
 msgfmt(1) is part of the base system, and, if it isn't, installs the
 <pkg>devel/gettext</pkg> package.  The latter adds a build dependency on either an
@@ -368,8 +375,8 @@
 </para>
 
 <para>
-In this case you can set CONFLICTS to a space separated list of packages
-(including version string) your package conflicts with.
+In this case you can set <varname>CONFLICTS</varname> to a space separated
+list of packages (including version string) your package conflicts with.
 </para>
 
 <para>
@@ -399,11 +406,12 @@
 <title>Software which has a WWW Home Page</title>
 
 <para>
-The NetBSD packages system now supports a variable called HOMEPAGE.
+The NetBSD packages system now supports a variable called
+<varname>HOMEPAGE</varname>.
 If the software being packaged has a home page, the Makefile should
-include the URL for that page in the HOMEPAGE variable. The definition
-of the variable should be placed immediately after the MAINTAINER
-variable.
+include the URL for that page in the <varname>HOMEPAGE</varname> variable.
+The definition of the variable should be placed immediately after the
+<varname>MAINTAINER</varname> variable.
 </para>
 </sect1>
 
@@ -438,7 +446,7 @@
 
 <para>
 In the case of the pkg_install package, you can get away with setting
-NOMAN=YES either in the environment or in
+<varname>NOMAN=YES</varname> either in the environment or in
 <filename>/etc/mk.conf</filename>.
 </para>
 </sect1>
@@ -450,21 +458,23 @@
 
 <para>
 When making fixes to an existing package it can be useful to change
-the version number in PKGNAME. To avoid conflicting with future versions
+the version number in <varname>PKGNAME</varname>. To avoid conflicting with
+future versions
 by the original author, a 'nb1' ('nb2', ...) suffix can be used on package
-versions by setting PKGREVISION=1 (2,. ..). The <quote>nb</quote> is treated like a "."
-by the pkg tools. E.g.
+versions by setting <varname>PKGREVISION=1</varname> (2,. ..). The
+<quote>nb</quote> is treated like a "." by the pkg tools. E.g.
 </para>
 
 <programlisting>DISTNAME=	foo-17.42
 PKGREVISION=	9</programlisting>
 
 <para>
-will result in a PKGNAME of <quote>foo-17.42nb9</quote>.
+will result in a <varname>PKGNAME</varname> of <quote>foo-17.42nb9</quote>.
 </para>
 
 <para>
-When a new release of the package is released, the PKGREVISION should be
+When a new release of the package is released, the
+<varname>PKGREVISION</varname> should be
 removed. e.g. on a new minor release of the above package, things should
 be like:
 </para>
@@ -503,7 +513,7 @@
 <itemizedlist>
 
 <listitem>
-<para>RESTRICTED</para>
+<para><varname>RESTRICTED</varname></para>
 <para>
    This variable should be set whenever a restriction exists
    (regardless of its kind).  Set this variable to a string
@@ -512,45 +522,46 @@
 </listitem>
 
 <listitem> 
-<para>NO_BIN_ON_CDROM</para>
+<para><varname>NO_BIN_ON_CDROM</varname></para>
 <para>
    Binaries may not be placed on CD-ROM.  Set this variable to
-   ${RESTRICTED} whenever a binary package may not be included
-   on a CD-ROM.
+   <varname>${RESTRICTED}</varname> whenever a binary package may not
+   be included on a CD-ROM.
 </para>
 </listitem>
 
 <listitem> 
-<para>NO_BIN_ON_FTP</para>
+<para><varname>NO_BIN_ON_FTP</varname></para>
 <para>
-   Binaries may not be placed on an ftp server.  Set this
-   variable to ${RESTRICTED} whenever a binary package may not
-   not be made available on the Internet.
+   Binaries may not be placed on an FTP server.  Set this
+   variable to <varname>${RESTRICTED}</varname> whenever a binary package
+   may not not be made available on the Internet.
 </para>
 </listitem>
 
 <listitem>
-<para>NO_SRC_ON_CDROM</para>
+<para><varname>NO_SRC_ON_CDROM</varname></para>
 <para>
    Distfiles may not be placed on CD-ROM.  Set this variable to
-   ${RESTRICTED} if re-distribution of the source code or other
-   distfile(s) is not allowed on CD-ROMs.
+   <varname>${RESTRICTED}</varname> if re-distribution of the source code
+   or other distfile(s) is not allowed on CD-ROMs.
 </para>
 </listitem>
 
 <listitem> 
-<para>NO_SRC_ON_FTP</para>
+<para><varname>NO_SRC_ON_FTP</varname></para>
 <para>
    Distfiles may not be placed on FTP.  Set this variable to
-   ${RESTRICTED} if re-distribution of the source code or other
-   distfile(s) via the Internet is not allowed.
+   <varname>${RESTRICTED}</varname> if re-distribution of the source
+   code or other distfile(s) via the Internet is not allowed.
 </para>
 </listitem>
 
 </itemizedlist>
 
 <para>
-Please note that the use of NO_PACKAGE, IGNORE, NO_CDROM, or other generic
+Please note that the use of <varname>NO_PACKAGE</varname>,
+<varname>IGNORE</varname>, <varname>NO_CDROM</varname>, or other generic
 make variables to denote restrictions is deprecated, because they
 unconditionally prevent users from generating binary packages!
 </para>
@@ -566,10 +577,12 @@
 </para>
 
 <para>
-If <filename>../../devel/ncurses/buildlink2.mk</filename> is included in a package's Makefile,
+If <filename>../../devel/ncurses/buildlink2.mk</filename> is included in
+a package's <filename>Makefile</filename>,
 then a curses library and headers with ncurses functionality are linked
-into ${BUILDLINK_DIR} at pre-configure time.  If ncurses is actually
-required, then define USE_NCURSES in the package's Makefile.
+into <varname>${BUILDLINK_DIR}</varname> at pre-configure time.  If
+ncurses is actually required, then define <varname>USE_NCURSES</varname>
+in the package's <filename>Makefile</filename>.
 </para>
 </sect1>
 
@@ -657,9 +670,10 @@
 
 <para>
 There are two make variables used to control the creation of package-specific
-groups and users at pre-install time.  The first is PKG_GROUPS, which is a
+groups and users at pre-install time.  The first is
+<varname>PKG_GROUPS</varname>, which is a
 list of group[:groupid] elements, where the groupid is optional.  The second
-is PKG_USERS, which is a list of elements of the form:
+is <varname>PKG_USERS</varname>, which is a list of elements of the form:
 </para>
 
 <programlisting>user:group[:[userid][:[description][:[home][:shell]]]]</programlisting>
@@ -681,8 +695,10 @@
 		second:group2::Second\\ User:/home/second:${SH}</programlisting>
 
 <para>
-By default, a new user will have home directory /nonexistent, and login shell
-/sbin/nologin unless they are specified as part of the user element.
+By default, a new user will have home directory
+<filename>/nonexistent</filename>, and login shell
+<filename>/sbin/nologin</filename> unless they are specified as part of
+the user element.
 </para>
 
 <para>
@@ -691,8 +707,8 @@
 the inclusion of <filename>bsd.pkg.mk</filename>.  This will cause the users and groups to be
 created at pre-install time, and the admin will be prompted to remove them at
 post-deinstall time.  Automatic creation of the users and groups can be
-toggled on and off by setting the environment variable PKG_CREATE_USERGROUP
-prior to package installation.
+toggled on and off by setting the environment variable
+<varname>PKG_CREATE_USERGROUP</varname> prior to package installation.
 </para>
 </sect1>
 
@@ -708,7 +724,8 @@
 </para>
 
 <para>
-Typically a workaround involves testing the MACHINE_ARCH and compiler
+Typically a workaround involves testing the <varname>MACHINE_ARCH</varname>
+and compiler
 version, disabling optimisation for that file/MACHINE_ARCH/compiler
 combination, and documenting it in <filename>doc/HACKS</filename>. See
 <filename>doc/HACKS</filename> for examples.
@@ -720,22 +737,23 @@
 <title>Packages providing info files</title>
 
 <para>
-Some packages install info files or use the makeinfo or install-info
-commands. In such cases, the makefile fragment
-<filename>mk/texinfo.mk</filename> should be
-included in the package Makefile before the inclusion of
+Some packages install info files or use the <command>makeinfo</command>
+or <command>install-info</command> commands. In such cases, the
+makefile fragment <filename>mk/texinfo.mk</filename> should be included
+in the package <filename>Makefile</filename> before the inclusion of
 <filename>mk/bsd.pkg.mk</filename>.
 Newer versions of texinfo (version 4 and above) are, unfortunately,
 incompatible from previous versions at the command line level and some
 extensions were introduced in the TeXinfo macro set. So the package creator
 should ensure that the correct binaries are selected, rather than relying
-on the contents of the PATH variable in the shell.
+on the contents of the <varname>PATH</varname> variable in the shell.
 </para>
 
 <para>
 The main info directory file needs to be updated to reflect the
 installation of info files. Some packages' installation processes take care
-of this for you. Otherwise the NetBSD Packages Collection has an INFO_FILES
+of this for you. Otherwise the NetBSD Packages Collection has an
+<varname>INFO_FILES</varname>
 definition which can be used to do this. Simply use the
 </para>
 
@@ -748,7 +766,8 @@
 
 <para>
 A package creator should also take care that the package build and install
-process uses the correct version of the makeinfo and install-info commands.
+process uses the correct version of the <command>makeinfo</command> and
+<command>install-info</command> commands.
 Some Makefiles and configure scripts from recent software packages include
 the pathnames to the <quote>makeinfo</quote> and
 <quote>install-info</quote> commands. Unfortunately,
@@ -767,12 +786,14 @@
 <para>
 If a minimum version of <quote>makeinfo</quote> and
 <quote>install-info</quote> commands are required,
-define TEXINFO_REQD in the package's Makefile to this minimum version.
+define <varname>TEXINFO_REQD</varname> in the package's Makefile to this
+minimum version.
 </para>
 
 <para>
-If a package is not well behaved (i.e., it does not pick MAKEINFO or
-INSTALL_INFO in the environment at configure or build time) you should do
+If a package is not well behaved (i.e., it does not pick
+<varname>MAKEINFO</varname> or <varname>INSTALL_INFO</varname> in the
+environment at configure or build time) you should do
 one of the following, whichever is more appropriate:
 </para>
 
@@ -780,17 +801,19 @@
 
 <listitem>
 <para>
-    patch the package files so MAKEINFO or INSTALL_INFO are picked from the
+    patch the package files so <varname>MAKEINFO</varname> or
+    <varname>INSTALL_INFO</varname> are picked from the
     environment at configure or build time and get used instead of
-    relying on makeinfo or install-info being accessible in PATH;
+    relying on makeinfo or install-info being accessible in
+    <varname>PATH</varname>;
 </para>
 </listitem>
 
 <listitem>
 <para>
-    put TEXINFO_OVERRIDE=YES in the package Makefile to let some sed
-    manipulation happen on some packages source files (see contents of
-    mk/texinfo.mk).
+    put <varname>TEXINFO_OVERRIDE=YES</varname> in the package Makefile
+    to let some sed manipulation happen on some packages source files
+    (see contents of <filename>mk/texinfo.mk</filename>).
 </para>
 </listitem>
 
@@ -802,7 +825,8 @@
 <title>Packages whose distfiles aren't available for plain downloading</title>
 
 <para>
-If you need to download from a dynamic URL you can set DYNAMIC_MASTER_SITES
+If you need to download from a dynamic URL you can set
+<varname>DYNAMIC_MASTER_SITES</varname>
 and a <command>make fetch</command> will call
 <filename>files/getsite.sh</filename> with the name of each file
 to download as an argument, expecting it to output the URL of the directory
@@ -812,9 +836,10 @@
 <para>
 If the download can't be automated, because the user must submit personal
 information to apply for a password, or must pay for the source, or whatever,
-you can set _FETCH_MESSAGE to a macro which displays a message explaining
-the situation. _FETCH_MESSAGE must be executable shell commands, not just a
-message. (Generally, it executes ${ECHO}). As of this writing, the following
+you can set <varname>_FETCH_MESSAGE</varname> to a macro which displays
+a message explaining the situation. <varname>_FETCH_MESSAGE</varname> must
+be executable shell commands, not just a message. (Generally, it executes
+<varname>${ECHO}</varname>). As of this writing, the following
 packages use this: <pkg>audio/realplayer</pkg>,
 <pkg>cad/simian</pkg>, <pkg>devel/ipv6socket</pkg>,
 <pkg>emulators/vmare-module</pkg>,
@@ -829,18 +854,20 @@
 <title>Configuration files handling and placement</title>
 
 <para>
-The global variable PKG_SYSCONFBASE (and some others) can be set by the
-system administrator in <filename>/etc/mk.conf</filename> to define the place where
+The global variable <varname>PKG_SYSCONFBASE</varname> (and some others)
+can be set by the system administrator in <filename>/etc/mk.conf</filename>
+to define the place where
 configuration files get installed. Therefore, packages must be adapted to
 support this feature. Keep in mind that you should only install files that
 are strictly necessary in the configuration directory, files that can
-go to $PREFIX/share should go there.
+go to <filename>$PREFIX/share</filename> should go there.
 </para>
 
 <para>
 We will take a look at available variables first
 (<filename>bsd.pkg.mk</filename> contains more
-information). PKG_SYSCONFDIR is where the configuration files for a package
+information). <varname>PKG_SYSCONFDIR</varname> is where the
+configuration files for a package
 may be found (that is, the full path, e.g. <filename>/etc</filename>
 or <filename>/usr/pkg/etc</filename>). This
 value may be customized in various ways:
@@ -850,17 +877,19 @@
 
 <listitem>
 <para>
-    PKG_SYSCONFBASE is the main config directory under which all package
-    configuration files are to be found. Users will typically want to set
-    it to /etc, or accept the default location of $PREFIX/etc.
+    <varname>PKG_SYSCONFBASE</varname> is the main config directory under
+    which all package configuration files are to be found. Users will
+    typically want to set it to /etc, or accept the default location of
+    <filename>$PREFIX/etc</filename>.
 </para>
 </listitem>
 
 <listitem>
 <para>
-    PKG_SYSCONFSUBDIR is the subdirectory of PKG_SYSCONFBASE under which
+    <varname>PKG_SYSCONFSUBDIR</varname> is the subdirectory of
+    <varname>PKG_SYSCONFBASE</varname> under which
     the configuration files for a particular package may be found. Defaults
-    to $SYSCONFBASE
+    to <varname>${SYSCONFBASE}</varname>.
 </para>
 </listitem>
 
@@ -876,14 +905,17 @@
 
 <listitem>
 <para>
-    PKG_SYSCONFDIR.${PKG_SYSCONFVAR} overrides the value of
-    ${PKG_SYSCONFDIR} for packages with the same value for PKG_SYSCONFVAR.
+    <varname>PKG_SYSCONFDIR.${PKG_SYSCONFVAR}</varname> overrides the value of
+    <varname>${PKG_SYSCONFDIR}</varname> for packages with the same value
+    for <varname>PKG_SYSCONFVAR</varname>.
 </para>
 
 <para>
     As an example, all the various KDE packages may want to set
-    PKG_SYSCONFVAR to "kde" so admins can set ${PKG_SYSCONFDIR.kde} in
-    <filename>/etc/mk.conf</filename> to define where to install KDE config files.
+    <varname>PKG_SYSCONFVAR</varname> to <quote>kde</quote> so admins can
+    set <varname>PKG_SYSCONFDIR.kde</varname> in
+    <filename>/etc/mk.conf</filename> to define where to install KDE
+    config files.
 </para>
 </listitem>
 
@@ -892,26 +924,32 @@
 <para>
 Programs' configuration directory should be defined during the configure
 stage. Packages that use GNU autoconf can usually do this by using the
---sysconfdir parameter, but this brings some problems as we will see now.
+<quote>--sysconfdir</quote> parameter, but this brings some problems as
+we will see now.
 When you change this pathname in packages, you should not allow them to
 install files in that directory directly. Instead they need to install
-those files under share/examples/${PKGNAME} so PLIST can register them.
+those files under <filename>share/examples/${PKGNAME}</filename> so
+<filename>PLIST</filename> can register them.
 </para>
 
 <para>
 Once you have the required configuration files in place (under the
-<filename>share/examples</filename> directory) the variable CONF_FILES should be set to copy
-them into PKG_SYSCONFDIR. The contents of this variable is formed by pairs
+<filename>share/examples</filename> directory) the variable
+<varname>CONF_FILES</varname> should be set to copy
+them into <varname>PKG_SYSCONFDIR</varname>. The contents of this variable
+is formed by pairs
 of filenames; the first element of the pair specifies the file inside the
-examples directory (registered by PLIST) and the second element specifies
+examples directory (registered by <filename>PLIST</filename>) and the
+second element specifies
 the target file. This is done this way to allow binary packages to place
-files in the right directory using INSTALL/DEINSTALL scripts which are
-created automatically.  The package Makefile must also include
-<filename>../../mk/bsd.pkg.install.mk</filename> prior to the inclusion of
-<filename>bsd.pkg.mk</filename> to use
+files in the right directory using
+<filename>INSTALL</filename>/<filename>DEINSTALL</filename> scripts which are
+created automatically.  The package <filename>Makefile</filename> must also
+include <filename>../../mk/bsd.pkg.install.mk</filename> prior to the
+inclusion of <filename>bsd.pkg.mk</filename> to use
 these automatically generated scripts.  The automatic copying of config
-files can be toggled by setting the environment variable PKG_CONFIG prior
-to package installation.
+files can be toggled by setting the environment variable
+<varname>PKG_CONFIG</varname> prior to package installation.
 </para>
 
 <para>
@@ -922,8 +960,10 @@
 CONF_FILES=	${EGDIR}/Muttrc ${PKG_SYSCONFDIR}/Muttrc</programlisting>
 
 <para>
-As you can see, this package installs configuration files inside EGDIR,
-which are registered by PLIST. After that, the variable CONF_FILES lists
+As you can see, this package installs configuration files inside
+<varname>EGDIR</varname>, which are registered by
+<filename>PLIST</filename>. After that, the variable
+<varname>CONF_FILES</varname> lists
 the installed file first and then the target file. Users will also get an
 automatic message when files are installed using this method.
 </para>
@@ -935,11 +975,13 @@
 
 <para>
 If the purpose of the package is to provide a login shell, the variable
-PKG_SHELL should contain the full pathname of the shell executable installed
-by this package. The package Makefile also must include
+<varname>PKG_SHELL</varname> should contain the full pathname of the
+shell executable installed by this package. The package
+<filename>Makefile</filename> also must include
 <filename>../../mk/bsd.pkg.install.mk</filename> prior to the inclusion of
 <filename>bsd.pkg.mk</filename> to use the
-automatically generated INSTALL/DEINSTALL scripts.
+automatically generated
+<filename>INSTALL</filename>/<filename>DEINSTALL</filename> scripts.
 </para>
 
 <para>
@@ -951,8 +993,9 @@
 
 <para>
 The shell is registered into <filename>/etc/shells</filename> file automatically in the
-post-install target by the INSTALL script generated by bsd.pkg.install.mk and
-removed in the deinstall target by the DEINSTALL script.
+post-install target by the <filename>INSTALL</filename> script generated
+by <filename>bsd.pkg.install.mk</filename> and removed in the deinstall
+target by the <filename>DEINSTALL</filename> script.
 </para>
 </sect1>
 
@@ -962,10 +1005,12 @@
 
 <para>
 If the package provides its own locale catalogues, the variable
-USE_PKGLOCALEDIR should be defined.  It will ensure that the package's
-Makefile template files are fixed and point to the correct locale directories
-(which may vary, depending on OS), if necessary.  See also section 5.1 for
-details about ${PKGLOCALEDIR}.  This functionality is buildlink2-only.
+<varname>USE_PKGLOCALEDIR</varname> should be defined.  It will ensure
+that the package's <filename>Makefile</filename> template files are fixed
+and point to the correct locale directories
+(which may vary, depending on OS), if necessary.  See also section 5.1 XXX for
+details about <varname>PKGLOCALEDIR</varname>.  This functionality is
+buildlink2-only.
 </para>
 </sect1>
 
@@ -991,9 +1036,10 @@
 <title>Packages containing perl scripts</title>
 
 <para>
-If your package contains interpreted perl scripts, set REPLACE_PERL to
-ensure that the proper interpreter path is set. REPLACE_PERL should
-contain a list of scripts, relative to WRKSRC, that you want adjusted.
+If your package contains interpreted perl scripts, set
+<varname>REPLACE_PERL</varname> to ensure that the proper interpreter
+path is set. <varname>REPLACE_PERL</varname> should contain a list of
+scripts, relative to <varname>WRKSRC</varname>, that you want adjusted.
 </para>
 </sect1>
 
@@ -1004,18 +1050,19 @@
 <para>
 There are several reasons why a package might be instructed to not
 build under certain circumstances. If the package builds and runs
-on most platforms, the exceptions should be noted with NOT_FOR_PLATFORM.
-If the package builds and runs on a small handful of platforms,
-set ONLY_FOR_PLATFORM instead. If the package should be skipped
-(for example, because it provides functionality already provided
-by the system), set PKG_SKIP_REASON to a descriptive message. If
+on most platforms, the exceptions should be noted with
+<varname>NOT_FOR_PLATFORM</varname>. If the package builds and runs on
+a small handful of platforms, set <varname>ONLY_FOR_PLATFORM</varname>
+instead. If the package should be skipped (for example, because it
+provides functionality already provided by the system), set
+<varname>PKG_SKIP_REASON</varname> to a descriptive message. If
 the package should fail because some preconditions are not met,
-set PKG_FAIL_REASON to a descriptive message.
+set <varname>PKG_FAIL_REASON</varname> to a descriptive message.
 </para>
 
 <para>
-IGNORE is deprecated because it didn't provide enough information
-to determine whether the build should fail.
+<varname>IGNORE</varname> is deprecated because it didn't provide enough
+information to determine whether the build should fail.
 </para>
 </sect1>