Debian JP Project

(for vocal browsers: toc, main)

Google
WWW 全体 www.debian.or.jp 検索
[ トップ | ダウンロード | インストール解説 | コミュニティ | Debian JP Project ]

[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ next ]

Debian ポリシーマニュアル
Chapter 5 - コントロールファイル (Control) とそのフィールド

パッケージ管理システムは共通のフォーマットで記述されたデータを扱います。 このフォーマットを control data と呼び、コントロールファイル 中に記載されています。 コントロールファイルはソースパッケージ、バイナリパッケージ、および .changes で使われており、 インストールとファイルのアップロードを制御します[30] 。

5.1 コントロールファイルの書式

コントロールファイルは、一つまたはそれ以上のフィールドの段落から成ります [31] 。段落は、空白行で区切られます。 いくつかのコントロールファイルは一つの段落しか持てませんが、複数の段落を持つことができるコントロールファイルもあります。 その場合には、通常、各段落は、それぞれ違うパッケージに対する記述になっています (例えば、ソースパッケージでは第一段落はソースパッケージを指し、以降のパッケージはそこから作成されたバイナリパッケージ群を指します)。

一つ一つの段落は、フィールドと値の連続したものです。 個々のフィールドは、名前とそれに続くコロンと値によって構成されます。 そして、(論理的な) 行末が終りです。水平方向に連続する空白 (スペースとタブ) は値の前後に入れることもできますが、その場合は無視されます; 慣習として、コロンの後に一つの空白を入れます。 例えば、フィールドは以下のようなものです。 

     Package: libc6

ここで、フィールド名は Package で、フィールドの値は libc6 です。

一つの段落に、特定のフィールド名が二回以上現れることは許されません。

多くのフィールドが、複数行で構成されています; この場合、継続行は、空白かタブで始まらなければ なりません。 フィールドの行の最後に続く空白やタブは全て無視されます。

改行を許さないと明示的に書かれているフィールドでは、フィールドの本体には一行のデータのみが許されており、空白は意味を持ちません。 空白は、 名前 (パッケージやアーキテクチャ、ファイル、その他) やバージョン番号、複数のキャラクタのバージョン関係の中には、絶対にあってはいけません。

フィールドの名前には、大文字か小文字かは関係ありません。 しかし、以下に示すように、大文字小文字を混在させる場合には、最初の一文字だけを大文字にするのが普通です。 フィールドの値は、フィールドの説明で特段の記載がない限り、大文字と小文字は区別されます。

空白行や空白とタブでだけ構成されている行は、フィールドの値や、フィールドとフィールドの間にあってはいけません - それは、新しい段落を意味してしまいます。

コントロールファイルは UTF-8 でエンコードしなければいけません。

5.2 ソースパッケージコントロールファイル -- debian/control

debian/control ファイルは、ソースパッケージとそれから生成されるバイナリパッケージについての最も重要な (バージョン非依存の) 詳細を含みます。

コントロールファイルの最初の段落には、ソースパッケージ全般に関する情報が収録されています。 それに引き続く部分にはソースツリーからビルドされたバイナリパッケージの記載が来ます。

全般部分の段落 (ソースパッケージ用の最初の部分) のフィールドは以下のものです。

バイナリパッケージ用の段落のフィールドは以下のものです。

フィールドの書式と意味は以下で記載されています。

これらのフィールドは、dpkg-gencontrol がバイナリパッケージ用のコントロールファイルを 生成するとき (以下参照) や dpkg-genchanges がアップロードに付随する .changes ファイルを生成するとき、または dpkg-source がソースアーカイブの一部として .dsc ソースコントロールファイルを生成するときに使用されます。 多くのフィールドは、debian/control 中では複数行に渡ることが許されていますが、 他のコントロールファイル中ではこれは認められていません。 上で挙げたツールは、debian/control 中のそのようなフィールドに対して、他のコントロールファイルを作成するために使用する際に、改行を削除する責任を負っています。

また、これらのフィールドは、変数参照を含むこともあります。 それらの値は、出力コントロールファイルを生成するときに dpkg-gencontrol、dpkg-genchanges 及び dpkg-source によって使用されます。 詳細は、変数置換: debian/substvars, Section 4.10 をご覧ください。

上記のコントロールファイルの書式 に加え、このファイルには先頭に空白なしで # から始まるコメント行を含めることができます。 そのような行は、複数行からなるフィールドの途中でも無視され、フィールドを終わらせるようなことはありません。

