Chapter 5. 基本内容

创建 Debian 二进制软件包的 Debian 打包工作流涉及创建数个特定名称的文件（参见 Section 5.4, “软件包名称和版本”），与《Debian 政策手册》的定义保持一致。

一个极其简化的 Debian 打包工作流可以概括为以下十步。

Test building and confirming of the binary package goodness as above is the moral obligation as a diligent Debian developer but there is no physical barrier for people to skip such operations at this moment for the source-only upload.

Under some exceptional situation such as NEW uploads, uploads to the Debian archive may need to include Debian binary package files. For such situation, sign package_version-revision_arch.changes instead of 'package_version-revision’_*source.changes* in the step 9, and upload the set of the Debian source and binary package files in the step 10.

这里，请将文件名中对应的部分使用下面的方式进行替换：

参见 Source-only uploads。

	Tip
	有很多种通过实践摸索而得到的补丁管理方法和版本控制系统的使用策略与技巧。您没有必要将它们全部用上。

	Tip
	在“Debian 开发者参考”一文的 第 6 章 最佳打包实践 部分有十分详尽的相关文档。请读一读这些内容。

Debian was started in 1990s when upstream packages were available from public FTP sites such as Sunsite. In those early days, Debian packaging used dpkg-source currently known as "Format: 1.0":

In order to address issues of old dpkg-source "Format: 1.0", new dpkg-source "Format: 3.0 (quilt)" was invented around 2008:

The use of Git repositories to distribute upstream packages with signed tags (supported feature since 2011) became very popular.

Debian also enforced the source-only upload when developing Debian/11 Bullseye (released in 2021).

In this tutorial, mostly simple tarball based dpkg-source "Format: 3.0 (quilt)" examples are presented as an introductory purpose.

Please assess these VCS usage approaches by yourself later to decide which one to deploy as your preferred one.

Please also read Notes on Debian by Russ Allbery which have best practices such as Using Git for Debian Packaging.

You can also search entire Debian source code by yourself, too.

请在《Debian 政策手册》的 第 5 章 - Control 文件及其字段 一节中查看其精确定义。

debmake 所假设的打包情景是相对简单的。因此，所有与解释器相关的程序都会默认为“Architecture: all”的情况。当然，这个假设并非总是成立。

您必须为 Debian 打包工作适当地调整软件包名称和上游版本号。

为了能有效地使用一些流行的工具（如 aptitude）管理软件包名称和版本信息，最好能将软件包名称保持在 30 字符以下；版本号和修订号加起来最好能不超过 14 个字符。^[11]

为了避免命名冲突，对用户可见的二进制软件包名称不应选择任何常用的单词。

如果上游没有使用像 2.30.32 这样正常的版本编号方案，而是使用了诸如 11Apr29 这样包含日期、某些代号或者一个版本控制系统散列值等字符串作为版本号的一部分的话，请在上游版本号中将这些部分移除。这些信息可以稍后在 debian/changelog 文件中进行记录。如果您需要为软件设计一个版本字符串，可以使用 YYYYMMDD 格式，如 20110429 的字符串作为上游版本号。这样能保证 dpkg 命令在升级时能正确地确定版本的先后关系。如果您想要确保万一上游在未来重新采纳正常版本编号方案，例如 0.1 时能够做到顺畅地迁移，可以另行使用 0~YYMMDD 的格式，如 0~110429 作为上游版本号。

版本字符串可以按如下的方式使用 dpkg 命令进行比较。

$ dpkg --compare-versions ver1 op ver2

版本比较的规则可以归纳如下：

对于某些字符，如句点（.）、加号（+）和波浪号（~），有如下的特殊规则。

0.0 < 0.5 < 0.10 < 0.99 < 1 < 1.0~rc1 < 1.0 < 1.0+b1 < 1.0+nmu1 < 1.1 < 2.0

