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 つで、メンテナの仕事を簡単にするための幾つかの一貫性と設定を共有します。