5.3 バイナリパッケージコントロールファイル -- DEBIAN/control

DEBIAN/control ファイルには、バイナリパッケージに関する最も重要な (バージョン依存の) 情報が収録されています。これは一つの段落からなります。

このファイルのフィールドは以下の通りです。

5.4 Debian ソースコントロールファイル -- .dsc

このファイルは、一つの段落からなり、恐らく PGP 署名で囲われています。 含まれるフィールドを以下に示します。またフィールドの書式は前に コントロールファイルとそのフィールド (旧 Packaging Manual より), Appendix D で説明されています。

ソースパッケージコントロールファイルはソースアーカイブビルド時に dpkg-source によりソースパッケージ中の、上記の説明している他のファイルから作成されます。 パッケージを解く時、ソースパッケージ中の他の部分のファイルとディレクトリとの整合性がチェックされます。

5.5 Debian changes ファイル -- .changes

.changes ファイルは、パッケージ更新を処理する際に Debian アーカイブ管理ソフトウェアによって使用されます。 このファイルは一つの段落からなり、debian/control と、 debian/changelog や debian/rules などから抽出したソースパッケージの情報が含まれています。

.changes ファイルは、文書化されたフィールドまたはその意味が変更されるたびに +1 されるフォーマットバージョン番号を持っています。 この文書では、1.8 フォーマットを記載します。

このファイルのフィールドは以下のものです。

5.6 フィールドのリスト

5.6.1 Source

このフィールドは、ソースパッケージの名前です。

debian/control ファイルや .dsc ファイル中のフィールドでは、 ソースパッケージの名前のみを含まなければいけません。

バイナリパッケージ中のコントロールファイルの中、または .changes ファイル中では、ソースパッケージ名の後に、 かっこに入れたバージョン番号を続けて記載することができます [32]。 このバージョン番号は、該当のバイナリパッケージの Version フィールドと同一の値を持っていた場合、dpkg-gencontrol によって削除されます。 また、ソースパッケージがバイナリパッケージと同じ名前とバージョンを持っていた場合は、 このフィールド自体がバイナリパッケージコントロールファイルから削除されます。

パッケージ名 (ソースパッケージとバイナリパッケージの両方とも。 Package, Section 5.6.7 参照) 小文字英字 (a-z), 数字 (0-9), プラス記号 (+) マイナス記号 (-) とピリオド (.) のみを含むようにしなければいけません。 また、少なくとも二文字で、英数字から始まらなければいけません。

5.6.2 Maintainer

パッケージメンテナの名前と email アドレスです。 最初に名前がこなくてはいけません。 その後に email アドレスを <> の中に (RFC822 フォーマットで) 入れます。

パッケージメンテナの名前にピリオドが含まれていると、RFC822 に規定されている文法のミスによって、全てのフィールドが email アドレスとして適用されなくなります; このフィールドをアドレスとして使用するプログラムは、これをチェックして、必要であれば修正しなければいけません (例えば、名前をかっこのなかに入れて最後尾に移動し、 email アドレスを前の方に持ってきます)。

5.6.3 Uploaders

パッケージの共同メンテナがいる場合、その人の名前と email アドレスの一覧です。もし、パッケージに Maintainer フィールド に記載した以外のメンテナがいる場合、その人たちの名前と email アドレスをここに記載します。 書式はメンテナフィールドのものと同じであり、複数のエントリはコンマ "," で区切ります。 このフィールドはオプションです。

debian/control ファイルの Uploaders フィールドを解釈するパーザは、この行が複数に渡ることを許容できなければなりません。 Uploaders 中の改行は意味を持たず、改行がない場合と同じものとして解釈されます。

5.6.4 Changed-By

この版のパッケージを用意した人、通常はメンテナ、の名前と電子メールアドレスです。 Maintainer fieldと同じ書式が適用されます。

5.6.5 Section

このフィールドには、パッケージを分類したアプリケーション分野を指定します。 セクション, Section 2.4 を参照ください。

debian/control ファイルに現れている場合、 .changes ファイルの Files フィールドの同名のサブフィールドの値に代入されます。 また、バイナリパッケージの同名のフィールドの初期値にも代入されます。

5.6.6 Priority

このフィールドには、このパッケージをインストールすることの重要性が示されています。プライオリティ, Section 2.5 参照のこと。

