3.1. Makefile の作成

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

# New ports collection makefile for:   oneko
# Date created:     5 December 1994
# Whom:             asami
#
# $FreeBSD$
#

PORTNAME=       oneko
PORTVERSION=    1.1b
CATEGORIES=     games
MASTER_SITES=   ftp://ftp.cs.columbia.edu/archives/X11R5/contrib/

MAINTAINER=     asami@FreeBSD.org
COMMENT=        A cat chasing a mouse all over the screen

MAN1=           oneko.1
MANCOMPRESSED=  yes
USE_IMAKE=      yes

.include <bsd.port.mk>

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

3.2. package 記述ファイルの作成

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

This is a port of oneko, in which a cat chases a poor mouse all over
the screen.
 :
(うんぬん。)

WWW: http://www.oneko.org/

- Satoshi
asami@cs.berkeley.edu

bin/oneko
lib/X11/app-defaults/Oneko
lib/X11/oneko/cat1.xpm
lib/X11/oneko/cat2.xpm
lib/X11/oneko/mouse.xpm
@dirrm lib/X11/oneko

3.3. チェックサムファイルの作成

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

3.4. port のテスト

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

• その port がインストールしないものが pkg-plist に含まれていないこと。

• その port がインストールする、すべてのものが pkg-plist に含まれていること。

• reinstall ターゲットを使うことで、その port が 何度でもインストール可能なこと。

• その port が deintall される際には 後片付けをすること。

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

3.5. portlint によるチェック

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

3.6. port の提出

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

さて、満足のいく 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 への貢献者の一覧やその他のファイルにも載るでしょう。 う〜ん、素晴らしい。:-)

4.1. port 構築の詳細

まず、あなたが 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 を作成するための推奨手順を 順に見ていきましょう。

4.2. オリジナルのソースの入手

(通常の場合、) 圧縮された 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 の記述を ご覧ください)。

4.3. port の修正

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

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

4.4. パッチの適用

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 ターゲットで消す方が簡単です。 できあがった差分に満足したら、 それらをソースのファイルごとに別々のパッチファイルに分割してください。

4.5. コンフィグレーション

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

4.6. ユーザからの入力の扱い

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

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

5.1. オリジナルのソース

ソースは 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 ターゲットを作成して、 デフォルトを上書きすることもできます。 しかし、そこまでする必要があることはめったにないでしょう。

5.2. 名前の付け方

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

PORTNAME=       gtkmumble
PORTVERSION=    0.10

PORTNAME=       gtkmumble
PORTVERSION=    0.10
PORTREVISION=   1

PORTNAME=       gtkmumble
PORTVERSION=    0.2
PORTEPOCH=      1

PORTNAME=       gtkmumble
PORTVERSION=    0.3
PORTEPOCH=      1

5.3. カテゴリ分類

5.4. 配布ファイル

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

MASTER_SITES=         ${MASTER_SITE_XCONTRIB}
MASTER_SITE_SUBDIR=   applications

DISTNAME=      foo
EXTRACT_SUFX=  .tgz

DISTFILES=     source1.tar.gz source2.tar.gz

DISTFILES=     source.tar.gz manual.html
EXTRACT_ONLY=  source.tar.gz

EXTRACT_ONLY=

DISTFILES=      alpha:0 beta:1

MASTER_SITES=   ftp://ftp.example1.com/:source1 \
                ftp://ftp.example2.com/:source2
DISTFILES=      source1.tar.gz:source1 \
                source2.tar.gz:source2

MASTER_SITES=   ftp://ftp.example1.com/:source1 \
                ftp://ftp.example2.com/:source2
DISTFILES=      source1.tar.gz:source1 \
                source2.tar.gz:source2 \
                source3.tar.gz:source2

5.5. MAINTAINER

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

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> は、セキュリティ上の理由で、 保守担当者の権限を剥奪したり担当者を変更する権利を持ちます。

5.6. COMMENT

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

COMMENT=       A cat chasing a mouse all over the screen

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

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