有一个稍需注意的情况，即当上游将 hello-0.9.12-ReleaseCandidate-99.tar.gz 这样的版本当作预发布版本，而将 hello-0.9.12.tar.gz 作为正式版本时。为了确保 Debian 软件包升级能够顺畅进行，您应当修改版本号命名，如将上游源代码压缩包重命名为 hello-0.9.12~rc99.tar.gz。

参见《Debian 政策手册》中的 第 5 章 - Control 文件及其字段 一章以了解每块元信息的具体定义。

	Note
	debmake 命令会在 debian/control 文件中写入“Build-Depends: debhelper-compat (= 13)”以设置 debhelper 兼容等级。

	Tip
	If an existing package has lower than debhelper compatibility level 9, probably it’s time to update its packaging.

5.7.1. Debian 二进制软件包的拆分

对行为良好的构建系统来说，对 Debian 二进制包的拆分可以由如下方式实现。

• 为所有二进制软件包在 debian/control 文件中创建对应的二进制软件包条目。
• 在对应的 debian/二进制软件包名.install 文件中列出所有文件的路径（相对于 debian/tmp 目录）。

请查看本指南中相关的例子：

• Section 8.11, “Autotools（多个二进制软件包）”（基于 Autotools）
• Section 8.12, “CMake（多个二进制软件包）”（基于 CMake）

5.7.1.1. debmake -b

debmake 命令的 -b 选项提供了一个符合直觉又灵活的功能，可以用来创建 debian/control 的初始模板文件，其中可以定义多个 Debian 二进制软件包，每节中含有如下字段：

• Package:
• Architecture:
• Multi-Arch:
• Depends:
• Pre-Depends:

debmake 命令也会在每个适当的依赖字段中设置合适的变量替换占位符（substvars）。

我们在这里直接引用 debmake 手册页中的相关一部分内容。

-b "二进制软件包名[:type],…", --binaryspec "二进制软件包名[:type],…"

设置二进制软件包的指定类型内容，使用一个用逗号分隔的二进制软件包名:类型成对列表；例如，使用完整形式“foo:bin,foo-doc:doc,libfoo1:lib,libfoo-dev:dev”或者使用短形式，“-doc,libfoo1,libfoo-dev”。

这里，二进制软件包是二进制软件包名称，可选的类型应当从下面的类型值中进行选取：

• bin：C/C++ 预编译 ELF 二进制代码软件包（any，foreign）（默认，别名：""，即，空字符串）
• data：数据（字体、图像、……）软件包（all，foreign）（别名：da）
• dev：库开发软件包（any，same）（别名：de）
• doc：文档软件包（all，foreign）（别名：do）
• lib：库软件包（any，same）（别名：l）
• perl：Perl 脚本软件包（all，foreign）（别名：pl）
• python3：Python（版本 3）脚本软件包（all，foreign）（别名：py3）
• ruby：Ruby 脚本软件包（all，foreign）（别名：rb）
• nodejs：基于 Node.js 的 JavaScript 软件包（all，foreign）（别名：js）
• script：Shell 脚本软件包（all，foreign）（别名：sh）

括号内成对的值，例如（any，foreign），是软件包的架构和多架构（Multi-Arch）特性的值，它们将设置在 debian/control 文件中。

大多数情况下，debmake 命令可以有效地从二进制软件包的名称猜测出正确的类型。如果类型的值并不明显，程序将回退到将类型设置为bin。例如，libfoo 设置类型为 lib，而 font-bar 会令程序设置类型为 data，……

如果源码树的内容和类型的设置不一致，debmake 命令会发出警告。

5.7.1.2. 拆包的场景和例子

对于下面这样的上游源代码示例，我们在这里给出使用 debmake 处理时一些典型的 multiarch 软件包拆分的场景和做法：

• 一个软件库源码 libfoo-1.0.tar.gz
• 一个软件工具源码 bar-1.0.tar.gz，软件由编译型语言编写
• 一个软件工具源码 baz-1.0.tar.gz，软件由解释型语言编写

