FreeBSD port 作成者のためのハンドブック

最小限の Makefile は 次のようなものになります。

おわかりでしょうか。 $FreeBSD$ を 含む行の内容については、気にする必要はありません。 この行は、このファイルが FreeBSD の ports ツリーに 取り込まれる際に、CVS によって自動的に書き込まれます。 もっと詳しい例が見たい場合には、 Makefile のサンプル の セクションをご覧ください。

package にするしないに関わらず、どのような port でも 2 つの記述ファイルが必要です。それは pkg-descr と pkg-plist です。ファイル名が pkg- で始まっていることで 他のファイルと区別できるようになっています。

make makesum と入力するだけで、 (訳注: bsd.port.mk に書かれている) port 生成ルールに従い、 自動的に distinfo ファイルが生成されます。

package 化も含め、その port が思った通りに 動くことを確認してください。 確認の必要な重要ポイントは以下の通りです。

package および deinstall の段階で、 どんな警告 (warning) も出力されないことを確認してください。 ステップ 3 の後、(訳注: その port が作成した) すべての新しい ディレクトリが正しく消去されていることを確認してください。 また、ステップ 4 の後にそのソフトウェアを使用してみて、 package からインストールされた場合にも正しく動作することを 確認してください。

portlint を使い、その port が FreeBSD の ガイドラインに沿っているかどうかを確認してください。 portlint プログラムは ports collection に 含まれています。 特に、 Makefile が 正しい形式になっているか、 package の 名前が正しいかどうかをチェックするのに良いでしょう。

まず、 やって良いこと悪いこと の セクションを読んでください。

さて、満足のいく port が完成したら、残るは それを FreeBSD のメインの ports ツリーに置いて、 他の人にも使ってもらうだけです。 work ディレクトリや pkgname.tgz といった package は 必要ありませんから、まずこれらを消去してください。 あとは shar find port_dir の出力を バグレポートに入れ、 send-pr(1) プログラムを使用して 送ってください ( send-pr(1) についての詳細は バグ報告と一般的な論評 を参照してください)。 もし、圧縮していない状態で 20KB 以上あるような port であれば、 それを ひとつの tar ファイルにまとめて圧縮し、 バグレポートに入れる前に uuencode(1) を使用してください (20KB 以下のものを tar ファイルにして送っても良いのですが、 あまり歓迎されません)。 バクレポートの category は必ず ports , class は change-request としてください (レポートを confidential (機密) 指定には しないでください!)。 また、port 化したプログラムの短い説明文を バグレポートの "Description" フィールドに追加して、 "Fix" フィールドには shar したファイル、 もしくは uuencode した tar ファイルを追加するようにしてください。

もう一度、 オリジナルのソースファイルや work ディレクトリ、 make package で作成した package が 含まれていないこと を確認してください。

port を提出したら、辛抱強くお待ちください。時には、ある port が FreeBSD に取り込まれるまで、数日しかかかりそうもないの に、数ヶ月かかることもあります。 FreeBSD へのコミット待ちの ports の一覧が見られます。

わたしたちがひとたびその port をチェックしたら、必要なら あなたに確認して、それをツリーへ置きます。 あなたの名前は その他の FreeBSD への貢献者 の一覧やその他のファイルにも載るでしょう。 う～ん、素晴らしい。:-)

まず、あなたが port のディレクトリで make と 入力してから起こる一連の出来事について、 順を追って説明します。 ここを読むときには、別のウィンドウに bsd.port.mk を表示しておくと 理解の助けになるかもしれません。

しかし、 bsd.port.mk が何をしているのか 完全に理解できなくても 心配する必要はありません。 それほど多くの人が理解している というわけでは ありませんから…​。 f( ;)_

上記はデフォルトの動作です。これに加えて pre- 何とか や post- 何とか という ターゲットを定義したり、そのような名前のスクリプトを scripts サブディレクトリに置くことも可能で、 それぞれデフォルトの動作の前や後に実行されます。

たとえば、 post-extract ターゲットが Makefile に定義されていて、 scripts サブディレクトリに pre-build というファイルが置かれている場合、 post-extract ターゲットは 通常の展開動作の後に呼び出され、 pre-build スクリプトは デフォルトのコンパイル動作の前に実行されます。 実行する動作が簡単であれば、スクリプトよりも Makefile のターゲットを使用することが 推奨されています。 なぜなら、その port では どのような非標準の動作が必要とされるのか、 一箇所にまとめて書いてあった方が他の人に理解しやすいからです。

デフォルトの動作は bsd.port.mk の do- 何とか という ターゲットで実行されます。 たとえば port を展開するコマンドは do-extract ターゲットに書かれています。 もしデフォルトのターゲットに不満があれば、 Makefile 中で do- 何とか という ターゲットを再定義することにより、 好きなように変更することができます。

これで、ユーザが make と 入力したときに何が起こるのかが理解できたと思います。 では、完璧な port を作成するための推奨手順を 順に見ていきましょう。

(通常の場合、) 圧縮された tar ファイルの形 ( foo.tar.gz あるいは foo.tar.Z ) で オリジナルのソースを入手して、 それを DISTDIR にコピーします。 できる限り、 主流の ソースを 使用するようにしてください。

