我々は、トロイの木馬等を含まないことを保証するために、pkgsrc 開発者からし かバイナリーを受け取りません。これは、誰かを排斥するものではなく、 むしろユーザーを保護するための方針です。しかしながら、あなたの作ったバイ ナリーパッケージをどこかに置き、配布することは自由に行なってもかまいま せん。NetBSD 開発者がバルクビルドを実行してパッケージをアップロードしたい場合は、 Section 7.3.8, “バルクビルドの成果をアップロードする”を参照してください。

最初にパッケージが完全かどうか、コンパイル、実行できるかどうかを確認して ください。 このドキュメントのChapter 20, デバッグ、その他が参考になるでしょう。次に、 パッケージを構成するファイルすべてからなる tar(1) アーカイブを作り、gzip して uuencode してください。 最後に、このパッケージを pkgsrc のバグ追跡システムに送信してください。 send-pr(1) コマンドを使って送信するか、このコマンドがない場合は web ページ http://www.NetBSD.org/support/send-pr.html をご覧ください。この web ページには、説明と、 パッケージを提出できるフォームへのリンクがあります。 これらのかわりに、 sysutils/gtk-send-pr パッケージを使って提出することもできます。

問題報告においては、カテゴリー (category) は “pkg” とし、問題の概要 (synopsis) にパッケージ名とバージョン番号を含めます。 また、説明 (description) のフィールドに、パッケージの簡単な説明 (COMMENT 変数または DESCR ファイルの内容でもOKです) を書きます。uuencode したパッケージのデータは “fix” フィールドに含めます。

複数のパッケージを提出したい場合は、一つのパッケージにつき一つのPRにわけ て送ってください。そうすることで、私たちが追跡しやすくなります。

以上のようにするほか、新しいパッケージは pkgsrc-wip (“pkgsrc work-in-progress”) に入れることもできます。 詳細は、ホームページ http://pkgsrc-wip.sourceforge.net/ をご覧ください。

パッケージの追加、更新、移動、および削除は、すべて pkgsrc/doc/CHANGES-YYYY に書いてください。 このファイルを、これまでと同じ形式のまま最新の状態に保つことは非常に重要なことです。 なぜなら、このファイルはスクリプトにより www.NetBSD.org や他のサイトのページを自動的に更新するために使用されているからです。 また、pkgsrc/doc/TODO ファイルを確認し、 今回更新あるいは削除したパッケージのことが書かれている場合は、 その部分を削除してください。

パッケージの PKGREVISION を引き上げた時に、 その変更がセキュリティーに関するものやその他関連のあるものである場合は、 pkgsrc/doc/CHANGES-YYYY に載せるようにします。 依存性の更新にともなう大量の引き上げについては、ここには書かないでください。 これら以外の場合は、書くべきかどうかは開発者が自分で決めることです。

正しい CHANGES-YYYY の項目を作るのを手伝ってくれる make ターゲット、 make changes-entry があります。このターゲットは CTYPE および NETBSD_LOGIN_NAME というオプションの変数を使います。 一般的な使い方は、まず CHANGES-YYYY ファイルを (あとで衝突して修正する必要が起こらないように) 最新の状態にした上で、パッケージのディレクトリーに cd します。パッケージを更新した場合は make changes-entry だけで十分です。新規パッケージの追加や、パッケージの移動または削除の場合は、 コマンドラインで CTYPE 変数を "Added", "Moved" または "Removed" に設定します。ローカルのログイン名が NetBSD のログイン名と異なる場合は、mk.conf で NETBSD_LOGIN_NAME を設定することができます。 また、このターゲットは、TODO ファイルから、 当該パッケージの項目を自動的に削除してくれます。最後に、 make changes-entry-commit などとして pkgsrc/doc/CHANGES-YYYY の変更を commit するのを忘れないでください。 なお、cvs.NetBSD.org から直接チェックアウトせずに、 ローカルにコピーしたリポジトリーを使って作業している場合などは、 USE_NETBSD_REPO=yes を設定するとよいでしょう。こうすると、 cvs コマンドでは本家リポジトリーを使うようになります。

このセクションは、pkgsrcリポジトリーへの書き込みアクセス権限を持っ ている pkgsrc 開発者にのみ意味があるものです。cvsはカレントディレクトリーから の相対位置にファイルをインポートすることと、cvs importコマンドに渡したパ ス名からリポジトリー中のファイルの位置が決まることを忘れないでください。新 しく作ったパッケージは、“TNF”のベンダータグと“pkgsrc-base”のリリースタ グでインポートしてください。例えば:

$ cd .../pkgsrc/category/pkgname
$ cvs import pkgsrc/category/pkgname TNF pkgsrc-base

また、インポートに使ったディレクトリーは、忘れずに邪魔にならないところに移 しておいてください。そうしておかないと、ソースツリーを次に“cvs update”した ときにcvsが文句を言います。さらに、この新しいパッケージを、categoryの Makefileに忘れずに追加してください。

初回のインポートでは、コミットメッセージにDESCRファイルの内容を含めておき、 どういうパッケージなのかがメーリングリストの読者にわかるようにしてください。

新しいパッケージを追加する場合は、“cvs add”ではなく“cvs import”を使うように してください。"cvs import"なら、単一のコマンドですべて記述することができ、 また、一貫したタグを打つことができるからです。

パッケージを更新するときは、新旧バージョン間の変更点の簡潔で適切で意味のあ る要約を、コミットログに必ず書いてください。そうすべき理由はいろいろありま す:

また、あるパッケージに新しいバージョンがリリースされたというだけの理由で、 CVSリポジトリー上のパッケージを更新しないほうがいいことを認識してください。 私たちは、pkgsrcに含まれるパッケージに関して保守的であることを好みます。と いうのも、開発版やベータ版のパッケージは、pkgsrcが使われる場面のほとんどに 対して、まったくふさわしくないからです。どのバージョンをpkgsrcに入れるのが よいか、分別をもって判断してください。新機能(テストされていない機能があるか もしれません)よりも安定性のほうが好ましいことを念頭に置いてください。

パッケージ名の変更は、なるべくしないようにしてください。

パッケージ名を変更する際には、かならず、 他の Makefile やオプションや buildlink などで古い名前を参照している箇所をすべて修正します。

パッケージ名を変更する際には、さらに、 SUPERSEDES を旧パッケージのパッケージ名と dewey 式のバージョン番号に設定します。 名前が複数回変わっている場合は、複数並べて設定することができます。 これで、新しいパッケージで旧名のパッケージを置き換える作業は完了です。

なお、CHANGES-YYYY ファイルにおける “successor” の記述は、必ずしも、supersedes の意味ではありません。successor は、厳密な同等品でなくても、 代替として使えるものを助言するものでもいいからです。

パッケージの名前の変更や移動は、しないほうがよいのですが、 それでも必要な場合は、以下の手順でおこないます。