二进制软件包	类型	Architecture:	Multi-Arch:	软件包内容
lib foo1	lib *	any	same	共享库，可共同安装
lib foo -dev	dev *	any	same	共享库头文件及相关开发文件，可共同安装
lib foo -tools	bin *	any	foreign	运行时支持程序，不可共同安装
lib foo -doc	doc *	all	foreign	共享库文档
bar	bin *	any	foreign	编译好的程序文件，不可共同安装
bar -doc	doc *	all	foreign	程序的配套文档文件
baz	script	all	foreign	解释型程序文件

5.7.1.3. 库软件包名称

我们考虑 libfoo 这个库的上游 tarball 源码压缩包的名字从 libfoo-7.0.tar.gz 更新为了 libfoo-8.0.tar.gz，同时带有一次 SONAME 大版本的跳跃（并因此影响了其它软件包）。

库的二进制软件包将必须从 libfoo7 重命名为 libfoo8 以保持使用 unstable 套件的系统上所有依赖该库的软件包在上传了基于 libfoo-8.0.tar.gz 的新库后仍然能够正常运行。

	Warning
	如果这个二进制库软件包没有得到更名，许多使用 unstable 套件的系统上的各个依赖该库的软件包会在新的库包上传后立刻破损，即便立刻请求进行 binNMU 上传也无法避免这个问题。由于种种原因，binNMU 不可能在上传后立刻开始进行，故无法缓解问题。

-dev 软件包必须遵循以下命名规则：

• 使用不带版本号的 -dev 软件包名称：libfoo-dev

  • 该情况通常适用于依赖关系处于叶节点的库软件包。

  • 仓库内只允许存在一个版本的库源码包。

    • 其相关联的库软件包在库变迁进行时需要从 libfoo7 重命名为 libfoo8 以避免 unstable 仓库内依赖关系的破坏。
  • 该方法适用于简单 binNMU 可以快速解决所有受影响软件包对该库依赖的情况下。（ABI 有变化，过时的 API 被移除而常用、活跃的 API 未变化。）
  • 该方法有时也能适用于可协调进行手动的代码更新，影响范围限定在有限的一些软件包中的情况下。（API 有变化）

• 使用带版本的 -dev 软件包名称：libfoo7-dev 和 libfoo8-dev

  • 该情况通常适用于各类重要库软件包。

  • 两个版本的库源码包可同时出现在发行版仓库中。

    • 令所有依赖该库的软件包依赖 libfoo-dev。
    • 令 libfoo7-dev 和 libfoo8-dev 两者都提供 libfoo-dev。
    • 源码包需要从 libfoo-?.0.tar.gz 相应地重命名为 libfoo7-7.0.tar.gz 和 libfoo8-8.0.tar.gz。
    • 需要仔细选择 libfoo7 和 libfoo8 软件包文件安装时的路径，如头文件等等，以保证它们可以同时安装。
  • 可能的话，不要使用这个重量级的、需要大量人为干预的方法。
  • 该方法适用于存在多个依赖该库的软件包，且升级时常常涉及手动代码更新的场景。（API 有变化）否则，受影响的软件包会无法从源码重新构建并导致对发行而言致命的 bug 出现。

	Tip
	如果包内数据文件编码方案有所变化（如，从 latin1 变为 utf-8），该场景应比照 API 变化做类似的考虑与处理。

参见 Section 5.20, “库软件包”。

debian/changelog 文件记录了 Debian 软件包的历史并在其第一行定义了上游软件包的版本和 Debian 修订版本。所有改变的内容应当以明确、正式而简明的语言风格进行记录。

• 即便您在自己独立进行软件包上传，您也必须记录所有较重要、用户可见的变更，例如：

  • 安全相关的漏洞修复。
  • 用户界面变动。

• 如果您需要他人协助您进行上传，您应当更详尽地记录变更内容，包括所有打包相关的变动，从而方便他人对您的软件包进行审查。

  • 协助上传的人员不应该也通常不会猜测您没有写出来的想法，所以请认真书写变更信息。
  • 通常来说，协助您上传的人的时间比您的时间更宝贵。