debian/control ファイルに現れている場合、 .changes ファイルの Files フィールドの同名のサブフィールドの値に代入されます。 また、バイナリパッケージの同名のフィールドの初期値にも代入されます。

5.6.7 Package

バイナリパッケージの名前です。

バイナリパッケージの名前は、ソースパッケージの名前と同じ書式および制限を持ちます。 詳細は Source, Section 5.6.1 を参照ください。

5.6.8 Architecture

これまでのコンテキストと、コントロールファイルの内容に依存しますが、 Architecture は以下の値を取ることができます。

ソースパッケージの中の、メインの debian/control ファイル中では、このフィールドには特別な値 all または 特別のアーキテクチャワイルドカード any か、スペースで区切られた複数のアーキテクチャまたはアーキテクチャワイルドカードのリストが許されます。 any または all が記載されている場合、これ以外の値を書くことは許されません。 殆どのパッケージでは、any または all のいずれかを使うことになります。

特定のアーキテクチャのリストを使う場合、そのソースからはフィールドに含まれているアーキテクチャのみに依存したパッケージがビルドされることを意味します。 特定のアーキテクチャのワイルドカードリストを使う場合、そのソースがフィールドにマッチするアーキテクチャのみに依存したパッケージをビルドすることを意味します。 アーキテクチャのリストや、any 以外のアーキテクチャワイルドカードを使う場合は例外的で、プログラムに可搬性がないか、一部のアーキテクチャでは役に立たない場合です。 一般的に言って、可能な限りプログラムは可搬性を持つように作成すべきです。

ソースパッケージの中の、ソースパッケージコントロールファイル .dsc の中には、アーキテクチャワイルドカード any か、スペースで区切られた複数のアーキテクチャまたはアーキテクチャワイルドカードのリストを書くことができます。 リストが記載されている場合、特別な値 all (あるいはそれのみ) を記載することが許されます。言い方を変えれば、.dsc は debian/control とは異なり、all は他の特定のアーキテクチャとの組み合わせとして記載することが許されています。 ソースパッケージコントロールファイル .dsc 中の Architecture フィールドは、通常はソースパッケージの debian/control の Architecture フィールドから作成されます。

any を指定した場合、ソースパッケージは特定のアーキテクチャへの依存性はなく、どのアーキテクチャでもコンパイルできるはずであるということを意味します。 作成されたバイナリパッケージ (群) は、現在のビルドアーキテクチャ依存か、アーキテクチャ非依存のいずれかになります。

単に all は、ソースパッケージは特定のアーキテクチャに依存しないパッケージのみをビルドすることを示しています。 この場合、any ではなく all を使用しなければいけません。 any は、ソースパッケージから少なくともひとつはアーキテクチャ依存のパッケージが作成されることを意味しています。

アーキテクチャあるいはアーキテクチャワイルドカードが列挙されている場合、 ソースはアーキテクチャ依存としてビルドされることを示しており、列挙されているか、あるいはワイルドカードにマッチしたアーキテクチャでのみ動作します。 ソースパッケージから少なくとも一種類のアーキテクチャ非依存のパッケージがビルドされる場合、リストに all を含めてください。

.changes ファイルの中の、Architecture フィールドは、そのパッケージが現在対応しているアーキテクチャを示します。 これはリストです。もし、特別なエントリ source があれば、そのパッケージのソースもアップロードされます。 アーキテクチャ非依存のパッケージがアップロードされる場合、all を含めます。.changes ファイルの Architecture フィールドに any などのアーキテクチャワイルドカードが現れてはいけません。

パッケージ構築の過程でアーキテクチャをどのように得るかについての情報は、 debian/rules - メイン構築スクリプト, Section C.2.1 を見てください。

5.6.9 Essential

これは、バイナリパッケージのコントロールファイル中、またはメインのソース制御データファイル中のパッケージごとの段落に記述される Yes/No の値です。

yes とセットしてあった場合、dpkg と dselect は、このパッケージの削除を行ないません (更新と置きかえは可能です)。 no の場合は、このフィールドを持っていない場合と同じです。

5.6.10 パッケージ間の関連性を示すフィールド: Depends, Pre-Depends, Recommends, Suggests, Breaks, Conflicts, Provides, Replaces, Enhances

これらのフィールドは、パッケージ間の関係を記述します。 パッケージ間の関連性の宣言, Chapter 7 を参照してください。

