为什么在 pbuilder 上使用 sbuild？

Question

有多种方法可以在干净且可重现的环境中构建 Debian 软件包。最常用的两个是 pbuilder 和 sbuild。就个人而言，我一直使用 pbuilder。我发现 pbuilder 更易于使用和维护。我一直无法找到两者的任何并排比较。我错过了什么？

使用 sbuild 比使用 pbuilder 有什么优势？

Answer 1

sbuild 和 pbuilder 多年来已经发展为具有几乎相同的功能，并且随着功能添加到其中一个，它们往往会很快被另一个采用。

由于 Debian 打包是一种策略驱动的格式，因此在确定给定的构建问题是构建器实现中的错误还是构建包具有多个构建系统实现的问题时，它是一个重要的帮助。为了保持这一点，领先的构建系统都必须有强大的党派支持他们，本着协作竞争的精神，以确保我们拥有最正确的可用政策实施。

sbuild 和 pbuilder 的内部机制有很大的不同，所以精确地拉出哪些包以满足构建依赖性或如何拉出它们，调用 debian/rules 中的各种目标的精确机制等可能不同，导致一些轻微的某些包在非常特定的情况下的行为差异。大多数情况下，这代表一个或另一个实现中的错误，有时反映了打包策略缺乏清晰度：无论如何，应该解决行为更改。

Debian 和 Ubuntu 中的官方构建都使用 sbuild（尽管通常不是档案中可用的 sbuild），这被一些开发人员认为是一个优势，因为他们更有信心他们的配置与构建时他们的包将暴露的配置相匹配，尽管如果每个人都这样做，我们将失去区分策略中的错误和 sbuild 中的错误的能力。

从历史上看，我的理解是 pbuilder 开发最初侧重于作为最终用户的开发人员的需求，而 sbuild 开发最初侧重于构建和归档管理员的需求。最近，这些焦点发生了变化，因为人们已经基于 pbuilder 构建了档案管理系统，并且使用 sbuild 构建了更有用的开发人员工具。

这两种工具（或其常用的密切衍生工具）都支持将 chroot 存储为 tarball，在系统上解压缩，在单独的卷中（具有用于特殊挂载的可用钩子：例如 LVM 快照），使用覆盖文件系统，使用写时复制语义等. 这两个工具都提供了简单的命令行工具来简化常见的案例（测试-构建包）和丰富的钩子语义来支持复杂的案例（大型档案）。两者都提供了在 chroot 中创建测试环境的方法。简而言之，这两种工具都提供了您可能认为在包构建工具中想要的任何东西（并且两者都有积极的上游乐于接受错误和补丁）。

总结：如果您对 pbuilder 感到满意，请继续使用它。如果您想玩 sbuild，请随意。最好的工具是您可以轻松使用的工具来完成您所做的工作。

Answer 2

不同意 Emmet 的观点总是很危险的，所以让我首先承认他的回答可能更正确。但是，我个人认为 pbuilder 更加用户友好且开箱即用。

如果您使用的是 Ubuntu 12.10 或更高版本，请务必安装出色的 pbuilder-scripts，它们是一组非常友好的原始 pbuilder 包装器。

如果您使用的是 Ubuntu 12.04，您可以从 backports 存储库安装 pbuilder-scripts。

现在，让我们比较和对比等效操作的用户友好性。在这些示例中，我将逐步使用托管在 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

结论：tie，两个命令行都非常简单，如果需要，两者都可以为更高级的用例提供额外的选项。但是，请注意由 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，现在我们看到使用 pbuild 的约定时的第一个重大胜利。与指定架构、chroot 的名称以及需要 sbuild 所需的 *.dsc 文件的路径相比，这是一个非常简单的命令，无需记住任何其他内容。此外，您必须记住使用 sbuild 生成一个新的 *.dsc 文件，而 pbuild 会自动为您完成。

第二次在 chroot 中构建相同的包

在上面的例子中，sbuild 和 pbuild 都会在各自的 chroots 下载并安装 build-deps。但是，pbuild将下载的 .deb 文件保存在 /var 中，因此如果您第二次调用 pbuild，则不必再次下载所有的 build-deps（尽管它们仍必须安装在 chroot 中）。sbuild 不缓存 .deb 文件（至少在默认情况下不是），因此，除了等待它们安装在 chroot 中之外，您还必须再次下载所有 build-deps。

判决：pbuild远射。缓存 build-dep 是一个很好的默认设置，并且 pbuild 足够聪明，可以检测存档中是否有更新版本的 build-dep，并在需要时下拉新版本。对于具有许多构建依赖的复杂包，这个简单的设置将为您节省几分钟。

概括

开箱即用，我发现 pbuilder-scripts 比 sbuild 等价物更友好、更快。当然，有一些方法可以使 pbuilder 更快（在 tmpfs 中构建，禁用一些 chroot 挂钩），并且 sbuild 可能也有相同的技巧，但我不知道它们。

希望这可以帮助。