もとの tar ファイルがどこにあるかを示すために、変数 MASTER_SITES を設定する必要があります。 主なサイトのほとんどについては省略形が bsd.sites.mk で定義されています。 これらのサイト (と付随する定義) を、ソースコード内で同じ情報が繰り返されるのを避けるために、 可能な限り使うようにしてください。 これらのサイトは時とともに変わってゆきますので、そうしないと、 関係者一同にとってメンテナンスの悪夢になってしまいます。

ネットワークへの接続の良好な FTP/HTTP サイトを 見つけることができなかったり、頭にくるような非標準的な形式しか 置いていないサイトしか見つけられないときには、 自分の管理下にあり信頼できる FTP サーバや HTTP サーバ (たとえば、あなた自身のホームページ) に置くこともできます。

そのような便利かつ信頼のおける置き場所が見つからない場合、 我々が ftp.FreeBSD.org に "置き場所"を提供することもできますが、 これはなるべく避けたい解決法です。 配布ファイルは、誰かの freefall アカウントの ~/public_distfiles/ に置かれることでしょう。 その port をコミットする人に、置いてもらえるように頼んでください。 その人は配布ファイルを置いて、 MASTER_SITES を MASTER_SITE_LOCAL にセットし、 MASTER_SITE_SUBDIR には 自分の freefall ユーザ名を 入れておいてくれるでしょう。

その port の配布ファイルが、 作者によるバージョン更新のようなことがなく変更されるなら、 その配布ファイルを あなたのホームページに置いて、 MASTER_SITES の 最初に指定することも考えてみてください。できれば、その port の作者にそういうことをしないようにお願いしてみてください。 そのためには、何かしらのソースコード管理を行うと役に立つでしょう。 あなたが独自のバージョンを置けば、ユーザが checksum mismatch エラーに悩まされることもなくなりますし、FreeBSD の FTP サイトの 保守担当者の負担も減らすこともできます。 また、その port にマスターサイトが一つしか存在しない場合には、 あなたのサイトにバックアップを置き、 それを MASTER_SITES の 2 番目に 指定すると良いでしょう。

その port がインターネット上で入手できる追加パッチを 必要とするのなら、それも取ってきて DISTDIR に置いてください。 それらがメインのソースの tar ファイルとは別のサイトに あったとしても、心配する必要はありません。 そのような状況にも ちゃんと対応できるようになっています (後述の PATCHFILES の記述 を ご覧ください)。

作業用のディレクトリに tar ファイルを展開し、 最新バージョンの FreeBSD 上で正しくコンパイルするために必要な、 あらゆる変更を行ないます。 この処理は最終的に自動化するわけですから、 何を行なったかを 注意深く記録しておきましょう 。 この port が完成した暁には、ファイルの削除、追加、 修正を含むすべての処理が自動化されたスクリプトや パッチファイルで行なえるようになっていなければなりません。

その port のコンパイルやインストールのために必要な手作業が あまりに多いようならば、Larry Wall の芸術的な Configure スクリプトを 参考にしたほうが良いかもしれません。 新しい ports collection は、エンドユーザにとって個々の port が 可能な限り"プラグ & プレイ"かつ 最小のディスク消費で make できることを目指しています。

port の準備段階で追加されたり変更されたりしたファイルは、 再帰的 diff(1) により後で patch(1) に与えられる形にすることができます。 パッチは適当にまとめて patch- という名前のファイルに入れてください。 はパッチが適用される順番を示します - これらは アルファベット順 、 つまり aa が最初、 ab が その次といった順番で処理されます。 お望みなら、 patch-Imakefile とか patch-src-config.h のように、 パッチ対象のファイルのパス名を示す名前を使うこともできます。 これらのファイルは PATCHDIR に置いてください。 そうすれば自動的に適用されるようになっています。 すべてのパッチは WRKSRC からの相対パスにするべきです (通常、 WRKSRC は port の tar ファイルが展開されるディレクトリで、 make が実行されるところと同じです)。 修正やアップグレードを容易にするため、 複数のパッチで同じファイルを修正するのは避けてください (たとえば、 patch-aa と patch-ab が共に WRKSRC/foobar.c を修正するなど)。

RCS にとって特別な意味を持つ文字列をパッチ内に入れないようにしてください。 ファイルを私たちのソースツリーに入れる時、 これらの文字列は CVS によって書き換えられてしまい、 後でまたパッチを使おうとした時にうまくいかないことがあります。 RCS 文字列はドル記号 ( $ ) で囲まれており、 $FreeBSD や $RCS などで始まります。

diff(1) の再帰 ( -r ) フラグを使って再帰的なパッチを作るのは大変結構なのですが、 でき上がったパッチは必ず目でチェックして余計なゴミが入っていないことを確認してください。 よくあるのはバックアップファイル同士の変更点、あるいは Imake や GNU configure を使うソフトウェアの Makefile の変更点が入っている場合などです。 また configure.in を編集して autoconf を使って configure を作り直すときには、 configure の diff は含めずに (それらは良く数千行におよぶことがあります)、 USE_AUTOCONF=yes を定義して configure.in の diff をとってください。

ファイルをまるごと消す場合には、 パッチを使わずに post-extract ターゲットで消す方が簡単です。 できあがった差分に満足したら、 それらをソースのファイルごとに別々のパッチファイルに分割してください。

カスタマイズのために追加したいコマンドがあれば、 configure という名前のスクリプトに入れて scripts サブディレクトリに置いてください。 上で述べたように、 pre-configure あるいは post-configure という Makefile ターゲットや、 スクリプトで処理することもできます。