5.6.11 Standards-Version

パッケージが準拠した最新の標準 (Debian ポリシーマニュアルおよびそれに関連するテキスト) のバージョンです。

バージョンナンバーはメジャー及びマイナーバージョン番号、さらにメジャー及びマイナーパッチレベルの 4 つの数字からなります。 全てのパッケージに渡って変更がなされる場合には、メジャーバージョンを変更します。 多くのパッケージに修正作業が必要な重要な変更の場合には、マイナーバージョンを変更することによってそれを示します。 パッチレベルについては、小さい変更であっても、それが基準の変更を伴う場合にはメジャーパッチレベルの変更となります。 マイナーパッチレベルの変更となるのは、表面上の変更、文書上の修正など意味合いの変化の無い場合、 またパッケージの内容に関して影響を与えない場合になります。

従ってマニュアルバージョンのうち最初の 3 つの数字が一般的なバージョンとしての意味を持ちます。 この数字を 3 つにするか 4 つ全てを使ってバージョンを規定するかは、オプション [33] です。

5.6.12 Version

パッケージのバージョン番号です。書式は、 [epoch:]upstream_version[-debian_revision] です。

バージョンを構成する 3 つの要素は

epoch

これは一桁の符号なし整数です。普通は小さい数になるはずです。 ゼロと仮定して良い場合は省略できます。省略した時には、 upstream_version にコロンを含めてはいけません。

これはパッケージの古いバージョンのバージョン番号の誤りを許したり、 パッケージの以前のバージョン番号体系をそのままに残しておくためにあります。

upstream_version

これがバージョン番号の主要部分です。通常支障ない場合は .deb ファイルが作られたオリジナルの ("上流の") パッケージのバージョン番号になります。 普通は上流の作者によって定められたものと同じ形式になりますが、 パッケージ管理システムと比較手法に沿って修正を加えなければならないかもしれません。

upstream_version に関するパッケージ管理システムの比較の挙動については次節で述べます。 バージョン番号中で、この upstream_version の部分は必須です。

upstream_version は英数字 [34] と文字 . + - : ~ (ピリオド、プラス、ハイフン、コロン、チルド) だけから構成されており、数字で始まるようにすべきです。 ただし、debian_revision がない場合、ハイフンは許されません。 また、epoch がない場合、コロンは許されません。

debian_revision

バージョンのこの部分は、そのパッケージを Debian バイナリパッケージにするためにほどこした修正のバージョン番号を表わしています。 これは英数字と + . ~ (プラス、ピリオド およびチルド) の三記号のみからなり、upstream_version と同じやり方で比較されます。

この部分はオプションです。 debian-revision を持たない場合には、 upstream-version はハイフンを含んでいてはいけません。 この debian-revision を持たない形式のものは Debian パッケージとして特別に書かれたソフトウェアであることを示しています。 その場合、Debian パッケージソースは元のソースと常に同一の筈ですから、レビジョンの追加は必要ありません。

upstream_version が増加するたびに、 debian_revision を 1 に戻すのが慣習となっています。

パッケージ管理システムは文字列中の最後のハイフン (あれば) のところでバージョン番号を upstream_version と debian_revision とに分割しようとします。 debian_revision がないものは、debian_revision が 0 と等価です。

二つのバージョン番号を比較する場合には、まず epoch 値が比較され、次に epoch が同じである場合には upstream_version が比較され、さらに upstream_version も同じである場合には debian_revision が比較されます。 epoch は数字として比較されます。 upstream_version と debian_revision の部分はパッケージ管理システムによって、以下記載のアルゴリズムを用いて比較されます。

文字列は左から右へと比較されます。

最初に、比較対象となる2つの文字列の中で、全て非数字で構成される最初の部分を決定します。 両方の文字列に対する、この数字でない部分 (そのうちの一つは空であってもかまいません) を辞書順で比較します。 もし違いが見つかれば、それを返します。 ここでの辞書順とは、すべての文字が非文字より先に来る様に修正し、 更にチルドがもっとも前に来る修正 (行末の空文字列より更に前) を加えた ASCII 順です。 例えば、以下の各部分は早いほうから遅いほうへの順でソートされます。 ~~, ~~a, ~, 空部分, a[35]。

