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