5.7. 依存関係

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

LIB_DEPENDS= jpeg.9:${PORTSDIR}/graphics/jpeg:install

RUN_DEPENDS=   ${LOCALBASE}/etc/innd:${PORTSDIR}/news/inn \
                wish8.0:${PORTSDIR}/x11-toolkits/tk80

BUILD_DEPENDS=unzip:${PORTSDIR}/archivers/unzip

FETCH_DEPENDS=ncftp2:${PORTSDIR}/net/ncftp2

EXTRACT_DEPENDS=
	    unzip:${PORTSDIR}/archivers/unzip

 PATCH_DEPENDS=
	    ${NONEXISTENT}:${PORTSDIR}/java/jfc:extract
	   

BUILD_DEPENDS=   ${NONEXISTENT}:${PORTSDIR}/graphics/jpeg:extract

5.8. 作業ディレクトリの指定

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

PORTNAME=      foo
PORTVERSION=   1.0

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

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

WRKSRC=      ${WRKDIR}/foo

WRKSRC=      ${WRKDIR}/${PORTNAME}

NO_WRKSUBDIR= yes

5.9. CONFLICTS

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

5.10. ビルドのメカニズム

そのソフトウェアがビルドの際に 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 も同様です。

6.1. 共有ライブラリ

その 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 で以下の記述を使用することができます:

INSTALLS_SHLIB= yes
LDCONFIG_DIRS=  %%PREFIX%%/lib/foo %%PREFIX%%/lib/bar

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

6.2. 配布制限がある ports

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

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

6.3. perl の利用

6.4. X11 の利用

6.5. automake, autoconf および libtool の利用

6.6. GNOME の利用

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

6.7. KDE の利用

6.8. Bison の利用

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

6.9. Java の利用

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

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

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

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

6.10. Python の利用

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

6.11. Emacs の利用

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

6.12. Ruby の利用

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

6.13. SDL の利用

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

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

• sdl: devel/sdl12

• gfx: graphics/sdl_gfx

• gui: x11-toolkits/sdl_gui

• image: graphics/sdl_image

• ldbad: devel/sdl_ldbad

• mixer: audio/sdl_mixer

• mm: devel/sdlmm

• net: net/sdl_net

• sound: audio/sdl_sound

• ttf: graphics/sdl_ttf

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

USE_SDL=	  net mixer

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

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

• BUILD_DEPENDS に sdl11-config への依存を追加します。

• CONFIGURE_ENV に SDL_CONFIG 変数を追加します。

• LIB_DEPENDS に選択したライブラリへの依存を追加します。

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

WANT_SDL=yes

.include <bsd.port.pre.mk>

.if ${HAVE_SDL:Mmixer}!=""
USE_SDL+=   mixer
.endif

.include <bsd.port.post.mk>

10.1. USE_MOTIF

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

10.2. MOTIFLIB

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

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

1. Makefile か Imakefile の中で Motif ライブラリが -lXm として使われている場合には、 かわりに MOTIFLIB と書いてください。

2. Imakefile の中で XmClientLibs が使われている場合には、それを ${MOTIFLIB} ${XTOOLLIB} ${XLIB} と書きかえてください。

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

13.1. pkg-message

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

13.2. pkg-install

バイナリパッケージが 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) を見てください。

13.3. pkg-deinstall

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

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

13.4. pkg-req

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

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

13.5. make の変数にあわせた pkg-plist の変更

いくつかの 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 に

OCTAVE_VERSION= 2.0.13
PLIST_SUB=      OCTAVE_VERSION=${OCTAVE_VERSION}

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

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

13.6. pkg-* ファイルの名前変更

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

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

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

14.1. portlint

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

14.2. PREFIX

なるべく 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 に インストールしないことを確認してください。 以下のようにすると、簡単なテストを行なうことができます:

# make clean; make package PREFIX=/var/tmp/port-name

この時、もし 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\" というフラグをコンパイラに渡すかわりに

