[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Packages.txt 7, 8
- Subject: Packages.txt 7, 8
- From: Yuji Yamano <yyamano@kt.rim.or.jp>
- To: www-changes-ja@jp.netbsd.org
- Date: Wed, 23 Feb 2000 13:04:17 +0900
- Message-ID: <871z64muny.wl@kt.rim.or.jp>
- Delivered-To: mailing list www-changes-ja@jp.netbsd.org
- Mailing-List: contact www-changes-ja-help@jp.netbsd.org; run by ezmlm-idx
- User-Agent: Wanderlust/2.2.15 (More Than Words) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.4 (i386-unknown-netbsd1.4.1) MULE/4.0 (HANANOEN)
こんにちは。
しばらくさぼってましたが、ようやく Documentation/Packages/Packages.txt
の 7、8 の訳がおわりました。
次は 6 をやりますけど、いいですかね?
-- やまの
7 構築の手順
============
プログラムを構築するための基本的な手順は常に同じです。最初に、プログラム
のソースファイル(distfile) をローカル・システムへ持ってきて展開します。
NetBSD 上でコンパイルするためのいくつかのパッチを適用した後に、ソフトウェア
を設定し、構築(通常、コンパイルすることによって)します。最後に作成された
バイナリー等を、システムにインストールします。これはまさに NetBSD パッ
ケージ・システムによって実行される手順です。この手順は、中心となる Makefile、
/usr/pkgsrc/mk/bsd.pkg.mk の中で一連のターゲットとして実装されています
7.1 プログラムの場所
====================
次のセクションで NetBSD パッケージ・システムによって実行される手順の概略
を述べる前に、プログラムがインストールされる場所、その場所に影響をおよぼ
す変数について簡単に記述します。
自動変数 PREFIX は、最終的にプログラムのすべてのファイルがインストール
される場所をしめします。通常、$LOCALBASE (/usr/pkg)、または「クロス」
カテゴリーのパッケージのための $CROSSBASE と同じ場所になっています。
もし USE_IMAKE、USE_MOTIF、あるいは USE_X11BASE が定義されていれば、
その値は $X11BASE と同じになります。${PREFIX}の値は、プログラムの
ソース中でこれらのファイルが符号化されるさまざまな場所に使用されるべき
です。詳細に関しては、セクション 4.3 および 6.2 を参照して下さい。
これらの変数のどれかを選択し使用する場合には、以下のルールに従ってください。
* ${PREFIX} は常に 現在のパッケージがインストールされる場所を指します。
パッケージ自身のインストール先のパスを参照する時に、${PREFIX} を使用
してください。
* ${LOCALBASE} は、すべての非 X11 パッケージがインストールされる場所
です。他の非 X11 パッケージによってインストールされたインクルード
ファイルやライブラリの場所をさがすためのコンパイラの -I や -L オプ
ションを指定する場合に、${LOCALBASE} を使用してください。
* ${X11BASE} は、実際に X11 ディストリビューションがインストールされる
場所です。通常の X11 のインクルードファイル(パッケージとしてインストール
されていない)をさがす場合、${X11BASE} を使用してください。
* X11 ベースのパッケージは特別です。/etc/mk.conf の設定によっては、
X11BASE、または LOCALBASE に依存するかもしれません。もし、USE_IMAKE
や USE_MOTIF、USE_X11BASE を Makefile で定義した pkg としてインストール
されたインクルードファイルやライブラリーをさがす場合、${X11BASE} と
${LOCALBASE} の両方を使用する必要があります。
7.2 主なターゲット
================
bsd.pkg.mk で定義された、構築手順で使用される主なターゲットについて述べます。
* fetch:
これは、変数 DISTFILES と PATCHFILES (パッケージの Makefile で定義
された)で指定されたファイルが、ローカルシステムの /usr/pkgsrc/distfiles
に存在するかどうかをチェックします。もし、存在しなければ、変数 PATCH_SITE
で指定されたサイトから、ftp(1) を使用し取得します。PATCH_SITE は
URL の形式で、ftp://-、および http://- が使用できます。これは、ftp(1)
が両方の形式を解釈できるからです。
* checksum:
distfile を取得した後に、MD5 チェックサムを生成し、files/md5 ファイル
に保存されたチェックサムと比較します。もし、チェックサムが一致しなけれ
ば、構築は中断されます。これはパッケージ作成時と同じ distfile が、構築
に使用されていること、つまり、悪意やネットワークの損失によって distfile
が変更されていないことを保証するためです。
* extract:
distfile がローカルシステム上に存在している場合、通常、それらは圧縮
アーカイブフォーマットで保存されているので、展開する必要があります。
もっとも一般なフォーマットは .tar.gz です。もし、すべての distfile
を伸張する必要がないのであれば、伸張するファイルを EXTRACE_ONLY に
設定してください。もしdistfile が .tar.gz フォーマットでなければ、
EXTRACT_CMD、EXTRACT_CMD、 EXTRACT_BEFORE_ARGS、そして EXTRACT_AFTER_ARGS
を設定することにより、それらを展開することができます。
* patch:
展開の後で、PATCHFILES で指定されたパッチとパッケージのパッチサブ
ディレクトリに存在するパッチ、すべてが適用されます。.Z、あるいは
.gz で終る名前のパッチファイルは、適用する前に伸張されます。.orig、
.rej で終るものは無視されます。patch(1) のためのいくつかのオプション
は、PATCH_DIST_ARGS で指定する事ができます。詳細に関してはセクション
4.3 を参照して下さい。
* configure:
ほとんどのソフトウェアは、NetBSD で利用できるヘッダーファイル、システム
コール、およびライブラリルーチンについての情報を必要とします。これは
コンフィギュレーションとして知られているプロセスであり、通常、自動化
されています。大抵の場合、スクリプトがソースと一緒に提供され、それを
実行することによりヘッダーファイルや Makefile 等が生成されます。
プログラムがコンフィギュレーションのためのスクリプトを提供していない
場合、パッケージのスクリプトディレクトリに configure という名前の
スクリプトを置くことができます。そして、それは sh(1) によって実行
されます。
もし、プログラムの distfile が 専用の configure スクリプトを含んで
いる場合、HAS_CONFIGURE を設定することにより、実行することができます。
もし、そのスクリプトが GNU の autoconf スクリプトである場合は、かわり
に、GNU_CONFIGURE を指定してください。どちらの場合も、configure スクリ
プトの引数は、変数 CONFIGURE_ARGS で指定されます。もし設定スクリプトの
名前がデフォルトの configure でない場合は、その名前を CONFIGURE_SCRIPT
に設定してください。
もし、プログラムがコンフィギュレーションのために Imakefile を使用する
のであれば、USE_IMAKE を YES に設定することにより、適切な手順が実行され
ます。(もし、$X11BASE にインストールされるパッケージが欲しいだけで、
xmkmf を実行したくない場合、かわりに USE_X11BASE を使用してください!)
* build:
コンフィギュレーションが終ったら、$MAKEFILE の中で、構築のターゲット
として $ALL_TARGET を指定し $MAKE_PROGRAM を起動することにより、
NetBSD 上にソフトウェアを構築することができます。もし、USE_GMAKE が
設定されていれば、デフォルトの MAKE_PROGRAM は「gmake」です。そうで
なければ、makeが使用されます。MAKEFILE にはデフォルトで Makefile が
設定されます。そして、ALL_TARGET のデフォルトは all です。デフォルト
の構築手順を変更するために、これらの変数を設定することができます。
* install:
構築の段階が完了すると、ユーザーのためにソフトウェアをパブリックな
ディレクトリにインストールする必要があります。。build ターゲットと
同様に、$MAKE_PROGRAM が $MAKEFILE 中で起動されます。ただし、
$INSTALL_TARGETが指定されます。この変数のデフォルトは「install」
です。(もし USE_IMAKE が設定されていれば、「install.man」も追加されます)。
もし、ターゲットが指定されなければ、デフォルトは「build」です。手順
の途中のターゲットが指定された場合、それ以前のすべての手順が実行され
ます。例えば「make build」は、以下と同等のことを実行します。
make fetch
make checksum
make extract
make patch
make configure
make build
7.3 他の役に立つターゲット
=========================
* pre/post-*
前のセクションで述べた主ターゲットのために、二つの補助ターゲット
が存在します。これは主ターゲットに「pre-」や「post-」というプレ
フィックスをつけたものです。これらのターゲットは、特別な設定やイ
ンストール手順のために、主ターゲットが実行される前や後に実行され
ます。例えば、プログラムのコンフィギュレーションスクリプトやイン
ストールターゲットが省略された場合に有用です。これらのターゲット
のために、同名のスクリプトをパッケージのスクリプト用のサブディレ
クトリに置くことができます。セクション4.5を見て下さい。
* do-*:
主なターゲットがおかしな動作をし、それを修正するための変数が存在
しない場合、do-* ターゲットを使用することにより、それらを再定義す
ることができます(do-* ターゲットのかわりに、ターゲット自体を再定義
してはいけません。pre-* や post-* ターゲットが実行されなくなってし
まいます)。通常、再定義する必要はありません。
*reinstall:
もし、「make install」実行後に、いくつかのファイルがきちんとインストール
されなかった事に気がついた場合、このターゲットを使い、再びインストール
する事ができます。この場合、「インストール済み」フラグは無視されます。
* deinstall:
このターゲットは、パッケージを削除するためにカレントディレクトリで
pkg_delete(1) を実行します。動作を制御するために、以下の変数をコマンド
ライン、または /etc/mk.conf で使用することができます。
- PKG_VERBOSE:
pkg_delete(1) コマンドに「-v」オプションを渡します。
- DEINSTALLDEPENDS:
指定されたパッケージに必要な(依存する)すべてのパッケージを削除します。
このターゲットは、指定されたパッケージによってインストールされた
パッケージを削除するために使用されます。例えば、DEINSTALLDEPENDS=1
が x11/kde で指定されている場合、KDE 全体 を削除します。pkg_delete
のコマンドラインに -R を指定すると設定されます。
*update:
このターゲットは、現在のパッケージを最新のものに更新します。最初に
パッケージと、それに依存するすべてのパッケージを削除します。それか
ら最新のバージョンのパッケージをコンパイル、インストールします。
これは、現在どのパッケージがインストールされているかを調べ、
「make deinstall」、「make clean」、「make install」を続けて実行す
るのと同じです。
以前に実行した「make uddate」がさまざまな理由で中断された場合、
パッケージの更新のために、このターゲットを使用することができます。
ただし、「make clean」を実行していない事、あるいは ${WRKDIR} の
依存パッケージのリストを削除していない事を確認してください。そう
でなければ、インストール済みの依存パッケージを使用し、現在のパッ
ケージを自動更新することができません。
「make update」の動作を変更するために、以下の変数をコマンドライン、
または/etc/mk.conf で使うことができます。
- DEPENDS_TARGET:
更新されたパッケージや依存パッケージのために使用されるインストール
ターゲット。デフォルトは「install」です。例えば、
「make update DEPENDS_TARGET=package」のように使用します。
- NOCLEAN:
更新した後、きれいに掃除をしません。調査やその他の目的のために、
更新されたパッケージの作業用ソース等をそのままにしておきたい場合
に役に立ちます。最終的にはソースツリーを掃除してください(以下の
「clean-update」ターゲットを見てください)。そうしなければ、次回の
「make」や「make update」の時に古いソースコードが残っていることで
トラブルがおこるかもしれません。
- REINSTALL:
すべてのパッケージを更新する場合は、${DEPEND_TARGET} でなく
「reinstall」を使用してください。この変数を使用する時には、
「reinstall」ターゲットが使用される事を覚えておいてください。
*clean-update:
カレントディレクトリで「make update」が実行された時に更新される
すべてのパッケージのソースツリーを掃除します。カレントパッケージ
(あるいは、依存パッケージ)がすでに削除されている(例えば make update
を実行した後)場合には、このターゲットを使ってはいけません。もし使用
すると、更新するつもりのパッケージのいくつかを失う可能性があります。
経験的には、初めて「make update」を実行する前、あるいは汚れたパッケージ
ツリーがある場合(例えば NOCLEAN を使用した場合)にのみ使用すべきです。
「make clean-update」の動作を変更するために、以下の変数をコマンドライン、
または /etc/mk.conf で使うことができます。
- CLEAR_DIRLIST:
「make clean」の後で、パッケージのためのディレクトリーのリストを
再構築しません。「make update」で、更新したいすべてのパッケージが
インストールされた場合にのみ使用してください。通常、これは
「make update」で自動的に実行されます。ただし、NOCLEAN 変数の設定
によって実行されない事もあります(上を参照してください)。
* readme:
このターゲットは、README.htmlファイルを作成します。このファイルは
netscape (pkgsrc/www/mozilla) や lynx (pkgsrc/www/lynx) のような
ブラウザで閲覧することができます。作成されたファイルは、ローカルホスト
の ${PACKAGES} ディレクトリにあるパッケージへの参照を含んでいます。
また、FTP_PKG_URL_HOST と FTP_PKG_URL_DIR を元にした URL を参照させる
こともできます。(例えば、ローカルマシン上の /usr/packages ディレクトリ
のバイナリーパッケージを参照する README.htmlファイルを作成したい場合、
FTP_PKG_URL_HOST=file://localhost と FTP_PKG_URL_DIR=/usr/packages
をセットしてください。${PACKAGES} ディレクトリと、そのサブディレクトリ
はすべてのバイナリパッケージで検索されます。
* readme-all:
このターゲットを使い、README-all.html を作成することができます。この
ファイルは NetBSD パッケージコレクションの中の、現在利用可能なすべて
のパッケージのリスト、また、それらが属するカテゴリーと簡単な説明を含
んでいます。このファイルは pkgsrc/*/README.html から作りだされます。
したがって、「make readme」の後に、このターゲットを実行してください。
* cdrom-readme:
これは readme ターゲット(上を見てください)とほとんど同じですが、
CD-ROM に焼かれる pkgsrc ツリーを作る時に使われます。また、
このターゲットは README.html ファイルを作成し、CDROM_PKG_URL_HOST と
CDROM_PKG_URL_DIR に基づくURLへの参照を作ります。
* show-distfiles:
このターゲットは、パッケージを構築するために、どの distfile や
パッチファイルが必要かを表示します。
* show-downlevel:
このターゲットは、パッケージがインストールされていない場合は何も表示
しません。もし、あるバージョンのパッケージがインストールされているが、
現在の pkgsrc のバージョンでインストールさらたものでない場合、警告
メッセージを表示します。このターゲットは、インストール済みのパッケージ
が古いバージョンであり、そのバージョンが削除可能で、最新の物が追加され
ることを表示するために使用されます。
8 デバッグ
==========
FreeBSD のポートからパッケージを作成する時に落ちいりやすい間違いを
チェックし、パッケージを動作させるための手順があります。これは基本的
には前のセクションで説明したことと同じですが、デバッグを助けるための
方法を追加しています。
- FreeBSD コレクションからポートをさがしてください。
- パッケージの Makefile 中の RCS-ID を修正してください。
セクション 4.1 を参考にしてください。
- 未変更の FreeBSD のソースをインポートしてください(cvs アクセスが
可能な場合だけおこなってください。そうでない場合は必要ありません。)。
(cd .../pkgsrc/category/pkgname ; cvs import pkgsrc/category/pkgname \
FREEBSD FreeBSD-current-yyyy-mm-dd)
- CVS にインポートしたら、以下の修正が必要かどうか調べて下さい
(CVS にアクセスできなければ必要ありません)。
- 必要なら Makefile を修正してください。セクション 4.1 を参考にしてください。
- パッチが適切かどうか確認してください。
- すべての pkg/PLIST の先頭行「@comment <$>NetBSD<$>」という行を追加して
ください(セクション5 を参考にしてください)。
- make
- もし何かがうまくいかなければ、修正してください。パッチを作成するために、
ファイルの修正後に diff を再生成してください。
「diff -bu foo.orig foo >../../patch-xx」
(作業する前に、mv patch-xx patch-xx.orig しておいてください)
もし、前のパッチで foo.orig が作成されない場合でも、必ず、どこかに
そのファイルの古いバージョンを持っていて下さい。この作業を繰り返して
ください。:)
- ビルドがすべて OK なら touch /tmp/bla して下さい。
- make install
- find /usr/pkg/ /usr/X11R6/ -newer /tmp/bla >/tmp/x
(又は、LOCALBASE や X11BASE を設定したすべてのディレクトリを対象として)
- pkg_delete blub
- find /usr/pkg/ /usr/X11R6/ -newer /tmp/bla
もし、なにかファイルが見つかれば、それらは pkg/PLIST* に不足している
ので、追加してください。
- pkg/PLIST* と /tmp/x を比較し、前者を修正してください。
( sort /tmp/x >/tmp/x2 ; sort pkg/PLIST >/tmp/P ; sdiff /tmp/x2 /tmp/P )
- make reinstall && make package
- pkg_delete blub
- 「find /usr/pkg/ /usr/X11R6/ -type f -newew /tmp/bla」を実行し、
何も見つからないことを確認してください。
- pkg_add .../blub.tgz
- 遊んでみてください。:)
- pkg_delete - 今までと同様に、いかなるファイルも残っていてはいけません。
(もう一度、上記のfind を実行してください)。
- 提出してください(もし cvs アクセス可能であればコミットしてください)。
セクション 10 が参考になります。