【Debian管理员手册】第 15 章创建一个 Debian 软件包

15.1. 从源码重建安装包

15.1.1. 获取源代码
15.1.2. 修改源码
15.1.3. Starting the Rebuild

15.2. Building your First Package

15.2.1. Meta-Packages or Fake Packages
15.2.2. Simple File Archive

15.3. Creating a Package Repository for APT

15.4. Becoming a Package Maintainer

15.4.1. Learning to Make Packages
15.4.2. Acceptance Process

对于以常规方式处理Debian软件包的管理员来说，最终觉得需要创建自己的软件包或修改现有软件包是很常见的。本章旨在回答本领域最常见的问题，并提供必要的元素以最好的方式利用Debian基础设施。在尝试你的本地包后，我希望你甚至可能觉得需要去更进一步并加入Debian项目！

15.1. 从源码重建安装包

在几种情况下需要重建二进制包。在某些情况下，管理员需要一个软件功能，需要使用特定的编译选项从源编译软件;还有一些情况，安装在Debian上的版本不够新。在后一种情况下，管理员通常将从较新版本的Debian构建一个更新的包 — 例如
Testing或者
Unstable，这样新的包可工作在
Stable上；这种操作被称之为 “backporting”。在执行这样的任务之前，通常应该小心检查是否有人已经做过了 – 在Debian Package Tracker 快速查看将显示该信息。 → https://tracker.debian.org/

15.1.1. 获取源代码

Rebuilding a Debian package starts with getting its source code. The easiest way is to use the
apt-get source 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 the
dget URL command. 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.

15.1.2. 修改源码

Let us use the
samba package as an example.

$ 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
Please use:
git clone https://salsa.debian.org/samba-team/samba.git
to retrieve the latest (possibly unreleased) updates to the package.
Need to get 11.7 MB of source archives.
Get:1 http://security.debian.org/debian-security buster/updates/main samba 2:4.9.5+dfsg-5+deb10u1 (dsc) [4,316 B]
Get:2 http://security.debian.org/debian-security buster/updates/main samba 2:4.9.5+dfsg-5+deb10u1 (tar) [11.4 MB]
Get:3 http://security.debian.org/debian-security buster/updates/main samba 2:4.9.5+dfsg-5+deb10u1 (diff) [252 kB]
Fetched 11.7 MB in 1s (9,505 kB/s)
dpkg-source: info: extracting samba in samba-4.9.5+dfsg
dpkg-source: info: unpacking samba_4.9.5+dfsg.orig.tar.xz
dpkg-source: info: unpacking samba_4.9.5+dfsg-5+deb10u1.debian.tar.xz
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: applying 07_private_lib
dpkg-source: info: applying bug_221618_precise-64bit-prototype.patch
[...]

The source of the package is now available in a directory named after the source package and its version (
samba-4.9.5+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.9.5+dfsg-5, we can create version
2:4.9.5+dfsg-5falcot1, 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.9.5+dfsg $ dch --local falcot

The last command invokes a text editor (
sensible-editor — this should be your favorite editor if it is mentioned in the
VISUAL or
EDITOR environment variables, and the default editor otherwise) to allow documenting the differences brought by this rebuild. This editor shows us that
dch really did change the
debian/changelog file. 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 …) 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 for explanations on how to achieve this). Depending on the local changes to the packages, an update may also be required in the
debian/control file, which contains a description of the generated packages. In particular, this file contains
Build-Depends lines controlling the list of dependencies that must be fulfilled at package build time. These often refer to versions of packages contained in the distribution the source package comes from, but which may not be available in the distribution used for the rebuild. There is no automated way to determine if a dependency is real or only specified to guarantee that the build should only be attempted with the latest version of a library — this is the only available way to force an
autobuilder to use a given package version during build, which is why Debian maintainers frequently use strictly versioned build-dependencies. If you know for sure that these build-dependencies are too strict, you should feel free to relax them locally. Reading the files which document the standard way of building the software — these files are often called
INSTALL — will help you figure out the appropriate dependencies. Ideally, all dependencies should be satisfiable from the distribution used for the rebuild; if they are not, a recursive process starts, whereby the packages mentioned in the
Build-Depends field must be backported before the target package can be. Some packages may not need backporting, and can be installed as-is during the build process (a notable example is
debhelper). Note that the backporting process can quickly become complex if you are not careful. Therefore, backports should be kept to a strict minimum when possible.

技巧安装构建依赖

apt-get allows installing all packages mentioned in the
Build-Depends fields of a source package available in a distribution mentioned in a
deb-src line of the
/etc/apt/sources.list file. This is a simple matter of running the
apt-get build-dep source-package command.

15.1.3. Starting the Rebuild

当所有要做的更改都应用到源代码后，我们就可以开始生成实际的二进制包（
.deb）。整个过程由
dpkg-buildpackage管理。

例 15.1. 重构建一个包

$ dpkg-buildpackage -us -uc […]

The previous command can fail if the
Build-Depends fields have 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.

工具fakeroot

In essence, the package creation process is a simple matter of gathering in an archive a set of existing (or built) files; most of the files will end up being owned by
root in the archive. However, building the whole package under this user would imply increased risks; fortunately, this can be avoided with the
fakeroot command. This tool can be used to run a program and give it the impression that it runs as
root and creates files with arbitrary ownership and permissions. When the program creates the archive that will become the Debian package, it is tricked into creating an archive containing files marked as belonging to arbitrary owners, including
root. This setup is so convenient that
dpkg-buildpackage uses
fakeroot by default when building packages. Note that the program is only tricked into “believing” that it operates as a privileged account, and the process actually runs as the user running
fakeroot program (and the files are actually created with that user’s permissions). At no time does it actually get root privileges that it could abuse. 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.

QUICK LOOK Building packages in a chrooted environment

The
pbuilder program (in the similarly named package) allows building a Debian package in a
chrooted environment. It first creates a temporary directory containing the minimal system required for building the package (including the packages mentioned in the
Build-Depends field). This directory is then used as the root directory (
/), using the
chroot command, during the build process. This tool allows the build process to happen in an environment that is not altered by users’ manipulations. This also allows for quick detection of the missing build-dependencies (since the build will fail unless the appropriate dependencies are documented). Finally, it allows building a package for a Debian version that is not the one used by the system as a whole: the machine can be using
Stable for its normal workload, and a
pbuilder running on the same machine can be using
Unstable for package builds.
schroot allows running a command or a login shell in a
chrooted environment.