-DPAGER=\"${PREFIX}/bin/less\"

-DPAGER=\"${LOCALBASE}/bin/less\"

14.3. FreshPorts 正当性テスト

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

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

16.1. はじめに

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

16.2. バイナリの strip

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

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

post-install:
	${STRIP_CMD} ${PREFIX}/bin/xdl

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

16.3. INSTALL_* マクロ

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

• ${INSTALL_PROGRAM} は実行可能なバイナリをインストール (し、その過程で strip 処理)するコマンドです。

• ${INSTALL_SCRIPT} は実行可能なスクリプトをインストールするコマンドです。

• ${INSTALL_DATA} は共有可能なデータをインストールするコマンドです。

• ${INSTALL_MAN} はマニュアルとその他の文書をインストールするコマンドです (圧縮はしません)。

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

16.4. WRKDIR

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

16.5. WRKDIRPREFIX

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

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

16.6. OS の種類やバージョンの識別

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

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

#if (defined(__unix__) || defined(unix)) && !defined(USG)
#include <sys/param.h>
#endif

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

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

#ifdef HAVE_SYS_PARAM_H
#include <sys/param.h>
#endif

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

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

#if (defined(BSD) && (BSD >= 199103))

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

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

これは、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__ マクロを使用してください。

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

• __FreeBSD__ はFreeBSDのすべての版で定義されています。 変更が FreeBSD だけに適用されるとき以外は使用しないでください。 port でよくある strerror() ではなく sys_errlist[] を使うなどは FreeBSDでの変更ではなく BSD の流儀です。

• FreeBSD 2.xでは __FreeBSD__ が 2 と定義されています。 それ以前の版では 1 になっています。 その後の版でもメジャー番号に合うように上げています。

• もし FreeBSD 1.x システムと FreeBSD 2.x 以降のシステムを区別する必要があれば、 上で述べた BSD マクロを使用するのが大抵の場合において正しい答です。 もし FreeBSD 特有の変更であれば (ld を使うときの共有ライブラリ用のオプションなど)、 __FreeBSD__を使い #if __FreeBSD__ > 1 のようにFreeBSD 2.x および、 それ以降のシステムを検出するのはかまいません。 もし 2.0-RELEASE 以降の FreeBSD システムを細かく検出したければ、 以下を使用することができます。

  #if __FreeBSD__ >= 2
  #include <osreldate.h>
  #    if __FreeBSD_version >= 199504
           /* 2.0.5+ release specific code here */
  #    endif
  #endif
  

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

16.7. __FreeBSD_version の値

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

16.8. bsd.port.mk の後に書くこと

.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 の後に書けるものの例です。

# no need to compile lang/perl5 if perl5 is already in system
.if ${OSVERSION} > 300003
BROKEN= perl is in system
.endif

# only one shlib version number for ELF
.if ${PORTOBJFORMAT} == "elf"
TCL_LIB_FILE=  ${TCL_LIB}.${SHLIB_MAJOR}
.else
TCL_LIB_FILE=  ${TCL_LIB}.${SHLIB_MAJOR}.${SHLIB_MINOR}
.endif

# software already makes link for ELF, but not for a.out
post-install:
.if ${PORTOBJFORMAT} == "aout"
       ${LN} -sf liblinpack.so.1.0 ${PREFIX}/lib/liblinpack.so
.endif

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

16.9. 付加的な文書のインストール

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

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

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

post-install:
.if !defined(NOPORTDOCS)
        ${MKDIR} ${DOCSDIR}
        ${INSTALL_MAN} ${WRKSRC}/docs/xvdocs.ps ${DOCSDIR}
.endif

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

• ${DATADIR} は ${PREFIX}/share/${PORTNAME} に展開されます。

• ${DOCSDIR} は ${PREFIX}/share/doc/${PORTNAME} に展開されます。

• ${EXAMPLESDIR} は ${PREFIX}/share/examples/${PORTNAME} に展開されます。

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

