问题描述
有许多方法可以在干净且可重现的环境中构建 Debian 软件包。最常用的两个是 pbuilder 和 sbuild。就个人而言，我一直使用 pbuilder。我发现 pbuilder 更易于使用和维护。我一直无法找到两者的任何并排比较。我错过了什么？
使用 sbuild 比使用 pbuilder 有什么优势？
最佳办法
sbuild 和 pbuilder 多年来已经发展到具有几乎相同的功能，并且随着功能被添加到任何一个中，它们往往会很快被另一个采用。
由于 Debian 打包是 policy-driven 格式，因此它有助于确定给定的构建问题是构建器实现中的错误，还是构建具有多个构建系统实现的包的问题。为了保持这一点，领先的构建系统都必须有强大的支持者支持它们，本着协作竞争的精神，以确保我们拥有最正确的可用政策实施。
sbuild 和 pbuilder 的内部机制有很大不同，因此精确地拉取哪些包以满足 build-dependencies 或如何拉取它们，调用 debian/rules 中的各种目标的精确机制等可能不同，导致在某些包在非常特殊的情况下的行为。大多数情况下，这代表了一个或另一个实现中的错误，有时反映了打包策略缺乏明确性：无论如何，应该解决行为更改。
Debian 和 Ubuntu 中的官方构建都使用 sbuild(尽管通常不是存档中可用的 sbuild)，这被一些开发人员认为是一个优势，因为他们更有信心他们的配置与构建时他们的包将暴露的配置相匹配，尽管如果每个人都这样做，我们将失去区分策略中的错误和 sbuild 中的错误的能力。
从历史上看，我的理解是 pbuilder 开发最初专注于开发人员的需求，如 end-user 和 sbuild 开发最初专注于构建和归档管理员的需求。最近，随着人们基于 pbuilder 构建归档管理系统以及使用 sbuild 的更有用的开发人员工具，这些关注点发生了转变。
两种工具(或其常用的密切衍生工具)都支持将 chroot 存储为 tarball，在系统上解压缩，在单独的卷中(具有用于特殊挂载的可用挂钩：例如 LVM 快照)，使用覆盖文件系统，使用 copy-on-write 语义等。这两个工具都提供简化常见案例(test-build 一个包)的琐碎 命令行 工具和支持复杂案例(大型档案)的丰富钩子语义。两者都提供了在 chroot 中创建测试环境的方法。简而言之，这两个工具几乎都提供了你可能认为你想要的包构建工具的任何东西(并且都有活跃的上游乐于接受错误和补丁)。
总结：如果您对 pbuilder 感到满意，请继续使用它。如果你想玩 sbuild，请随意。最好的工具是您对自己所做的工作感到舒适的工具。
次佳办法
不同意 Emmet 总是很危险的，所以让我首先承认他的回答可能更正确。但是，我个人发现 pbuilder 更多 user-friendly 并且开箱即用的性能更高。
如果您使用的是 Ubuntu 12.10 或更高版本，请务必安装出色的 pbuilder-scripts，它是一组非常友好的原始 pbuilder 包装器。
如果您使用的是 Ubuntu 12.04，则可以从 backports 存储库安装 pbuilder-scripts。
现在，我们来对比一下等效操作的user-friendliness。在这些示例中，我将介绍如何使用托管在 x86 上的 ARM chroot，但这些概念仍然适用于托管在 x86 上的 x86 chroot。请记住，我使用的是 pbuilder-scripts 包装器。
需要注意的一点是 pbuilder-scripts 实现了一些约定，类似于 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 源代码也会提取源代码，为您留下 *.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，现在我们看到了使用 pbuild 约定时的第一个重大胜利。与指定体系结构、chroot 的名称以及需要 sbuild 所需的 *.dsc 文件的路径相比，这是一个非常简单的命令，无需记住其他任何内容。此外，您必须记住使用 sbuild 生成一个新的 *.dsc 文件，而 pbuild 会自动为您完成。
在 chroot 中构建相同的包，第二次
在上面的示例中，sbuild 和 pbuild 都将下载并安装 build-deps 到各自的 chroot 中。但是，pbuild 将下载的 .deb 文件保存在 /var 中，因此如果您第二次调用 pbuild，则不必再次下载所有 build-deps(尽管它们仍必须安装在 chroot 中)。 sbuild 不会缓存 .deb 文件(至少默认情况下不会)，因此，除了等待它们安装在 chroot 中之外，您还必须再次下载所有 build-deps。
判决：pbuild 远投。缓存 build-deps 是一个很好的默认设置，pbuild 足够聪明，可以检测存档中是否有更新版本的 build-dep，并在需要时拉下新版本。对于包含许多 build-deps 的复杂封装，这个简单的设置将为您节省几分钟的生命。
概括
开箱即用，我发现 pbuilder-scripts 比 sbuild 等价物更友好、更快。当然，有一些方法可以让 pbuilder 更快(在 tmpfs 中构建，禁用一些 chroot 挂钩)，并且 sbuild 可能也有相同的技巧，但我不知道它们。
希望这可以帮助。