在几种情况下需要重新构建二进制包。在某些情况下，管理员需要一个软件功能，需要软件使用特定的编译选项从源码来编译；还有一些其它情况，在已安装的 Debian 版本上打包的软件版本不够新。在后一种情况下，管理员通常将从较新版本的 Debian 构建更新的软件包——如
Testing（测试版）或者
Unstable（不稳定版）——这样新的软件包可以工作在
Stable（稳定版）上；这种操作被称之为“backporting”（向后移植）。像通常一样，应该小心谨慎，在执行这样的任务之前要检查是否有人已经做过了—— 在 Debian Package Tracker （Debian 软件包跟踪网页）上快速查看会显示该信息。
Rebuilding a Debian package starts with getting its source code. The easiest way is to use the
apt-get source package-name command. This command requires a
deb-src line in the
/etc/apt/sources.list file, and up-to-date index files (i.e.
apt-get update). These conditions should already be met if you followed the instructions from the chapter dealing with APT configuration (see
第 6.1 节 “编写 sources.list 文件”). Note, however, that you will be downloading the source packages from the Debian version mentioned in the
deb-src line.
If you need another version, you may need to download it manually from a Debian mirror or from the web site. This involves fetching two or three files (with extensions *.dsc — for Debian Source Control — *.tar.comp, and sometimes *.diff.gz or *.debian.tar.comp — comp taking one value among gz, bz2 or xz depending on the compression tool in use), then run the dpkg-source -x file.dsc command. If the *.dsc file is directly accessible at a given URL, there is an even simpler way to fetch it all, with dget URL. This command (which can be found in the devscripts package) fetches the *.dsc file at the given address, then analyzes its contents, and automatically fetches the file or files referenced within. Once everything has been downloaded, it verifies the integrity of the downloaded source packages using dscverify, and it extracts the source package (unless the -d or --download-only option is used). The Debian keyring is needed, unless the option -u is supplied.
让我们使用 samba 软件包作为示例。
$ apt source samba
Reading package lists... Done
NOTICE: 'samba' packaging is maintained in the 'Git' version control system at:
https://salsa.debian.org/samba-team/samba.git -b bookworm
Please use:
git clone https://salsa.debian.org/samba-team/samba.git -b bookworm
to retrieve the latest (possibly unreleased) updates to the package.
Need to get 18.5 MB of source archives.
Get:1 http://deb.debian.org/debian bookworm/main samba 2:4.17.12+dfsg-0+deb12u1 (dsc) [4,466 B]
Get:2 http://deb.debian.org/debian bookworm/main samba 2:4.17.12+dfsg-0+deb12u1 (tar) [18.2 MB]
Get:3 http://deb.debian.org/debian bookworm/main samba 2:4.17.12+dfsg-0+deb12u1 (diff) [273 kB]
Fetched 18.5 MB in 0s (59.1 MB/s)
dpkg-source: info: extracting samba in samba-4.17.12+dfsg
dpkg-source: info: unpacking samba_4.17.12+dfsg.orig.tar.xz
dpkg-source: info: unpacking samba_4.17.12+dfsg-0+deb12u1.debian.tar.xz
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: applying libsmbclient-ensure-lfs-221618.patch
dpkg-source: info: applying hurd-compat.patch
dpkg-source: info: applying [...]
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 文件中也会需要更新，这个文件包含了对生成的软件包的描述。特别是，这个文件包含了 Build-Depends 行来控制依赖的列表，依赖列表必须在软件包构建时填入。这些经常参考源码包所来自的发布版本中包含的软件包版本，但在用于重新构建的发布版本中会不可用。没有自动的方式来确定依赖是真实的，还是特定的从而保证只通过最新版的库来尝试构建——这是在构建中强制 autobuilder 使用给定的软件包版本的唯一可用方式，这就是为什么 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.