もし、その port がビルド、コンフィグレーション、または インストールの際にユーザからの入力を必要とするならば、 Makefile 中で IS_INTERACTIVE を設定しなければなりません。 これにより、ユーザが環境変数 BATCH を セットしている場合には、この port の処理がスキップされるので "夜間の無人ビルド" が実行可能になります。 (逆に環境変数 INTERACTIVE がセットされていると、 ユーザからの入力を必要とする port だけ が コンパイルされます)。 これは、連続して ports をビルドするマシン群で、 無駄になる時間を大きく減らします。

もし、適切なデフォルト設定が存在するのであれば、 PACKAGE_BUILDING 変数をチェックして、 それが設定されている場合には ユーザ入力のスクリプトを起動しないようにしてください。 こうすることによって、我々 ports 管理者が CDROM や FTP に 置く package を作成することができます。

ソースは foozolix-1.2.tar.gz といった名前の 標準的な gzip された tar ファイルの形式で DISTDIR に置かれていますか? そうなっていれば、次のステップに進めます。 異なっている場合には、変数 DISTNAME , EXTRACT_CMD , EXTRACT_BEFORE_ARGS , EXTRACT_AFTER_ARGS , EXTRACT_SUFX , DISTFILES のうち いくつかを書き換える必要があります。 どれだけ変更しないといけないかは、その port の配布ファイルが どの程度標準からかけはなれているかによります (最もよくあるのは gzip ではなく普通の compress コマンドで tar ファイルが圧縮されている場合で、そのときは EXTRACT_SUFX=.tar.Z とするだけです)。

最悪の場合には、自分で do-extract ターゲットを作成して、 デフォルトを上書きすることもできます。 しかし、そこまでする必要があることはめったにないでしょう。

Port の Makefile のはじめの部分で port に名前をつけ、バージョン番号を記述し、適切なカテゴリに載せます。

Makefile の第二の部分では、 その port をビルドするためにダウンロードしなければならないファイルと、 それをどこからダウンロードできるか説明しています。

あなたのメールアドレスをここに入れてください。 お願いします。 :-)

MAINTAINER の値は、コメント部のない単一のアドレスしか受け付けられません。 user@hostname.domain という形式を利用してください。この項目には、 あなたの本名などの説明用のテキストは一切いれないでください。 (そうしても、ただ bsd.port.mk が混乱するだけです)。そういう情報は pkg-descr に書いてください。

保守担当者 (maintainer) の責任に関する詳細説明は、 Makefile 中の MAINTAINER の セクションを参照してください。

Port のメンテナがユーザからの更新要求に (主な公休日を除いて) 2 週間返答しなかったら、 保守担当者の持ち時間が切れたとみなして、 保守担当者の明示的な了承なしに更新して構いません。 保守担当者が 3 ヶ月以内に返答しない場合は、 その保守担当者は無断で不在にしているとみなして、 問題となっている port の保守担当者を入れ替えても構いません。 例外となるは、ports 管理チーム < portmgr@FreeBSD.org > または セキュリティオフィサチーム < security-officer@FreeBSD.org > が保守しているものです。このグループが保守している port に対しては許可を得ずにコミットしてはいけません。

ports 管理チーム < portmgr@FreeBSD.org > は、何か理由があれば、 誰かを保守担当から外したり、別の方を担当者にする権利を持ちます。 セキュリティオフィサチーム < security-officer@FreeBSD.org > は、セキュリティ上の理由で、 保守担当者の権限を剥奪したり担当者を変更する権利を持ちます。

その port の 1 行の説明です。 コメントにはパッケージ名 (やソフトウェアのバージョン) を 入れないでください 。 コメントは大文字で始め、最後にピリオドは付けないでください。 たとえば、こんな具合です。

Makefile 中で、 COMMENT 変数は MAINTAINER 変数の直後においてください。

COMMENT 行は、port の 1 行の要約としてユーザに示されるので、 70 文字未満に抑えるようにしてください。

多くの port は他の port に依存しています。 必要なものすべてがユーザのマシン上に存在することを 保証するために使用可能な、7 つの変数が用意されています。 よくあるケースのためにあらかじめ設定された依存変数に加え、 いくつかの依存関係の制御のための変数があります。

それぞれの port は作業ディレクトリに展開されるので、 作業ディレクトリは書き込み可能でなければなりません。 Ports システムは、デフォルトでは DISTFILES が ${DISTNAME} というディレクトリに展開されると想定します。 つまり、次のように設定していたら、

その port の配布ファイルの内容は、最上位のディレクトリが foo-1.0 で、 残りのファイルはそのディレクトリの下に置かれているということです。

そうでない場合に上書きできる変数がたくさんあります。

あなたが作成している package が他の packageと (ファイルの衝突や実行時の非互換性により) 共存できないのであれば、 CONFLICTS 変数にその package の名称を挙げてください。 * や ? のようなシェルの補完が利用できます。package 名は /var/db/pkg にあるのと同じ形式で並べてください。

