apt-get source source-package-name
コマンドを使う事です。このコマンドを実行するには /etc/apt/sources.list
ファイルの中に deb-src
行が必要で、さらに最新のインデックスファイル (例えば apt-get update
の実行) が必要です。管理者が APT 設定を取り扱う章で説明した内容 (「sources.list
ファイルの内容」参照) に従っている場合、これらの状況は既に満足されているはずです。しかしながら、このコマンドは deb-src
行で言及されている Debian バージョンのソースパッケージをダウンロードする点に注意してください。もし他のバージョンのソースパッケージが必要な場合、Debian ミラーや Debian のウェブサイトから手作業でダウンロードする必要があるかもしれません。ここでは 2、3 個のファイルを取得します (Debian Source Control 用に *.dsc
拡張子を持つファイル、*.tar.comp
としばしば *.diff.gz
や *.debian.tar.comp
拡張子を持つファイル、ここで comp は使われている圧縮ツールに応じて gz
、bz2
、lzma
、xz
の内のどれか 1 つです)。そしてdpkg-source -x file.dsc
コマンドを実行します。*.dsc
ファイルが URL を指定すれば直接的に利用可能な場合、dget URL
コマンドを使えばより簡単にすべてを取得する事が可能です。dget コマンドは (devscripts パッケージに含まれます) 指定したアドレスから *.dsc
ファイルを取得し、内容を解析し、ファイル内で参照されている単一もしくは復数のファイルを自動的に取得します。-x
オプションを付けることで、ダウンロードの後ソースパッケージを展開します。
3.6.16-2
の場合、バージョン 3.6.16-2falcot1
を作成する事が可能です。これはパッケージの出自を明らかに示しています。このパッケージのバージョン番号は Debian が提供するパッケージのバージョン番号よりも大きいため、このパッケージを元パッケージの更新として簡単にインストール可能です。このような作業を極めて効果的に行うには、devscripts パッケージの提供する dch
コマンド (Debian CHangelog) を dch --local falcot
のように使います。これは最良の効果を発揮します。このコマンドはテキストエディタ (sensible-editor
、このエディタは VISUAL
または EDITOR
環境変数で定義されている場合お気に入りのエディタです、そうでなければデフォルトエディタです) を起動します。ここで、再ビルドによって導入される変更の内容を記述してください。このエディタは dch
が debian/changelog
ファイルを変更した事を示します。
debian/rules
を修正します。debian/rules
はパッケージビルド作業を動作させるものです。debian/rules
が最も単純に書かれている場合、初期設定 (./configure …
) や実際のビルド ($(MAKE) …
や make …
) を簡単に見つけられるでしょう。ファイル内にこれらのコマンドが明示的に書かれていない場合、このファイルの内容は別のコマンドに対する作用を書いているのかもしれません。このような場合、デフォルト挙動を変える方法をより詳細に学ぶために文書を参照してください。
debian/control
ファイルの内容もまた更新する必要があります。debian/control
ファイルには生成されるパッケージの説明が含まれます。特に、debian/control
ファイルには、パッケージのビルド時点で満足されなければいけない依存関係のリストを制御する Build-Depends
行が含まれます。Build-Depends
行で指定されているパッケージのバージョンはソースパッケージが提供されるディストリビューションに含まれるパッケージのバージョンと一致している場合が多いです。しかし、再ビルドを行うディストリビューションではここで指定されているバージョンが利用できないかもしれません。依存関係が本物か、それともビルド時にライブラリの最新版を試す事を保証するためだけ指定されているかを決定する自動的な方法はありません。Build-Depends
行を使う事が、autobuilder にビルド中に与えられたパッケージバージョンを使う事を強制するための、唯一の利用可能な方法なので、Debian メンテナはバージョンを厳しく指定したビルド依存関係を使う事が多いです。
INSTALL
ファイルを読むことは適切な依存関係を明らかにする助けになります。理想的に言えば、再ビルドに使うディストリビューションの要素を使って、すべての依存関係を満足するべきです; それが無理ならば、対象のパッケージをバックポートする前に、再帰的に Build-Depends
フィールドで言及されているパッケージを必ずバックポートしなければいけません。一部のパッケージはバックポートの必要が無く、ビルド作業中に現状のままインストール可能です (特筆すべき例は debhelper です)。バックポート作業は気を付けないとすぐに複雑になる点に注意してください。それゆえ、バックポートは可能な限り厳密に必要最低限に留めるべきです。
.deb
ファイル) を生成します。すべてのプロセスは dpkg-buildpackage
コマンドで管理されます。
Build-Depends
フィールドが更新されていなかったり、関連するパッケージがインストールされていなかった場合、dpkg-buildpackage
コマンドは失敗します。そのような場合、dpkg-buildpackage
に -d
オプションを指定して、依存関係確認を行わないようにする事も可能です。しかしながら、依存関係を明示的に無視すると、後々の段階でビルド作業が失敗する恐れがあります。さらに悪いことに、パッケージが正常にビルドされたように見えても、正しく動かない可能性があります: 一部のプログラムは、必要なライブラリがビルド時に利用可能でない場合、一部の機能を自動的に無効化します。
debuild
等の高レベルプログラムを使います; debuild
は通常通り dpkg-buildpackage
を実行しますが、加えて生成されたパッケージの Debian ポリシーに対する妥当性を確認するプログラムを実行します。このスクリプトは、手元の環境変数がパッケージビルドを「汚染」しないように、ビルド環境を整えます。debuild
コマンドは devscripts スイートに含まれるツールの 1 つで、メンテナの仕事を簡単にするための幾つかの一貫性と設定を共有します。