为什么要在pbuilder上使用sbuild？

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

与sbuild相比，使用sbuild有什么优势？

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

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

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

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

从历史上看，我的理解是pbuilder开发最初专注于作为最终用户的开发人员的需求，而sbuild开发最初专注于构建和归档管理员的需求。最近，随着人们已经基于pbuilder构建了档案管理系统以及使用sbuild开发了更多有用的开发人员工具，这些关注点已经发生了变化。

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

总结：如果您对pbuilder满意，请继续使用它。如果您想玩sbuild，请放心。最好的工具是您愿意使用的一种工具。

不同意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

结论：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都将在各自的chroot中下载并安装build-deps。但是，pbuild 将下载的.deb文件保存在/ var中，因此，如果再次调用pbuild，则不必再次下载所有build-deps（尽管它们仍必须安装在chroot中）。sbuild不会缓存.deb文件（至少默认情况下不是），因此，除了等待将它们安装在chroot中之外，您还必须再次下载所有build-deps。

判决：pbuild远射。缓存build-deps是一个很好的默认设置，而pbuild很聪明，可以检测存档中是否有build-dep的较新版本，并在需要时将其下拉。对于具有许多构建后勤的复杂软件包，此简单设置将节省您的生命。

摘要

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

希望这可以帮助。