そのソフトウェアがビルドの際に GNU make を使う場合には、 USE_GMAKE=yes をセットしてください。 configure を使う場合には、 HAS_CONFIGURE=yes をセットしてください。 GNU configure を使う場合には、 GNU_CONFIGURE=yes をセットしてください (これにより HAS_CONFIGURE もセットされます)。 configure に追加の引数を渡したい場合には、 追加部分を CONFIGURE_ARGS に指定してください。 (デフォルトの引数リストは、GNU configure では --prefix=${PREFIX} に、 GNU でない configure では空リストになります。) GNU autoconf を使う場合には、 USE_AUTOCONF=yes をセットしてください。 これにより GNU_CONFIGURE もセットされ、 configure を実行する前に autoconf が実行されます。

そのソフトウェアが X Window System のアプリケーションなどで、 imake を使って Imakefile から Makefile を作成する場合には、 USE_IMAKE=yes を指定してください。 そうするとコンフィグレーションステージで自動的に xmkmf -a が実行されます。 もし -a フラグが問題を引き起こすなら、 さらに XMKMF=xmkmf をセットしてください。 もし、その port が imake を使用するけれども install.man ターゲットを持たない場合には、 NO_INSTALL_MANPAGES=yes をセットしてください。 ついでに、そのソフトウェアの作者を探し出して八つ裂きにするといいでしょう。 (- -#)_

そのソフトウェアの元々の Makefile が all 以外のものをメインのターゲットとしている場合には、それを ALL_TARGET に指定してください。 install と INSTALL_TARGET も同様です。

その port が共有ライブラリのインストールを行なう場合、 make 変数 INSTALLS_SHLIB を定義してください。 これにより、 bsd.port.mk が post-install ターゲットの実行時に新しいライブラリがインストールされたディレクトリ (通常は PREFIX/lib ) に ${LDCONFIG} -m を実行し、 共有ライブラリキャッシュへの登録が行なわれるようになります。 また、この変数が定義されている場合、共有ライブラリを インストールしたユーザが それをすぐに使い始められるように、 また、削除の際には そのライブラリが まだ存在していると システムに誤認されないように、 適切な @exec /sbin/ldconfig -m と @unexec /sbin/ldconfig -R のペアが pkg-plist ファイルに 指定されているように扱われます。

必要であれば、 共有ライブラリがインストールされるディレクトリのリストを格納する make 変数 LDCONFIG_DIRS を定義することにより、 新しいライブラリがインストールされるデフォルトの位置を上書きすることも可能です。 例えば、その port が共有ライブラリを PREFIX/lib/foo と PREFIX/lib/bar に インストールする場合、 Makefile で以下の記述を使用することができます:

pkg-plist の他の部分と同様に、 LDCONFIG_DIRS の内容も sed(1) による処理が行なわれるため、ここでも PLIST_SUB に指定した置換が行なわれることに注意してください。 PREFIX には %%PREFIX%% を、 LOCALBASE には %%LOCALBASE%% , X11BASE には %%X11BASE%% を使用することを推奨します。

ライセンスにはさまざまなものがあり、なかには、 アプリケーションをパッケージ化するやり方、営利目的で販売できるか、 といったことに制限をかけているものがあります。

そのような場合、次の節で説明されている変数が設定できます。

FreeBSD/GNOME プロジェクトは、ある特定の port が使っている GNOME コンポーネントを特定するために 独自の変数群を使っています。 FreeBSD/GNOME プロジェクトのページに その変数のわかりやすい一覧 があります。

この節はまだ書かれていません。

あなたが作成している port の構築、実行、 または配布ファイルの展開に Java™ 開発キット (JDK) が必要なら、 USE_JAVA を定義してください。

Ports Collection には、さまざまなベンダの JDK のいろいろなバージョンがあります。 あなたが作成している port がその中のいずれかのバージョンを使わなければならないなら、 どれを使うか指定できます。最新のバージョンは、 java/jdk14 です。

以下は、 USE_JAVA を設定した port で行われる設定の一覧です。

Port のデバッグ情報を得るのに、 java-debug make ターゲットが使えます。 これは、前述の変数の多くについて値を表示します。

この節はまだ書かれていません。

この節はまだ書かれていません。

この節はまだ書かれていません。

USE_SDL 変数は、 devel/sdl12 や x11-toolkits/sdl_gui など、SDL ベースの ports への依存を自動設定するのに使われます。

今のところ、次の SDL ライブラリが認識されます。

したがって、ある port が net/sdl_net と audio/sdl_mixer に依存していたら、構文は次のようになります。

net/sdl_net と audio/sdl_mixer が必要とする devel/sdl12 の依存も自動的に追加されます。

USE_SDL を使うと、以下のことが自動的に行われます。

SDL ライブラリが利用できるかどうか調べるためには、 WANT_SDL 変数を使ってください。

Motif が無いとコンパイルできない port の Makefile では、この変数を指定してください。 これにより、Motif を持っていない人がこの port をコンパイルしようとするのを未然に防ぎます。

この変数は bsd.port.mk によって適当な Motif ライブラリの指定に置き換えられます。Port のソースの Makefile や Imakefile で Motif ライブラリを参照しているところを、 この変数を参照するようにパッチを適用してください。

代表的な例としては以下の二つがあげられます:

なお MOTIFLIB は通常、 -L/usr/X11R6/lib -lXm か /usr/X11R6/lib/libXm.a に置き換えられます。 したがって前に -L や -l をつける必要はありません。

もしインストールする人にメッセージを表示する必要がある場合には、 そのメッセージを pkg-message に置くことができます。 この機能は pkg_add(1) の後の追加のインストール手続きを表示するときなどに重宝します。

バイナリパッケージが pkg_add(1) でインストールされるときに実行する必要のあるコマンドがあれば、 pkg-install スクリプトを使って実行することができます。 このスクリプトは自動的に package に加えられ、 pkg_add(1) によって 2 回実行されます。 1 回目は ${SH} pkg-install ${PKGNAME} PRE-INSTALL として、2 回目には ${SH} pkg-install ${PKGNAME} POST-INSTALL として実行されます。 どちらのモードで実行されているかは $2 を調べることによってわかります。 環境変数 PKG_PREFIX には package がインストールされるディレクトリが設定されます。 詳細は pkg_add(1) を見てください。

このスクリプトは package が削除される際に実行されます。

このスクリプトは、 pkg_delete(1) から 2 回実行されます。1 回目は ${SH} pkg-install ${PKGNAME} DEINSTALL と、2 回目は ${SH} pkg-install ${PKGNAME} POST-DEINSTALL という形で実行されます。

(訳注: 実行されるマシンの状態に応じて) その port をインストールするべきか、そうでないかを判断する必要があるときには、 "要件 (requirements)" スクリプト pkg-req を作ることができます。 インストールや削除を実行すべきかどうか判断するために、 このスクリプトがインストールや削除を実行する際に自動的に実行されます。

このスクリプトはインストール時には pkg_add(1) により pkg-req ${PKGNAME} INSTALL として実行され、 削除時には pkg_delete(1) により pkg-req ${PKGNAME} DEINSTALL として 実行されます。

いくつかの port、特に p5- ports などは、configure のオプション (あるいは、 p5- の場合は perl のバージョン) によって pkg-plist を変える必要があります。 これを容易に実現するために pkg-plist 中の %%OSREL%% , %%PERL_VER%% , %%PERL_VERSION%% は適切に置き換えられるようになっています。 %%OSREL%% の値はオペレーティングシステムの数字で表されたリビジョンです (たとえば 4.9 )。 %%PERL_VERSION%% は perl のバージョン番号全体 (たとえば 5.00502 ) で、 %%PERL_VER%% は perl のバージョン番号からパッチレベルを引いたものです (たとえば 5.005 )。

他の置き換えが必要であれば、 PLIST_SUB 変数に VAR=VALUE という形式のペアのリストを設定することによって、 pkg-plist 中の %%VAR%% は VALUE に置き換えられます。 たとえばバージョンに固有のたくさんのファイルをインストールする場合には、 Makefile に

と書いて、 PLIST 中のバージョン番号が表われるすべてのところに、 %%OCTAVE_VERSION%% と書きます。 このようにしておけば、port をアップグレードするときに、 何十行 (時として、何百行) も pkg-plist を書き替えないですみます。

この書き換えは ( マニュアル の追加も) pre-install と do-install ターゲットの間に pkg-plist を読み TMPPLIST (デフォルトは WRKDIR/.PLIST.mktmp ) に書き込むことによって行なわれます。 もし、あなたの port が PLIST を実行時に生成するのであれば、 pre-install の間かその前に行なうようにしてください。 また、書きかえられたあとのファイルを編集する必要がある場合には、 post-install で TMPPLIST を書きかえてください。

pkg-* ファイルの名前はすべて変数を使用して定義されていますので、 必要であれば Makefile 中で変更可能です。 いくつかの ports で一つの pkg-* ファイルを共有する場合や、 上記のファイルに書き込みをしなければならないときなど特に便利です ( pkg-* サブディレクトリに直接書き込むのが良くない理由については WRKDIR 以外への書きこみ を参照してください)。

以下に変数名と そのデフォルト値のリストを示します。 ( PKGDIR のデフォルト値は ${MASTERDIR} になっています。)

PKG_ARGS を上書きせずにこれらの変数を変更するようにしてください。 PKG_ARGS を変更すると、これらのファイルは port から正しく /var/db/pkg にインストールされなくなります。

送付や commit をする前に portlint を使ってチェックしましょう。

なるべく port は PREFIX に対する相対パスにインストールすることができるように心がけてください (この変数の値は USE_X_PREFIX か USE_IMAKE が指定してある時には X11BASE (デフォルトは /usr/X11R6 )、 そうでない場合には LOCALBASE (デフォルトは /usr/local ) にセットされます)。

サイトによってフリーソフトウェアがインストールされる場所が違いますので、 ソース内で /usr/local や /usr/X11R6 を明示的に書かないようにしてください。 X のプログラムで imake を使うものについては、 これは問題にはなりません。 それ以外の場合には port の scripts/Makefile で /usr/local (imake を使わない X のプログラムは /usr/X11R6 ) と書いてあるところを、 ${PREFIX} に書き換えてください。 この値は port のコンパイルおよび、 インストールの全段階において、自動的に下位のプロセスに渡されます。

そのアプリケーションが PREFIX を 使用しないで、何かを直接 /usr/local に インストールしないことを確認してください。 以下のようにすると、簡単なテストを行なうことができます:

この時、もし PREFIX の外に 何かがインストールされていた場合、package 生成プロセスは ファイルが見つからないと文句を言うはずです。

ただし、これは そのソフトウェアが内部で決め打ちの参照を していないかどうか だとか、他の port によってインストールされる ファイルを参照する際に LOCALBASE を 正しく使用しているかどうかをテストしているわけではありません。 その port を他の場所にインストールした状態で、 /var/tmp/port-name に 対するインストールを試みることにより、 そのテストをすることができるでしょう。

USE_X_PREFIX は本当に必要な時 (つまり X のライブラリをリンクしたり、 X11BASE 以下にある ファイルを参照したりする必要がある時) 以外には 設定しないでください。

変数 PREFIX の値は port の Makefile やユーザの環境で変更することもできます。 しかし、個々の port が Makefile でこの変数の値を明示的に設定することはなるべくしないでください。

また、他の port によりインストールされるプログラムや ファイルを指定する場合には、直接的なパス名を使用するのではなく 上で述べた変数を使用してください。 たとえば less のフルパスを PAGER というマクロに入れたい場合は、 -DPAGER=\"/usr/local/bin/less\" というフラグをコンパイラに渡すかわりに

(X Window System を使う port の場合には

) を渡してください。 こうしておけば、システム管理者が /usr/local を まるごと どこか他の場所に移していたとしても、その port が そのまま使える可能性が高くなります。

http://www.FreshPorts.org/ には、FreeBSD ports へ commit されたものについて、 自動的に正当性テストを行う仕組みがあります。 このサービスに登録すると、あなたが commit したものについて、 正当性テストでエラーが起きると連絡が行きます。

このサービスを利用したい場合、必要なのは FreshPorts のアカウントだけです。登録したメールアドレスが @FreeBSD.org のものであれば、 ウェブページの右側にサービスを選択するリンクがあるはずです。 FreshPorts にアカウントを持っていても @FreeBSD.org のメールアドレスを利用していない場合、メールアドレスを @FreeBSD.org に変え、登録したあとで、 メールアドレスをまた変更してください。

このセクションではソフトウェアを port する上で、 良くある落し穴などについて説明します。 このリストを使ってあなた自身が作成した port のチェックはもとより、 さらに 障害報告データベース にある他の人が提出した port のチェックもできます。 PR データベースにある、 他の人が作成した port のチェックもできます。 あなたがチェックした port についてのコメントを バグ報告と一般的な論評 にしたがって送ってください。 PR データベースにある port をチェックすることは、 わたしたちがそれらを commit するのを早めるとともに、 何をしているかをあなたが理解していることも証明します。

バイナリは特に必要がなければ、手動で strip しないでください。 すべてのバイナリは strip すべきですが、 INSTALL_PROGRAM マクロがバイナリのインストールと strip を同時に行います (次節をご覧ください)。

ファイルを strip する必要はあるものの INSTALL_PROGRAM マクロを使いたくない場合は、 ${STRIP_CMD} でプログラムを strip できます。 これは、多くの場合 post-install ターゲット内で行われます。たとえば

インストールされた実行形式がすでに strip されているかどうかは file コマンドで確認できます。 "not stripped" と表示されなければ strip されていることを示しています。 さらに、 strip(1) はすでに strip されたプログラムは strip せず、問題なく終了します。

あなた自身の *-install ターゲットでファイルの正しいモードとオーナを保証するために、 必ず bsd.port.mk で提供されているマクロを使用してください。

これらは基本的に install コマンドに適切なフラグを与えたものです。 それらは distfile の Makefile で、頭に "BSD_" が付けられた (つまり BSD_INSTALL_PROGRM というような) 形で使うことができます。 どのようにこれらを使用するかは以下の例を見てください。

WRKDIR の外に存在するファイルには何も書き込んではいけません。 port のビルド中に書き込み可能なことが保証されているのは WRKDIR の中だけです (書き込み不可のツリー上での port ビルドの例については、 CDROM からの ports のインストール を参照のこと)。 pkg-* ファイルを変更する必要があるときには、 ファイルを上書きするのではなく 変数の再定義 により 行なうようにしてください。

WRKDIRPREFIX を尊重していることを確認してください。特に、別の port の WRKDIR を参照しているときには気を付けてください。 正しい場所は、 WRKDIRPREFIXPORTSDIR/subdir/name/work です。 PORTSDIR/subdir/name/work や .CURDIR/../../subdir/name/work ではありません。

また、 自分で WRKDIR 定義するときには先頭に ${WRKDIRPREFIX}${.CURDIR} が付いていることを確認してください。

どのバージョンの Unix で動かすかによって、 変更や条件つきコンパイルが必要なコードに出くわすこともあるでしょう。 そのような変更を行なう場合には、 古い FreeBSD システムへのバックポートや、 CSRG の 4.4BSD, BSD/386, 386BSD, NetBSD, OpenBSD 等、 他の BSD システムへの移植が可能なように、 できるだけ汎用的な変更を行なうことを心がけてください。

4.3BSD/Reno (1990) と、それより新しいバージョンの BSD コードを区別するには、 <sys/param.h> で定義されている BSD マクロを利用するのがよいでしょう。 このファイルがすでにインクルードされていれば良いのですが、 そうでない場合には、その .c ファイルの 適当な場所に以下のコードを追加してください。

これらの二つのシンボルが定義されているシステムには必ず sys/param.h があるはずです。 もしそうでないシステムを発見したら、 FreeBSD ports メーリングリスト までメールを送ってわたしたちに伝えてください。

あるいは、GNU Autoconf のスタイルを使用することもできます。

この方法を使用するときには、 Makefile 中の CFLAGS に -DHAVE_SYS_PARAM_H を加えることを忘れないようにしてください。

いったん sys/param.h がインクルードされると、

このようにしてそのコードが 4.3 Net2 コードベース、 またはそれより新しいもの (例: FreeBSD 1.x, 4.3/Reno, NetBSD 0.9, 386BSD, BSD/386 1.1 とそれ以前) の上でコンパイルされているかを検出できます。

これは、4.4コードベース、またはそれより新しいもの (例: FreeBSD 2.x, 4.4, NetBSD 1.0, BSD/386 2.0 とそれ以後) の上でコンパイルされているかどうかを検出するために使用します。

4.4BSD-Lite2 コードベースでは BSD マクロの値は 199506 になっています。 これは参考程度の意味合いしかありません。 4.4-Lite ベースの FreeBSD と 4.4-Lite2 での変更がマージされたバージョンとを区別するのに使用するべきものではありません。 この目的のためにはかわりに {freebsd} マクロを使用してください。

以下は控え目に使ってください。

これまで、何百もの port が作られてきましたが、 {freebsd} が正しく使われたのは一つか二つの場合だけでしょう。 以前の port が間違ってふさわしくない場所で そのマクロを使っているからといって、 それをまねする理由はありません。

以下は、 sys/param.h で定義されている __FreeBSD_version の便利な一覧です。

.include <bsd.port.mk> の行の後には何も書かないようにしてください。 大抵の場合は Makefile の中程のどこかで bsd.port.pre.mk をインクルードして、 最後に bsd.port.pre.mk をインクルードすることによって避けることができます。

前者はいくつかの変数の定義だけをして Makefile でのテストに使用し、後者は残りを定義します。

以下は bsd.port.pre.mk で定義される重要な変数です (これは、すべてではありません。 完全なリストは bsd.port.mk を参照してください)。

以下は bsd.port.pre.mk の後に書けるものの例です。

BROKEN= と TCL_LIB_FILE= の後にスペースではなくタブを使うことを覚えていましたか? :-)