debmake 命令会创建初始的模板文件，其中带有上游软件包版本和 Debian 打包修订编号。发行版部分被设置为 UNRELEASED 以避免半成品不小心被上传进入 Debian 仓库。

通常使用 debchange 命令（它具有一个别名，即 dch）对其进行编辑。

	Tip
	您也可以手动使用任何文本编辑器修改 debian/changelog 文件，只要您能够遵循 debchange 命令所使用的特定文本排版格式即可。

	Tip
	debian/changelog 文件使用的日期字符串可以使用“LC_ALL=C date -R”命令手动生成。

该文件将由 dh_installchangelogs 命令安装到 /usr/share/doc/binarypackage 目录，文件名为 changelog.Debian.gz。

上游的变更日志则会安装至 /usr/share/doc/binarypackage 目录中，文件名为 changelog.gz。

上游的变更日志是由 dh_installchangelogs 程序自动进行搜索和处理的；它会使用大小写不敏感的搜索方式寻找上游代码中特定名称的文件，如 changelog、changes、changelog.txt、changes.txt、history、history.txt 或 changelog.md。除了根目录，程序还会在 doc/ 目录和 docs/ 目录内进行搜索。

当您完成了主要打包工作并验证了其质量之后，请考虑运行“dch -r”命令并将最终完成的 debian/changelog 文件中发行版（distribution）部分进行设置，通常该字段应当使用 unstable。^[15] 如果您的打包是一次向后移植（backports）、是安全更新或是对长期支持版的上传等等其它情况，请使用相应合适的发行版名称。

您应当按照 机器可解析的 debian/copyright 文件（DEP-5）对其进行排版。

	Caution
	这里的 debian/copyright 文件中描述的许可证信息匹配信息应当合适地进行排序，以确保越宽泛的文件匹配越靠前。请参见 Section 6.4, “debmake -k”。

debmake 命令会以扫描整个源码树的方式创建初步的、兼容 DEP-5 的模板文件。它会内部调用许可证检查工具来对许可证文本进行分类。^[16]

除非明确指定（有些严格过头的） -P 选项，debmake 命令会为了实用性而跳过对自动生成的文件的检查与报告，默认它们采用宽松的许可证。

	Note
	如果您发现了这个许可证检查工具存在一些问题，请向 debmake 软件包提交缺陷报告并提供包含出现问题的许可证和版权信息在内的相关文本内容。

	Note
	debmake 命令专注于在创建 debian/copyright 模板时聚合相同的授权和许可证信息并收录其详细内容。为了在有限的时间内尽可能完成工作，工具将只会提取文件中第一块看起来像授权文本或许可证声明的部分。因此，生成的许可证信息可能并不完美。请同时考虑使用其它工具，如 licensecheck 辅助进行检查。

	Tip
	我们强烈推荐您使用 licensecheck(1) 命令再次检查源码许可证的状态，并在有必要的情况下进行人工代码审查。

在构建过程开始之前，debian/patches/ 目录内的 -p1 等级的补丁将会按照在 debian/patches/series 文件中指定的顺序依次应用于上游代码树中。

	Note
	原生 Debian 软件包（参见 Section 5.5, “原生 Debian 软件包”）将不使用这些文件。

要准备这一系列 -p1 等级的补丁，有几种不同的方式可供您选择。

无论这些补丁的来源如何，都建议使用兼容于 DEP-3 的头部信息对其进行标记。

	Tip
	dgit 软件包提供了另外一套直接使用 git 集成操作 Debian 软件包仓库的工具。

 $ while dquilt push; do dquilt refresh ; done
 $ dquilt pop -a

例如，GNU hello 可使用 HTTP 协议从 https://ftp.gnu.org/gnu/hello/ 下载。它含有以下文件：

我们现在来选择最新的版本套装。

$ wget https://ftp.gnu.org/gnu/hello/hello-2.9.tar.gz
 ...
$ wget https://ftp.gnu.org/gnu/hello/hello-2.9.tar.gz.sig
 ...
