dpkg は、主に Debian GNU/Linux を対象と
しています。しかし、他のシステム上でも動くでしょうし、
他のシステムに移植することもできるでしょう。
つまり、そのスクリプトの実行が成功しても、 失敗しても、そのスクリプトが再び呼び出された時に 暴走せず、ただ、全てが正しく動作するいうことです。
この Architecture フィールドは、全てのパッケージに 存在しなければ
なりません。ただし、今のところ dpkg は、 古いパッケージも
インストールできるように、Architecture フィールドを 要求しません。
タイムスタンプを保持する根拠は、ファイルの作成時間を 知ることによって伝わる情報があるからです。例えば、 ある文書の修正時間を見ることによって、それが非常に 古いものであるのかどうかを判断することができます。 ですから、アップストリームのソースの修正時間を 保持しておくのはとても良いことです。
これは、作成される制御ファイルが、 正しい許可属性を持つようにするためです。
近くリリースされる新しいバージョンの dpkg では、
実行形式と同様に、共有ライブラリも引数にして dpkg-shlibdeps
を呼び出すことが 要求されるでしょう。
引数となる実行可能ファイルには、それらの作られる ソースツリーのある場所や、バイナリパッケージが 作られる前に仮インストールされる構築ツリーの ある場所を指定することもできます。
changelog の著者がパッケージの保守担当者でもある場合、 パッケージの全ての変更に対して changelog を 使わないようにすることもできますが、パッケージや 元のソースの保守担当者が違う人になった時には、 名前を変更しなければなりません。
これは 822-date プログラムによって 作成されます。
files.new は dpkg-gencontrol と
dpkg-distaddfile が一時的な
ファイルとして使います。エラーが起こったときに
作られる問題のあるファイルをそのまま残して おかないようにするため、
dpkg-gencontrol と dpkg-distaddfile
は、新しいバージョンの files をここに書き出し、そしてファイル名を
かえます。
現在、ソースパッケージの構築中にハードリンクは 検出されませんが、ソースパッケージの展開時にのみ 検出されます。
将来、ハードリンクが認められるかもしれませんが、 それにはとても多くの作業が必要となります。
setgid されたディレクトリーは認められています。
ファイル名の変更については特別扱いしません。 つまり、古いファイルの削除 （dpkg-source によって警告が発せられるか、 そうでなければ無視されます。）と 新しいファイルの作成として扱われます。
@ : = % _ (アットマーク、コロン、等号、パーセント、 アンダースコア) といった記号は、以前には 認められていて、今でも、パッケージファイルの名前に 現れた場合には許容されますが、新しいパッケージでは 使ってはいけません。
これはバグです。
もしバージョンナンバーが指定されているなら、 通常、パッケージの名前の後に一つの空白を残します。
英語の習慣では、コンマの後には空白を入れます。
つまり、tar ファイルに無い部分のうちで、 .dsc ファイル以外の部分のことです。
問題のうちの一部は、おそらく、dpkg のバグによるものです。
バージョン 0.93.23 以降。
現行バージョン（1.2.4）の dpkg には、
依存関係の判定部分中にバグがあり、依存関係の問題の
うちのいくらかを無視してしまいます。
現在、dpkg-shlibdeps は ldd
を呼び出します。しかし、近くリリースされる新しい
バージョンでは、objdumpを呼び出すでしょう。
ただし、この変更のために、パッケージの構築方法にも 多くの変更が必要です。
ライブラリ libbar がバイナリ foo に
リンクされ、foo が libbar を
直接使っていると仮定します。その他のライブラリが libbar
に必要な場合、そのライブラリは foo に間接的にリンクされていて、
libbar がロードされるときに自動的に
ダイナミックリンカーがロードします。 ldd
を使うと、直接使われているライブラリと
間接的に使われているライブラリを、全て列挙します。 しかし、objdump
は直接使われているライブラリ のみを列挙します。間接的に使われるライブラリは、
直接使われてるライブラリから依存されているはずなので、
パッケージは直接リンクしているライブラリにだけ 依存する必要があります。
この変更は、パッケージの構築方法に変更があることを 意味します。現在、dpkg-shlibdeps はバイナリに 対してのみ実行されています。しかし、今後は、 あるライブラリが他のライブラリを必要とする場合には、 前者のライブラリが後者のライブラリに依存する必要が あるので、ライブラリに対しても dpkg-shlibdeps を 実行することが必要になります。
このことについての理解を助けとなる良い例が、 複数のバージョンの mesa ライブラリにたいする 現在の混乱です。ldd を基本としたシステムでは、 mesa を使う全てのパッケージは、glide mesa 互換 ライブラリを取り扱うために、svgalib|svgalib-dummy への 依存関係を加える必要があります。 objdump を基本としたシステムでは、このことは、 もはや必要でなく、全ての人のたくさんの労力を省くことが できます。
例をもうひとつ挙げます。dgf という新しいグラフィック フォーマットに対応した、新しいバージョンの libimlib に 更新することができるとします。もし、古い ldd による 方法を用いるとすれば、libimlib を使うパッケージは全て libgdf にも依存するようにコンパイルし直す必要が あります。そうでなければ、missing symbols となって 実行することができません。しかし、新しいシステムでは、 libimlib 自身が libdgf に依存するので、libimlib を 使っているパッケージは libimlib に依存しておけば、 更新する必要がありません。
Debian Packaging Manual
version revision 1.13, 2000-08-22ijackson@gnu.ai.mit.edubweaver@debian.orgschwarz@debian.orgsrivasta@debian.orgJ.D.Gilbey@qmw.ac.ukdebian-policy@lists.debian.orgshayase@tky3.3web.ne.jpdebian-doc@debian.or.jp