普通のマニュアルや info ファイルの他にユーザにとって有用だと思えるような文書がある場合には、 PREFIX/shared/doc の下にインストールしてください。 これは前記と同様 post-install ターゲットの中から行なうと良いでしょう。

まず、あなたの port のために新しいディレクトリを作ります。 どの port の文書か簡単にわかるような名前にする必要がありますので、 普通は PORTNAME を使うと良いでしょう。 もちろん、ユーザが異なるバージョンのものを同時に使うことが予想される port の場合には PKGNAME をそのまま使っても構いません。

ユーザが /etc/make.conf でこの部分を禁止するために NOPORTDOCS という変数をセットしている場合には、 これらの文書がインストールされないようにしてください。 こんな具合です。

ここでは、変数をいくつかと、それを Makefile で利用した時にどう展開されるかを説明します。

文書ファイルおよびディレクトリはすべて pkg-plist の中に %%PORTDOCS%% を頭につけて書く必要があります。 たとえば、次のようにしてください。

インストール時に pkg-message ファイルを利用してメッセージを表示することができます。詳細は pkg-message を使う のセクションを参照してください。

インストール時には PREFIX の正しいサブディレクトリにファイルを置くように心がけてください。 ソフトウェアによっては新しいディレクトリを一つ作って、 ファイルを全部それに入れてしまうものがありますが、 それは良くありません。 また、バイナリ、ヘッダファイルとマニュアル以外のすべてを lib というディレクトリに入れてしまう port もありますが、これも BSD 的なファイルシステム構成とはうまく合いません。 これは以下のように分散すべきです。 etc にセットアップ/コンフィグレーションファイル、 libexec に内部で使用されるプログラム (コマンドラインから呼ばれることのないコマンド)、 sbin に管理者用のコマンド、 info に GNU Info 用の文書、 そして share にアーキテクチャに依存しないファイルが入ります。 詳細については hier(7) を参照してください。 /usr の構成方針はほとんどそのまま /usr/local にもあてはまります。 USENET "ニュース"を扱う ports は例外です。 これらはファイルのインストール先として PREFIX/news を使用します。