次に、二つの文字列の残りの部分から、全て数字で構成される最初の部分を決定します。 この二つの数値を比較し、比較結果として見つかった違いを返します。 このとき、空文字列 (比較している一方もしくは双方のバージョン文字列の末尾においてのみ生じる) は 0 として数えます。

違いが見つかるか、双方の文字列を調べ尽くすかするまで、この二つのステップを (先頭から、最初の非数字の文字列と最初の数字の文字列を比較し、切り離しながら) 繰り返します。

epoch の目的はバージョン番号付けのミスをそのままにできるようにするため、またバージョン番号の付け方を変更した場合に、 それをうまく扱えるようにするためだということに注意してください。 パッケージ管理システムが解釈することのできない文字 (ALPHA や pre- など) から成る文字列を含むバージョン番号や、思慮の浅い順序付け[36] をうまく処理するためでは ありません。

5.6.13 Description

ソースおよびバイナリパッケージのコントロールファイル中で、 Description フィールドにはバイナリパッケージの説明が含まれています。 この説明は、概要または短い説明と、長い説明の二つの部分からなります。 書式を以下に示します。 

     	Description: <一行概要>
     	 <複数行にわたる長い説明>

長い説明の部分のフォーマットは以下の通りです。

タブは使用しないでください。どういう動作をするか分かりません。

更に詳しい説明は、パッケージの説明, Section 3.4 の項を参照ください。

.changes ファイル中では、Description フィールドにアップロードされるパッケージの説明文の要約を含んでいます。 この場合、フィールド値の最初の行 (Description: などと同じ行の部分) は常に空行です。 フィールドの内容は、継続行にパッケージ毎に１行で記述されます。 それぞれの行は、一つの空白でインデントされ、バイナリパッケージ名、空白、 ハイフン (-)、空白、パッケージから持ってきた短い説明という構成になっています。

5.6.14 Distribution

.changes ファイルか changelog の解析出力には、 このパッケージがインストールされていた、またはこれからインストールされるディストリビューションの名前が空白で区切られて含まれます。 有効なディストリビューション名はアーカイブメンテナが決定します。 [38] Debian アーカイブソフトウェアは、単一のディストリビューションの記載しかサポートしていません。 パッケージを他のディストリビューションに移動する処理はアップロードプロセスの外で行われます。

5.6.15 Date

このフィールドにはパッケージがビルドされた、または修正された日付を記載します。 これは、debian/changelog エントリの date と同じフォーマットでなければいけません。

このフィールドの値は通常 debian/changelog ファイルから抽出します。Debian changelog: debian/changelog, Section 4.4 を参照ください。

5.6.16 Format

.changes ファイルでは、このフィールドはこのファイルのフォーマットバージョンを宣言します。 このフィールドの値の書式は パッケージバージョン番号と同じですが、 epoch や Debian revision は付けることができません。 書式は、本文書では 1.8 に記載されています。

Debian ソースコントロールファイル .dsc では、このフィールドはソースパッケージのフォーマットを宣言します。 このフィールドの値は、ソースパッケージ内のファイルのリストを解釈し、アンパック方法を判断する必要があるような、パッケージを操作するためのプログラムで用いられます。 このフィールドの値の書式は、数字のメジャーレビジョン、ピリオド、数字のマイナーレビジョンに、その後空白を挟んでオプションのサブタイプが続くものです。 サブタイプがある場合、それはかっこで囲まれた英数字の語です。 サブタイプは書式上は省略可能ですが、特定のソースフォーマットレビジョンでは必須になります [39]。

5.6.17 Urgency

以前のバージョンからのアップグレードがどの程度重要なのかを示します。 以下のいずれかのキーワードのひとつを指定します low、medium、 high emergency および critical[40] (大文字と小文字は区別されません)。 空白で区切られたコメント (たいていかっこにはいっています) がオプションとしてつくこともあります。例えば： 

       Urgency: low (HIGH for users of diversions)

このフィールドの値は普通は debian/changelog から取ってきます。Debian changelog: debian/changelog, Section 4.4 を参照ください。

5.6.18 Changes

このフィールドは、人が読むための変更点のデータを示します。 一つ前のバージョンと現在のバージョンとの相違を説明します。

フィールドの最初の値 (Changes: と同じ行の部分) は必ず空です。 フィールドの値は継続行に記載され、最低限一つの空白によってインデントされます。 空行は、空白とピリオド (.) だけからなる行で作成されます。

このフィールドの値は普通は debian/changelog から取ってきます。Debian changelog: debian/changelog, Section 4.4 を参照ください。