$ gpg --verify hello-2.9.tar.gz.sig
gpg: Signature made Thu 10 Oct 2013 08:49:23 AM JST using DSA key ID 80EE4A00
gpg: Can't check signature: public key not found

如果您从邮件列表获知上游维护者所使用的 GPG 公钥信息，请将它作为 debian/upstream/signing-key.asc 文件进行存储。否则，请使用 hkp 公钥服务器并经由您的信任网进行验证。

$ gpg --keyserver hkp://keys.gnupg.net --recv-key 80EE4A00
gpg: requesting key 80EE4A00 from hkp server keys.gnupg.net
gpg: key 80EE4A00: public key "Reuben Thomas <rrt@sc3d.org>" imported
gpg: no ultimately trusted keys found
gpg: Total number processed: 1
gpg:               imported: 1
$ gpg --verify hello-2.9.tar.gz.sig
gpg: Signature made Thu 10 Oct 2013 08:49:23 AM JST using DSA key ID 80EE4A00
gpg: Good signature from "Reuben Thomas <rrt@sc3d.org>"
  ...
Primary key fingerprint: 9297 8852 A62F A5E2 85B2  A174 6808 9F73 80EE 4A00

	Tip
	如果您的网络环境阻挡了对 HKP 11371 端口的访问，请考虑使用“hkp://keyserver.ubuntu.com:80”。

在确认密钥身份 80EE4A00 值得信任之后，应当下载其公钥并将其保存在 debian/upstream/signing-key.asc 文件中。

$ gpg --armor --export 80EE4A00 >debian/upstream/signing-key.asc

之后，应相应地在 debian/watch 文件中做如下的修改。

version=4
pgpsigurlmangle=s/$/.sig/  https://ftp.gnu.org/gnu/hello/ hello-(\d[\d.]*)\.tar\.(?:gz|bz2|xz)

现在 uscan 命令会在扫描时自动使用 GPG 签名验证上游源码包的真实性。

Debian 严肃地对待软件自由，遵循 Debian 自由软件指导方针（DFSG）。

在使用 uscan 命令来更新 Debian 打包所用代码时，上游源码包（tarball）中不符合Debian 自由软件指导方针（DFSG）的部分可以利用该工具简单地进行移除。

另外也可以添加一些可选的配置文件并放入 debian/ 目录。它们大多用于控制由 debhelper 软件包提供的 dh_* 命令的行为，但也有一些文件会影响 dpkg-source、lintian 和 gbp 这些命令。

	Tip
	请检查 debhelper(7) 的内容以了解当前可用的 dh_* 命令列表。

这些 debian/binarypackage.* 的文件提供了设置文件安装路径的强大功能。即使上游源代码没有构建系统，这个软件依然可以利用这里提到的这些文件来进行打包。请参考 Section 8.2, “无 Makefile（shell，命令行界面）” 的示例。

下面列表中出现的“-x[1234]”上标指示了 debmake -x 选项生成对应模板文件所需要的最小值。请参考 debmake(1) 以了解详情。

下面按照字母表顺序列出一些值得注意的可选配置文件。

这里给出针对上面列表中信息的一些额外提醒。

所有对 Debian 软件包进行定制化的数据都存在于 debian/ 目录中。我们在Section 4.7, “第三步：编辑模板文件”这里给出了一个简单的例子。通常情况下，定制化会涉及以下各个项目：

