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

Packages.txt: 1.162 -> 1.183



Packages.txt: 1.162 -> 1.183 です。ツッコミをお願いします。

対応する原文の差分は
  http://cvsweb.NetBSD.org/bsdweb.cgi/pkgsrc/Attic/Packages.txt.diff?r1=1.162&r2=1.183
です。

査読等の便のため、改行位置の調整はしていません。
(調整したうえでcommitします)

8 buildlink.mk methodology の章は訳してありません。
(buildlink3 になってから訳すということで)

--- Packages.txt.orig	Fri Nov 18 00:45:20 2005
+++ Packages.txt	Sat Nov 26 09:49:52 2005
@@ -1,4 +1,4 @@
-# $NetBSD: Packages.txt,v 1.162 2001/06/19 16:23:33 jlam Exp $
+# $NetBSD: Packages.txt,v 1.183 2001/09/04 13:00:44 hubertf Exp $
 # $Id: Packages.txt,v 1.17 2005/11/17 15:45:20 kano Exp $
 ###########################################################################
 
@@ -200,14 +200,14 @@
 	% setenv CVSROOT anoncvs@anoncvs.netbsd.org:/cvsroot
 	% setenv CVS_RSH ssh 
 	% cd /usr
-	% cvs checkout pkgsrc
+	% cvs checkout -P pkgsrc
 
 こうすると、/usr以下に"pkgsrc"ディレクトリーが作られ、/usr/pkgsrc以下に全パッ
 ケージのソースが入った状態になります。一旦チェックアウトしたpkgsrcを更新す
 るには、CVS_RSHを上のように設定してから、以下のようにします:
 
 	% cd /usr/pkgsrc
-	% cvs update
+	% cvs -q update -dP
 
 
  2.3 配布ファイルの取得
@@ -232,7 +232,7 @@
  2.4 構築とインストール方法
  ==========================
 
-上記の作業が完了したら、rootになり適切なディレクトリーに移動してください。
+配布ファイルの取得(前節参照)が完了したら、rootになり適切なディレクトリーに移動してください。
 そして、シェル・プロンプト上で以下のようにタイプしてください。
 
 	make
@@ -383,7 +383,7 @@
 pre-build.localの使い方の例としては、このファイルに
 
 	echo "I do not have enough disk space to build this pig." \
-		> games/crafty-book-enormous/$BROKENF
+		> pkgsrc/games/crafty-book-enormous/$BROKENF
 
 のような内容を書いておいて、3 Gb近くのディスク容量が必要な個々のパッケージ
 の構築をしないようにする、というものがあります。
@@ -391,8 +391,14 @@
  3.2.2 ほか、環境に関する考察
  ============================
 
-あなた好みのログインシェルを/usr/localに移しておくか、/etc/rc.localでインス
-トールするようにしておきます。また、1.5より前のバージョンのOSを使っていたり、
+/usr/pkgはバルクビルド開始時に完全に削除されるので、
+ログインシェルが別の場所にあることを確認してください。
+ログインシェルを/usr/local/binに移して(それに合わせてパスワードファイルも修正して)おくか、/etc/rc.localでpkg_addを使って(再)インス
+トールするようにしておきます。
+これでリブート後もログインできます
+(パッケージが削除されてもシェルのプロセスは死なず、
+シェルを新たに起動できなくなるだけです)。
+また、1.5より前のバージョンのOSを使っていたり、
 何らかの理由でpkgsrc版のsshを使いたい場合は、rc.localでsshdが起動する前に
 sshをインストールするようにしておきます:
 
@@ -410,7 +416,7 @@
 
 すでにインストールされているどのパッケージも必要ない状態にしてください。
 注意: バルクビルドの過程で、 *すべての* パッケージが削除されます!!! その他
-のものも(/usr/local, ...から)すべて削除しておいてください。root になって、
+、構築の妨げになりうるもの(/usr/localにインストールされているライブラリーなど)もすべて削除しておいてください。root になって、
 以下のようにタイプします:
 
         # cd /usr/pkgsrc
@@ -473,7 +479,7 @@
  ====================================================
 
 pkgsrcのバルクビルド完了後、できあがったバイナリーパッケージからCD-ROMを作っ