それぞれのバージョンの変更情報は、「title」行の後に続きます。 この「title」行には、すくなくとも、バージョン、ディストリビューション、緊急度のフィールドが人が読める形式で含まれています。

もし、いくつかのバージョンのバージョン情報が返されるような場合、 最新のバージョンに対するものを最初に返すようにすべきで、 同時に空行を入れてエントリ行を分割してください (「title」行の後もまた空行のあとで 続けてください)。

5.6.19 Binary

このフィールドはバイナリパッケージのリストです。 書式と意味は、このフィールドが現れたコントロールパッケージが何であるかに依存します。

.dsc ファイルに記載されている場合は、それはそのソースパッケージが生成できるバイナリパッケージのカンマで区切られたリストです [41]。 ソースパッケージでは、すべてのアーキテクチャで、ここに記載された全バイナリパッケージが生成できる必要はありません。 個々のバイナリパッケージがどのアーキテクチャに対応しているかの詳細は、ソースコントロールファイルには含まれません。

.changes ファイル中では、このフィールドの値は、 実際にアップロードされているバイナリパッケージの名前の、空白 (カンマではなく) で区切られたリストです。 複数行に渡って記載することもできます。

5.6.20 Installed-Size

このフィールドは、バイナリパッケージのコントロールファイルと Packagesファイルに現われます。 名前で指定されたパッケージをインストールするのに必要なディスク容量の概算値を示します。 実際に消費されるインストールサイズはブロックサイズ、ファイルシステムプロパティやパッケージメンテナスクリプトでの処理に依存します。

ディスク容量は、バイト値のインストールサイズを 1,024 で割って切り上げた整数値です。

5.6.21 Files

このフィールドは、ファイルとそれについての情報を逐一記したリストから構成されます。 厳密な情報と書式は使われる状況によります。

どの場合においても、Files は複数行からなるフィールドです。 フィールドの最初の行 (即ち Files: のある行) は空です。 継続行に 1 つのファイルにつき一行の内容が記されます。 このとき各行は 1 つの空白文字でインデントされ、下記の通り、空白で区切られた各サブフィールドが続きます。

.dsc ファイルの場合には、このフィールドには tar ファイルと、ソースパッケージの残りの部分である diff ファイル (存在する場合) の各々について、MD5 チェックサム、サイズ、ファイル名が記されます。 この diff ファイルは、ソースパッケージの変更分 [42] です。例を挙げます。 

     Files:
      c6f698f19f2a2aa07dbb9bbda90a2754 571925 example_1.2.orig.tar.gz
      938512f08422f3509ff36f125f5873ba 6220 example_1.2-1.diff.gz

ファイル名などの項目についての正確な書式は、 Source packages as archives, Section C.3 をごらんください。

.changes ファイルの場合には、このフィールドには 1 つのアップロードされるファイルごとに 1 行ずつ、 MD5 チェックサムとサイズ、セクション、プライオリティ、ファイル名が記述されます。 以下に例を示します。 

     Files:
      4c31ab7bfc40d3cf49d7811987390357 1428 text extra example_1.2-1.dsc
      c6f698f19f2a2aa07dbb9bbda90a2754 571925 text extra example_1.2.orig.tar.gz
      938512f08422f3509ff36f125f5873ba 6220 text extra example_1.2-1.diff.gz
      7c98fe853b3bbb47a00e5cd129b6cb56 703542 text extra example_1.2-1_i386.deb

セクション (section) とプライオリティ (priority) フィールドはメインのソースコントロールファイルの対応する値となります。 もし、セクションとプライオリティが決定されていなかったら、 - を使うべきです。 しかしながら、セクションとプライオリティの値は新しいパッケージを適切にインストールするため、本来指定しておかなければならないものです。

.changes ファイルのセクションが byhand という特別の値であれば、該当するファイルは通常のパッケージファイルとして扱えないため、 ディストリビューション管理者が手動でインストールしなければなりません。 セクションが byhand 値であった場合には、プライオリティは - にすべきです。

新しい Debian パッケージをリリースする時に、新しい上流のソースアーカイブの配布を伴わない場合、 .dsc ファイルの Files フィールドには、オリジナルのソースアーカイブ package_upstream-version.orig.tar.gz に対するエントリを含んでいなければなりません。 一方、.changes ファイル中の Files フィールドにはこのエントリがあってはいけません。 この場合、配布サイトのオリジナルソースアーカイブは、アップロードしようとしている .dsc ファイルと、diff ファイルを生成するのに使用されたソースアーカイブとバイト単位で正確に一致していなければなりません。

