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

Re: Packages.txt 7, 8



こんにちは。

Yuji Yamano <yyamano@kt.rim.or.jp> writes:

> Package.txt の 6章の翻訳が終ったので添付しておきます。

すみません、添付するのをわすれてました。
5、6 章分を添付しておきます。

次は 4.4 pkg/* 以降をやります。


 5 PLIST* 問題 
 =============

このセクションでは、PLIST ファイル(複数の場合もあります、以下を参照
してください)を扱う場合に注意が必要な、いくつかの特別な問題について
述べます。


 5.1 雑多な事
 ============

 * RCS Id : 
   あなたが書いたすべての PLIST ファイルの先頭行に RCS ID が追加されて
   いることを確認してください。

	@comment <$>NetBSD<$>

 * ranlib: 
   ranlib コマンドを PLIST ファイルに記述しないでください。パッケージ
   が削除される時にトラブルをひきおこすかもしれません。構築時にだけ 
   ranlib が実行されること(通常、実行します)を確認してください。そう
   すれば特に気にする必要はありません。これは FreeBSD ポートを流用
   する時にいつも問題となります。

 * ldconfig:
   ldconfig コマンドを PLIST ファイルに記述しないでください。このコマ
   ンドは問題をひきおこす可能性があります。NetBSD では、共有オブジェ
   クトのキャッシングは自動的におこなわれます(あなたが、
   「"Automatic shared object handling」メッセージの出力を見た時にお
   こなわれています)。したがって、これに関しては気にする必要はありま
   せん。もしパッケージの中に共有オブジェクトが見つかれば、自動的に
   処理されます。必要であれば ldconfig を実行し、そうでなければ実行し
   ません。これは FreeBSD ポートを流用する時にいつも問題となります。

 * ${MACHINE_ARCH}、${MACHINE_GNU_ARCH}:
   emacs、および perl のようないくつかのパッケージは、それらが構築
   されたアーキテクチャーに関する情報を、インストールするファイルの
   パス名に埋め込みます。このようなケースに対応するため、実際に使わ
   れる前に、PLIST に前処理がおこなわれます。そして、シンボル
   「${MACHINE_ARCH}」は、「sysctl -n hw.machine_arch」の出力でおき
   かえられます。${MACHINE_GNU_ARCH} が PLIST のどこかにうめこまれて
   いる場合も同様の事がおこなわれます。これは、GNU autoconfigure を
   使用しているパッケージで使われます。

   昔の話:「<$ARCH>」シンボルは「uname -m」の出力によって置きかえられ
   ていました。しかし、もはやサポートされていませんし、削除されています。

 * ${OPSYS}、${OS_VERSION}: 
   いくつかのパッケージでは、OS 名とバージョンをいくつかのパス名に埋め
   込みます。このような場合、PLIST で二つの変数を使用してください。
   ${OPSYS} は「uname - s」の出力で置きかえられます。${OS_VERSION}には
   「uname - r」出力が設定されます。

 * マニュアルページの圧縮: 
   もし、(bsd.own.mk に)MANZ が設定されていれば、マニュアルページは圧縮
   形式でインストールされます。そうでなければ展開された形式でインストー
   ルされます。PLIST ファイルでこれをサポートするために、MANX と 
   MANCOMPRESSED の設定の有無に従い、「.gz」サフィックスがマニュアルペー
   ジに自動的に追加、削除されます。この PLIST ファイルに対する変更は、
   pkg/PLIST 自身にたいしてでなく、それがコピーされる時におこなわれます。 


 5.2 MD/MI 対 汎用の PLIST  
 =========================

pkg/PLIST のパッケージング・リストは、プラットフォーム間で時々異なり
ます。例えば、あるプラットフォームが共有ライブラリーをサポートして、
それ以外ではサポートしていない場合です。これに対応するために、パッケー
ジの Makefile 中で条件に従い自由に PLIST ファイルを定義できるフックが、
NetBSD パッケージシステムへ導入されました。


 5.2.1 $PLIST_SRC  
 ================ 

ひとつ以上のファイルを、バイナリー・パッケージを構築するために PLIST の
ソースとして使用する時は、それらのファイル名を変数 PLIST_SRC に設定して
ください。これらのファイルは、後で cat(1) によって連結されます。連結の
順番は重要な問題なので、以下を参照してください。


 5.2.2 PLIST-mi、PLIST-md.shared、PLIST-md.static
 ================================================

もし、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を見て下さい)。


 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 がパッ
ケージ固有の設定のために使用される場合にも、同じ注意が必要です。


 6 パッケージの修正に関する 6 つの注意
 =====================================

 6.1 CPP 定義
 ============

アプリケーションを NetBSD に移植するためには、コンパイラーがコンパイル
しているシステムを判断する必要があります。したがって、C のプリプロセッサー
がシステムを判断できるように、CPP の定義を使います。

非常に簡単に言うと、多くのFreeBSDポート(NetBSD ではパッケージとよばれる)
が CPPの定義 __FreeBSD__ に依存しています。この定義は FreeBSD 固有の仕様
のためにだけ使用すべきですが、残念ながら今はそうなっていません。また多く
の FreeBSD ポートは、CPU がインテルベースのリトルエンディアンという事実
に依存しています。

4.4 BSD から派生したシステム上で作業しているかどうかをテストするためには、
BSD 定義を使用するべきです。これは <sys/param.h> で定義されています。

        #include <sys/param.h>

また、BSD に固有の部分を、以下の条件でかこむこともできます。

	#if (defined(BSD) && BSD >= 199306)
	...
	#endif

どうか注意して __NetBSD__ 定義を使って下さい。4.4-lite から派生した他のBSD
にない NetBSD 固有の特徴にのみ適用してください。

美的な観点からすると、__FreeBSD__=1 を定義して、単純に FreeBSDポートを使う
ことは避けるべきです。


 6.2 共有ライブラリ- libtool  
 ===========================

NetBSD はさまざまな種類のマシンをサポートします。それらは a.out と 
ELF のような異なるオブジェクトフォーマットを使い、共有ライブラリ、
ダイナミックローディングの有無すらも異なります。これに対応するため
にコマンドそのもの、およびオプションがコンパイラー、リンカなどに渡
される必要があります。すべてのマシンで正しく動作させることは非常に
むずかしく、テストのためにすべてのマシンを持っていない場合は特にそ
うでしょう。「libtool」パッケージはこれを助けます。「libtool」は
ソースファイルから、静的、動的なライブラリー両方を構築する方法を
知っています。したがって、プラットフォーム独立です。

「libtool」を使うためには、まず libtool-pkg への構築依存性を追加して
ください。それからライブラリー構築時に libtool を使用するように、パッ
ケージのソースを変更してください。最後に変更の結果をパッチとして、
パッケージの patches ディレクトリにおいてください。

以下に、libtool をパッケージで使用するための 7 つの手順を記述します。

1. USE_LIBTOOL=yes をパッケージの Makefile へ追加します。

2. ライブラリーオブジェクトのために、 ${LIBTOOL} --mode=compile ${CC}
   を ${CC} に設定します。ライブラリが、提供された Makefile だけを使用
   して構築されるのであれば、CCの定義にこれを追加するだけです。このコマ
   ンドひとつだけで、PIC と 非 PIC のライブラリーオブジェクトを作成しま
   す。したがって、共有ライブラリとそうでないライブラリーの構築規則を別
   々に記述する必要はありません。

3. ライブラリーのリンクのために、「ar」、「ranlib」、「ld -Bshareble」
   コマンドを削除してください。そしてその代わりに以下のコマンドを使用
   してください。

	${LIBTOOL} --mode=link cc -o ${.TARGET:.a=.la} ${OBJS:.o=.lo} -rpath ${PREFIX}/lib -version-info major:minor

   ライブラリーは.la 拡張のために変更され、オブジェクトは .lo 拡張のために
   変更されることに注意してください。OBJS を必要に応じて変更してください。
   このコマンドは、必要なものすべて、.a、.so.major.minor、そして ELF の
   symlink(必要なら)を自動的にカレントディレクトリに作成します。

4. インストールする前のライブラリーに依存するプログラムをリンクする時に、
   cc か ld の前に「${LIBTOOL} --mode=link」を書いてください。このコマン
   ドは、正しいライブラリー(静的、または共有)を見つけます。ただし、libtool
   を使う時には -L オプションで相対パスを指定すること(-L../somelib のよ
   うに)ができない事に注意してください。引数として .la ファイルを使うよ
   うに修正しなければなりません。例えば、

	${LIBTOOL} --mode=link ${CC} -o someprog -L../somelib -lsomelib

   は正常に動作しないので、以下のように変更する必要があります。

	${LIBTOOL} --mode=link ${CC} -o someprog ../somelib/somelib.la

   これで、ライブラリーを正しく扱う事ができます。もし、-L で相対パスを
   使用しなければならず、インストールする前にこのプログラムを実行しない
   場合は、リンクおよびインストールの時に libtool を使用しなくてもかまい
   ません。この場合、-L でサブディレクトリー「.libs」を追加してください。

	${CC} -o someprog -L../somelib/.libs -lsomelib

5. ライブラリをインストールするときに、install あるいは cp コマンドの
   前に「${LIBTOOL} --mode=install」を書いて下さい。そしてライブラリの
   名前を .la に変えてください。例えば、以下のように書く必要があります。

	${LIBTOOL} --mode=install ${BSD_INSTALL_DATA} ${SOMELIB:.a=.la} ${PREFIX}/lib

   これは、静的リンクのための .a、共用ライブラリ、必要な symlink を
   インストールし、「ldconfig」を実行します。

6. PLIST の中に、.a、.la、そして so.major.minor ファイルを追加してください。
   ただし、ELF の symlink は追加しないでください。これは自動的に作成されます。

すでに libtool をサポートしている GNU パッケージのための注意
USE_LIBTOOL=yes をパッケージの Makefile に追加してください。パッケージ
に含まれている libtool をチェックしない、または構成しないように、configure
スクリプトを修正する必要があるでしょう。パッケージの libtool を回避する簡単
な例は、libwww パッケージ、patch-ab を参考にしてください。


 6.3 FreeBSDポートに関する注意
 =============================

Makefile の問題(MANx、CATx、MANCOMPRESSED、ldconfig、RCS IDs)については
4.1 を参照してください。FreeBSD のポートからパッチを流用した場合におこなう
べき作業については 4.3 を参照してください。

FreeBSDポートの最も大きい問題の1つが、多くのポートが ${PREFIX} の設定
を無視し /usr/local にインストールされると仮定されている事です。これを
修正するために、パッケージの Makefile に以下のような行を追加してください。

pre-configure:
        for f in `find ${WRKDIR} -type f -print|xargs grep -l '/usr/local'`; do
\
                ${SED} -e 's:/usr/local:'${PREFIX}':g' < $$f > $$f.pdone && ${MV} $
$f.pdone $$f; \
        done

これは sysutils/rtty パッケージで使用している方法です。これがあなたの
パッケージでも正しく動作することを確認してください。例えば、/usr/local
で何かを探すことは、実際には意味があるかもしれません。したがって、
無条件に /usr/local を置き換えてはいけません。

FreeBSD は、パッケージの Makefile にマニュアルページを列挙し、PLIST に
対応するエントリーを作らないことを決めました。MAN[1-8ln] の定義を削除
する前に、これらを PLIST に追加する必要があるでしょう。 MLINKS と 
CAT[1-8ln] エントリーも同様です。

PLIST のマニュアルページについての注意
.gz サフィックスについては特に注意をはらう必要はありません。多くの 
FreeBSD ポートは、実際には圧縮せずにマニュアルページをインストール
する場合も、PLIST に .gz ページをもっていますが、気にしなくてもかま
いません。我々は、MANZ に従い.gz サフィックスを追加します。つまり、
PLIST のマニュアルページの名前が .gz サフィックスを持っているかどうか
は重要ではありません。もし、それが必要であれば自動的に追加されるし、
不必要な .gz サフィックスがあれば自動的に削除されるでしょう。

いくつかのパッケージは、構築時に bsd スタイルの .mk ファイルを使用します。
したがって MANZ が設定されていれば、インストールされるマニュアルページは 
gzip で圧縮されます。もし、MANZ が設定されていなければ圧縮しません。もし
パッケージが bsd スタイルの .mkファイルを使う場合は、Makefile の中で変数 
MANCOMPRESSED_IF_MANZに yes を設定してください。


 6.4 作者へのフィードバック
 ========================== 

もしパッケージの不具合を発見し動作するように修正した場合、NetBSD 上で動作
させるために特別な手順が必要だった場合、あるいはさまざまなソフトウェアの
拡張をおこなった場合、これらの修正をプログラムのオリジナルの作者へ報告
してください。このようなサポートによってのみ、プログラムの次のリリース
にそれらの修正を反映することができます。そして、NetBSD パッケージシステム
を使用していない人々も、あなたの努力でのおかげで幸せになれます。

フリー・ソフトウェアの理念をサポートして下さい。