如果以上提到的手段仍然不足以制作满足要求的 Debian 软件包的话，对上游源代码的修改应当使用 -p1 补丁文件存放在打包源码树 debian/patches/ 目录下。这些补丁将按照 debian/patches/series 文件所规定的顺序在构建软件包之前应用（参见 Section 5.10, “debian/patches/*”）。Section 4.9, “第三步（备选）：修改上游源代码” 这里给出了一些简单的例子。

您应当以引入最少修改的方式解决打包中出现的根本问题。所生成的软件包应当考虑到未来的更新需求并有一定的健壮性。

	Note
	如果补丁对上游有所帮助的话，也请将解决根本问题的补丁反馈给上游作者和维护者。

通常情况下，Debian 打包活动使用 Git 作为版本控制系统（VCS）进行记录；通常会用到下列的分支。

	Tip
	添加一个 .gitignore 文件并将 .pc 文件列入其中也是一个好主意。

	Tip
	可以在 debian/source/local-options 文件中添加 unapply-patches 和 abort-on-upstream-changes 这两行以保持上游源码处于未修改状态。

	Tip
	您也可以使用除 upstream 分支以外其它名称的分支跟踪上游版本控制数据以方便拣选补丁。

通常情况下，Section 3.5, “devscripts” 中设置的用于 dpkg-source 命令的 -i 和 -I 选项可以避免这些问题。这里 -i 针对非原生软件包而 -I 则针对本土软件包。请参见 dpkg-source(1) 和“dpkg-source --help”的输出。

以下几种方法均可避免引入不必要的内容。

5.17.1. 使用 debian/rules clean 进行修复

含有多余文件的问题可以使用“debian/rules clean”这个 Makefile 目标的调用来解决，只需在该目标内删除文件即可。它也能处理自动生成的文件。

	Note
	运行 dpkg-buildpackage 命令时，它会在“dpkg-source --build”命令之前被调用“debian/rules clean”目标，而“dpkg-source --build”命令会忽略被删除的文件。

5.17.2. 使用版本控制系统修复

含有多余文件的问题还可以使用版本控制系统修复；具体来说，可以在首次构建之前将源码树提交到版本控制系统中。

您可以在第二次构建软件包之前恢复最初的源码树。例如：

 $ git reset --hard
 $ git clean -dfx
 $ debuild

这里工作的原理是 dpkg-source 命令会忽略源码树中典型的版本控制系统相关的文件，相关的设置可以在 Section 3.5, “devscripts” 的 DEBUILD_DPKG_BUILDPACKAGE_OPTS 设置中找到。

	Tip
	如果源码树未受版本控制系统管理，您可以在第一次构建之前运行“git init; git add -A .; git commit”来初始化。

5.17.3. 使用 extend-diff-ignore 修复

这种做法仅适合非原生软件包。

含有多余文件的问题可以使用在 debian/source/options 文件中添加忽略信息的方式解决，令编译系统忽略多余的文件；具体配置语法为添加 extend-diff-ignore=…”一行内容。

如需排除 config.sub、config.guess 和 Makefile 文件：

# Don't store changes on autogenerated files
extend-diff-ignore = "(^|/)(config\.sub|config\.guess|Makefile)$"

	Note
	即使您无法删除文件，这种做法总可以正常工作。您无需在每次构建之前手动删除文件并手动进行恢复。

	Tip
	如果您转而使用 debian/source/local-options 文件，您可以在生成的源码包中隐藏该项设置。这种做法在本地非标准版本控制系统和您的打包工作有冲突时可能有用。

5.17.4. 使用 tar-ignore 修复

这个方法只适用于原生软件包。

您可以使用这种做法在生成的源码包中排除某些文件；只需在 debian/source/options 文件或者 debian/source/local-options 文件中添加含有通配符的 “tar-ignore=…”一行内容即可。

	Note
	例如，如果您的原生软件包的源码包使用了一些具有 .o 扩展名的文件作为测试数据的话，Section 3.5, “devscripts” 的默认设置就过于激进了，这些文件会被当作多余的文件默认自动排除。如需解决这个问题，您可以在 Section 3.5, “devscripts” 中的 DEBUILD_DPKG_BUILDPACKAGE_OPTS 参数中移除 -I 选项，同时在每个软件包的 debian/source/local-options 文件中添加 “tar-ignore=…”的配置行。

Debian 软件吧在构建时都会带上调试信息；但打包生成二进制软件包时，这些打包信息会按照《Debian 政策手册》中第十章 - 文件的要求进行剥离。

参见

在打包共享库软件之前，请查阅：

如需研究其历史背景，请参见：

5.20.1. 库符号

Debian lenny（5.0，2009年5月）中引入的 dpkg 符号支持可以帮助我们管理同一共享链接库软件包的向后 ABI 兼容性（backward ABI compatibility）。二进制软件包中的 DEBIAN/symbols 文件提供了每个符号及其对应的最小版本号。

一个极其简化的软件库打包流程大概如下所示。

• 从前一个二进制软件包中使用“dpkg-deb -e”命令解压缩得到旧有的 DEBIAN/symbols 文件。

  • 或者，mc 命令也可以用来解压得到 DEBIAN/symbols 文件。

• 将其复制为 debian/binarypackage.symbols 文件。

  • 如果这是第一次打包的话，可以只创建一个空文件。

• 构建二进制软件包。

  • 如果 dpkg-gensymbols 命令警告添加了新的符号的话：

    • 使用“dpkg-deb -e”命令解压得到更新的 DEBIAN/symbols 文件。
    • 将其中的 Debian 修订版本号，例如 -1，从文件中去除。
    • 将其复制为 debian/binarypackage.symbols 文件。
    • 重新构建二进制软件包。

  • 如果 dpkg-gensymbols 命令不报和新链接符号有关的警告：

    • 您已完成了共享库的打包工作。

如需了解详细信息，您应当阅读下列第一手参考资料。

• 《Debian 政策手册》的 8.6.3 符号（symbols）系统
• dh_makeshlibs(1)
• dpkg-gensymbols(1)
• dpkg-shlibdeps(1)
• deb-symbols(5)

您也应当查看：

• Debian 维基 使用符号文件
• Debian 维基 项目/改进的 DpkgShlibdeps
• Debian kde 团队 处理 symbols 文件
• Section 8.11, “Autotools（多个二进制软件包）”
• Section 8.12, “CMake（多个二进制软件包）”

	Tip
	对于 C++ 软件库或者其它一些难以跟踪符号变化的场景，请按照《Debian 政策手册》的 8.6.4 The shlibs system 一节的内容来代替。请确保这样操作时，事先删除 debmake 命令生成的空的 debian/binarypackage.symbols 文件。在这种情况下，应当转而使用 DEBIAN/shlibs 文件。

5.20.2. 库变迁

当您打包新版本的库软件包而且此次更新影响到其它的软件包时，您必须向 release.debian.org 伪软件包提交一个变迁 bug 报告并附带一个 ben 文件；您可以使用 reportbug 工具进行提交。提交后，请等待发行团队的审核批准方可进行下一步。

发行团队提供了变迁跟踪系统。参见 变迁（Transition）。

	Caution
	请确保您按照 Section 5.7.1.3, “库软件包名称” 的描述正确地对二进制软件包进行了重命名。

参见 dh_installdebconf(1)、debconf(7)、debconf-devel(7) 和《Debian 政策手册》中的 3.9.1 维护者脚本中的用户交互提示。

多架构支持使用三元组（<triplet>）的值，例如 i386-linux-gnu 和 x86_64-linux-gnu；它们出现在共享链接库的安装路径中，例如 /usr/lib/<triplet>/，等等。

参见：

5.22.1. 多架构库路径

Debian 政策要求遵守文件系统层级标准。其中 /usr/lib：程序和软件包的库 声明“/usr/lib 包含目标文件、库和其它不应由用户或 shell 脚本直接调用的内部二进制文件。”

Debian 在文件系统层级标准的基础上添加一项例外，即使用 /usr/lib/<triplet>/ 而非 /usr/lib<qual>/（例如，/lib32/ 和 /lib64/）以对多架构库提供支持。

Table 5.1. 多架构库路径选项

经典路径	i386 多体系结构路径	amd64 多体系结构路径
/lib/	/lib/i386-linux-gnu/	/lib/x86_64-linux-gnu/
/usr/lib/	/usr/lib/i386-linux-gnu/	/usr/lib/x86_64-linux-gnu/

对基于 Autotools 且由 debhelper （compat>=9）管理的软件包来说，这些路径设置已由 dh_auto_configure 命令自动处理。

对于其它使用不支持的构建系统的软件包，您需要按照下面的方式手动调整安装路径。

• 如果在 debian/rules 文件中设置了 override_dh_auto_configure 目标且其中手动调用了“./configure”命令，请确保将其替换为“dh_auto_configure --”，这样可以将安装路径从 /usr/lib/ 替换为 /usr/lib/$(DEB_HOST_MULTIARCH)/。
• 请在 debian/foo.install 文件中将所有出现的 /usr/lib/ 字符串替换为 /usr/lib/*/。

