[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Packages.txt: 1.100 -> 1.146
Packages.txt: 1.100 -> 1.146 です。ツッコミをお願いします。
対応する原文の差分は
http://cvsweb.NetBSD.org/bsdweb.cgi/pkgsrc/Attic/Packages.txt.diff?r1=1.100&r2=1.146
です。
査読等の便のため、改行位置の調整はしていません。
(調整したうえでcommitします)
--- Packages.txt.orig Tue Sep 20 20:51:30 2005
+++ Packages.txt Sun Sep 25 13:04:03 2005
@@ -1,4 +1,4 @@
-# $NetBSD: Packages.txt,v 1.100 2000/07/21 06:56:35 rh Exp $
+# $NetBSD: Packages.txt,v 1.146 2001/03/23 17:11:17 skrll Exp $
# $Id: Packages.txt,v 1.12 2005/09/20 11:51:30 kano Exp $
###########################################################################
@@ -13,6 +13,7 @@
目次:
=====
+目次作成にはこのコマンドを実行します:
grep -B1 '^.====' Packages.txt | egrep -v '^.[-=]'
@@ -167,7 +168,16 @@
ガイド」を読む事をお勧めします。
- 2.1 どこからpkgsrcを得るか
+ 2.1 必要なもの
+ ==============
+
+NetBSDシステム上で、ソースからパッケージを構築するためには、
+"comp"および"text"配布物一式をインストールしておく必要があります。
+X11関連のパッケージを構築する場合は、さらに"xbase"および"xcomp"
+配布物一式も必要です。
+
+
+ 2.2 どこからpkgsrcを得るか
==========================
パッケージのソースを入手するためには、pkgsrc.tar.gzファイルを
@@ -181,7 +191,7 @@
後は「sup -v /path/to/your/supfile」を実行するだけです。
- 2.2 配布ファイルの取得
+ 2.3 配布ファイルの取得
======================
ひとつ注意しておくことがあります:パッケージシステムを構築するためには、ディ
@@ -200,7 +210,7 @@
らの配布ファイルを/usr/pkgsrc/distfilesに置いてください。
- 2.3 構築とインストール方法
+ 2.4 構築とインストール方法
==========================
上記の作業が完了したら、rootになり適切なディレクトリーに移動してください。
@@ -225,7 +235,13 @@
LOCALBASE=/usr/local
-と設定してください。もちろん、ひとつ例外があります。X11パッケージは伝統的に
+と設定してください。
+なお、ルートにはパッケージ専用の場所を使うべきであり、
+他のプログラムと共有させてはいけません
+(つまり、 LOCALBASE=/usr などとしてはいけません)。
+これは、パッケージシステムがインストールするプログラムなどのファイルが、
+そこにインストールされているかもしれない別のファイルと衝突することがないようにするためです。
+もちろん、ひとつ例外があります。X11パッケージは伝統的に
X11ツリーにインストールされます。X11ツリーのルートの決定には、X11BASEの定義
が使われます。
@@ -244,10 +260,23 @@
トを使うことができます。このターゲットは、 - もし可能ならば - pkg_addを使っ
てバイナリーパッケージをインストールするほか、"make package"をおこないます。
+最後に警告: 標準でないLOCALBASE(またはX11BASE)の設定をしたシステムの場合は、
+各パッケージのインストール前にこれらを設定するようにしてください。
+複数のディレクトリーを同じ目的用に分散して使うことはできないからです。
+そのようなことをすると、pkgsrcはインストール済みのパッケージを正しく検出することができず、
+無惨に失敗することになるでしょう。
+また、コンパイル済バイナリーパッケージは、通常はデフォルトのLOCALBASEである
+/usr/pkgを使って構築されているので、
+標準でないLOCALBASEを使っている場合は、
+とにかくコンパイル済バイナリーパッケージをインストールしては*いけません*。
+
3 コンパイル済みのパッケージを作る
==================================
+ 3.1 単数のパッケージを作成する
+ ==============================
+
上に述べた手順でパッケージを構築しインストールしたら、これをバイナリー・パッ
ケージにすることができます。- 他のNetBSDマシン上で作成したバイナリーを使い
たいと思うかもしれませんし、単にCPU時間を無駄に使わずにすむようにあなたのバ
@@ -267,6 +296,145 @@
の後の「提出」セクションを参照してください。
+ 3.2 全パッケージをbulk buildする
+ ================================
+
+この章では、コンパイル済みバイナリーパッケージを全部揃えたい人のために、その方法を説明します。
+bulk buildを行うと、その時点でシステムにインストールされているパッケージをすべて削除しますので注意してください!
+bulk buildを行うマシンかその近くのNFSサーバーをFTPサーバーに設定することで、
+構築したパッケージをみんなが使えるようにできます。
+さらなる情報はftpd(8)をご覧ください。
+リモートNFSサーバーのストレージを使っている場合、
+実際のコンパイルがNFSストレージ上で行われると非常に遅くなるので、
+そうなっていないことを確認してください。
+
+
+ 3.2.1 設定
+ ==========
+
+ 3.2.1.1 /etc/mk.conf
+ ====================
+
+/etc/mk.confで以下の設定をするとよいでしょう。
+詳細はpkgsrc/mk/mk.conf.exampleを見てください。
+ACCEPTABLE_LICENSESはローカルポリシーに適合するようにしておきます:
+
+ BATCH= yes # required for bulk builds
+ DEPENDS_TARGET?= bulk-install
+ PACKAGES?= ${PKGSRCDIR}/packages/${MACHINE_ARCH}
+ OBJMACHINE?= 1 # use work.${MACHINE_ARCH}
+ WRKOBJDIR?= /usr/tmp/pkgsrc # build here instead of in pkgsrc
+ FAILOVER_FETCH= yes # insist on the correct checksum
+ PKG_DEVELOPER?= yes
+ ACCEPTABLE_LICENSES= shareware \
+ fee-based-commercial-use \
+ no-profit \
+ no-commercial-use \
+ non-commercial-use \
+ limited-redistribution \
+ kermit-license \
+ sun-swing-license \
+ sun-jsdk20-license
+
+完全な構築のためにxpkgwedgeを使いたい場合は、以下を加えます:
+
+ BULK_PREREQ+= pkgtools/xpkgwedge
+
+構築の振舞を変えるためにbulk buildの最中にインストールされている必要があるパッケージがこれ以外にあれば、
+BULK_PREREQ変数に追加することができます。
+ただし、BULK_PREREQに設定する意味があるパッケージは、現在のところxpkgwedgeだけです。
+
+ 3.2.1.2 build.conf
+ ==================
+
+pkgsrc/mk/bulkディレクトリーの``build.conf-example''を``build.conf''
+にコピーし、このファイル中のコメントに従って編集します。このファイルは、
+構築後に作られるログファイルをどこに置くか、構築の報告メールをどこに出すか、
+pkgsrcの場所はどこか、および、どのユーザーにsuして'cvs update'をおこなうか、
+を決める設定ファイルです。
+
+
+ 3.2.2 ほか、環境に関する考察
+ ============================
+
+あなた好みのログインシェルを/usr/localに移しておくか、
+/etc/rc.localでインストールするようにしておきます。
+また、1.5より前のバージョンのOSを使っていたり、
+何らかの理由で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
+
+こうしておかないと、bulk build終了後や、あるいはマシンがリブートやクラッシュした場合に
+sshでログインできなくなります。
+警告しておきましたよ! :)
+
+
+ 3.2.3 操作
+ ==========
+
+すでにインストールされているどのパッケージも必要ない状態にしてください。
+注意: bulk buildの過程で、 *すべての* パッケージが削除されます!!!
+その他のものも(/usr/local, ...から)すべて削除しておいてください。
+root になって、以下のようにタイプします:
+
+ # cd /usr/pkgsrc
+ # sh mk/bulk/build
+
+何らかの理由で前回の構築が完了していない場合(電源断、システムパニックなど)は、
+以下を実行すると、その続きをすることができます:
+
+ # sh mk/bulk/build restart
+
+bulk実行が終わると、その要約がメールで届きます。
+また、"build.conf"ファイルの"FTP"で指定したディレクトリーに、
+構築ログがあります。
+
+
+ 3.2.4 何を実行するのか
+ ======================
+
+bulk buildは三つの段階からなります:
+
+1. build前: スクリプトがpkgsrcを(anon)cvsで更新します。そして、
+ 壊れているdistfileをすべて一掃し、インストールされているパッケージをすべて削除します。
+
+2. bulk build: これは基本的に、'make bulk-package'を、
+ パッケージの構築順序を最適化しておこなうものです。
+ 他のパッケージに依存しないパッケージが最初に構築され、
+ 多くの依存関係を持つパッケージは後に構築されます。
+
+3. build後: 報告を作成し、build.confで指定されたディレクトリーに`broken.html''
+ という名前で置きます。
+ あわせて、この報告の簡略版が構築管理者にメールで送られます。
+
+構築中、壊れているパッケージの一覧が
+/usr/pkgsrc/.broken (OBJMACHINEが設定されている場合は.../.broken.${MACHINE})に作られ、
+構築が壊れているものの個々の構築ログは、各パッケージのディレクトリーに置かれます。
+これらのファイルは、壊れているパッケージを再度構築しようとするような無駄をなくすために、
+bulk-ターゲットが構築が壊れていることを記録するのに使われます。
+また、壊れているパッケージを後でデバッグするためにも使えます。
+
+
+ 3.2.5 必要なディスク容量
+ ========================
+
+現在、1.5/i386
+ではおおむね以下の容量が必要です:
+
+ * distfile: 1500MB (NFSでも可)
+ * 全バイナリー一式: 1000MB (NFSでも可)
+ * コンパイル用の一時領域: 1500MB (ローカルディスクが必要)
+
+各パッケージは、バイナリーパッケージ作成直後にデインストールされた上、作業用ソースも削除されます。
+このため、莫大なディスク容量は必要ありません。
+後になって、このパッケージがまた必要となった場合は、再度構築することなくpkg_addでインストールされるので、
+無駄な再コンパイルの繰り返しは発生しません。
+
+
==============================
第二部: パッケージ構築者ガイド
==============================
@@ -292,7 +460,9 @@
須となるフィールドは、インターネットのサイトからダウンロードされる配布ファ
イルのベース名を指定するDISTNAMEと、そのサイトを指定するMASTER_SITES、パッ
ケージが置かれるカテゴリーを意味するCATEGORIES、パッケージの名前である
-PKGNAMEとメインテイナー名であるMAINTAINERです。これは、そのパッケージを維持
+PKGNAMEと、メインテイナー名であるMAINTAINERと、
+パッケージの一行説明(パッケージ名は自動的に追加されるので、含めないでください)
+からなるCOMMENT変数です。mainainer変数は、そのパッケージを維持
する人による(いつも完全に正しい)決定にへりくつを言う誰かが、活発に苦情を言
うことができるようにするためです。
@@ -303,6 +473,8 @@
${MASTER_SITE_PERL_CPAN}
${MASTER_SITE_TEX_CTAN}
${MASTER_SITE_SUNSITE}
+ ${MASTER_SITE_GNOME}
+ ${MASTER_SITE_SOURCEFORGE}
もしこれらの予め定義されたサイトの1つを選んだ場合、そのサイトのサブディレク
トリーを指定する方法が必要となるかもしれません。これらのマクロは一つ以上の
@@ -317,14 +489,14 @@
現在CATEGORIESの値として以下が使用できます。もし一つ以上にまたがる場合、そ
れらの値はスペースで分けられる必要があります:
- archivers databases ham net security
- audio devel japanese news shells
- benchmarks distfiles lang packages sysutils
- biology editors mail parallel templates
- cad emulators math pkglocate textproc
- comms fonts mbone pkgtools www
- converters games meta-pkgs plan9 x11
- cross graphics misc print
+ archivers audio benchmarks biology cad
+ chat comms converters cross databases
+ devel editors emulators finance fonts
+ games graphics ham japanese lang
+ mail math mbone misc net
+ news parallel print security shells
+ sysutils textproc time wm www
+ x11
全ての利用できるオプション、および変数の記述に関しては、NetBSD packages(7)
マニュアルページを参照してください。
@@ -374,6 +546,11 @@
- もし問題のソフトウェアにホームページが存在するのであれば、MAINTAINERの後
ろにHOMEPAGEを追加してください。HOMEPAGEの値はホームページのURLにしてく
ださい。
+ - パッケージの短い説明をCOMMENT変数に設定してください。
+
+ port2pkg (pkgsrc/pkgtools/port2pkg)は、上述した手順の多くを
+あなたのかわりに行なってくれます--操作は慎重にすべきではありますが。
+
4.2 files/*
===========
@@ -411,9 +588,8 @@
patch-abより前に適用されます。
問題を避けるため、patch-??ファイルはdiff -buフォーマットとし、かつ、曖昧さ
-なしで適用可能であるべきです。(/etc/mk.confでPKG_DEVELOPERを設定することで、
-後者を確実にすることができます - パッチが曖昧さをもって適用されたときのみ、
-構築は失敗するようになります)。なお、将来の変更が難しくなってしまうので、一
+なしで適用可能であるべきです。(曖昧さがあっても強制的にパッチを適用させるため、
+PATCH_FUZZ_FACTOR=-F2を設定することができます)。なお、将来の変更が難しくなってしまうので、一
つのパッチファイルに、複数のファイルへの変更を入れるのは止めてください。
一つ重要なこととして、NetBSD CVSツリーにチェックインした後に問題を引き起こ
@@ -458,10 +634,6 @@
4.4.1 必須のファイル
=====================
- * pkg/COMMENT:
- ソフトウェアについての一行の説明。この中でパッケージの名前を記述する必要
- はありません。- 名前はpkg_*ツールが起動された時に自動的に追加されます。
-
* pkg/DESCR:
ソフトウェアについての複数行の説明。このファイルには適切なクレジットを含
めておいてください。他人があなたのユーモアのセンス(あるいは変わった綴り)
@@ -505,14 +677,15 @@
作成されたファイルをどのように削除するかをすべて知っておかなければならな
いからです。より詳細な情報はpkg_add(1)とpkg_create(1)を参照してください。
- * pkg/REQ:
- インストール、アンインストール(de-install)前に、アカウントが存在するかど
- うか、ユーザーあるいはシステム管理者が使用ポリシーに同意するかどうか等を
- 確認するために起動される要求スクリプトです。
-
- * pkg/MESSAGE
+ * pkg/MESSAGE:
パッケージのインストール後にこのファイルの内容が表示されます。完全にフリー
でないソフトウェアについての法的な通知等に役立ちます。
+ パッケージのMakefileでMESSAGE_SUBSTを使うことで、
+ 変数を簡単に変えられることに注意してください:
+ MESSAGE_SUBST+= SOMEVAR="somevalue"
+ とすると、pkg/MESSAGE中の
+ ${SOMEVAR}
+ は、メッセージ表示前に"somevalue"に置換されます。
4.5 scripts/*
@@ -552,30 +725,6 @@
めにも使用されます。
- 4.7 パッケージのCVSへのインポート
- =================================
-
-新しく作ったパッケージは、「TNF」のベンダータグと「pkgsrc-base」のリリース
-タグでインポートしてください。例えば:
-
- cvs import pkgsrc/<category>/frobnitz TNF pkgsrc-base
-
-FreeBSDポートから派生したパッケージは、「FREEBSD」のベンダータグと
-「FreeBSD-current-YYYY-MM-DD」のリリースタグ(YYYY-MM-DDはFreeBSDのツリーか
-らポートのスナップショットをとってきた日付)でインポートします。そして、通常
-のCVSのオペレーションにより必要な変更をおこなってください。例えば:
-
- cvs import pkgsrc/<category>/mumbler FREEBSD FreeBSD-current-1998-04-01
- cvs rm patches/patch-a
- cvs add patches/patch-aa
- cvs ci
-
-すべてのパッケージの変更、追加をdoc/pkg-CHANGESに記述してください。このファ
-イルを、これまでと同じ形式のまま最新の状態に保つことは非常に重要なことです。
-なぜなら、このファイルはスクリプトによりwww.netbsd.orgのページを自動的に更
-新するために使用されているからです。
-
-
5 PLIST*問題
============
@@ -606,6 +755,8 @@
は気にする必要はありません。もしパッケージの中に共有オブジェクトが見つか
れば、自動的に処理されます。必要であれば ldconfig を実行し、そうでなけれ
ば実行しません。これは FreeBSD ポートを流用する時にいつも問題となります。
+ この自動処理が行われないようにするには、
+ パッケージのMakefileでSHLIB_HANDLINGをNOに設定してください。
* ${MACHINE_ARCH}、${MACHINE_GNU_ARCH}:
emacs、およびperlのようないくつかのパッケージは、それらが構築されたアー
@@ -635,76 +786,45 @@
* PLIST の半自動生成:
"make print-PLIST"コマンドを使って、パッケージの展開後に新しくできた全ファ
- イルにマッチするPLISTを出力することができます。パッケージが、tar(1)その
- 他のファイルのアクセス時刻を更新しない方法を使ってファイルをインストール
- する場合は、それらのファイルを手でpkg/PLISTに書き足すよう注意してくださ
- い!
-
-
- 5.2 MD/MI 対 汎用のPLIST
- ========================
-
-pkg/PLISTのパッケージング・リストは、プラットフォーム間で時々異なります。例
-えば、あるプラットフォームが共有ライブラリーをサポートして、それ以外ではサ
-ポートしていない場合です。これに対応するために、パッケージのMakefile中で条
-件に従い自由にPLISTファイルを定義できるフックが、NetBSDパッケージシステムへ
-導入されました。
+ イルにマッチするPLISTを出力することができます。
+ このターゲットに関するさらなる情報は、下の説明をご覧ください。
- 5.2.1 $PLIST_SRC
+ 5.2 ${PLIST_SRC}
================
ひとつ以上のファイルを、バイナリー・パッケージを構築するためにPLISTのソース
として使用する時は、それらのファイル名を変数PLIST_SRCに設定してください。こ
-れらのファイルは、後でcat(1)によって連結されます。連結の順番は重要な問題な
-ので、以下を参照してください。
+れらのファイルは、後でcat(1)によって連結されます。連結の順番は重要です。
+ 5.3 ${PLIST_SUBST}
+ ==================
- 5.2.2 PLIST-mi、PLIST-md.shared、PLIST-md.static
- ================================================
+MESSAGE_SUBST(上を参照)に似ており、
+以下のようにして、変数とその展開結果を追加することができます:
-もし、PLIST_SRCが設定されていない(通常の場合)、あるいは、pkg/PLISTが存在し
-ない場合、パッケージシステムは、各プラットフォーム間の共有ライブラリーのサ
-ポートの有無を吸収するために、pkg/PLIST-mi、pkg/PLIST-md.shared、
-pkg/PLIST-md.staticを検索します。PLIST-miは機種独立なファイルを含みます。
-PLIST-md*は機種依存のファイルを含んでいます。これは動的ライブラリーと共有ロー
-ディングをサポートしていないアーキテクチャー間で異なります。現在、これは
-perlのパッケージでのみ使用されています。alpha上のperl5は、まだperl/TKのよう
-な拡張された動的ローディングをサポートしていません。PLIST-mi.staticも又、
-(pmax、powerpc以外では) alphaで使用されています。perlの動的ローディングが修
-正されたら、alphaでは使われなくなるでしょう。
-
-(このMI/MD PLISTファイルの扱いは、PLIST_SRCに「PLIST-mi PLIST-md.static」が
-設定されているか、あるいは「PLIST-mi PLIST-md.shared」が設定されているかに
-よって異なります。/usr/pkgsrc/mk/bsd.pkg.mkを見て下さい)。
+ PLIST_SUBST+= SOMEVAR="somevalue"
+これは、PLIST中にある${SOMEVAR}をすべて"somevalue"に置換します。
+デフォルトで置換が行なわれる値については、bsd.pkg.mkを見て
+(PLIST_SUBSTを調べて)ください。
- 5.2.3 PLIST* ファイルの順番
- ===========================
-
-@dirrmステートメントの順番については間違いやすいので注意する必要があります。
-MD @dirrmディレクティブの後に実行されるMI @dirrmディレクティブは、
-PLIST.md-*に記述しなければなりません。これはPLIST-miと
-PLIST.md-{shared/static}が、この順番で連結されるためです。もしMIディレクト
-リーがPLIST-miにリストされれば、それは、MDディレクトリーの前に削除され、う
-まく動作しないでしょう。
-
-例えば、以下のディレクトリーが存在する場合、
-
- foo/mi
- foo/mi/md
-
-PLIST-miは以下のものを含みます。
- <nothing>
-
-そして、PLIST-md.*は以下のものを含みます。
- @dirrm foo/mi/md
- @dirrm foo/mi
-
-これは、いくつかの@dirrmステートメントの重複をまねくでしょう。しかし、すべ
-てが適切に削除されることを保証する唯一の方法です。PLIST_SRCがパッケージ固有
-の設定のために使用される場合にも、同じ注意が必要です。
+ 5.4 Perl5 モジュール
+ ====================
+Perl5 のモジュールがインストールされる場所は、構築プロセスで使われる
+perl のバージョンに応じて変わります。これを扱うために、NetBSD パッケージシステムは、
+インストールされた.packlistファイル(ほとんどの perl5 モジュールが生成します)に列挙された各ファイルに対応する行を、
+PLIST に追加します。
+これは、packlistファイルへのパスをスペースで区切ったリストを
+PERL5_PACKLISTとして定義することで行なわれるようになります:
+
+ PERL5_PACKLIST= ${PERL5_SITEARCH}/auto/Pg/.packlist
+
+PERL5_SITELIB, PERL5_SITEARCH, PERL5_ARCHLIBの各変数は、
+perl5モジュールがインストールされうる三つの場所を表すもので、
+packlistを持たないperl5パッケージで使うことができます。
+この3変数の置換は、PLISTでもおこなわれます。
6 パッケージの修正に関する6つの注意
===================================
@@ -751,7 +871,7 @@
「libtool」はソースファイルから、静的、動的なライブラリー両方を構築する方法
を知っています。したがって、プラットフォーム独立です。
-以下に、libtoolをパッケージで使用するための6つの手順を記述します。
+以下に、libtoolをパッケージで使用するための7つの手順を記述します。
1. USE_LIBTOOL=yesをパッケージのMakefileへ追加します。
@@ -770,8 +890,28 @@
注意してください。OBJSを必要に応じて変更してください。このコマンドは、必
要なものすべて、.a、.so.major.minor、そしてELFのsymlink (必要なら)を自動
的にカレントディレクトリーに作成します。
+ 特に、メジャー番号とマイナー番号がゼロの場合は、
+ -version-infoをかならず含めるようにしてください。
+ そうしないとlibtoolは共有ライブラリーのバージョンを取り除きます。
+
+ また、"-release"オプションは、ある一つの場合に限って、
+ a.outとELF(symlinkを除く)との間で異なる結果をもたらします。
+ libfoo-release.so.x.yの形式のELFライブラリーは、a.outプラットフォーム上では
+ libfoo.so.x.yのsymlinkを持ちます。
+ これは自動的に処理されます。
+
+ -rpath引数は構築されたライブラリーのインストール先ディレクトリーです。
-4. インストールする前のライブラリーに依存するプログラムをリンクする時に、cc
+ PLISTには、.a, .laおよびso, .so.major, .so.major.minorがすべて含まれるべきです。
+
+4. 共有オブジェクト(.so)ファイル(すなわち、dlopen(3)でロードされるファイルであって、
+ 共有ライブラリーでは*ありません*)のリンク時には、
+ ファイルにバージョンが加えられないようにするため、
+ "-module -avoid-version"を使ってください。
+
+ PLISTにはfoo.soの一覧が加わります。
+
+5. インストールする前のライブラリーに依存するプログラムをリンクする時に、cc
かldの前に「${LIBTOOL} --mode=link」を書いてください。このコマンドは、正
しいライブラリー(静的、または共有)を見つけます。ただし、libtoolを使う時
には-Lオプションで相対パスを指定すること(-L../somelibのように)ができない
@@ -791,7 +931,7 @@
${CC} -o someprog -L../somelib/.libs -lsomelib
-5. ライブラリーをインストールするときに、installあるいはcpコマンドの前に
+6. ライブラリーをインストールするときに、installあるいはcpコマンドの前に
「${LIBTOOL} --mode=install」を書いて下さい。そしてライブラリーの名前を
.laに変えてください。例えば、以下のように書く必要があります。
@@ -800,16 +940,9 @@
これは、静的リンクのための.a、共有ライブラリー、必要なsymlinkをインストー
ルし、「ldconfig」を実行します。
-6. PLIST の中に、.a、.la、そしてso.major.minorファイルを追加してください。
- ただし、ELFのsymlink(.so.major, .so)は追加しないでください。これは自動的
- に追加されます。
-
-pkglibtoolは使わないでください! 以前は、パッケージシステムはpkgtoolsによっ
-てパッケージシステム専用版のlibtoolを使っていました。しかし、時間の経過によ
-りこれは時代遅れのものとなり、今では無用のものとなりました。既存パッケージ
-のなかには、USE_PKGLIBTOOLを定義して、この時代遅れのバージョンのlibtoolをい
-まだに使うものがあるかもしれません。新しいパッケージでは、どうかこの定義は
-使わないでください!
+7. PLIST の中に、.a、.la、そしてso, .so.major, .so.major.minor
+ ファイルを追加してください(以前とはやり方が変わっています)。
+
6.3 すでにlibtoolをサポートしているGNUパッケージでlibtoolを使う
===============================================================
@@ -819,9 +952,25 @@
い。パッケージのlibtoolは、do-configureターゲットでltconfigスクリプトにより
作られます。USE_LIBTOOL および LTCONFIG_OVERRIDE が定義されている場合、指定
されたltconfigは、パッケージのlibtoolのかわりにdevel/libtoolを使うよう上書
-きされます。パッケージにdevel/libtoolで置き換え可能なオリジナルの"libtool"
-がすでにある場合は、パッケージのMakefileでLIBTOOL_OVERRIDEを定義する必要が
-あるかもしれません。
+きされます。
+
+パッケージが動的共有オブジェクトのロードに
+libltdlによるプラットフォーム独立な方法を使う場合は、
+MakefileにUSE_LTDL= yesを追記してください。
+
+パッケージによっては、NetBSD上での動作や構築はできるかもしれませんが、
+正しくないlibtoolの使い方をしているものがあります。ありがちな間違いは以下のようなものです。
+
+ * 実行形式やライブラリーで、共有オブジェクト(-module)を依存ライブラリーとしてインクルードする。
+ このこと自体は、以下の二つのうちいずれかが行なわれている場合は、問題になりません。
+
+ 1. その共有オブジェクトが正しく命名されている。すなわち、foo.laではなくlibfoo.laとなっている。
+
+ 2. -dlopenオプションが実行形式のリンク時に使われている。
+
+ * ルーチンの初期化を適切に呼ばずにlibltdlを使う。
+ 関数lt_dlinit()を呼んで、
+ マクロLTDL_SET_PRELOADED_SYMBOLSを実行形式にインクルードすべきです。
6.4 FreeBSDポートに関する注意
=============================
@@ -917,7 +1066,7 @@
ラリーの場所をさがすためのコンパイラーの-Iや-Lオプションを指定する場合に、
${LOCALBASE}を使用してください。
- * ${X11BASE}は、実際にX11ディストリビューションがインストールされる場所で
+ * ${X11BASE}は、実際に(xsrcなどに由来する)X11ディストリビューションがインストールされる場所で
す。通常のX11のインクルードファイル(パッケージとしてインストールされてい
ない)をさがす場合、${X11BASE}を使用してください。
@@ -928,10 +1077,10 @@
ストールされたインクルードファイルやライブラリーをさがす場合、${X11BASE}
と${LOCALBASE}の両方を使用する必要があります。
- * ${X11BASE}は、インストールされたX11ツリーのルートを指します。X11パッケー
- ジのインストール場所を参照する用途には、${X11PREFIX}定義を使ってください
- (これは、xpkgwedgeがインストールされていない場合は${X11BASE}となり、
- xpkgwedgeがインストールされている場合は${LOCALBASE}となります)。
+ * X11パッケー
+ ジのインストール場所を参照する用途には、${X11PREFIX}を使ってください。
+ X11PREFIXは、xpkgwedgeがインストールされていない場合は${X11BASE}となり、
+ xpkgwedgeがインストールされている場合は${LOCALBASE}となります。
7.2 主なターゲット
@@ -970,7 +1119,7 @@
視されます。patch(1)のためのいくつかのオプションは、PATCH_DIST_ARGSで指
定する事ができます。詳細に関してはセクション4.3を参照して下さい。
- /etc/mk.confでPKG_DEVELOPERが設定されていると、パッチに曖昧さがあった場
+ デフォルトでは、パッチに曖昧さがあった場
合にはpatchが異常終了するような特別な引数が渡されます。パッチを修正(再作
成) して、きれいに適用できるようにしてください。そうする理由は、パッチが
うまく適用できても、実は誤った場所に適用されていて、深刻な問題を起こす可
@@ -1124,13 +1273,17 @@
的に実行されます。ただし、NOCLEAN変数の設定によって実行されない事もあ
ります(上を参照してください)。
+ * info:
+ このターゲットは、現在のパッケージに対して"pkg_info"をおこないます。
+ これを使って、たとえば、インストールされているパッケージのバージョンを調べることができます。
+
* readme:
このターゲットは、README.htmlファイルを作成します。このファイルは
- netscape (pkgsrc/www/mozilla)やlynx (pkgsrc/www/lynx)のようなブラウザー
+ navigator (pkgsrc/www/navigator)やlynx (pkgsrc/www/lynx)のようなブラウザー
で閲覧することができます。作成されたファイルは、ローカルホストの
${PACKAGES}ディレクトリーにあるパッケージへの参照を含んでいます。また、
FTP_PKG_URL_HOSTとFTP_PKG_URL_DIRを元にしたURLを参照させることもできます。
- (例えば、ローカルマシン上の/usr/packagesディレクトリーのバイナリー・パッ
+ 例えば、ローカルマシン上の/usr/packagesディレクトリーのバイナリー・パッ
ケージを参照するREADME.htmlファイルを作成したい場合、
FTP_PKG_URL_HOST=file://localhostとFTP_PKG_URL_DIR=/usr/packagesをセット
してください。${PACKAGES}ディレクトリーと、そのサブディレクトリーはすべ
@@ -1176,6 +1329,36 @@
認します。/etc/mk.confでPKG_DEVELOPERが設定されている場合はデフォルトで
実行します。
+ * print-PLIST:
+ パッケージを新規に、または更新のために'make install'した後、
+ 'find -newer work/.extract_done'をもとに新しいPLISTを生成して表示します。
+ PLIST生成は、共有ライブラリーなどに配慮して行われますが、
+ 生成した結果をpkg/PLISTに置く前に再確認するよう*強く*おすすめします。
+ パッケージ更新時には、このコマンドの出力と、
+ 更新前のpkg/PLISTファイルとを比較すると便利でしょう。
+
+ パッケージが、tar(1)その
+ 他のファイルのアクセス時刻を更新しない方法を使ってファイルをインストール
+ する場合は、それらのファイルは'find -newer'で検出されないので、
+ 手でpkg/PLISTに書き足すよう注意してください!
+
+ * bulk-package:
+ bulk buildの実行に使われます。
+ 適切なバイナリーパッケージがすでに存在する場合は、何もしません。
+ そうでない場合は、コンパイル、インストール、パッケージ作成をおこないます。
+ バイナリーパッケージ作成後、ディスクの空き領域を確保するために、
+ ソース、インストールしたばかりのパッケージと依存パッケージは削除されます。
+
+ * bulk-install:
+ 依存パッケージ群をインストールするためのbulkインストールで使われます。
+ 適切なバイナリーパッケージが利用可能な場合、pkg_addでそれをインストールします。
+ そうでない場合は、"make bulk-package"が実行されますが、インストールされたバイナリーは削除されません。
+ バイナリーパッケージがpkg_addでインストールされるのに"適切"である条件は、以下のとおりです:
+
+ - パッケージファイル(Makefile, ...)が、
+ いずれも構築時から変更されていないこと
+ - そのパッケージが依存している(バイナリー)パッケージが、
+ いずれも構築時から変更されていないこと
8 デバッグ
==========
@@ -1239,27 +1422,6 @@
===============================
9.1 GNU autoconfigを利用するパッケージ
- 9.2 tar.gz 以外の配布方法
- 9.3 それ自身のサブディレクトリーを作り出さないパッケージ
- 9.4 カスタムコンフィギュレーションプロセス
- 9.5 DISTNAMEディレクトリーで作成されないパッケージ
- 9.6 一度にすべてのdistfilesを取得する方法
- 9.7 防火壁の内側からファイルを取得する方法
- 9.8 パッチがRCS IDを含む場合
- 9.9 /etc/mk.confから変数を捕まえる方法
- 9.10 pkgについて話しあうためのメーリングリストはありますか?
- 9.11 どうすれば「make fetch」でpassive FTPを使用することができますか?
- 9.12 他のパッケージへの依存
- 9.13 他のパッケージとの衝突
- 9.14 WWWホームページがあるソフトウェア
- 9.15 '古い'名前のまま更新されたdistfileの取り扱い
- 9.16 "Don't know how to make /usr/share/tmac/tmac.andoc" ってどういうこと?
- 9.17 既存パッケージ修正時に、バージョンを上げるにはどうするか
- 9.18 "Could not find bsd.own.mk" - 何がいけないの?
- 9.19 制限つきパッケージ
-
-
- 9.1 GNU autoconfigを利用するパッケージ
======================================
もしパッケージがGNU autoconfを使うのであれば、パッケージのMakefileに以下の
@@ -1275,7 +1437,7 @@
9.2 tar.gz 以外の配布方法
=========================
-パッケージがtar.gz以外の方法で配布されている場合、plan9/samパッケージを参考
+パッケージがtar.gz以外の方法で配布されている場合、editors/samパッケージを参考
にしてください。これはgzipされたシェルアーカイブ(shar)を使っています。いち
おう簡単に説明すると、DISTNAMEフィールドの後でEXTRACT_SUFXに名前を設定し、
パッケージのMakefileに以下の設定を追加してください。
@@ -1290,7 +1452,7 @@
========================================================
パッケージが例えばGNUソフトウェアのようにサブディレクトリーを作るのではなく、
-カレントディレクトリーに展開される場合、もう一度plan9/samを見てください。簡
+カレントディレクトリーに展開される場合、もう一度editors/samを見てください。簡
単にいうと以下の設定が必要です。
> NO_WRKSUBDIR= yes
@@ -1324,8 +1486,32 @@
ftp.netbsd.orgにはdistfilesのアーカイブはありません。そしてftp.freebsd.org
上にあるアーカイブは、移植されていない多くのdistfilesを含んでいます。
-現時点では、「make fetch-list」を/usr/pkgsrcで実行し、その結果のリストを使
-用してくださいとしかいえません、
+現時点では、「make fetch-list」を/usr/pkgsrcで実行し、その結果のリストを
+職場や学校のマシンに持ってきて、使
+用してくださいとしかいえません。
+NetBSDと互換なftp(1)(lukemftpなど)が使えない場合は、
+URLを指定して取得ができるコマンドをFETCH_CMDに指定することを忘れないでください:
+
+自宅で:
+ cd /usr/pkgsrc
+ make fetch-list FETCH_CMD=wget DISTDIR=/tmp/distfiles >/tmp/fetch.sh
+ scp /tmp/fetch.sh work:/tmp
+
+職場で:
+ sh /tmp/fetch.sh
+ /tmp/distfilesをtarで固めて自宅へ持っていく
+
+NetBSDで動いているマシンがあって、*すべての*distfile
+(そのマシンのアーキテクチャー向けではないものも含む)を取得したい場合は、
+上述の'make fetch-list'の方法を使うか、以下のようにして
+distfileを直接取得することができます。
+
+ make mirror-distfiles
+
+NO_{SRC,BIN}_ON_{FTP,CDROM}も無視したい場合は、
+以下のようにしてすべてのものを取得することができます。
+
+ make fetch NO_IGNORE=yes
9.7 防火壁の内側からファイルを取得する方法
@@ -1573,9 +1759,44 @@
うべきでないことに注意してください。これらは、ユーザーのバイナリーパッケー
ジ作成を、無条件にできないようにするからです。
+ 9.20 (n)cursesを使うパッケージ
+ ==============================
+
+パッケージによってはcurses機能を必要としますが、NetBSDには1.4Yで実装されるまではcursesがありませんでした。
+curses機能を使うパッケージ用に、いくつかの変数が用意されています:
+パッケージのMakefileでUSE_CURSESを設定した場合、
+そのシステムでのncursesへの依存関係の必要性に応じて、
+自動的にNEED_NCURSESがYESかNOに設定されます。
+この変数を、たとえば、ncursesを使うかどうかをパッケージに知らせるために、
+configureの引数に追加して使うことができます。
+
+さらに、いくつかのファイル名に対してREPLACE_NCURSESを設定することができます。
+パッケージがncursesを必要としない場合は、
+これが設定された各ファイル中のすべての'ncurses'が'curses'に置換されます。
+ncursesがインストールされていて、かつパッケージのconfigureスクリプトがncursesを優先して使うようになっている場合、
+この変数を使う必要があるかもしれません。
+
+たとえばmail/muttでは、関連する部分は以下の各行です:
+USE_CURSES= YES
+REPLACE_NCURSES= configure configure.in
+[...]
+.include "../../mk/bsd.prefs.mk"
+
+.if defined(NEED_NCURSES) && ${NEED_NCURSES} == "YES"
+CONFIGURE_ARGS+= --with-curses=${LOCALBASE}
+.endif
+
+NEED_NCURSES変数はbsd.prefs.mkで設定されるので、
+この変数を確認するのはbsd.prefs.mkをインクルードした後でなければならないことに注意してください。
+
+
+ 10 提出およびコミット
+ =====================
+
+ 10.1 あなたが作ったパッケージの提出
+ ===================================
- 10 提出
- =======
+ここでは、バイナリーパッケージと"通常の"(ソース)パッケージとを区別する必要があります:
*コンパイル済みのバイナリー・パッケージ:
我々は、トロイの木馬等を含まないことを保証するために、NetBSD開発者からし
@@ -1591,12 +1812,51 @@
い。これは、すべてのファイルをひとつのディレクトリーにおきたいためです。
次に、そのtarファイルを、パッケージのメンテナーがFTPかHTTP (WWW)を使用し
て取得できる場所においてください。最後に、パッケージの名前とバージョンを
- 含む概要、簡単な説明(pkg/COMMENTの内容でもOKです)、そしてtarファイルのURL
+ 含む概要、簡単な説明(COMMENT変数の内容でもOKです)、そしてtarファイルのURL
を書き、「pkg」カテゴリーでsend-pr (問題報告)をおこなってください。
問題報告が処理されたら、あなたに連絡がいきます。そうすれば、tarファイルを
削除してもかまいません。
+ 複数のパッケージを提出したい場合は、
+ 一つのパッケージにつき一つのPRにわけて送ってください。
+ そうすることで、私たちが追跡しやすくなります。
+
+
+ 10.2 コミット: パッケージのCVSへのインポート
+ ============================================
+
+このセクションは、
+NetBSDのpkgsrcリポジトリーへの書き込みアクセス権限を持っているNetBSD開発者にのみ意味があるものです。
+cvsはカレントディレクトリーからの相対位置にファイルをインポートすることと、
+"cvs import"コマンドに渡したパス名からリポジトリー中のファイルの位置が決まることを忘れないでください。
+新しく作ったパッケージは、「TNF」のベンダータグと「pkgsrc-base」のリリース
+タグでインポートしてください。例えば:
+
+ cd .../pkgsrc/<category>/<pkgname>
+ cvs import pkgsrc/<category>/<pkgname> TNF pkgsrc-base
+
+
+また、インポートに使ったディレクトリーは、
+忘れずに邪魔にならないところに移しておいてください。
+そうしておかないと、ソースツリーを次に"cvs update"したときにcvsが文句を言います。
+
+FreeBSDポートから派生したパッケージは、「FREEBSD」のベンダータグと
+「FreeBSD-current-YYYY-MM-DD」のリリースタグ(YYYY-MM-DDはFreeBSDのツリーか
+らポートのスナップショットをとってきた日付)でインポートします。そして、通常
+のCVSのオペレーションにより必要な変更をおこなってください。例えば:
+
+ cd .../pkgsrc/<category>/<pkgname>
+ cvs import pkgsrc/<category>/<pkgname> FREEBSD FreeBSD-current-1998-04-01
+ cvs rm patches/patch-a
+ cvs add patches/patch-aa
+ cvs ci
+
+すべてのパッケージの変更、追加をdoc/pkg-CHANGESに記述してください。このファ
+イルを、これまでと同じ形式のまま最新の状態に保つことは非常に重要なことです。
+なぜなら、このファイルはスクリプトによりwww.netbsd.orgや他のサイトのページを自動的に更
+新するために使用されているからです。
+
11 パッケージの簡単な例: bison
==============================
@@ -1624,6 +1884,7 @@
>
> MAINTAINER= thorpej@netbsd.org
> HOMEPAGE= http://www.gnu.org/software/bison/bison.html
+> COMMENT= GNU yacc clone
>
> GNU_CONFIGURE= yes
> INFO_FILES= bison.info
@@ -1631,13 +1892,7 @@
> .include "../../mk/bsd.pkg.mk"
- 11.1.2 pkg/COMMENT
- ==================
-
-> GNU yacc clone.
-
-
- 11.1.3 pkg/DESCR
+ 11.1.2 pkg/DESCR
================
> GNU version of yacc. Can make re-entrant parsers, and numerous other
@@ -1645,7 +1900,7 @@
> of the NetBSD source tree is beyond me.
- 11.1.4 pkg/PLIST
+ 11.1.3 pkg/PLIST
================
> @comment <$>NetBSD<$>
@@ -1663,7 +1918,7 @@
> share/bison.hairy
- 11.1.5 パッケージをチェックする 「pkglint」
+ 11.1.4 パッケージをチェックする 「pkglint」
==========================================
NetBSDパッケージシステムは、「pkglint」(pkgsrc/pkgtools/pkglintディレクトリー
@@ -1673,7 +1928,6 @@
移動し、「pkglint」を実行するだけです。
> tron@lyssa:/usr/pkgsrc/devel/bison>pkglint
-> OK: checking pkg/COMMENT.
> OK: checking pkg/DESCR.
> OK: checking Makefile.
> OK: checking files/md5.
@@ -1681,7 +1935,7 @@
> looks fine.
指定されたコマンド行の引き数(「man pkglint」を見てください)によっては、より
-きびしいチェックがおこなわれます。例えば「pkglint -a -v」は、大変詳細かつ冗
+冗長なチェックがおこなわれます。例えば「pkglint -v」は、大変詳細かつ冗
長なチェックをおこないます。
@@ -1696,7 +1950,7 @@
> root@pumpy:/u/pkgsrc/lang(1766)# cd bison
> root@pumpy:/u/pkgsrc/lang/bison(1768)# mkdir files patches pkg
-セクション11.1のようにMakefile、pkg/COMMENT、pkg/DESCR、およびpkg/PLISTを作
+セクション11.1のようにMakefile、pkg/DESCR、およびpkg/PLISTを作
り、distfileを取得します。
> root@pumpy:/u/pkgsrc/lang/bison(1769)# make fetch
@@ -1766,8 +2020,7 @@
> cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g version.c
> cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g getopt.c
> cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g getopt1.c
-> cc -g -o bison LR0.o allocate.o closure.o conflicts.o derives.o files.o getargs.o gram.o lalr.o lex.o main.o nullable.o output.o print.o reader.o reduce.o symtab.o warshall.o version.o
- getopt.o getopt1.o
+> cc -g -o bison LR0.o allocate.o closure.o conflicts.o derives.o files.o getargs.o gram.o lalr.o lex.o main.o nullable.o output.o print.o reader.o reduce.o symtab.o warshall.o version.o getopt.o getopt1.o
> ./files.c:240: warning: mktemp() possibly used unsafely, consider using mkstemp()
> rm -f bison.s1
> sed -e "/^#line/ s|bison|/usr/pkg/share/bison|" < ./bison.simple > bison.s1
@@ -1904,7 +2157,7 @@
README
distfiles/
pkgsrc -> /pub/NetBSD/NetBSD-current/pkgsrc
- 1.3/
+ 1.5/
i386/
All/
archivers/
@@ -1922,10 +2175,23 @@
作成:
- cd /usr/pkgsrc ; make install ; make package
- - /usr/pkgsrc/packages を ftp://ftp.netbsd.org/pub/NetBSD/packages/`uname -r`/`sysctl -n hw.machine_arch`へアップロードする。
+ - /usr/pkgsrc/packages を
+ ftp://ftp.netbsd.org/pub/NetBSD/packages/\
+ `uname -r | sed 's@\.\([0-9]*\)[\._].*@\.\1@'`/`sysctl -n hw.machine_arch`
+ へアップロードする。
- 必要ならln -s `sysctl -n hw.machine` `sysctl -n hw.machine_arch`
必要なディスクスペース: 不明
+
+NetBSDのリリースバージョン向けのパッケージは、
+リリースバージョンの番号にあわせたmajor.minorという形式の名前のディレクトリーにアップロードされるべきです。
+"1.5.1"というバージョンのNetBSD向けのパッケージをアップロードするディレクトリーは、
+tinyバージョン番号を省いた"1.5"になります。
+LKMなど、OSバージョンに強く依存するパッケージについては、
+major.minor.tinyリリースディレクトリーを作って、そこに置くことができます。
+このようなパッケージには、バイナリーパッケージ構築者のために何らかの方法で
+"OSVERSION_SPECIFIC=yes"
+変数をつけてください。
###########################################################################