問題を避けるため、patch-*ファイルは diff -buフォーマットとし、かつ、曖昧 さなしで適用できるようにします。(曖昧さがあっても強制的にパッチを適用させる ため、PATCH_FUZZ_FACTOR=-F2を設定することができます)。 さらに、各パッチファイルは一つのファイルに対する修正だけを含むようにし、 また、一つのファイルを複数のパッチファイルによって修正するようなことはしないようにします。 こうすることで、将来の変更が簡単になります。

各パッチファイルは、以下のような構造となっています: 最初の行には パッチそのものの RCS Id があります。2 行目は、見栄えをよくするため、 空にします。これより後には、そのパッチによる各変更についてのコメントを書きます。 これには標準的な事例がいくつもあります。

あらゆる事例において、 そのアプリケーションのコードを理解している開発者がパッチを利用できるようにするため、 パッチにはコメントを書くようにします。上流の開発者に対しては特に注意が必要です。 たいていの場合、私たちの将来の作業を減らすために、 上流の開発者にパッチを採用してもらいたいからです。

一つ重要なこととして、NetBSD CVSツリーにチェックインした後に問題を引き起こ すので、パッチファイルにRCS IDを含ませないように注意してください。 この問題を避けるため、 pkgtools/pkgdiff パッケージの pkgdiff コマンドを使ってください。

さらに自動化するため、同パッケージのmkpatchesを使ってパッチ一式を作ることを おすすめします。あなたがやらねばならないことは、ファイルの編集前に cp -p filename filename.origのようにするか、あるいはさらに簡単に、同パッケージの pkgviを使って、元のファイルをfilename.origの名前でバックアップしておくだ けです。この方法でパッケージをアップグレードした場合、patchdiffを使って、新 しいパッチと既存のパッチを簡単に比較することができます。 patches 以下のファイルは新しいファイルに置き換えられますので、 変更点が適切かどうかをしっかり確認してください。

パッケージを作り終えたとき、忘れずにmake makepatchsumコマンドでパッチファ イルのチェックサムを生成するようにしてください。Section 11.2, “distinfo”を参照してくだ さい。

(たとえば、マニュアルページのインストール先を pkgsrc の流儀に合わせて変えるといったものではなく) distfile の問題を正すパッチを追加した場合は、 そのパッチをバグ報告としてメンテナーに送ってください。 こうすることで、pkgsrc を使っていない利用者も幸せになれますし、 通常は、将来のバージョンでパッチを削除することができるようになります。

パッチファイルのファイル名は、通常は patch-path_to_file__with__underscores.c という形式です。 多くのパッケージでは、以前使われていた patch-[a-z][a-z] という形式をまだ使っていますが、 パッチを新たに作る場合は、ファイル名を含んだ形式にしてください。pkgtools/pkgdiff に含まれている mkpatches は、 パッチファイルのファイル名を自動で処理します。

pkgsrc の複数のパッケージが同じ distfile を使っているなどの理由で、 複数のパッケージの間でパッチを共有したい場合は、 PATCHDIR をパッチファイルのある場所へのパスに設定します。 たとえば以下のようにします。

PATCHDIR= ${.CURDIR}/../xemacs/patches

作者その他のメンテナーが配布しているパッチファイルは、 PATCHFILES に列挙することができます。

置いておきたいパッチがあるがpkgsrcにcommitすべきものではない場合、それを pkgsrcツリーの外の $LOCALPATCHES ディレクトリーに置いておくことができます。こ のディレクトリーツリーはpkgsrcと同様の “category/package”の構造を持つように し、パッチを各パッケージのディレクトリー(すなわち$LOCALPATCHES/$PKGPATH)に 置くようになっています。たとえば、 pkgsrc/graphics/pngに私的なパッチを適用す るようにしたい場合は、そのパッチを $LOCALPATCHES/graphics/png/mypatchに置き ます。このディレクトリーにあるファイルはすべてパッチファイルとして扱われ、 pkgsrcのパッチが適用された後に、このパッチが適用されます。

コードの移植性に関する問題を修正する場合は、 プリプロセッサーの細工を使ってオペレーティングシステムやプラットフォームを判別するようなことはしてはいけません。 そのような方法では、各 OS 固有性の詳細が適切に抽象化できないため、 他のオペレーティングシステムに対する移植性を損なってしまいます。

一般的な決めごとは、 アプリケーションを構築しているオペレーティングシステムそのものを検査するのではなく、 必要としている特有の機能を検査する、というものです。 たとえば、kqueue は NetBSD において利用可能であると仮定して __NetBSD__ マクロを kqueue 対応の条件として使う、 ということはせずに、kqueue 自体を検出するようにするのです。 そしてこれは、一般的には configure スクリプトにパッチを適用することになります。 ある OS が他の OS (たとえば kqueue を実装した Linux) のインターフェースを採用してはいけない理由はまったくありませんが、 前述のようにオペレーティングシステムそのものを検査してしまうと、 そのような状況に対応することができません。

もちろん、機能を検査することは、 一般的に、開発者側の負担が多くなります。しかし、 機能を検査するようにすれば、その結果はきれいな変更となり、 他の多くのプラットフォームで動作させられる可能性があります。 また、本家のソースに統合される可能性が高くなることはいうまでもありません。 正しくない限り動かないの哲学を忘れないでください。

典型的な例としては、以下のようなものがあります。

case ${target_os} in
netbsd*) have_kvm=yes ;;
*)       have_kvm=no  ;;
esac

AC_CHECK_LIB(kvm, kvm_open, have_kvm=yes, have_kvm=no)

#if defined(__NetBSD__)
#  include <sys/event.h>
#endif

#if defined(HAVE_SYS_EVENT_H)
#  include <sys/event.h>
#endif

int
monitor_file(...)
{
#if defined(__NetBSD__)
        int fd = kqueue();
        ...
#else
        ...
#endif
}

int
monitor_file(...)
{
#if defined(HAVE_KQUEUE)
        int fd = kqueue();
        ...
#else
	...
#endif
}

さらなる情報は、Making packager-friendly software の記事 (第 1 部、第 2 部) をお読みください。この記事では、ソフトウェアをパッケージ化しやすくする方法について、 複数の点での詳細をまとめています。ここで述べられている提案は、いずれも、 私たちが pkgsrc の作業をした経験から集められたものですので、 パッチの作成に際しても役に立つかもしれません。

常に、常に、常に、 パッケージに施したあらゆる移植性に関する修正や改良点を、 本家の開発者に還元するようにしてください。 彼らに移植性についての注意を喚起して、将来のバージョンが無修正で NetBSD で構築できるようにするためには、そうするしかないのです。 また、将来のバージョンの配布ファイルの利用者は、 フィードバックされた修正をパッケージのコードから直接利用することができるようになります。

フィードバックをする方法は、一般的には、 パッチをきれいに書き直し (pkgsrc で追加されたパッチは、 時にはクイックハックであることがあるからです)、 フィードバック先のプロジェクト用の適切な追跡システムに対してバグ報告をし、 変更が受け入れられるよう本家の作者とともに作業する、というものです。 フィードバックをすることで、pkgsrc のパッケージを単純なものとし、 さほど労力を割かずに将来の変更ができるようにするということが、 特に重要です。

フィードバックをしたら、上流のバグレポートの URL を パッチのコメントに追加してください。

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