所有启用多架构的软件包安装至相同路径的文件必须内容完全相同。您必须小心处理，避免数据字节序或者压缩算法等等问题带来的文件内容差异。

Note

./configure 的 --libexecdir选项指定了由程序而非用户所使用的可执行文件的默认安装路径。其 Autotools 的默认值为 /usr/libexec/ 但在未启用多架构特性的 Debian 系统上其默认值是 /usr/lib/。如果这些可执行程序属于被标记为“Multi-arch: foreign”的软件包，最好还是使用例如 /usr/lib/ 或者 /usr/lib/软件包名 这样的路径而非使用 dh_auto_configure 设置的 /usr/lib/<triplet>/ 路径。GNU 编程规范：7.2.5 用于安装目录的变量 对 libexecdir 的描述是“libexecdir 的定义对所有软件包相同，所以您应当将您的数据安装在其下的一个子目录中。大多数软件包将数据安装至 $(libexecdir)/package-name/ 之中……”（在与 Debian 政策不冲突的前提下，遵守 GNU 的标准总是更好的。）

位于默认路径 /usr/lib/ 和 /usr/lib/<triplet>/ 的共享库可被自动加载。

对位于其它路径的共享库，必须使用 pkg-config 命令设置 GCC 选项 -l 以正确进行加载。