%%PORTDOCS%%%%DOCSDIR%%/AUTHORS
%%PORTDOCS%%%%DOCSDIR%%/CONTACT
%%PORTDOCS%%@dirrm %%DOCSDIR%%

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

16.10. ディレクトリ構成

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

16.11. 空のディレクトリの削除

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

 :
lib/X11/oneko/pixmaps/cat.xpm
lib/X11/oneko/sounds/cat.au
 :
@dirrm lib/X11/oneko/pixmaps
@dirrm lib/X11/oneko/sounds
@dirrm lib/X11/oneko

といった感じです。

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

@unexec rmdir %D/share/doc/gimp 2>/dev/null || true

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

16.12. UID

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

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

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

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

bind:*:53:53:Bind Sandbox:/:/sbin/nologin
majordom:*:54:54:Majordomo Pseudo User:/usr/local/majordomo:/nonexistent
cyrus:*:60:60:the cyrus mail server:/nonexistent:/nonexistent
gnats:*:61:1:GNATS database owner:/usr/local/share/gnats/gnats-db:/bin/sh
proxy:*:62:62:Packet Filter pseudo-user:/nonexistent:/nonexistent
uucp:*:66:66:UUCP pseudo-user:/var/spool/uucppublic:/usr/libexec/uucp/uucico
xten:*:67:67:X-10 daemon:/usr/local/xten:/nonexistent
pop:*:68:6:Post Office Owner (popper):/nonexistent:/sbin/nologin
wnn:*:69:7:Wnn:/nonexistent:/nonexistent
pgsql:*:70:70:PostgreSQL pseudo-user:/usr/local/pgsql:/bin/sh
oracle:*:71:71::0:0:Oracle:/usr/local/oracle7:/sbin/nologin
ircd:*:72:72:IRC daemon:/nonexistent:/nonexistent
ircservices:*:73:73:IRC services:/nonexistent:/nonexistent
ifmail:*:75:66:Ifmail user:/nonexistent:/nonexistent
www:*:80:80:World Wide Web Owner:/nonexistent:/sbin/nologin
alias:*:81:81:QMail user:/var/qmail/alias:/nonexistent
qmaild:*:82:81:QMail user:/var/qmail:/nonexistent
qmaill:*:83:81:QMail user:/var/qmail:/nonexistent
qmailp:*:84:81:QMail user:/var/qmail:/nonexistent
qmailq:*:85:82:QMail user:/var/qmail:/nonexistent
qmailr:*:86:82:QMail user:/var/qmail:/nonexistent
qmails:*:87:82:QMail user:/var/qmail:/nonexistent
mysql:*:88:88:MySQL Daemon:/var/db/mysql:/sbin/nologin
vpopmail:*:89:89:VPop Mail User:/usr/local/vpopmail:/nonexistent
firebird:*:90:90:Firebird Database Administrator:/usr/local/firebird:/bin/sh
mailman:*:91:91:Mailman User:/usr/local/mailman:/sbin/nologin
gdm:*:92:92:GDM Sandbox:/:/sbin/nologin
jabber:*:93:93:Jabber Daemon:/nonexistent:/nonexistent
p4admin:*:94:94:Perforce admin:/usr/local/perforce:/sbin/nologin
interch:*:95:95:Interchange user:/usr/local/interchange:/sbin/nologin
squeuer:*:96:96:SQueuer Owner:/nonexistent:/bin/sh
mud:*:97:97:MUD Owner:/usr/local/share/dgd:/bin/sh
msql:*:98:98:mSQL-2 pseudo-user:/var/db/msqldb:/bin/sh
rscsi:*:99:99:Remote SCSI:/usr/local/rscsi:/usr/local/sbin/rscsi
squid:*:100:100:squid caching-proxy pseudo user:/usr/local/squid:/sbin/nologin
quagga:*:101:101:Quagga route daemon pseudo user:/usr/local/etc/quagga:/sbin/nologin
ganglia:*:102:102:Ganglia User:/nonexistent:/sbin/nologin
sgeadmin:*:103:103:Sun Grid Engine Admin:/nonexistent:/sbin/nologin
slimserv:*:104:104:Slim Devices SlimServer pseudo-user:/nonexistent:/sbin/nologin
fido:*:111:111:Fido System:/usr/local/fido:/bin/sh
postfix:*:125:125:Postfix Mail System:/var/spool/postfix:/sbin/nologin
rbldns:*:153:153:rbldnsd pseudo-user:/nonexistent:/sbin/nologin
sfs:*:171:171:Self-Certifying File System:/nonexistent:/sbin/nologin
agk:*:172:172:AquaGateKeeper:/nonexistent:/nonexistent
ldap:*:389:389:OpenLDAP Server:/nonexistent:/sbin/nologin
drweb:*:426:426:Dr.Web Mail Scanner:/nonexistent:/sbin/nologin
qtss:*:554:554:Darwin Streaming Server:/nonexistent:/sbin/nologin
ircdru:*:555:555:Russian hybrid IRC server:/nonexistent:/bin/sh
bacula:*:910:910:Bacula Daemon:/var/db/bacula:/sbin/nologin

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