ports は削除の際に、 自分自身を消去したあとに (ディレクトリの) 削除をするようにしてください。 これは大抵の場合 @dirrm の行を ports が作成するすべてのディレクトリについて加えることによって実現できます。 親ディレクトリは子ディレクトリを先に消さないと消せないことに注意してください。

といった感じです。

しかし時として、 他の port とディレクトリを共有しているために @dirrm がエラーを返すことがあります。 rmdir を @unexec から呼びだすことによって、 警告(warning)なしで空のディレクトリのみを削除することができます。

これを使えば、たとえ他の port がファイルをインストールしていて PREFIX/shared/doc/gimp が空でない場合でもエラーメッセージは表示されませんし、 pkg_delete(1) が異常終了することもありません。

あなたの port が、 インストールされるシステム上に特定のユーザを必要とする場合は pkg-install スクリプトから pw コマンドを実行して自動的にそのユーザを追加するようにしてください。 net/cvsup-mirror の port が参考になるでしょう。

あなたの port がバイナリの package としてインストールされる場合とコンパイルされる場合の両方で、 同じユーザー/グループ ID を使わなければならないのなら、50 から 999 の間で空いている UID を選んで登録してください。 japanese/Wnn6 の port が参考になるでしょう。

既にシステムや他の port で利用されている UID を使わないように十分注意してください。