debmake 命令会向 debian/rules 文件中按需添加 DEB_BUILD_MAINT_OPTIONS、DEB_CFLAGS_MAINT_APPEND 和 DEB_LDFLAGS_MAINT_APPEND 的项目（参见 Chapter 4, 简单例子 和 dpkg-buildflags(1)）。

DEP-8 定义了 debian/tests/control 文件的格式，它是 RFC822 风格的测试元数据文件，用于 Debian 软件包的持续集成（CI）。

它在完成构建包含 debian/tests/control 文件的源码包、得到二进制包之后发挥作用。在运行 autopkgtest 命令时，所生成的二进制软件包会根据这个文件在虚拟环境中自动进行安装和测试。

See documents in the /usr/share/doc/autopkgtest/ directory and 4. autopkgtest: Automatic testing for packages of the “Ubuntu Packaging Guide”.

	Note
	Testing of the binary packages during their building time can be accomodated by dh_auto_test.

您可以在 Debian 系统上探索使用不同的持续集成系统。

Debian packaging practices are moving target. Please keep your eyes on DEP - Debian Enhancement Proposals.

Debian 关心对新硬件架构的移植工作。新架构的移植工作对自举（bootstrapping）操作有所要求，以完成对初始最小本地构建系统的交叉编译。为了在自举（bootstrapping）时避免构建依赖成环的问题，需要使用 配置类型（profile） 的构建功能特性来缩减所需构建依赖。

	Tip
	如果一个核心软件包 foo 构建时依赖于 bar 软件包，但后者会引入一长串构建依赖链而且 bar 仅在 foo 的 test 目标中使用（即仅用于构建后测试），那么您可以安全地在 foo 软件包的 Build-depends 一栏中将 bar 标记为 <!nocheck> 以规避构建依赖环。

参见 dh_bugfiles(1) 和 为开发者提供的 reportbug 功能特性

	Tip
	如果您总是需要提醒提交报告的用户某些注意事项或询问他们某些问题，使用这些文件可以将这个过程自动化。