有多种方法可以在干净且可重现的环境中构建 Debian 软件包。最常用的两种方法是 pbuilder 和 sbuild。就我个人而言，我一直使用 pbuilder。我发现 pbuilder 更易于使用和维护。我找不到两者的并排比较。我错过了什么？
与 pbuilder 相比，使用 sbuild 有哪些优势？
答案1
sbuild 和 pbuilder 经过多年的发展，已经具有几乎相同的功能，并且随着其中任一方添加新功能，它们往往会很快被对方采用。
由于 Debian 打包是一种策略驱动的格式，因此，拥有多个构建系统实现对于确定给定的构建问题是构建器实现中的错误还是正在构建的软件包存在问题具有重要帮助。为了保持这一点，领先的构建系统必须都有强大的支持者，本着合作竞争的精神，确保我们拥有最正确的可用策略实现。
sbuild 和 pbuilder 的内部机制有很大不同，因此具体需要提取哪些软件包来满足构建依赖关系或如何提取这些软件包、调用 debian/rules 中各个目标的具体机制等可能有所不同，这会导致某些软件包在特定情况下的行为略有不同。大多数情况下，这表示其中一个或另一个实现存在错误，有时则反映出打包策略不够明确：无论如何，行为变化都应该得到解决。
Debian 和 Ubuntu 中的官方 buildds 都使用 sbuild（尽管通常不是档案中提供的 sbuild），一些开发人员认为这是一个优势，因为他们更有信心他们的配置与构建时他们的包将暴露的配置相匹配，尽管如果每个人都这样做，我们就失去了区分策略中的错误和 sbuild 中的错误的能力。
从历史上看，我的理解是 pbuilder 开发最初侧重于开发者作为最终用户的需求，而 sbuild 开发最初侧重于 buildd 和档案管理员的需求。最近，随着人们基于 pbuilder 构建档案管理系统，并使用 sbuild 构建更有用的开发人员工具，这些重点已经发生了转变。
这两种工具（或它们常见的类似衍生产品）都支持将 chroot 存储为 tarball，在系统上解压，存储在单独的卷中（具有可用于特殊安装的钩子：例如 LVM 快照），使用覆盖文件系统，使用写时复制语义等。这两种工具都提供了简单的命令行工具来简化常见情况（测试构建包）和丰富的钩子语义来支持复杂情况（大型档案）。两者都提供了一种在 chroot 中创建测试环境的方法。简而言之，这两种工具几乎提供了您在包构建工具中想要的任何东西（并且都有活跃的上游乐于接受错误和补丁）。
总结：如果您对 pbuilder 感到满意，请继续使用它。如果您想使用 sbuild，请随意。最好的工具是您能够轻松完成工作的工具。
答案2
不同意 Emmet 的观点总是很危险的，所以我首先承认他的答案可能更正确。不过，我个人认为 pbuilder 更人性化，开箱即用的性能也更好。
如果你使用的是 Ubuntu 12.10 或更高版本，请务必安装优秀的 pbuilder 脚本，它是一组极其原始 pbuilder 的友好包装器。
如果您使用的是 Ubuntu 12.04，您可以从 backports 存储库安装 pbuilder-scripts。
现在，让我们比较和对比等效操作的用户友好性。在这些示例中，我将使用托管在 x86 上的 ARM chroot 进行演示，但这些概念仍然适用于托管在 x86 上的 x86 chroot。请记住，我使用的是 pbuilder-scripts 包装器。
需要注意的一点是，pbuilder 脚本实现了一些约定，类似于 Ruby on Rails 为您做出一些决定的方式，以便您可以快速开始。我会尝试在我们进行过程中指出这些。
创建一个 chroot
mk-sbuild --arch=armhf quantal
对比
# in addition to the chroot, creates a new, empty directory named ~/Projects/quantal-armhf
pcreate -a armhf -d quantal quantal-armhf
判决：领带，这两个命令行都非常简单，如果需要，它们都可以为更复杂的用例提供额外的选项。但是，请注意 pcreate 创建的额外新目录。
下载源码包
# standard debian/ubuntu method, works in any directory
apt-get source casper
对阵
# 'quantal-armhf' is the name of the chroot created earlier
# results in downloading package to: ~/Projects/quantal-armhf/casper/
pget quantal-armhf casper
判决：sbuild 略有优势，因为您使用的是标准的 debian/ubuntu 最佳实践。pget 使用的约定乍一看可能有点奇怪，但由于我使用过多个 Ubuntu 版本的多个软件包，所以我喜欢它所采用的组织方式。还请注意，apt-get source 还会在您运行命令的任何地方提取源代码，只留下 *.orig.tar.gz、*.debian.tar.gz、*.dsc 和扩展目录，我个人觉得这些目录很乱。我保证，这种组织方式的美妙之处很快就会显现出来。
进入 chroot，临时版本
schroot -c quantal-armhf
对阵
ptest quantal-armhf
判决：pbuild 略有优势，输入的字符越少，字符数就越少。请注意，在此进入 chroot 的版本中，一旦退出 chroot，您在此处所做的任何更改都将丢失。还请注意，在 schroot 中，您将保持普通用户身份，而在 ptest 中，您将以 root 用户身份进入 chroot。
进入chroot，保存修改版本
sudo schroot -c quantal-armhf-source -u root
对阵
ptest quantal-armhf --save
判决：pbuild 略有优势在我看来，字符更少，命令行参数更直观。在此版本的 chroot 中，您所做的任何更改都将保存以供将来调用。
在 chroot 中构建包
debuild -S -sa -I -i
sbuild -A --arch armhf -d quantal-armhf /path/to/casper-1.315.dsc
对阵
# must be invoked when pwd is ~/Projects/quantal-armhf/casper/casper-1.315
pbuild
判决：构建，现在我们看到了使用 pbuild 约定的第一个重大优势。这是一个非常简单的命令，无需记住其他任何内容，而需要指定体系结构、chroot 的名称，并要求 sbuild 所需的 *.dsc 文件的路径。此外，您必须记住使用 sbuild 生成一个新的 *.dsc 文件，而 pbuild 会自动为您完成此操作。
在 chroot 中再次构建相同的包
在上面的例子中，sbuild 和 pbuild 都将在各自的 chroot 中下载并安装 build-deps。但是，pbuild保存下载的 .deb 文件放在 /var 中，因此如果您第二次调用 pbuild，则不必再次下载所有的 build-deps（尽管它们仍然必须安装在 chroot 中）。sbuild 不会缓存 .deb 文件（至少默认情况下不会），因此，除了等待它们安装在 chroot 中之外，您还必须再次下载所有的 build-deps。
判决：构建远远胜过其他设置。缓存 build-deps 是一个很棒的默认设置，并且 pbuild 足够智能，可以检测存档中是否有 build-dep 的较新版本，并在需要时拉取新版本。对于具有许多 build-deps 的复杂包，这个简单的设置将为您节省数分钟的时间。
概括
我发现，开箱即用的 pbuilder 脚本比 sbuild 脚本更友好、更快速。当然，有办法让 pbuilder 更快（在 tmpfs 中构建，禁用一些 chroot 钩子），sbuild 可能也有同样的技巧，但我不知道。
希望这可以帮助。