いくつかの状況下では、バイナリパッケージの再ビルドが必要です。たとえば、管理者は特定のコンパイルオプションを付けてソフトウェアをソースからコンパイルすることで導入されるソフトウェアの機能を必要とする場合があります。そしてまた、インストール済みの Debian のバージョン用にパッケージングされたソフトウェアのバージョンが古い場合があります。ソフトウェアのバージョンが古い場合、管理者は
テスト版や
不安定版などの Debian の新しいバージョンから取得したより新しいパッケージをビルドすることが多いです。こうすることで、新しいパッケージを
安定版ディストリビューションで動かすことが可能です。この操作は「バックポート」と呼ばれています。いつも通り、バックポート作業の前に既にバックポートパッケージが公開されているか否かを注意深く確認するべきです。対象のパッケージに対する Debian Package Tracker を一読するだけでこの種の情報が明らかになります。
Debian パッケージの再構築は、ソースコードを取得することから始まります。最も簡単な方法は、
apt-get source package-name コマンドを使用することです。このコマンドを使用するには、
/etc/apt/sources.list ファイルに
deb-src の記述を書式に従って追加し、(
apt-get update など) で最新の状態に更新する必要があります。APT の設定に関する章の指示に従っている場合、これらの条件は既に満たされているはずです (
第 6.1 節「sources.list ファイルの内容」 を参照)。ただし、
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 ファイルを取得し、内容を解析し、ファイル内で参照されている単一もしくは複数のファイルを自動的に取得します。すべてのダウンロードが完了したら、dscverifyを使いソースパッケージの整合性を確認して、これを展開します (これは -d または --download-only オプションが使われていない場合に限ります)。オプション -u を指定しない限り、Debian keyring が必要です。
Let us use the samba package as an example.
$ apt source samba
パッケージリストを読み込んでいます... 完了
注意: 'samba' パッケージは、以下の 'Git' バージョン管理システムで管理されています:
https://salsa.debian.org/samba-team/samba.git -b bookworm
以下のコマンドを使用して、パッケージの最新（未リリースの可能性もあります）アップデートを取得してください:
git clone https://salsa.debian.org/samba-team/samba.git -b bookworm
18.5 MB のソースアーカイブを取得する必要があります。
取得:1 http://deb.debian.org/debian bookworm/main samba 2:4.17.12+dfsg-0+deb12u1 (dsc) [4,466 B]
取得:2 http://deb.debian.org/debian bookworm/main samba 2:4.17.12+dfsg-0+deb12u1 (tar) [18.2 MB]
取得:3 http://deb.debian.org/debian bookworm/main samba 2:4.17.12+dfsg-0+deb12u1 (diff) [273 kB]
18.5 MB を 0 秒で取得 (59.1 MB/秒)
dpkg-source: info: samba-4.17.12+dfsg から samba を抽出中
dpkg-source: info: 解凍中samba_4.17.12+dfsg.orig.tar.xz
dpkg-source: 情報: samba_4.17.12+dfsg-0+deb12u1.debian.tar.xz を展開しています
dpkg-source: 情報: debian/patches/series のパッチリストを使用しています
dpkg-source: 情報: libsmbclient-ensure-lfs-221618.patch を適用しています
dpkg-source: 情報: hurd-compat.patch を適用しています
dpkg-source: 情報: [...] を適用しています
The source of the package is now available in a directory named after the source package and its version (samba-4.17.12+dfsg); this is where we'll work on our local changes.
The first thing to do is to change the package version number, so that the rebuilt packages can be distinguished from the original packages provided by Debian. Assuming the current version is
2:4.17.12+dfsg-0+deb12u1, we can create version
2:4.17.12+dfsg-0+deb12u1+falcot1, which clearly indicates the origin of the package. This makes the package version number higher than the one provided by Debian, so that the package will easily install as an update to the original package. Such a change is best effected with the
dch command (
Debian CHangelog) from the
devscripts package.
$ cd samba-4.17.12+dfsg
$ dch --local +falcot
直近のコマンドはテキストエディタ（
sensible-editor —
VISUAL または
EDITOR 環境変数で指定されている場合はお気に入りのエディタ、そうでない場合はデフォルトのエディタ）を起動し、今回のリビルドによって生じた変更点を記録できるようにします。このエディタは、
dch によって実際に
debian/changelog ファイルが変更されたことを示しています。
When a change in build options is required, the changes need to be made in debian/rules, which drives the steps in the package build process. In the simplest cases, the lines concerning the initial configuration (./configure …) or the actual build ($(MAKE) … or make … or cmake … or …) are easy to spot. If these commands are not explicitly called, they are probably a side effect of another explicit command, in which case please refer to their documentation to learn more about how to change the default behavior. With packages using dh, you might need to add an override for the dh_auto_configure or dh_auto_build commands (see their respective manual pages and debhelper(7) for explanations on how to achieve this).
パッケージに対して行った変更の内容によっては、debian/control ファイルの内容もまた更新する必要があります。debian/control ファイルには生成されるパッケージの説明が含まれます。特に、debian/control ファイルにはパッケージのビルド時点で満足されなければいけない依存関係のリストを制御する Build-Depends 行が含まれます。Build-Depends 行で指定されているパッケージのバージョンはソースパッケージが提供されるディストリビューションに含まれるパッケージのバージョンと一致している場合が多いです。しかし、再ビルドを行うディストリビューションではここで指定されているバージョンが利用できないかもしれません。依存関係が本物か、それともビルド時にライブラリの最新版を試すことを保証するためだけ指定されているかを決定する自動的な方法はありません。Build-Depends 行を使うことが自動ビルドロボットにビルド中に与えられたパッケージバージョンを使うことを強制するための唯一の方法なので、Debian メンテナはバージョンを厳しく指定したビルド依存関係を使うことが多いです。
もしあなたが、指定されているビルド依存関係を緩めても問題ないと確信できる場合、手元で自由に依存関係を緩和することが可能です。対象のソフトウェアをビルドする標準的な方法について説明しているファイル (INSTALL と名付けられていることが多いです) を読むことは適切な依存関係を明らかにする助けになります。理想的に言えば、再ビルドに使うディストリビューションの要素を使ってすべての依存関係を満足させるべきです。しかしそれが無理ならば、対象のパッケージをバックポートする前に、再帰的に Build-Depends フィールドで言及されているパッケージを必ずバックポートしなければいけません。一部のパッケージはバックポートの必要がなく、ビルド作業中に現状のままインストールできます (特筆すべき例は debhelper です)。バックポート作業は気を付けないとすぐに複雑になる点に注意してください。それゆえ、バックポートは可能な限り厳密に必要最低限に留めるべきです。
ソースに対するすべての必要な変更が完了したら、実際のバイナリパッケージ (.deb ファイル) を生成します。すべてのプロセスは dpkg-buildpackage コマンドで管理されます。
例 15.1 パッケージの再ビルド
$ dpkg-buildpackage -us -uc
[...]
The previous command can fail if the
Build-Depends field has not been updated, or if the related packages are not installed. In such a case, it is possible to overrule this check by passing the
-d option to
dpkg-buildpackage. However, explicitly ignoring these dependencies runs the risk of the build process failing at a later stage. Worse, the package may seem to build correctly but fail to run properly: some programs automatically disable some of their features when a required library is not available at build time. The switch can still be very useful if you only want to create a source package, which is supposed to be passed to clean build environments as described in
「QUICK LOOK Building packages in chrooted and virtual environments」.
The other options used in the above example make sure that neither the source package's .dsc (-us) nor the produced .changes file (-uc) get signed with the package builder's cryptographic key after a successful build.
More often than not, Debian developers use a higher-level program such as debuild; this runs dpkg-buildpackage as usual, but it also adds an invocation of a program that runs many checks to validate the generated package against the Debian policy. This script also cleans up the environment so that local environment variables do not “pollute” the package build. The debuild command is one of the tools in the devscripts suite, which share some consistency and configuration to make the maintainers' task easier.
