Port の Makefile
のはじめの部分で port
に名前をつけ、バージョン番号を記述し、適切なカテゴリに載せます。
PORTREVISION
変数は単調増加する値です。
PORTVERSION
が増加した時 (つまり、
新しいオフィシャルベンダーリリースが行なわれた時) には
いつでも 0 にリセットされます。
また、その値が 0 でない場合には package 名に追加されます。
PORTREVISION
の変更は、(例えば
pkg_version(1) 等の) 自動化ツールが、
新たな package が入手できることを示すのに使われます。
その port から作られる package の内容や構造に
大きな影響を与える変更を行なった時には、
PORTREVISION
を増やしてください。
PORTREVISION
を上げる必要がある変更の例:
セキュリティ上の脆弱性やバグを修正するため、または その port に新しい機能を追加するためのパッチの追加。
package のコンパイル時オプションの有効化や
無効化のための port の Makefile
の変更。
パッキングリストの変更や、package のインストール時の 挙動の変更 (たとえば、ssh のホストキーのような package の 初期データを生成するスクリプトの変更など)。
その port が依存する共有ライブラリのバージョンを 上げる場合 (新しいバージョンの共有ライブラリが インストールされた後に、そのライブラリに依存していた 古い package をインストールを試みる場合、 その package は新しい libfoo.(x+1) ではなく 古い libfoo.x を探そうとするため、インストールに失敗します。 (訳注: そのため、PORTREVISION を上げた package を 作成する必要があるわけです))。
ひそかに port 配布ファイルの変更が行なわれ、
その機能に大きな変化があった場合。
つまり、distinfo
の修正を
必要とするような配布ファイルの変更が行なわれ、
新旧のバージョンの diff -ru
を取ると
些細とは言えない変更が認められるにもかかわらず、
オリジナルのバージョン番号が変更されていないことから
PORTVERSION
の変更は難しい場合。
PORTREVISION を上げる必要の無い変更の例:
生成される package に機能の変化が起らないような port スケルトンのスタイル変更。
生成される package に影響しないような
MASTER_SITES
その他の
port に対する機能変更。
誤植の修正などの些細な変更で、その package のユーザが アップグレードを必要とするほどには重要でないパッチ。
以前にはコンパイルが通らなかった package を
ビルド可能にするための修正 (その port が以前にビルド可能だった
プラットフォームにおいて、その変更により何らかの機能的な
違いが発生しない場合に限ります)。
PORTREVISION
は package
の内容を反映したものなので、その package
が以前にビルド可能でなかったのなら、変更を示すために、
PORTREVISION
を
増やす必要はありません。
経験的な判断方法としては、ある port にコミットされた変更が
(それが強化や修正によるものであれ、新しい package による
実質的な効能であれ)、アップデートすることにより、
誰もが利益を受けるような何かかどうか、また定期的に ports
ツリーを更新している人に更新を強制するということに値するか自問してみることです。
もし答がイエスであれば、
PORTREVISION
を上げるべきでしょう。
ソフトウェアのベンダや FreeBSD の port 作成者は、 以前のものよりも小さい数字のバージョン番号をつけたソフトウェアをリリースするといった、 何か馬鹿げたことをすることが時々あります。 例をあげると、ある port が foo-20000801 から foo-1.0 になるといった具合です (数字として見ると 20000801 は 1 よりも大きいため、 間違って前者の方が新しいバージョンとして扱われてしまいます)。
このような場合には PORTEPOCH
バージョンを増やしてください。
上のセクション 0 で説明したように、
PORTEPOCH
がゼロでない場合には、
それがパッケージ名の後ろにつけられます。絶対に
PORTEPOCH
を減らしたり、ゼロにリセットしてはいけません。
さもないと、以前に作成された package との比較に失敗する
(つまり、その package が古くなっていることがわからない) ためです:
新しいバージョン番号 (上の例では1.0,1
) は
依然として前のバージョン番号 (20000801) よりも
数字としては小さいのですが、自動化ツールが
サフィックス ,1
を特別扱いすることで、
以前の package には明示されていないサフィックス
,0
よりも新しいことがわかります。
誤って PORTEPOCH
を削除したりリセットしたりすると、終わりのない悲劇に見舞われます。
上記の議論を理解できないなら、
わかるまで議論をたどるかメーリングリストで質問してください。
大多数の ports では、PORTEPOCH
が
必要になることは まず無いものと考えられています。
また、注意深く PORTVERSION
を使用することで、
そのソフトウェアの将来のリリースがバージョン構造を変更する必要が出てきた場合にも、
多くの場合前もって対応しておくことができるでしょう。
しかし、「スナップショット」リリースのように、
オフィシャルなバージョン番号を持たないベンダーリリースが行なわれた時には、
FreeBSD 版の port 作者によるケアが必要になります。
そういったリリースに対し、
リリース日付を使ったラベルを付けたいという誘惑にかられることがあるでしょうが、
そうすると新しい「オフィシャル」リリースが行なわれた時に、
上の例で示したような問題が起きることでしょう。
例えば、あるソフトウェアのスナップショットリリースが
20000917 に行なわれ、以前のバージョン番号が 1.2 だったとすると、
そのスナップショットの PORTVERSION
には
20000917 ではなく 1.2.20000917 か何か、そのような番号を
指定するのが良いでしょう。
そうしておけば、例えばバージョン番号 1.3 として後続のリリースが
行なわれた場合にも、大小関係が崩されずにすむわけです。
gtkmumble
の port,
バージョン 0.10
が
ports collection にコミットされます。
PORTNAME= gtkmumble PORTVERSION= 0.10
PKGNAME
は
gtkmumble-0.10
になります。
ローカルな FreeBSD パッチを必要とする
セキュリティホールが発見されました。
それに合わせて PORTREVISION
を増やします。
PORTNAME= gtkmumble PORTVERSION= 0.10 PORTREVISION= 1
PKGNAME
は
gtkmumble-0.10_1
になります。
ベンダから 0.2
という番号が振られた
新バージョンがリリースされます (これにより、
作者は 0.10
という番号を
「0.9 の次という意味ではなく」、
実際には 0.1.0
のつもりで
使用していたことがわかります - あらら、今さら遅すぎる)。
新しいマイナーバージョン 2
は数字として以前のバージョン番号
10
より小さいので、
強制的に新しい package 「の方が新しい」と認識させるため
PORTEPOCH
を増やす必要があります。
これは新しいベンダーリリースなので、
PORTREVISION
は 0 にリセット
(または Makefile
から削除) されます。
PORTNAME= gtkmumble PORTVERSION= 0.2 PORTEPOCH= 1
PKGNAME
は
gtkmumble-0.2,1
になります。
次のリリースは 0.3 です。
PORTEPOCH
は減少することが無いため、
今度のバージョン変数は次のようになります:
PORTNAME= gtkmumble PORTVERSION= 0.3 PORTEPOCH= 1
PKGNAME
は
gtkmumble-0.3,1
になります。
もし、このアップグレードによって
PORTEPOCH
が 0
に
リセットされたとすると、3
は数字として
10
よりも小さいため、
gtkmumble-0.10_1
の package をインストールした誰かは
gtkmumble-0.3
の package
の方が新しいことに気がつかないことになるでしょう。
これが、そもそも PORTEPOCH
が導入された肝心な理由です。
二つのオプション変数 PKGNAMEPREFIX
と
PKGNAMESUFFIX
は、
PORTNAME
および
PORTVERSION
と結合され、
PKGNAME
を
${PKGNAMEPREFIX}${PORTNAME}${PKGNAMESUFFIX}-${PORTVERSION}
として定義します。
この時、適切な package 名を選ぶための
ガイドラインに沿っているかどうかを確認してください。
特に、PORTVERSION
中に
ハイフン (-
)
を使用することは禁止されています。
また、package 名に
language-
もしくは
-compiled.specifics
部分が
含まれる場合、それぞれ PKGNAMEPREFIX
と
PKGNAMESUFFIX
を使用してください。
これらを PORTNAME
の一部としてはいけません。
package の名前は以下のルールにしたがってつけてください。 これは package のディレクトリを見やすくするためで、 既に何千ものパッケージがありますし、 目を痛めてしまうようだとユーザはそっぽを向くでしょう。
package の名前は以下のようにしてください。
言語-名前-オプションバージョン.番号
package 名は
${PKGNAMEPREFIX}${PORTNAME}${PKGNAMESUFFIX}-${PORTVERSION}
というように定義されています。
変数がこの書式と適合していることを確認してください。
FreeBSD
はユーザの慣れ親しんだ言語のサポートに力を入れています。
特定の言語のための port の package 名には
言語-
に ISO-639
で定義されている言語名の略称を入れてください。
たとえば日本語なら ja
、
ロシア語なら ru
、
ベトナム語なら vi
、
中国語なら zh
、
韓国語ならば ko
、
ドイツ語なら de
といった具合です。
port がある言語地域に特化したものである場合には、
さらに二文字の国名コードを付加してください。
たとえば合衆国英語圏は en_US
となり、
スイスのフランス語圏は fr_CH
となります。
言語-
部分は、
PKGNAMEPREFIX
変数に
定義されなければなりません。
名前
の部分の最初の文字は
小文字でなければなりません。
(名前の残りの部分は大文字を含んでいても構わないため、
大文字を含んだソフトウェア名を変換する際の規則は、
あなた自身の裁量に任されています。)
perl 5
のモジュールでは先頭に
p5-
を付け、
二重コロン (::
)
のセパレータをハイフン
(-
)
に置きかえる習慣になっています。
たとえば
Data::Dumper
は
p5-Data-Dumper
になります。
また、そのソフトウェアの名前として通常使われるものに番号、
ハイフン、あるいは下線が入っている場合には、
それらを使うことも構いません
(kinput2
など)。
コンパイル時に環境変数や
make
の引数などでハードコードされたデフォルトを変えてコンパイルできる場合、
-compiled.specifics
にそのコンパイル時のデフォルトを入れてください
(ハイフンはあってもなくてもかまいません)。
用紙のサイズ、あるいはフォントの解像度などがこれにあたります。
-compiled.specifics
部分は、
PKGNAMESUFFIX
変数に定義されなければなりません。
バージョン番号は数字とアルファベットからなり、
ピリオド (.) で区切ります。
アルファベットは二文字以上続けてはいけません。
唯一の例外は「パッチレベル」を意味する文字列
pl
で、
それ以外にバージョン番号がまったくついていない場合にのみ使うことができます。
もしソフトウェアのバージョンに
「alpha」, 「beta」, 「rc」
や 「pre」 といった文字列が含まれるなら、
ピリオドの後に最初の一文字をとってください。
これらの後に、さらにバージョン文字列が続く場合には、
一文字のアルファベットの後にピリオドをつけずに番号を続けます。
この考え方は、
バージョン文字列を見て簡単に ports を並べられるようにするためのものです。
特に、バージョン番号の各部分が必ずピリオドで区切られていること、
また日付の部分がバージョン文字列の一部となっている場合には
yyyy.mm.dd
という書式を使っていることを確認してください。
dd.mm.yyyy
や、2000 年問題に対応していない
yy.mm.dd
という書式を使ってはいけません。
では、DISTNAME
を正しい
PKGNAME
に直す例を見てみましょう:
以下は、ソフトウェアの作者が決めた名前から 適切な package 名に変換する方法を示した (実際の) 例です。
配布名 | PKGNAMEPREFIX | PORTNAME | PKGNAMESUFFIX | PORTVERSION | 理由 |
---|---|---|---|---|---|
mule-2.2.2 | (空) | mule | (空) | 2.2.2 | 変更の必要はありません |
XFree86-3.3.6 | (空) | XFree86 | (空) | 3.3.6 | 変更の必要はありません |
EmiClock-1.0.2 | (空) | emiclock | (空) | 1.0.2 | プログラム一つだけの時は小文字のみ |
rdist-1.3alpha | (空) | rdist | (空) | 1.3.a | alpha のような文字列は使えない |
es-0.9-beta1 | (空) | es | (空) | 0.9.b1 | alpha のような文字列は使えない |
mailman-2.0rc3 | (空) | mailman | (空) | 2.0.r3 | rc のような文字列は使えない |
v3.3beta021.src | (空) | tiff | (空) | 3.3 | なんなんでしょう ;) |
tvtwm | (空) | tvtwm | (空) | pl11 | バージョン番号は必ず必要 |
piewm | (空) | piewm | (空) | 1.0 | 同上 |
xvgr-2.10pl1 | (空) | xvgr | (空) | 2.10.1 | pl が使えるのは、
他にメジャー/マイナーバージョン番号がない場合のみ |
gawk-2.15.6 | ja- | gawk | (空) | 2.15.6 | 日本語バージョン |
psutils-1.13 | (空) | psutils | -letter | 1.13 | コンパイル時に用紙のサイズを指定 |
pkfonts | (空) | pkfonts | 300 | 1.0 | 300dpiフォント用の package |
オリジナルのソースにまったくバージョン情報が見当たらず、
また原作者が新しいバージョンをリリースする可能性が低いときには、
バージョン番号として
1.0
を使えばいいでしょう
(上記の piewm
の例がこれにあたります)。
そうでない場合には原作者に聞くか、日付
(yyyy.mm.dd
)
を使うなどしてください。
本文書、および他の文書は ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/ からダウンロードできます。
FreeBSD に関する質問がある場合には、
ドキュメント を読んだ上で
<questions@FreeBSD.org> まで (英語で) 連絡してください。
本文書に関する質問については、
<doc@FreeBSD.org> まで電子メールを (英語で) 送ってください。