現在の 50 から 999 までの間の UID は以下のとおりです。

以下は、現在予約されている GID の一覧です。

このリストを最新の状態に保つためにも、 この範囲の UID や GID を予約するような port を作ったり、 既存の port にそのような改変を行なってわたしたちに送るときには UID の予約に関する注意書きをつけてください。

Makefile は単純かつ適切であるべきです。もし、 Makefile を数行短かくできたり、 もっと読みやすくできるのであればそうしてください。 たとえば、 シェルの if 構文を使うかわりに make の .if 構文を使う、 EXTRACT* の再定義で代用できるのであれば do-extract を再定義しない、 CONFIGURE_ARGS += --prefix=${PREFIX} とするかわりに GNU_CONFIGURE とする、などです。

何かをするのに自分で新しくコードをたくさん書かなければならなくなった場合は、 戻って bsd.port.mk であなたがやろうとしていることが既に実装されていないか見直してください。 読むのは大変ですが、難しく見える問題で bsd.port.mk が簡単な解決法を提供しているものが数多くあります。

Port は CC および CXX 変数を尊重すべきです。ここで言いたいのは、port は、既存の値を上書きしてこれらの変数をまるごと設定しなおすべきではなく、 その代わり必要な値を既存の値に追加してゆくべきだということです。 そうすれば、すべての ports に影響するビルドオプションをグローバルに設定できます。