5.6.22 Closes

.changes ファイルでの変更/修正により、アップロードで閉じられるバグレポート番号を、空白で区切って列挙します。

5.6.23 Homepage

このパッケージのウェブサイトの URL です。可能な場合、望ましいのは元のソースが入手でき、追加の上流の文書や情報が入手できるようなサイトです。 このフィールドの内容には、<> などで囲まない単純な URL を記載します。

5.6.24 Checksums-Sha1 および Checksums-Sha256

これらのフィールドには、各ファイルに対しチェックサムとサイズが付けられたリストが格納されています。 Checksums-Sha1 と Checksums-Sha256 は同じ書式で、使ったチェックサムアルゴリズムのみ異なります。 Checksums-Sha1 では SHA-1 が用いられ、 Checksums-Sha256 では SHA-256 が使われます。

Checksums-Sha1 と Checksums-Sha256 は、複数行からなるフィールドです。フィールドの最初の行の値 (つまり、Checksums-Sha1 や Checksums-Sha256 と同じ行にある値) は、常に空白です。 実際のフィールドの内容は継続行に記載され、ファイル一つにつき一行です。 各行は、チェックサム、空白、ファイルサイズ、空白、ファイル名となります。 例を (.changes ファイルから) 以下に示します。 

     Checksums-Sha1:
      1f418afaa01464e63cc1ee8a66a05f0848bd155c 1276 example_1.0-1.dsc
      a0ed1456fad61116f868b1855530dbe948e20f06 171602 example_1.0.orig.tar.gz
      5e86ecf0671e113b63388dac81dd8d00e00ef298 6137 example_1.0-1.debian.tar.gz
      71a0ff7da0faaf608481195f9cf30974b142c183 548402 example_1.0-1_i386.deb
     Checksums-Sha256:
      ac9d57254f7e835bed299926fd51bf6f534597cc3fcc52db01c4bffedae81272 1276 example_1.0-1.dsc
      0d123be7f51e61c4bf15e5c492b484054be7e90f3081608a5517007bfb1fd128 171602 example_1.0.orig.tar.gz
      f54ae966a5f580571ae7d9ef5e1df0bd42d63e27cb505b27957351a495bc6288 6137 example_1.0-1.debian.tar.gz
      3bec05c03974fdecd11d020fc2e8250de8404867a8a2ce865160c250eb723664 548402 example_1.0-1_i386.deb

.dsc ファイルには、これらのフィールドにはソースパッケージを構成する全てのファイルを列挙すべきです。 .changes ファイルには、これらのフィールドにはアップロードしようとする全てのファイルを列挙すべきです。 これらのフィールド中のファイルのリストは、Files フィールドのファイルのリストと一致している必要があります。

5.7 ユーザ定義フィールド

ソースパッケージコントロールファイルにはユーザ定義フィールドを追加することができます。 これらは無視され、(例えば) バイナリやソースパッケージコントロールファイル、アップロードコントロールファイルにはコピーされません。

出力ファイルにサポートされていないフィールドを付加したいときは、ここに述べる方法を使用してください。

メインのソースコントロールファイルにおいて、X から始まり、BCS とハイフン - が続くフィールドは、出力ファイルにコピーされます。 そして出力ファイルには、フィールド名のハイフンの後に続く文字部のみが使用されます。 ここで、B はバイナリパッケージコントロールファイルに使用されるとき、 S ソースパッケージコントロールファイルに使用されるとき、 C は、アップロードコントロールファイル (.changes) に使用されるときに使われます。

メインのソース情報コントロールファイルが以下のフィールドを含んでいるときは、 

       XBS-Comment: I stand between the candle and the star.

バイナリとソースパッケージコントロールファイルは、次のフィールドを含みます。 

       Comment: I stand between the candle and the star.

[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ next ]

Debian ポリシーマニュアル

バージョン 3.9.1.0, 2011-07-05

The Debian Policy Mailing List

このページに関するご感想・ご質問は webadmin+at+debian.or.jp までお送りください。

Copyright © Debian JP Project / ライセンス条項を見る。

powered by Debian Valid HTML 4.01! Valid CSS!