-て、他のマシンへのインストール用に使うことができます。pkgtools/cdpackパッケー
+て、他のマシンへのインストール用に使うことができます。pkgsrc/pkgtools/cdpackパッケー
 ジに、そのようなISO 9660イメージ作成用の簡単なツールがあります。`cdpack'は、
 依存関係が一枚のCD内で完結するように、パッケージを複数枚のCD-ROMに編集して
 くれます。
@@ -643,7 +649,7 @@
 	md5, rmd160, sha1, sha256, sha384 and sha512
 
 パッケージによっては、アーキテクチャー毎にdistfileの組が異なるものがありま
-す。(www/navigatorがよい例です)。この情報は単一のdistinfoファイルに書かれる
+す。(pkgsrc/www/navigatorがよい例です)。この情報は単一のdistinfoファイルに書かれる
 ので、このようなパッケージの更新時には、distfileの情報が失われないように注
 意を払ってください。
 
@@ -676,9 +682,9 @@
 一つ重要なこととして、NetBSD CVSツリーにチェックインした後に問題を引き起こ
 すので、パッチファイルにRCS IDを含ませないように注意してください。これを避
 けるためには、diffを"-U 2"または"-U 1"オプションのどちらかを使ってください。
-あるいはpkgsrc/pkgdiffにある'pkgdiff'コマンドを使ってください。
+あるいはpkgsrc/pkgtools/pkgdiffにある'pkgdiff'コマンドを使ってください。
 
-この 2 段落で述べた問題に気を使いたくない場合は、pkgtools/pkgdiffパッケージ
+この 2 段落で述べた問題に気を使いたくない場合は、pkgsrc/pkgtools/pkgdiffパッケージ
 のpkgdiffを使ってください。これはすべてのRCS Idをよきにはからってくれます。
 
 さらに自動化するため、同パッケージのmkpatchesを使ってパッチ一式を作ることを
@@ -703,6 +709,15 @@
 イルのチェックサムを生成するようにしてください。セクション4.2を参照してくだ
 さい。
 
+置いておきたいパッチがあるがpkgsrcにcommitすべきものではない場合、
+それをpkgsrcツリーの外の$LOCALPATCHESディレクトリーに置いておくことができます。
+このディレクトリーツリーはpkgsrcと同様の"category/package"の構造を持つようにし、
+パッチを各パッケージのディレクトリー(すなわち$LOCALPATCHES/$PKGPATH)に置くようになっています。
+たとえば、pkgsrc/graphics/pngに私的なパッチを適用するようにしたい場合は、
+そのパッチを$LOCALPATCHES/graphics/png/mypatchに置きます。
+このディレクトリーにあるファイルはすべてパッチファイルとして扱われ、
+pkgsrcの「標準の」パッチが適用された後に、このパッチが適用されます。
+
 
  4.4 pkg/*
  =========
@@ -1043,7 +1058,7 @@
 LTCONFIG_OVERRIDE=${WRKSRC}/ltconfigをパッケージのMakefileに追加してくださ
 い。パッケージのlibtoolは、do-configureターゲットでltconfigスクリプトにより
 作られます。USE_LIBTOOL および LTCONFIG_OVERRIDE が定義されている場合、指定
-されたltconfigは、パッケージのlibtoolのかわりにdevel/libtoolを使うよう上書
+されたltconfigは、パッケージのlibtoolのかわりにpkgsrc/devel/libtoolを使うよう上書
 きされます。
 
 パッケージが動的共有オブジェクトのロードに、libtool (libltdl)のプラットフォー
@@ -1083,7 +1098,7 @@
 $f.pdone $$f; \
         done
 
-これはsysutils/rttyパッケージで使用している方法です。これがあなたのパッケー
+これはpkgsrc/sysutils/rttyパッケージで使用している方法です。これがあなたのパッケー
 ジでも正しく動作することを確認してください。例えば、/usr/localで何かを探す
 ことは、実際には意味があるかもしれません。したがって、無条件に/usr/localを
 置き換えてはいけません。
@@ -1230,7 +1245,9 @@
 
  * patch:
    展開の後で、PATCHFILESで指定されたパッチとパッケージのパッチサブディレク
-   トリーに存在するパッチ、すべてが適用されます。.Z、あるいは.gzで終る名前
+   トリーに存在するパッチ、
+さらに、$LOCALPATCHES/$PKGPATH (たとえば /usr/local/patches/graphics/png)に存在するパッチの
+すべてが適用されます。.Z、あるいは.gzで終る名前
    のパッチファイルは、適用する前に伸張されます。.orig、.rejで終るものは無
    視されます。patch(1)のためのいくつかのオプションは、PATCH_DIST_ARGSで指
    定する事ができます。詳細に関してはセクション4.3を参照して下さい。
@@ -1328,7 +1345,7 @@
       指定されたパッケージに必要な(依存する)すべてのパッケージを削除します。
       このターゲットは、指定されたパッケージによってインストールされたパッ
       ケージを削除するために使用されます。例えば、DEINSTALLDEPENDS=1が
-      x11/kdeで指定されている場合、KDE全体を削除します。pkg_deleteのコマン
+      pkgsrc/x11/kdeで指定されている場合、KDE全体を削除します。pkg_deleteのコマン
       ドラインに-Rを指定すると設定されます。
 
  * update:
@@ -1476,7 +1493,151 @@
     - そのパッケージが依存している(バイナリー)パッケージが、いずれも構築時
       から変更されていないこと
 
- 8 デバッグ
+ 8 buildlink.mk methodology
+ ==========================
+
+Many packages that install libraries and headers for use in other packages
+now have buildlink.mk files in their pkgsrc subdirectory.  The purpose of
+these files is two-fold:
+
+  (1) Cause all headers and libraries used by a particular package to be
+      found in a known location during the configure and build process.
+      These packages are said to be "weakly-buildlinked".
+
+  (2) Cause _only_ those headers and libraries used by a particular package
+      to be found during the configure and build process.
+      These packages are said to be "strongly-buildlinked".
+
+
+ 8.1 Using buildlink.mk files
+ ============================
+
+Goal (1) is accomplished by simply including a package dependency's
+buildlink.mk file in a package's Makefile, which does the following:
+
+  (1a) Adds a DEPENDS or BUILD_DEPENDS line for the package;
+
+  (1b) Creates a directory ${BUILDLINK_DIR}, by default set to a
+       subdirectory of ${WRKDIR};
+
+  (1c) Links all the headers and libraries for that dependency into
+       ${BUILDLINK_DIR}/include and ${BUILDLINK_DIR}/lib, respectively;
+
+  (1d) Prepends -I${BUILDLINK_DIR}/include to CPPFLAGS, CFLAGS, CXXFLAGS,
+       and -L${BUILDLINK_DIR}/lib to LDFLAGS;
+
+  (1e) Creates a wrapper script for GTK+-style config scripts, often found
+       in GNOME software, that translates -I${LOCALBASE}/include and
+       -L${LOCALBASE}/lib into references into ${BUILDLINK_DIR}.
+
+Some packages are for software libraries whose functionality is a part of
+recent released versions of NetBSD, e.g. readline, OpenSSL, and ncurses.
+For those packages, the buildlink.mk files link the appropriate system
+headers and libraries into ${BUILDLINK_DIR} so that goal (1) is still met.
+Where possible, the system headers and libraries are renamed when linked
+into ${BUILDLINK_DIR} to match the names of their pkgsrc counterparts so
+that the files may be referenced under a consistent name.
+
+Goal (2) requires some work on the part of the package builder.  As all
+headers and libraries used by a package may be found in ${BUILDLINK_DIR},
+and -I${BUILDLINK_DIR}/include and -L${BUILDLINK_DIR}/lib are already passed
+to the compiler, it is no longer necessary to pass -I${LOCALBASE}/include or
+-L${LOCABASE}/lib to the compiler.  Therefore, those lines should be removed
+from package Makefiles, and where necessary, the package sources should be
+patched to do the same.  Also, if a package uses X11, then by including
+mk/x11.buildlink.mk, -I${BUILDLINK_X11_DIR}/include and
+-L${BUILDLINK_X11_DIR}/lib are also passed to the compiler instead of the
+corresponding directories in ${X11BASE}.  Also, if USE_BUILDLINK_ONLY is
+defined, then -L${LOCALBASE}/lib is not automatically added to LDFLAGS in
+bsd.pkg.mk.
+
+
+ 8.2 Writing buildlink.mk files
+ ==============================
+
+Most of the work done by buildlink.mk files is encapsulated and shared
+through bsd.buildlink.mk, which is included by packages' buildlink.mk files.
+Please see the comments at the top of bsd.buildlink.mk for complete
+documentation on how to use the file.  A simple example of a buildlink.mk
+for a mythical package foo follows:
+
+> .include "../../mk/bsd.buildlink.mk"
+> 
+> BUILDLINK_DEPENDS.foo?=	foo>=1.0
+> DEPENDS+=			${BUILDLINK_DEPENDS.foo}:../../category/foo
+> 
+> EVAL_PREFIX+=			BUILDLINK_PREFIX.foo=foo
+> BUILDLINK_FILES.foo=		include/foo.h
+> BUILDLINK_FILES.foo+=		include/bar.h
+> BUILDLINK_FILES.foo+=		lib/libfoo.*
+> 
+> # We need the libraries to be called "libbar.*".
+> BUILDLINK_TRANSFORM.foo=	-e "s|libfoo|libbar|g"
+> 
+> BUILDLINK_TARGETS+=		foo-buildlink
+> 
+> pre-configure: foo-buildlink
+> foo-buildlink: _BUILDLINK_USE
+
+
+ 8.3 Converting packages to use buildlink.mk files
+ =================================================
+
+The process of converting existing packages to use the buildlink.mk
+infrastructure is fairly straightforward.  If a dependency on a particular
+package is required for its libraries and headers, then rather than
+directly adding a dependency on that package, include that package's
+buildlink.mk instead.  The following variables may also be replaced with
+buildlink.mk files:
+
+    USE_CURSES	-->	.include "../../devel/ncurses/buildlink.mk"
+    USE_LIBINTL	-->	.include "../../devel/gettext-lib/buildlink.mk"
+    USE_LTDL	-->	.include "../../devel/libtool/buildlink.mk"
+    USE_MESA	-->	.include "../../graphics/Mesa/buildlink.mk"
+    USE_MOTIF	-->	.include "../../x11/lesstif/buildlink.mk"
+    USE_MOTIF12	-->	.include "../../x11/lesstif12/buildlink.mk"
+    USE_SSL	-->	.include "../../security/openssl/buildlink.mk"
+    USE_X11	-->	.include "../../mk/x11.buildlink.mk"
+    USE_XAW	-->	.include "../../mk/xaw.buildlink.mk"
+    USE_XPM	-->	.include "../../graphics/xpm/buildlink.mk"
+
+Packages that have an explicit dependency on ncurses should set USE_NCURSES
+to the reason why the system curses is insufficient, and include
+"../../devel/ncurses/buildlink.mk" afterwards.  This helps to identify
+where the system curses differs from ncurses, and when the development of
+the system curses catches up in functionality, the USE_NCURSES setting may
+be removed.
+
+Packages that use OpenSSL that require a specific version of OpenSSL should
+define USE_OPENSSL_VERSION to the minimum version number required prior to
+including "../../security/openssl/buildlink.mk".  The version number is the
+hexadecimal number found in <openssl/opensslv.h>, or the variables
+OPENSSL_VERSION_{095A,096,096A,096B} may be used.
+
+The use of EVAL_PREFIX to find the installation prefix for packages may be
+removed since references to package library and header files are found
+through ${BUILDLINK_DIR}.  If the required dependency pattern for a package
+differs from the default specified in the package's buildlink.mk file, then
+it may be set by defining BUILDLINK_DEPENDS.<pkgname> in the Makefile to
+the dependency pattern required.
+
+Packages will still need LDFLAGS to be set to include the appropriate rpath
+settings in order for built packages to find libraries.  LDFLAGS should
+still contain -Wl,-R${LOCALBASE}/lib, and -Wl,-R${X11BASE}/lib if the
+package requires the X11 libraries.  -Wl,-R should never refer to a
+${BUILDLINK_DIR} library directory, and all such references should be
+purged from the build.
+
+A package that builds correctly with USE_BUILDLINK_ONLY set should have
+that setting added to its Makefile to note that it doesn't use any
+libraries or headers in ${LOCALBASE} directly, but rather references them
+only through ${BUILDLINK_DIR}.  Note that you MUST check the build output
+to verify that no references to ${LOCALBASE} directories occurred during
+the configure or build process, or else the package cannot be marked as
+USE_BUILDLINK_ONLY.
+
+
+ 9 デバッグ
  ==========
 
 (FreeBSDのportから、または一から)パッケージを作成する時に落ちいりやすい間違
@@ -1534,11 +1695,11 @@
    セクション 10 が参考になります。
 
 
- 9 FAQとパッケージシステムの特徴
- ===============================
+ 10 FAQとパッケージシステムの特徴
+ ================================
 
- 9.1 GNU autoconfigを利用するパッケージ
- ======================================
+ 10.1 GNU autoconfigを利用するパッケージ
+ =======================================
 
 もしパッケージがGNU autoconfを使うのであれば、パッケージのMakefileに以下の
 設定を追加してください。
@@ -1550,10 +1711,10 @@
 あなたの望む設定とは異なるかもしれません。
 
 
- 9.2 tar.gz 以外の配布方法
- =========================
+ 10.2 tar.gz 以外の配布方法
+ ==========================
 
-パッケージがtar.gz以外の方法で配布されている場合、editors/samパッケージを参
+パッケージがtar.gz以外の方法で配布されている場合、pkgsrc/editors/samパッケージを参
 考にしてください。これはgzipされたシェルアーカイブ(shar)を使っています。い
 ちおう簡単に説明すると、DISTNAMEフィールドの後でEXTRACT_SUFXに名前を設定し、
 パッケージのMakefileに以下の設定を追加してください。
@@ -1564,18 +1725,18 @@
 > EXTRACT_AFTER_ARGS=     |sh
 
 
- 9.3 それ自身のサブディレクトリーを作り出さないパッケージ
- ========================================================
+ 10.3 それ自身のサブディレクトリーを作り出さないパッケージ
+ =========================================================
 
 パッケージが例えばGNUソフトウェアのようにサブディレクトリーを作るのではなく、
-カレントディレクトリーに展開される場合、もう一度editors/samを見てください。
+カレントディレクトリーに展開される場合、もう一度pkgsrc/editors/samを見てください。
 簡単にいうと以下の設定が必要です。
 
 > NO_WRKSUBDIR=   yes
 
 
- 9.4 カスタムコンフィギュレーションプロセス
- ==========================================
+ 10.4 カスタムコンフィギュレーションプロセス
+ ===========================================
 
 パッケージが、かわったConfigureスクリプトを使用している場合、topのパッケー
 ジを参照してください。簡単にいえば、以下の設定をおこなってください。
@@ -1585,8 +1746,8 @@
 > CONFIGURE_ARGS+=        netbsd13
 
 
- 9.5 DISTNAMEディレクトリーで作成されないパッケージ
- ==================================================
+ 10.5 DISTNAMEディレクトリーで作成されないパッケージ
+ ===================================================
 
 パッケージが、DISTNAMEをベースにしないディレクトリーで構築される場合、tcl、
 およびtkパッケージを参考にしてください。
@@ -1594,8 +1755,8 @@
 > WRKSRC=         ${WRKDIR}/${DISTNAME}/unix
 
 
- 9.6 一度にすべてのdistfilesを取得する方法
- =========================================
+ 10.6 一度にすべてのdistfilesを取得する方法
+ ==========================================
 
 「make fetch」を実行できない職場や大学において、一回のバッチ処理で、すべて
 のdistfilesをダウンロードしたいと思うことがあるかもしれません。しかしながら、
@@ -1628,8 +1789,8 @@
 	make fetch NO_IGNORE=yes
 
 
- 9.7 防火壁の内側からファイルを取得する方法
- ==========================================
+ 10.7 防火壁の内側からファイルを取得する方法
+ ===========================================
 
 もし、あなたが防火壁の内側にいて、インターネットのホストに直接接続できない
 (つまりNATを使っていない)場合、適切なプロキシーホストを指定することができま
@@ -1641,14 +1802,14 @@
 	http_proxy=http://orpheus.amdahl.com:80/
 
 
- 9.8 パッチがRCS IDを含む場合
- ============================
+ 10.8 パッチがRCS IDを含む場合
+ =============================
 
 パッチからRCS IDを削除する方法については、セクション4.3を参照してください。
 
 
- 9.9 /etc/mk.confから変数を捕まえる方法
- ======================================
+ 10.9 /etc/mk.confから変数を捕まえる方法
+ =======================================
 
 MAKECONFや/etc/mk.confで上書き可能な、パッケージで定義された変数には問題が
 あります。それは、変数はmake(1)がそれを使う時に展開されるが、プリプロセッサー
@@ -1667,8 +1828,8 @@
 	.endif
 
 
- 9.10 pkgについて話しあうためのメーリングリストはありますか?
- ===========================================================
+ 10.10 pkgについて話しあうためのメーリングリストはありますか?
+ ============================================================
 
 はい。パッケージに関する問題を議論するためにtech-pkg@netbsd.orgが存在します。
 購読するためには以下のようにして下さい。
@@ -1676,8 +1837,8 @@
     echo subscribe tech-pkg | mail majordomo@netbsd.org
 
 
- 9.11 どうすれば「make fetch」でpassive FTPを使用することができますか?
- =====================================================================
+ 10.11 どうすれば「make fetch」でpassive FTPを使用することができますか?
+ ======================================================================
 
 distfileの取得にどのユーティリティーを使っているかによります。bsd.pkg.mkは、
 以下のリストのなかで利用可能なコマンドのうち、最初のものをFETCH_CMDに割り当
@@ -1696,8 +1857,8 @@
 ります。
 
 
- 9.12 他のパッケージへの依存
- ===========================
+ 10.12 他のパッケージへの依存
+ ============================
 
 パッケージは他のパッケージに依存するかもしれません。そして、この依存性を定
 義するためのいろいろな方法があります。NetBSDはBUILD_DEPENDS、DEPENDS定義を
@@ -1724,7 +1885,7 @@
 	BUILD_DEPENDS+=  autoconf-2.13:../../devel/autoconf
 
 (b) もし、パッケージがリンクのためのライブラリーを必要とするなら、DEPENDS定
-義を使ってください。たとえば、print/lyxパッケージは、作成のためにxpmライブ
+義を使ってください。たとえば、pkgsrc/print/lyxパッケージは、作成のためにxpmライブ
 ラリーのバージョン3.4jを使用します。
 
 	DEPENDS+=       xpm-3.4j:../../graphics/xpm
@@ -1750,7 +1911,7 @@
 	BUILD_DEPENDS+=	perl-5.*:../../lang/perl
 
 (c) もし、パッケージを実行するために、いくつかの実行可能ファイルが必要なら、
-DEPENDS定義を使ってください。print/lyxパッケージを実行する時には、teTexパッ
+DEPENDS定義を使ってください。pkgsrc/print/lyxパッケージを実行する時には、teTexパッ
 ケージ由来のlatex のバイナリーが実行可能でなければなりません。これは、以下
 のように指定します。
 
@@ -1759,7 +1920,7 @@
 上述した、ワイルドカード依存関係に関する注意は、ここにも当てはまります。
 
 パッケージの構築用に別のパッケージに含まれるファイルが必要な場合は、
-print/ghostscript5パッケージの"do-configure"ターゲットの最初の部分をご覧く
+pkgsrc/print/ghostscript5パッケージの"do-configure"ターゲットの最初の部分をご覧く
 ださい(このパッケージは、構築の際にjpegのソースがソースの状態で存在すること
 に依存しています)。
 
@@ -1769,14 +1930,14 @@
 
 また、便利に使うことができるBUILD_USES_MSGFMTおよびBUILD_USES_GETTEXT_M4定
 義にも注意してください。前者は、基本システムにmsgfmt(1)があるかどうか調べて、
-ない場合はdevel/gettextパッケージをインストールします。後者は、構築の際に、
+ない場合はpkgsrc/devel/gettextパッケージをインストールします。後者は、構築の際に、
 旧バージョンのgettextパッケージがインストールされていることに依存するように
-し、これがインストールされていない場合はdevel/gettext-m4パッケージをインス
+し、これがインストールされていない場合はpkgsrc/devel/gettext-m4パッケージをインス
 トールします。
 
 
- 9.13 他のパッケージとの衝突
- ===========================
+ 10.13 他のパッケージとの衝突
+ ============================
 
 パッケージは、すでにインストール済みの別のパッケージと衝突する可能性があり
 ます。例えば、パッケージが、pkgsrcの中の別のパッケージと同じファイルをイン
@@ -1800,8 +1961,8 @@
 「Xaw3d-1.3」と衝突するでしょう。
 
 
- 9.14 WWWホームページがあるソフトウェア
- ======================================
+ 10.14 WWWホームページがあるソフトウェア
+ =======================================
 
 NetBSDパッケージシステムは、HOMEPAGE変数をサポートしています。もし、パッケー
 ジ化されたソフトウェアのホームページが存在するのであれば、そのページのURLを
@@ -1809,8 +1970,8 @@
 に定義してください。
 
 
- 9.15 '古い'名前のまま更新されたdistfileの取り扱い
- =================================================
+ 10.15 '古い'名前のまま更新されたdistfileの取り扱い
+ ==================================================
 
 時々、ソフトウェアパッケージの作者がソフトウェアのリリース後に変更を加え、
 変更後のdistfileを、バージョン番号を変えずに公開することがあります。このと
@@ -1823,8 +1984,8 @@
 れたのではないことを確認します。
 
 
- 9.16 "Don't know how to make /usr/share/tmac/tmac.andoc" ってどういうこと?
- ==========================================================================
+ 10.16 "Don't know how to make /usr/share/tmac/tmac.andoc" ってどういうこと?
+ ===========================================================================
 
 pkgsrc/pkgtools/pkg_installパッケージのコンパイル時に、makeが
 /usr/share/tmac/tmac.andoc の作り方がわからないというエラーを出します。これ
@@ -1834,16 +1995,16 @@
 このpkg_installパッケージの事例は、環境変数か/etc/mk.confのどちらかで
 NOMAN=YESを設定して回避することもできます。
 
- 9.17 既存パッケージ修正時に、バージョンを上げるにはどうするか
- =============================================================
+ 10.17 既存パッケージ修正時に、バージョンを上げるにはどうするか
+ ==============================================================
 
 既存のパッケージに修正を加えたときに、PKGNAMEのバージョン番号を変えると便利
 な場合があります。元の作者による将来のバージョンと衝突しないようにするため、
 'nb1'を後に付けます(さらにバージョンを上げるときは'nb2'などとします)。
 
 
- 9.18 "Could not find bsd.own.mk" - 何がいけないの?
- ==================================================
+ 10.18 "Could not find bsd.own.mk" - 何がいけないの?
+ ===================================================
 
 NetBSDのインストール時にコンパイラー一式comp.tgzをインストールしなかったか
 らです。comp.tgzを入手し、/で展開してインストールしてください:
@@ -1854,8 +2015,8 @@
 したリリース("uname -r"で調べられます) に合ったものを入手してください。
 
 
- 9.19 制限つきパッケージ
- =======================
+ 10.19 制限つきパッケージ
+ ========================
 
 ライセンスによっては、ソフトウェアの再配布方法に制限があります。このような
 制限を満たすようにするため、パッケージシステムでは以下のような制限を設定で
@@ -1889,11 +2050,19 @@
 うべきでないことに注意してください。これらは、ユーザーのバイナリーパッケー
 ジ作成を、無条件にできないようにするからです。
 
- 9.20 (n)cursesを使うパッケージ
- ==============================
+ 10.20 (n)cursesを使うパッケージ
+ ===============================
 
 パッケージによっては1.4Y以前のNetBSD自身のcursesにはなかった機能を必要とし
-ます。そんな機能を使うパッケージ用に、いくつかの変数が用意されています: パッ
+ます。そんな機能を使うパッケージ用の方法が二つあります。
+USE_CURSES変数を使う方法と、
+そのパッケージのMakefileで../../devel/ncurses/buildlink.mkをインクルードする方法です。
+
+
+ 10.20.1 USE_CURSES
+ ===================
+
+パッ
 ケージのMakefileでUSE_CURSESを設定した場合、そのシステムでのncursesへの依存
 関係の必要性に応じて、自動的にNEED_NCURSESがYESかNOに設定されます。この変数
 を、たとえば、ncursesを使うかどうかをパッケージに知らせるために、configure
@@ -1905,7 +2074,7 @@
 つパッケージのconfigureスクリプトがncursesを優先して使うようになっている場
 合、この変数を使う必要があるかもしれません。
 
-たとえばmail/muttでは、関連する部分は以下の各行です:
+たとえばpkgsrc/mail/muttでは、関連する部分は以下の各行です:
 USE_CURSES=		YES
 REPLACE_NCURSES=	configure configure.in
 [...]
@@ -1918,9 +2087,20 @@
 NEED_NCURSES変数はbsd.prefs.mkで設定されるので、この変数を確認するのは
 bsd.prefs.mkをインクルードした後でなければならないことに注意してください。
 
+ 10.20.2 devel/ncurses/buildlink.mk
+ ==================================
+
+パッケージのMakefileで../../devel/ncurses/buildlink.mkをインクルードすると、
+pre-configure時に、
+cursesライブラリーとncurses機能用のヘッダーが${BUILDLINK_DIR}内にリンクされます。
+ncursesが必要な場合は、ncursesへの依存関係がパッケージに追加されるか、
+または(システムのcursesで十分な場合は)ライブラリーとヘッダーがncursesの名前で
+${BUILDLINK_DIR}内にリンクされます。
+ncursesが本当に必要な場合は、パッケージのMakefileでUSE_NCURSESを定義してください。
 
- 9.21 自動セキュリティーチェック
- ===============================
+
+ 10.21 自動セキュリティーチェック
+ ================================
 
 サードパーティーのソフトウェアにはしばしばバグがあること、そして、バグのな
 かにはマシンをアタッカーの攻撃に対して脆弱な状態にするものもあることに、ど
@@ -1948,36 +2128,41 @@
 
 audit-packagesのインストール中に以下のようなメッセージが表示されます。
 
-======================================================================
-You may wish to have the vulnerabilities file downloaded daily so that
-it remains current.  This may be done by adding an appropriate entry
-to the root users crontab(5) entry.  For example the entry
-
-# download vulnerabilities file
-0 3 * * * ${PREFIX}/sbin/download-vulnerability-list >/dev/null 2>&1
-
-will update the vulnerability list every day at 3AM.
-
-In addition, you may wish to run the package audit from the daily
-security script.  This may be accomplished by adding the following
-lines to /etc/security.local
-
-if [ -x ${PREFIX}/sbin/audit-packages ]; then
-        ${PREFIX}/sbin/audit-packages
-fi
-======================================================================
+  ======================================================================
+  You may wish to have the vulnerabilities file downloaded daily so that
+  it remains current.  This may be done by adding an appropriate entry
+  to the root users crontab(5) entry.  For example the entry
+  
+  # download vulnerabilities file
+  0 3 * * * ${PREFIX}/sbin/download-vulnerability-list >/dev/null 2>&1
+  
+  will update the vulnerability list every day at 3AM.
+  
+  In addition, you may wish to run the package audit from the daily
+  security script.  This may be accomplished by adding the following
+  lines to /etc/security.local
+  
+  if [ -x ${PREFIX}/sbin/audit-packages ]; then
+          ${PREFIX}/sbin/audit-packages
+  fi
+  ======================================================================
 
 
 パッケージ開発者への註: 脆弱性が発見された場合、そのことを
 localsrc/security/advisories/pkg-vulnerabilitiesに記載してcommitしてくださ
 い。このファイルはftp.netbsd.orgの
 /pub/NetBSD/packages/distfiles/vulnerabilities にコピーされます。
+ 10.22 パッケージでアカウントを作成する場合の適切な方法は?
+ =========================================================
+
+たとえば、pkgsrc/sysutils/amanda-common/{Makefile,pkg/INSTALL}
+でどのようにしているかを見てください。
 
 
- 10 提出およびコミット
+ 11 提出およびコミット
  =====================
 
- 10.1 あなたが作ったパッケージの提出
+ 11.1 あなたが作ったパッケージの提出
  ===================================
 
 ここでは、バイナリーパッケージと"通常の"(ソース)パッケージとを区別する必要
@@ -2007,7 +2192,7 @@
   て送ってください。そうすることで、私たちが追跡しやすくなります。
 
 
- 10.2 コミット: パッケージのCVSへのインポート
+ 11.2 コミット: パッケージのCVSへのインポート
  ============================================
 
 このセクションは、NetBSDのpkgsrcリポジトリーへの書き込みアクセス権限を持っ
@@ -2042,7 +2227,7 @@
 を自動的に更新するために使用されているからです。
 
 
- 11 パッケージの簡単な例: bison
+ 12 パッケージの簡単な例: bison
  ==============================
 
 私は、FreeBSDのポート(ports)にないソフトウェアをさがし、GNU bisonを選びまし
@@ -2050,14 +2235,14 @@
 いないでしょう。しかし、練習という意味では役にたちます。
 
 
- 11.1 ファイル
+ 12.1 ファイル
  =============
 
 このセクションのファイルの内容は、実際には「> 」というプレフィックスなしで
 使用してください。
 
 
- 11.1.1 Makefile
+ 12.1.1 Makefile
  ===============
 
 > # <$>NetBSD<$>
@@ -2076,7 +2261,7 @@
 > .include "../../mk/bsd.pkg.mk"
 
 
- 11.1.2 pkg/DESCR
+ 12.1.2 pkg/DESCR
  ================
 
 > GNU version of yacc.  Can make re-entrant parsers, and numerous other
@@ -2084,7 +2269,7 @@
 > of the NetBSD source tree is beyond me.
 
 
- 11.1.3 pkg/PLIST
+ 12.1.3 pkg/PLIST
  ================
 
 > @comment <$>NetBSD<$>
@@ -2102,7 +2287,7 @@
 > share/bison.hairy
 
 
- 11.1.4 パッケージをチェックする 「pkglint」
+ 12.1.4 パッケージをチェックする 「pkglint」
  ==========================================
 
 NetBSDパッケージシステムは、「pkglint」(pkgsrc/pkgtools/pkglintディレクトリー
@@ -2123,7 +2308,7 @@
 チェックをおこないます。
 
 
- 11.2 構築、インストール、パッケージングの手順
+ 12.2 構築、インストール、パッケージングの手順
  =============================================
 
 パッケージのためのディレクトリーと、いくつかの追加のディレクトリーを作成し