openSUSE:パッケージ命名ガイドライン
目次
パッケージ命名時における文字セットについて
openSUSE は国際的なコミュニティであり、一貫性と有用性を維持するため、パッケージ名には汎用的な文字セットを利用する必要があります。
具体的には、すべての openSUSE パッケージは下記の ASCII 文字のみを利用して命名されなければなりません:
abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ 0123456789-._+
アップストリーム (提供元) の命名規約との区別について
openSUSE では、名前のテキストを ASCII 文字セットに変換する作業 (字訳とも呼びます) が難しい作業であることを知っています。そのため、アップストリームで設定されている名前が ASCII の文字セット外のものである場合、 openSUSE パッケージメンテナは該当するソフトウエアのアップストリームに問い合わせを行ない、 openSUSE で利用すべきパッケージ名を判断してください。
なお、アップストリームのプロジェクトが字訳を提供できない場合、もしくは提供を望まない場合や提供しない旨を通知された場合にのみ、 openSUSE のパッケージャは下記の基準で作業を行なってください:
- 独自に字訳を実施するか、もしくは openSUSE 内にパッケージを取り込むのをあきらめるか、いずれかを選択しなければなりません。
- 他のディストリビューションでどのような名前になっているのかを確認し、その名前も考慮に入れるべきです。
なお、字訳したほうのパッケージで Provide: 句を利用して、オリジナルの (つまり字訳前の) 名前を設定することもできます。こちらは必須ではありません。
一般的な命名規約
パッケージを命名する際、名前はアップストリーム (提供元) の tar ボールやプロジェクト名に一致すべきです。ただし、場合によってはこれによって名前を選択しにくくしてしまう場合があります。他のディストリビューションで作成されているパッケージや、他のパッケージャが作成していたパッケージがあるような場合は、一貫性を維持する目的で、その名前を利用すべきです。いずれの場合であっても、あなた自身が他の開発者の支援を考慮に入れながら、最適な判断を下す必要があります。
なお、アップストリームの名前が 一般的な文字セットを利用していない 場合があります。この場合は、 アップストリーム (提供元) の命名規約との区別について をお読みください。
何らかのパッケージに対する拡張やプラグインの場合
機能的な実態がプラグインであるようなものの場合、プラグインの対象となるソフトウエアの名前を冒頭に付与し、そのあとに '-plugin-' という固定文字列を追加して、最後にプラグインの機能や名前などを追加して、パッケージ名を構成してください。
たとえば plymouth-plugin-script というパッケージ名は、 plymouth に対してスクリプト機能を提供するプラグインを意味します。
区切り文字
openSUSE でパッケージの命名を行なう際、メンテナはダッシュ '-' を各名前パーツ間の区切り文字として利用しなければなりません。メンテナはアンダースコア '_', プラス '+', ピリオド '.' を区切り文字として利用してはなりません。
ただし、アンダースコア '_' を使用してはならないというルールには、いくつかの例外があります:
- httpd, pam, SDL の各アドオンパッケージは除外されます。詳しくは アドオンパッケージ (httpd, pam, SDL) をお読みください。
- ロケール (言語) 固有のパッケージであり、ロケール自身を名前の中に含む場合は除外されます。詳しくは アドオンパッケージ (ロケール) をお読みください。
- また、アップストリーム側の名前自身にアンダースコアを含む場合も、除外するものとします。
たとえば下記のようなパッケージ名があります:
java_cup libart_lgpl microcode_ctl nss_ldap sg3_utils
何か質問があれば、 opensuse-packaging メーリングリスト (英語) にてご質問ください。
同じソフトウエアに対する複数のパッケージ提供について
様々な理由により、 openSUSE では特定のパッケージに対する複数のバージョンを同時にインストールする必要があったり、インストールしたほうが適切であったりします。下記の説明は、ソースパッケージの名前とバイナリパッケージの名前の両方に適用されるものですが、共有ライブラリについては 独自のガイドライン が存在するため、こちらを参照してください。
特定のソフトウエアに対して複数のバージョンを提供する際、その旨をパッケージ名に表す必要があります。また、最新バージョンのパッケージはバージョン番号無しの名前とし、それ以外のバージョンのパッケージにはバージョン番号を追加するものとします。ただし、すべてのパッケージ名にバージョン番号が付与されているものもあります (例: sqlite など) 。また、パッケージによっては区切り文字を付けずに名前が設定されていることもあります (例: celt051) 。ただし、この場合はどこまでが数字の範囲なのかがわからなくなってしまいます (例えば celt010 はバージョン 0.10 なのか 0.1.0 なのかが判断できません) 。また、共有ライブラリのパッケージングポリシー (区切り文字をアンダースコアに置き換えるというもの) の推奨事項を適用してもかまいません (例: love-0_7_2) 。
例:
- 同時にインストールすることのできる開発用パッケージ: celt051-devel, libcelt-devel; sqlite2-devel, sqlite3-devel
- 同時にインストールすることのできるアプリケーションソフトウエア: love-0_7_2, love; autoconf213, autoconf
大文字と小文字の区別にいて
openSUSE のパッケージにおいては、メンテナ自身がパッケージの命名を判断すべきです。ですが、大文字と小文字の区別についてはその限りではありません。アップストリームの開発者が希望している場合は、開発者の希望を尊重してください。たとえば "ORBit" と呼ばれるアプリケーションがそれに当てはまります。この場合は "orbit" ではなく "ORBit" をパッケージ名として利用すべきです。なお、特に大文字を使用するように希望していない場合は、小文字で記述してください。
なお、 Perl モジュールのパッケージ作成の場合は例外です。 CPAN グループとタイプはいずれも名前の冒頭が大文字で始まるべきです (詳しくは アドオンパッケージ (perl モジュール) をお読みください) 。
spec ファイルのファイル名について
spec ファイルは %{name}.spec の形式のファイル名であるべきです。たとえばソースパッケージの名前を foo-1.0-1.src.rpm としたい場合は、 spec ファイルは foo.spec であるべきです。
特殊なバージョン文字列の取り扱い
バージョンはアップストリーム (提供元) の tar ボールにあるバージョンに合わせてください。
もしもこれが実現できないような場合は、上記までの解決方法が該当しないかをご確認ください。
バージョン管理システムのスナップショット
バージョン管理システムのリポジトリから tar ボールを作成している場合は、最も近いリリース版の後に区切り文字 (しばしば '+' を使用しますが、 '.' のほうが見やすいです) を追加し、その後ろにシステムの名称とそのシステム内での管理情報 (一般的には単調に増加するだけの識別子) を付けてください。下記に一般的なバージョン管理システムにおける設定例を示します:
Git は各コミットをタグからのオフセット値という識別子で表します。たとえば `git describe` が v3.14.1-5-g9265358 という文字列を出力した場合、 RPM 側ではバージョンを 3.14.1+git5 とするか、もしくはより詳しく記述する場合は 3.14.1+git5.g9265358 のようにします。なお、 git リポジトリのメンテナが注釈付きタグを使用しておらず、シンプルタグだけを使用している場合は、 `git describe --tags` を使用する必要があるかもしれません。また、メンテナが全くタグを使用していない場合は、その問題点を報告してください。それと同時に、履歴のルートをベースとして利用して、単調に増加するだけの識別子を取得して、バージョンの代わりにすることもできます (`git rev-list 9265358 | wc -l`) 。これに特に、プロジェクトがまだ初期段階の状態にあり、まだリリースされていないような場合に有用です (例: Version: 0~git123) 。
Subversion はリビジョン番号をそのまま利用することができます。ベースとなるバージョンは、リビジョンとは別の方法で判断する必要があります (例: Version: 3.14.1+svn592) 。
For CVS はスナップショットに対するタイムスタンプがもっとも短い識別子となります (少なくとも開発者にとっては) 。なぜなら、すべてのファイルにはリビジョンが付与されているためです (例: Version: 3.14.1+cvs20130621) 。
プレリリース版パッケージ
最終リリースと同じバージョン体系を持つプレリリース版のパッケージを公開したい場合は、追加の注意が必要となります。これは、開発者によってプレリリースを表す方法が異なる可能性があるためです。たとえば "1.8b" はバージョン 1.8 のベータ版 (つまり 1.8 よりも 前に リリースされる版) を意味する場合があるほか、 1.8 よりも 後に リリースされたものを意味する場合もあります。このようなことから、パッケージユーティリティは "alpha", "beta", "a", "b" などの文字列を特別に扱うようにはなっておらず、単純に文字列の長さから "1.8" の後ろに "1.8b" が来るようになっています。ディストリビューションにおけるパッケージメンテナは、 .spec ファイル内の Version: 番号を適切に管理して、それらのユーティリティで正しい順序になるように調整しなければなりません。下記に示すどのような方法をとってもかまいませんが、いずれか 1 つの方法のみ を採用してください。また、下記は推奨される順番に並んでいます (つまり、できる限り上の方法を取ってください):
- アップストリームによっては、プレリリースに対して並べ替えることのできる番号 (つまり通常のリリースでは存在しない番号) を付与している場合があります。たとえば sssd-1.8.0beta2.tar.gz は "1.7.92" というバージョン番号が設定されていたりします。このような場合は、そのまま Version: 1.7.92 を使用してください。
- "チルダバージョン" を使用する方法もあります。 spec ファイルでの Version: フィールドにはチルダ (~) という特殊なマーカーを含めることができるようになっています。チルダは "それよりも前" を意味する記号で、たとえば "1.8~" は "1.8" よりも前のバージョンであるものと判断されます。この機能は rpm-4.10 以降で利用できるようになった機能で、 openSUSE 12.2 の rpm 4.9.1 にも移植されています。このような場合は、 Version: 1.8.0~beta2 のように指定してください。また、チルダは複数回使用することもできますが、どうしても必要な場合に限ってください。
- アップストリーム側で、最終リリースが後ろに (かつ将来のリリースよりも前に) 来るようにバージョン番号を付与している場合もあります。たとえばプレリリース版の場合は Version: 1.8.0.beta2 を設定し、最終リリースは Version: 1.8.0.0 などのようになります。これは RPM の特性を利用したもので、 A-Z が 0-9 よりも前に来るようになっているためです。このように RPM は単純に ASCII 順で並び替えるようなことはしませんが、この方法は RPM 以外のシステムでは利用できません。 OBS を利用する場合は、他の方法で解決する必要があります。
- プレリリース版に対しては、並び替え時に最終バージョンよりも前に来るバージョンを選択しますが、同一ラインの後継バージョンにも備えるため、実際のバージョンを前に付ける方法もあります。たとえばプレリリース版に対しては Version: 1.7.99_1.8.0beta2 のようにし、最終リリース版に対しては Version: 1.8.0 のようにすることができます。
- Epoch: と呼ばれるフィールドを使用する方法もあります。ただし、 openSUSE では Epoch: の使用に反対しており、実際に使用もしていない ことに注意してください。これは、 zypper (およびおそらく yum も) は `zypper dup` や `zypper in` などで、ダウングレードも扱うことができるようになっているためです。事実、 Maximum RPM の書籍内でも、下記のように Epoch is considered harmful (Epoch は有害であるものと考えられている) とされています:
(原文)
(翻訳)
なお、 RPM の Release: タグを バージョン 情報の目的で使用するのはおやめください。ここはバージョン番号を記すための場所ではありませんし、 Open Build Service はチェックイン回数やビルド回数を示すため、常に Release: タグを上書きするようにもなっています。
ポストリリース版パッケージ
一般的には、ポストリリース版のパッケージにはアップストリームが最終バージョンに続く適切なバージョン番号を付与するため、特に問題となることはありません。
アップストリームが許容される文字セット内で区切り文字を利用しているような場合も、それをそのままバージョン文字列に反映するのが適切です。それ以外の文字を使用している場合は、何らかの許容される文字をお使いください。
- openssl-0.9.8p: Version: 0.9.8p
- suse-11-GA1: Version: 11.GA1 # GA=General Availability (一般公開版)
また、人間にとってのみ意味を持つ文字列 (上記の例では GA など) が数字の前にあるような場合は、 A-Z の自然な順序となるよう調整する必要があります。たとえば FUBAR が GA の後にリリースされたような場合は、下記のようになります:
- suse-11-GA1: Version: 11+0.GA1
- suse-11-FUBAR1: Version: 11+1.FUBAR1
ここでは '.' を区切り文字に使用せず、 '+' を使用していますが、これはバージョン番号が不明確になってしまうのを避ける目的があります (たとえば 11.0.GA1 のようにしてしまうと、 11.0+GA1 なのか 11+0.GA1 なのかがわからなくなってしまいます) 。
なお、ポストリリース版に対するプレリリース版については、上述のチルダバージョン方式をお使いください (例: "openssl-0.9.6q~betaX").
既存のパッケージに対する改名や置き換え
パッケージの依存関係: パッケージの改名 をお読みください。
ドキュメンテーション向けサブパッケージ
巨大なドキュメンテーションを提供するような場合は、それをサブパッケージにすべきです。このサブパッケージには、 %{name}-doc のような形式で命名してください。
サブパッケージに分けるかどうかはパッケージャの判断に任せますが、サイズだけでなく分量の理由で分割することもお考えください。
アドオンパッケージ (一般)
新しいパッケージが既存の openSUSE パッケージに対して新しい機能を追加したり、機能を拡張したりする "プラグイン" パッケージの場合は、その旨を名前に示しておくべきです。
新しいパッケージ ("子") は、パッケージ名の冒頭に "親" のパッケージ名を付与します。具体的には、 %{親}-%{子} のような形式で指定してください。
例:
gnome-applet-netmon (GNOME 向け netmon アプレット (GNOME に依存)) php-adodb (php 向け adodb 機能 (php を利用する)) python-twisted (Python 向け twisted モジュール (python に依存)) xmms-cdread (xmms 向け直接 CD 読み込み機能 (xmms に依存))