[% title = "Debian ポリシーマニュアル - コントロールファイル (Control) とそのフィールド" %]
[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ next ]
パッケージ管理システムは共通のフォーマットで記述されたデータを扱います。
このフォーマットを control data と呼び、コントロールファイル
中に記載されています。
コントロールファイルはソースパッケージ、バイナリパッケージ、および
.changes
で使われており、
インストールとファイルのアップロードを制御します[32] 。
コントロールファイルは、一つまたはそれ以上のフィールドの段落から成ります [33] 。段落は、空白行で区切られます。 パーザは空白文字とタブだけからなる行も段落の区切りとして処理しても構いませんが、 コントロールファイルでは空行を使うべきです。 いくつかのコントロールファイルは一つの段落しか持てませんが、複数の段落を持つことができるコントロールファイルもあります。 その場合には、通常、各段落は、それぞれ違うパッケージに対する記述になっています (例えば、ソースパッケージでは第一段落はソースパッケージを指し、以降のパッケージはそこから作成されたバイナリパッケージ群を指します)。 コントロールファイル中の段落の順序は意味を持ちます。
一つ一つの段落は、フィールドと値の連続したものです。 個々のフィールドは、名前とそれに続くコロンとデータ/値によって構成されます。 フィールド名は制御文字、空白とコロンを除く ASCII 文字から構成されます (つまり、33-57 または 59-126 までの間でなければいけません)。 フィールド名は、コメント文字 # やハイフン文字 - で始まってはいけません。
そして、改行または最後の継続行の終わりがフィールドの終わりです。 水平方向に連続する空白 (スペースとタブ) は値の前後に入れることもできますが、その場合は無視されます; 慣習として、コロンの後に一つの空白を入れます。 例えば、フィールドは以下のようなものです。
Package: libc6
ここで、フィールド名は Package で、フィールドの値は libc6 です。
一つの段落に、特定のフィールド名が二回以上現れることは許されません。
フィールドには三種類あります。
このフィールドは値を含めて一行でなければなりません。 フィールドを折り返すことは許されません。 これは、フィールドの定義で他のフィールド種別を許していない場合、標準のフィールドの種類になります。
折り返しを許す (folded) フィールドの値は、複数行に展開可能な論理的な行です。 最初の行に続く行は継続行と呼ばれ、空白またはタブで始まらなければいけません。 改行を含む空白文字は、折り返しを許すフィールドの値の場合、意味を持ちません [34]
複数行 (multiline) フィールドの値は、複数の継続行から構成されます。 最初の行の値は (フィールド名と同じ行にある値の部分)、 しばしば特別の意味を持ち、空にしなければならない場合もあります。 残りの行は「折り返しを許すフィールド」の継続行と同じ書式で付け加えられます。 空白や改行は、複数行フィールドでは意味を持ちます。
空白は、 名前 (パッケージやアーキテクチャ、ファイル、その他) やバージョン番号、複数のキャラクタのバージョン関係の中には、絶対にあってはいけません。
各フィールドの存在と用途、および値の書式はコントロールファイル毎に異なります。
フィールドの名前には、大文字か小文字かは関係ありません。 しかし、以下に示すように、大文字小文字を混在させる場合には、最初の一文字だけを大文字にするのが普通です。 フィールドの値は、フィールドの説明で特段の記載がない限り、大文字と小文字は区別されます。
段落の区切り (空行) や、空白行や空白とタブでだけ構成されている行が、フィールドの値や、フィールドとフィールドの間にあってはいけません。 フィールドの値としての空行は、通常は 空白とドット という値にエスケープされます。
行が前に空白なしで #
で始まっている場合、それはソースパッケージコントロールファイル
(debian/control
) 中でのみ許されるコメント行です。
このコメント行は、継続行の途中にある場合も含めて、無視されます。
また、フィールドの論理行の終りを意味することもありません。
コントロールファイルは UTF-8 でエンコードしなければいけません。
debian/control
debian/control
ファイルは、ソースパッケージとそれから生成されるバイナリパッケージについての最も重要な
(バージョン非依存の) 詳細を含みます。
コントロールファイルの最初の段落には、ソースパッケージ全般に関する情報が収録されています。 それに引き続く部分にはソースツリーからビルドされたバイナリパッケージの記載が来ます。
全般部分の段落 (ソースパッケージ用の最初の部分) のフィールドは以下のものです。
Source (必須)
Maintainer (必須)
Section (推奨)
Priority (推奨)
バイナリパッケージ用の段落のフィールドは以下のものです。
Package (必須)
Architecture (必須)
Section (推奨)
Priority (推奨)
Description (必須)
フィールドの書式と意味は以下で記載されています。
これらのフィールドは、dpkg-gencontrol
がバイナリパッケージ用のコントロールファイルを 生成するとき (以下参照) や
dpkg-genchanges
がアップロードに付随する .changes
ファイルを生成するとき、または dpkg-source
がソースアーカイブの一部として .dsc
ソースコントロールファイルを生成するときに使用されます。
一部のフィールドは、debian/control
中での折り返しを許す行の使用が許されていますが、
他のコントロールファイル中ではこれは認められていません。
上で挙げたツールは、debian/control
中のそのようなフィールドに対して、他のコントロールファイルを作成するために使用する際に、改行を削除する責任を負っています。
また、これらのフィールドは、変数参照を含むこともあります。
それらの値は、出力コントロールファイルを生成するときに
dpkg-gencontrol
、dpkg-genchanges
及び
dpkg-source
によって使用されます。 詳細は、変数置換: debian/substvars
,
Section 4.10 をご覧ください。
DEBIAN/control
DEBIAN/control
ファイルには、バイナリパッケージに関する最も重要な
(バージョン依存の) 情報が収録されています。これは一つの段落からなります。
このファイルのフィールドは以下の通りです。
Package (必須)
Version (必須)
Section (推奨)
Priority (推奨)
Architecture (必須)
Maintainer (必須)
Description (必須)
このファイルは、一つの段落からなり、恐らく PGP 署名で囲われています。 含まれるフィールドを以下に示します。またフィールドの書式は前に コントロールファイルの書式, Section 5.1 で説明されています。
Format (必須)
Source (必須)
Version (必須)
Maintainer (必須)
Package-List (推奨)
Files (必須)
Debian ソースコントロールファイルはソースアーカイブビルド時に
dpkg-source
によりソースパッケージ中の、上記の説明している他のファイルから作成されます。
パッケージを展開する時、ソースパッケージ中の他の部分のファイルとディレクトリとの整合性がチェックされます。
.changes
.changes
ファイルは、パッケージ更新を処理する際に Debian
アーカイブ管理ソフトウェアによって使用されます。
このファイルは一つの段落からなり、debian/control と、
debian/changelog や debian/rules
などから抽出したソースパッケージの情報が含まれています。
.changes
ファイルは、文書化されたフィールドまたはその意味が変更されるたびに +1
されるフォーマットバージョン番号を持っています。 この文書では、1.8
フォーマットを記載します。
このファイルのフィールドは以下のものです。
Format (必須)
Date (必須)
Source (必須)
Binary (必須)
Architecture (必須)
Version (必須)
Distribution (必須)
Urgency (推奨)
Maintainer (必須)
Description (必須)
Changes (必須)
Files (必須)
このフィールドは、ソースパッケージの名前です。
debian/control
ファイルや .dsc
ファイル中のフィールドでは、
ソースパッケージの名前のみを含まなければいけません。
バイナリパッケージ中のコントロールファイルの中、または .changes
ファイル中では、ソースパッケージ名の後に、
かっこに入れたバージョン番号を続けて記載することができます [35]。
このバージョン番号は、該当のバイナリパッケージの Version
フィールドと同一の値を持っていた場合、dpkg-gencontrol
によって削除されます。
また、ソースパッケージがバイナリパッケージと同じ名前とバージョンを持っていた場合は、
このフィールド自体がバイナリパッケージコントロールファイルから削除されます。
パッケージ名 (ソースパッケージとバイナリパッケージの両方とも。 Package, Section 5.6.7 参照) 小文字英字 (a-z), 数字 (0-9), プラス記号 (+) マイナス記号 (-) とピリオド (.) のみを含むようにしなければいけません。 また、少なくとも二文字で、英数字から始まらなければいけません。
パッケージメンテナの名前と email アドレスです。 最初に名前がこなくてはいけません。 その後に email アドレスを <> の中に (RFC822 フォーマットで) 入れます。
パッケージメンテナの名前にピリオドが含まれていると、RFC822 に規定されている文法のミスによって、全てのフィールドが email アドレスとして適用されなくなります; このフィールドをアドレスとして使用するプログラムは、これをチェックして、必要であれば修正しなければいけません (例えば、名前をかっこのなかに入れて最後尾に移動し、 email アドレスを前の方に持ってきます)。
パッケージメンテナに関するこれ以外の要求事項や説明は、 パッケージのメンテナ, Section 3.3 を参照ください。
パッケージの共同メンテナがいる場合、その人 (達) の名前と email アドレスの一覧です。もし、パッケージに Maintainer フィールド に記載した以外のメンテナがいる場合、その人たちの名前と email アドレスをここに記載します。 書式はメンテナフィールドのものと同じであり、複数のエントリはコンマ "," で区切ります。
これは通常はオプションのフィールドですが、Maintainer にメールアドレスを共有するグループが指定されている場合には Uploaders フィールドの指定が必須で、ひとりの個人とその人の電子メールアドレスとが記載されていなければいけません。
debian/control
ファイルの Uploaders
フィールドでは、折り返しが許されています。
この版のパッケージを用意した人、通常はメンテナ、の名前と電子メールアドレスです。 Maintainer fieldと同じ書式が適用されます。
このフィールドには、パッケージを分類したアプリケーション分野を指定します。 セクション, Section 2.4 を参照ください。
debian/control
ファイルに現れている場合、 .changes
ファイルの Files
フィールドの同名のサブフィールドの値に代入されます。
また、バイナリパッケージの同名のフィールドの初期値にも代入されます。
このフィールドには、このパッケージをインストールすることの重要性が示されています。プライオリティ, Section 2.5 参照のこと。
debian/control
ファイルに現れている場合、 .changes
ファイルの Files
フィールドの同名のサブフィールドの値に代入されます。
また、バイナリパッケージの同名のフィールドの初期値にも代入されます。
バイナリパッケージの名前です。
バイナリパッケージの名前は、ソースパッケージの名前と同じ書式および制限を持ちます。 詳細は Source, Section 5.6.1 を参照ください。
これまでのコンテキストと、コントロールファイルの内容に依存しますが、 Architecture は以下の値を取ることができます。
Debian マシンアーキテクチャを示す、一意の一語。 アーキテクチャ指定のための文字列, Section 11.1 で規定されています。
アーキテクチャワイルドカードは Debian マシンアーキテクチャの集合を指定します。 アーキテクチャワイルドカード, Section 11.1.1 を参照ください。 any は全ての Debian マシンアーキテクチャにマッチし、もっとも良く使われます。
all これはアーキテクチャに依存しないパッケージであることを示します。
source 、つまりソースパッケージであることを示します。
ソースパッケージの中の、メインの debian/control
ファイル中では、このフィールドには特別な値 all または
特別のアーキテクチャワイルドカード any
か、スペースで区切られた複数のアーキテクチャまたはアーキテクチャワイルドカードのリストが許されます。
any または all
が記載されている場合、これ以外の値を書くことは許されません。
殆どのパッケージでは、any または all
のいずれかを使うことになります。
特定のアーキテクチャのリストを使う場合、そのソースからはフィールドに含まれているアーキテクチャのみに依存したパッケージがビルドされることを意味します。 特定のアーキテクチャのワイルドカードリストを使う場合、そのソースがフィールドにマッチするアーキテクチャのみに依存したパッケージをビルドすることを意味します。 アーキテクチャのリストや、any 以外のアーキテクチャワイルドカードを使う場合は例外的で、プログラムに可搬性がないか、一部のアーキテクチャでは役に立たない場合です。 一般的に言って、可能な限りプログラムは可搬性を持つように作成すべきです。
Debian ソースコントロールファイル .dsc
の中には、スペースで区切られたアーキテクチャまたはアーキテクチャワイルドカードのリストを書くことができます。
リストにアーキテクチャワイルドカード any が含まれる場合は、他には
all のみをリストに記載することが許されます。
リストには、特別な値 all (あるいはそれのみ)
を記載することが許されます。言い方を変えれば、.dsc
は
debian/control
とは異なり、all
は他の特定のアーキテクチャとの組み合わせとして記載することが許されています。
Debian ソースコントロールファイル .dsc
中の
Architecture フィールドは、通常はソースパッケージの
debian/control
の Architecture
フィールドから作成されます。
any のみを指定した場合、ソースパッケージは特定のアーキテクチャへの依存性はなく、どのアーキテクチャでもコンパイルできるはずであるということを意味します。 作成されたバイナリパッケージ (群) は、現在のビルドアーキテクチャ依存になります。
単に all は、ソースパッケージは特定のアーキテクチャに依存しないパッケージのみをビルドすることを示しています。
any all が指定されている場合は、ソースパッケージは特定のいずれのアーキテクチャにも依存しないことを示しています。 作成されるバイナリパッケージには、少なくともひとつのアーキテクチャ依存のパッケージと、ひとつのアーキテクチャ非依存のパッケージが含まれます。
アーキテクチャあるいはアーキテクチャワイルドカードが列挙されている場合、 ソースはアーキテクチャ依存としてビルドされることを示しており、列挙されているか、あるいはワイルドカードにマッチしたアーキテクチャでのみ動作します。 ソースパッケージから少なくとも一種類のアーキテクチャ非依存のパッケージがビルドされる場合、リストに all を含めてください。
.changes
ファイルの中の、Architecture
フィールドは、そのパッケージが現在対応しているアーキテクチャを示します。
これはリストです。もし、特別なエントリ source
があれば、そのパッケージのソースもアップロードされます。
アーキテクチャ非依存のパッケージがアップロードされる場合、all
を含めます。.changes
ファイルの Architecture
フィールドに any
などのアーキテクチャワイルドカードが現れてはいけません。
パッケージ構築の過程でアーキテクチャをどのように得るかについての情報は、 debian/rules
-
メイン構築スクリプト, Section C.2.1 を見てください。
これは、バイナリパッケージのコントロールファイル中、またはソース制御データファイル中のパッケージごとの段落に記述される yes/no の値です。
yes とセットしてあった場合、dpkg
と
dselect
は、このパッケージの削除を行ないません
(更新と置きかえは可能です)。 no
の場合は、このフィールドを持っていない場合と同じです。
これらのフィールドは、パッケージ間の関係を記述します。 パッケージ間の関連性の宣言, Chapter 7 を参照してください。
パッケージが準拠した最新の標準 (Debian ポリシーマニュアルおよびそれに関連するテキスト) のバージョンです。
バージョンナンバーはメジャー及びマイナーバージョン番号、さらにメジャー及びマイナーパッチレベルの 4 つの数字からなります。 全てのパッケージに渡って変更がなされる場合には、メジャーバージョンを変更します。 多くのパッケージに修正作業が必要な重要な変更の場合には、マイナーバージョンを変更することによってそれを示します。 パッチレベルについては、小さい変更であっても、それが基準の変更を伴う場合にはメジャーパッチレベルの変更となります。 マイナーパッチレベルの変更となるのは、表面上の変更、文書上の修正など意味合いの変化の無い場合、 またパッケージの内容に関して影響を与えない場合になります。
従ってマニュアルバージョンのうち最初の 3 つの数字が一般的なバージョンとしての意味を持ちます。 この数字を 3 つにするか 4 つ全てを使ってバージョンを規定するかは、オプション [36] です。
パッケージのバージョン番号です。書式は、 [epoch:]upstream_version[-debian_revision] です。
バージョンを構成する 3 つの要素は
これは一桁の符号なし整数です。普通は小さい数になるはずです。 ゼロと仮定して良い場合は省略できます。省略した時には、 upstream_version にコロンを含めてはいけません。
これはパッケージの古いバージョンのバージョン番号の誤りを許したり、 パッケージの以前のバージョン番号体系をそのままに残しておくためにあります。
これがバージョン番号の主要部分です。通常支障ない場合は .deb
ファイルが作られたオリジナルの ("上流の")
パッケージのバージョン番号になります。
普通は上流の作者によって定められたものと同じ形式になりますが、
パッケージ管理システムと比較手法に沿って修正を加えなければならないかもしれません。
upstream_version に関するパッケージ管理システムの比較の挙動については次節で述べます。 バージョン番号中で、この upstream_version の部分は必須です。
upstream_version は英数字 [37] と文字 . + - : ~ (ピリオド、プラス、ハイフン、コロン、チルド) だけから構成されており、数字で始まるようにすべきです。 ただし、debian_revision がない場合、ハイフンは許されません。 また、epoch がない場合、コロンは許されません。
バージョンのこの部分は、そのパッケージを 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[38]。
次に、二つの文字列の残りの部分から、全て数字で構成される最初の部分を決定します。 この二つの数値を比較し、比較結果として見つかった違いを返します。 このとき、空文字列 (比較している一方もしくは双方のバージョン文字列の末尾においてのみ生じる) は 0 として数えます。
違いが見つかるか、双方の文字列を調べ尽くすかするまで、この二つのステップを (先頭から、最初の非数字の文字列と最初の数字の文字列を比較し、切り離しながら) 繰り返します。
epoch の目的はバージョン番号付けのミスをそのままにできるようにするため、またバージョン番号の付け方を変更した場合に、 それをうまく扱えるようにするためだということに注意してください。 パッケージ管理システムが解釈することのできない文字 (ALPHA や pre- など) から成る文字列を含むバージョン番号や、思慮の浅い順序付け[39] をうまく処理するためでは ありません。
ソースおよびバイナリパッケージのコントロールファイル中で、 Description フィールドにはバイナリパッケージの説明が含まれています。 この説明は、概要または短い説明と、長い説明の二つの部分からなります。 このフィールドは複数行を許す行であり、書式を以下に示します。
Description: <一行概要> <複数行にわたる長い説明>
長い説明の部分のフォーマットは以下の通りです。
空白一つから始まる行は、パラグラフ (節) の一部です。 この行に引き続く行は、表示の際にはワードラップが行われます。 最初の空白は通常 (表示の際は) 削除されます。 この行には少なくとも一文字の空白以外の文字が含まれていなければいけません。
空白二つ以上から始まる行は、そのまま表示されます。 表示部を水平方向に広げられない場合は、表示プログラムは内容を強制改行 (単語境界を考慮せずに改行を挿入する) します。 可能な場合は必要に応じて表示が右側にはみ出します。表示時に、0 個 から 2 個までの空白が削除されますが、この際に削除される空白の個数は各行で一緒です (従って、インデントされた内容は正しく表示されます)。 この行には少なくとも一文字の空白以外の文字が含まれていなければいけません。
空白とドット ('.') のみからなる行は、空行として表示されます。 これは空行を表示させる唯一の手段です[40]。
空白、ドットといくつかの文字が続く行形式は将来の拡張用で、使わないでください。
タブは使用しないでください。どういう動作をするか分かりません。
更に詳しい説明は、パッケージの説明, Section 3.4 の項を参照ください。
.changes
ファイル中では、Description
フィールドにアップロードされるパッケージの説明文の要約を含んでいます。
この場合、フィールド値の最初の行 (Description: などと同じ行の部分)
は常に空行です。
これは複数行を許すフィールドで、パッケージ毎に論理行一行になります。
それぞれの行は、一つの空白でインデントされ、バイナリパッケージ名、空白、
ハイフン
(-)、空白、パッケージから持ってきた短い説明という構成になっています。
.changes
ファイルか changelog の解析出力には、
このパッケージがインストールされていた、またはこれからインストールされるディストリビューションの名前が空白で区切られて含まれます。
有効なディストリビューション名はアーカイブメンテナが決定します。 [41] Debian
アーカイブソフトウェアは、単一のディストリビューションの記載しかサポートしていません。
パッケージを他のディストリビューションに移動する処理はアップロードプロセスの外で行われます。
このフィールドにはパッケージがビルドされた、または修正された日付を記載します。
これは、debian/changelog
エントリの date
と同じフォーマットでなければいけません。
このフィールドの値は通常 debian/changelog
ファイルから抽出します。Debian
changelog: debian/changelog
, Section 4.4 を参照ください。
.changes
ファイルでは、このフィールドはこのファイルのフォーマットバージョンを宣言します。
このフィールドの値の書式は パッケージバージョン番号と同じですが、 epoch や Debian
revision は付けることができません。 書式は、本文書では 1.8
に記載されています。
Debian ソースコントロールファイル
.dsc
では、このフィールドはソースパッケージのフォーマットを宣言します。
このフィールドの値は、ソースパッケージ内のファイルのリストを解釈し、アンパック方法を判断する必要があるような、パッケージを操作するためのプログラムで用いられます。
このフィールドの値の書式は、数字のメジャーレビジョン、ピリオド、数字のマイナーレビジョンに、その後空白を挟んでオプションのサブタイプが続くものです。
サブタイプがある場合、それはかっこで囲まれた英数字の語です。
サブタイプは書式上は省略可能ですが、特定のソースフォーマットレビジョンでは必須になります
[42]。
以前のバージョンからのアップグレードがどの程度重要なのかを示します。 以下のいずれかのキーワードのひとつを指定します low、medium、 high emergency および critical[43] (大文字と小文字は区別されません)。 空白で区切られたコメント (たいていかっこにはいっています) がオプションとしてつくこともあります。例えば:
Urgency: low (HIGH for users of diversions)
このフィールドの値は普通は debian/changelog
から取ってきます。Debian changelog:
debian/changelog
, Section 4.4 を参照ください。
このフィールドは複数行を許す書式で、人が読むための変更点のデータを示します。 一つ前のバージョンと現在のバージョンとの相違を説明します。
フィールドの最初の値 (Changes: と同じ行の部分) は必ず空です。 フィールドの値は継続行に記載され、最低限一つの空白によってインデントされます。 空行は、空白とピリオド (.) だけからなる行で作成されます。
このフィールドの値は普通は debian/changelog
から取ってきます。Debian changelog:
debian/changelog
, Section 4.4 を参照ください。
それぞれのバージョンの変更情報は、「title」行の後に続きます。 この「title」行には、すくなくとも、バージョン、ディストリビューション、緊急度のフィールドが人が読める形式で含まれています。
もし、いくつかのバージョンのバージョン情報が返されるような場合、 最新のバージョンに対するものを最初に返すようにすべきで、 同時に空行を入れてエントリ行を分割してください (「title」行の後もまた空行のあとで 続けてください)。
このフィールドは折り返しを許す書式で、バイナリパッケージのリストです。 書式と意味は、このフィールドが現れたコントロールパッケージが何であるかに依存します。
.dsc
ファイルに記載されている場合は、それはそのソースパッケージが生成できるバイナリパッケージのカンマで区切られたリストです
[44]。
ソースパッケージでは、ここに記載された全バイナリパッケージがすべてのアーキテクチャで生成できる必要はありません。
個々のバイナリパッケージがどのアーキテクチャに対応しているかの詳細は、ソースコントロールファイルには含まれません。
.changes
ファイル中では、このフィールドの値は、
実際にアップロードされているバイナリパッケージの名前の、空白 (カンマではなく)
で区切られたリストです。
このフィールドは、バイナリパッケージのコントロールファイルと
Packages
ファイルに現われます。
名前で指定されたパッケージをインストールするのに必要なディスク容量の概算値を示します。
実際に消費されるインストールサイズはブロックサイズ、ファイルシステムプロパティやパッケージメンテナスクリプトでの処理に依存します。
ディスク容量は、バイト値のインストールサイズを 1,024 で割って切り上げた整数値です。
このフィールドは、ファイルとそれについての情報を逐一記したリストから構成されます。 厳密な情報と書式は使われる状況によります。
どの場合においても、Files は複数行からなるフィールドです。 フィールドの最初の行 (即ち Files: のある行) は空です。 継続行に 1 つのファイルにつき一行の内容が記されます。 このとき各行は 1 つの空白文字でインデントされ、下記の通り、空白で区切られた各サブフィールドが続きます。
.dsc
ファイルの場合には、このフィールドには tar
ファイルと、ソースパッケージの残りの部分である diff ファイル (存在する場合)
の各々について、MD5 チェックサム、サイズ、ファイル名が記されます。 この diff
ファイルは、ソースパッケージの変更分 [45] です。例を挙げます。
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
ファイルを生成するのに使用されたソースアーカイブとバイト単位で正確に一致していなければなりません。
.changes ファイルでの変更/修正により、アップロードで閉じられるバグレポート番号を、空白で区切って列挙します。
このパッケージのウェブサイトの URL です。 可能な場合、望ましいのは元のソースが入手でき、追加の上流の文書や情報が入手できるようなサイトです。 このフィールドの内容には、<> などで囲まない単純な URL を記載します。
これらのフィールドは複数行を許す書式で、各ファイルに対しチェックサムとサイズを付けたリストが格納されています。 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
フィールドのファイルのリストと一致している必要があります。
廃止になりました。以下を参照ください。
VCS を使って開発される Debian ソースパッケージが増えてきています。 以下のフィールドは、Debian ソースパッケージの開発が行われている一般からアクセス可能なリポジトリを示すために用いられます。
リボジトリのブラウズのためのウェブインターフェースの URL です。
フィールド名で VCS の種別を識別します。 フィールドの値は各バージョンコントロールシステムで一般的なリポジトリの位置を示す書式で、パッケージングのためのリポジトリの位置を決めるのに十分な値にすべきです。 理想的には、この値は Debian パッケージの新版の開発で用いているブランチの位置も示しているのが望ましいです。
Git の場合、この値は URL からなり、オプションとして -b という語と、示されたレポジトリのブランチ名が続きます。これは git clone コマンドの書式に沿ったものです。 ブランチが指定されない場合、パッケージングは既定のブランチで行われているべきです。
ひとつのパッケージで、ひとつ以上の VCS を指定しても構いません。
このフィールドは複数行を許す書式で、当該ソースパッケージから作成されるすべてのパッケージを、すべてのアーキテクチャを考慮して列挙します。 このフィールドの最初の行の値は空です。 次の行からは順に各行に一つのバイナリパッケージが、名前、タイプ、セクション、プライオリティの順に空白区切りで列挙されます。 5 番目、およびそれ以降の空白区切りの要素を記載可能で、このフィールドのパーザはそれを許すようにしなければいけません。 パッケージタイプについては Package-Type フィールドを参照してください。
1 語からなる単純なフィールドで、パッケージのタイプを記載します。 バイナリパッケージに対しては deb を、マイクロバイナリパッケージには udeb を指定します。 ここで定義されていない他のタイプも記載可能です。 ソースパッケージコントロールファイルでは、Package-Type には deb を指定せず、省略すべきです。 これは、このフィールドを省略した場合、deb とみなされるためです。
折り返しされるフィールドで、git のコミットハッシュ (full 形式) 1 つに、将来の拡張時に定義される予定の空白区切りのデータが続きます。
ソースパッケージが、dgit-repos という名称の基準となる場所で提供される
Git
リポジトリにて、ここで記載されたコミットと正確に一致しているということを宣言します。
上記の場所は、Debian アーカイブと Git との間の双方向ゲートウェイで、
dgit
で利用されます。 当該コミットは、名称が
refs/dgit/* に一致する一参照から (少なくとも) 到達可能です。詳細は
dgit
のマニュアルを参照ください。
Debian ソースコントロールファイルにはユーザ定義フィールドを追加することができます。 これらは無視され、(例えば) バイナリやソースパッケージコントロールファイル、アップロードコントロールファイルにはコピーされません。
出力ファイルにサポートされていないフィールドを付加したいときは、ここに述べる方法を使用してください。
メインのソースコントロールファイルにおいて、X から始まり、BCS とハイフン - が続くフィールドは、出力ファイルにコピーされます。 そして出力ファイルには、フィールド名のハイフンの後に続く文字部のみが使用されます。 ここで、B はバイナリパッケージコントロールファイルに使用されるとき、 S Debian ソースコントロールファイルに使用されるとき、 C は、アップロードコントロールファイル (.changes) に使用されるときに使われます。
メインのソース情報コントロールファイルが以下のフィールドを含んでいるときは、
XBS-Comment: I stand between the candle and the star.
バイナリと Debian ソースコントロールファイルは、次のフィールドを含みます。
Comment: I stand between the candle and the star.
以下のフィールドは廃止になっており、ポリシィの以前の版に対応したパッケージで指定されているかもしれません。
Debian メンテナに、対象パッケージを Debian
アーカイブにアップロードして良いことを指示します。 このフィールドの有効な値は
yes のみです。 このフィールドは Debian
メンテナの行うアップロードを調整するために使われていました。
この件の詳細は、一般決議 Endorse the concept of Debian
Maintainers (Debian メンテナの考え方を裏書する)
を参照ください。
[ 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.5.0, 2014-07-03