Port がこれらの変数を尊重しない場合は、 Makefile に NO_PACKAGE=ignores either cc or cxx を追加してください。

CC と CXX 変数を尊重している Makefile の例を次に示します。 ?= に注意してください。

こちらは、 CC 変数も CXX 変数も尊重していない例です。

FreeBSD システム上では、 CC および CFLAGS 変数は、どちらも /etc/make.conf で定義できます。最初の例では、システム全体の定義を保存している /etc/make.conf で値がすでに設定されてない場合に限って、値を設定します。 2 番目の例では、すでに設定されていた内容を上書きしてしまいます。

CFLAGS 変数は尊重すべきです。 ここでいいたいのは、port は、 既存の値を上書きしてこの変数をまるごと設定しなおすべきではなく、 その代わり必要な値を既存の値に追加してゆくべきだということです。 そうすれば、すべてての ports に影響するビルドオプションをグローバルに設定できます。

port がこれを尊重しない場合は、 NO_PACKAGE=ignores cflags を Makefile に加えてください。

CFLAGS 変数をきちんと考慮した Makefile の例を以下に示します。 += の部分に注目してください。

次は CFLAGS 変数を考慮しない Makefile の例です。

CFLAGS 変数は、FreeBSD システムの /etc/make.conf で定義されています。 最初の例では既存の定義を保存しつつ CFLAGS 変数にオプションフラグを追加しているのに対し、 二番目の例では既存の定義をすべて無効にしてしまっています。

もしあなたの port が設定ファイルを PREFIX/etc に置く必要がある場合には、それを単純にインストールしたり、 pkg-plist に加えては いけません 。 こうしてしまうと pkg_delete(1) によってユーザが苦労して作ったファイルが消えてしまったり、 新しくインストールする時に上書きされてしまったりします。

かわりに見本となるファイルをサフィックス ( filename.sample が良いでしょう) を付けてインストールして メッセージ を表示し、 ソフトウェアを動かす前にユーザがそのファイルをコピーして編集をしなければならないことを知らせましょう。

port を作るためにソフトウェアに変更を加えたら、 なるべく原作者にその旨を伝えてパッチ等を送ってください。 これらが次のリリースに取り入れられればアップグレードが楽になります。

README.html というファイルを含めてはいけません。 このファイルは、cvs コレクションの一部ではなく、 make readme コマンドで生成されるファイルです。

ある port にセキュリティ脆弱性があることが判明したり、 根本的に壊れてしまい修正に何時間もの注意深い作業が必要になったり、 基本的には廃れてしまったものの、 何らかの理由で ports ツリーには残される (もちろんあとで修正しますよね?) という日が来るのは避けられません。 ある port が壊れていることを示すために、port の Makefile では 3 つの make 変数が使えます。以下の make 変数の値は、 その port が壊れている理由を説明するためにユーザに示されます。 それぞれの make 変数は、ユーザと Makefile を処理する自動化システムに対して根本的に異なる意味を伝えますので、 正しい make 変数をお使いください。

この変数を使うのは、port が更新できない場合の最後の手段にしてください。 ずっと壊れたままの port は、ports ツリーから完全に削除すべきです。

古いバージョンの FreeBSD のソフトウェアにあるバグを回避する必要があることがあります。

となります。4.9 と 5.2 で port のインストールテストを行っても、 この問題は 見つかりません 。

ファイル pkg-descr と pkg-plist はそれぞれ二重にチェックしてください。 再検討してもっと良い記述があればそれに置きかえてください。

GNU General Public License (GNU一般公有使用許諾) のコピーは (すでにあるので) コピーしないでください。 お願いします。

法律に関することには十分注意をはらってください。 わたしたちに法律に反するような形でソフトウェアの配布をさせないでください!

わたしたちに質問を送る前に、 既存の port の例と bsd.port.mk をちゃんと読んでください! ;)

それでもわからないことがあったら一人で悩まないでどんどん質問してください! :-)