bind:*:53:
cyrus:*:60:
proxy:*:62:
authpf:*:63:
uucp:*:66:
dialer:*:68:
network:*:69:
pgsql:*:70:
www:*:80:
qnofiles:*:81:
qmail:*:82:
mailman:*:91:
postfix:*:125:
maildrop:*:126:
rbldns:*:153:
qtss:*:554:
ircdru:*:555:

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

16.13. 合理的な port

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

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

16.14. CC および CXX の尊重

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

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

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

CC ?= gcc

CXX ?= g++

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

CC = gcc

CXX = g++

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

16.15. CFLAGS の尊重

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

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

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

CFLAGS += -Wall -Werror

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

CFLAGS = -Wall -Werror

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

16.16. コンフィグレーション (設定) ファイル

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

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

16.17. フィードバック

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

16.18. README.html

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

16.19. Port に BROKEN, FORBIDDEN などの印をつける

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

• BROKEN は、動作しないためインストールすべきでない port 用のものです。これは、ユーザがその port をインストールしないようにしますが、 BROKEN とされた port は Bento クラスタで引き続きビルドされます。 ユーザには port をインストールしてほしくないけれども Bento ではビルドしてほしい場合は、port を BROKEN にしてください。

• FORBIDDEN は、セキュリティ脆弱性があったり、その port をインストールすると FreeBSD システムの安全性に重大な懸念を生じる (たとえば、セキュアでないという評判があるプログラムや、 容易に悪用できるサービスを提供するプログラムなど) port 用のものです。 あるソフトウェアの一部に脆弱性があることが判明し、 修正がリリースされていない場合は FORBIDDEN にすべきです。 理想的には、セキュリティ脆弱性が発見された時は、 脆弱性を抱えた FreeBSD ホストの数を減らすために、 ただちに ports を更新すべきです (我々は、セキュアであるという評判を得たいのです)。 しかし、脆弱性が公表されてから、 脆弱性を抱えたソフトウェアの新しい版がリリースされるまでに無視できない時間があくことがままあります。 セキュリティ以外の理由で port を FORBIDDEN にしないでください。

• IGNORE は、どんな理由であれビルドすべきではない port 用です。 ユーザも Bento クラスタ も、どんな状況であれ IGNORE とされた port はビルドしません。 嘘だと思うなら、port のビルドを妨げるのに IGNORE を使ってみてください。

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

16.20. 必要な回避策

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

• make(1) は、少なくとも 4.8 と 5.0 を含むいくつかのバージョンで、OSVERSION に基づく比較に関してバグがあります。 これは、make describe の最中にエラーを起こすことになりやすく (したがって make index 全体も失敗することに) なります。回避策は、条件比較を括弧にいれることで、たとえば

  if ( ${OSVERSION} > 500023 )
  

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

16.21. その他諸々

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

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

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

16.22. 困ったら…

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

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