有很多方法可以在一个干净而可复现的环境中构建Debian软件包。其中两种最常用的是pbuilder和sbuild。个人而言，我一直使用pbuilder。我发现pbuilder更容易使用和维护。我还没有找到任何对这两者进行并排比较的信息。我错过了什么？
使用sbuild相比pbuilder有哪些优势呢？
2个回答
sbuild和pbuilder多年来发展得几乎具有相同的功能，而且只要其中一个添加了新功能，往往很快就会被另一个采纳。
由于Debian打包是一种基于政策的格式，拥有多个构建系统的实现可以很大程度上帮助确定给定构建问题是构建器实现中的错误还是正在构建的软件包中的问题。为了保持这一点，领先的构建系统必须都有强力支持者，以合作竞争的精神确保我们拥有最正确的可用政策实现。
sbuild和pbuilder的内部机制存在相当大的差异，因此在满足构建依赖关系时拉取的软件包以及拉取方式，debian/rules中各个目标的调用机制等可能会有所不同，这可能导致某些特定软件包在某些特定情况下行为略有差异。大部分情况下，这代表着其中一个实现中的错误，有时也反映了打包政策的不清晰：无论如何，应该解决行为变化的问题。
官方的Debian和Ubuntu都使用sbuild来构建（尽管通常不是存档中可用的sbuild），这被一些开发人员认为是一个优势，因为他们更有信心自己的配置与构建时将暴露给其软件包的配置相匹配，尽管如果每个人都这样做，我们就失去了在策略错误和sbuild错误之间区分错误的能力。
从历史上看，我理解pbuilder的开发最初关注的是开发人员作为最终用户的需求，而sbuild的开发最初关注的是buildd和存档管理员的需求。最近，随着人们基于pbuilder构建存档管理系统，并使用sbuild构建更有帮助的开发人员工具，这些关注点已经转变。
这两个工具（或其常见的衍生版本）都支持将chroot存储为tarball，在系统上解压缩到单独的卷中（可用于特殊挂载的钩子，例如LVM快照），使用覆盖文件系统，使用写时复制语义等。这两个工具都提供了简单的命令行工具来简化常见情况（测试构建软件包），并提供了丰富的钩子语义来支持复杂情况（大型存档）。两者都提供了在chroot中创建测试环境的方法。简而言之，这两个工具几乎提供了您可能认为在软件包构建工具中需要的任何功能（并且两者都有积极的上游开发人员愿意接受错误报告和补丁）。
总结一下：如果你对pbuilder感到满意，就继续使用它。如果你想尝试sbuild，随意去试试。最好的工具是你在做你的工作时感到舒适的工具。
由于Debian打包是一种基于政策的格式，拥有多个构建系统的实现可以很大程度上帮助确定给定构建问题是构建器实现中的错误还是正在构建的软件包中的问题。为了保持这一点，领先的构建系统必须都有强力支持者，以合作竞争的精神确保我们拥有最正确的可用政策实现。
sbuild和pbuilder的内部机制存在相当大的差异，因此在满足构建依赖关系时拉取的软件包以及拉取方式，debian/rules中各个目标的调用机制等可能会有所不同，这可能导致某些特定软件包在某些特定情况下行为略有差异。大部分情况下，这代表着其中一个实现中的错误，有时也反映了打包政策的不清晰：无论如何，应该解决行为变化的问题。
官方的Debian和Ubuntu都使用sbuild来构建（尽管通常不是存档中可用的sbuild），这被一些开发人员认为是一个优势，因为他们更有信心自己的配置与构建时将暴露给其软件包的配置相匹配，尽管如果每个人都这样做，我们就失去了在策略错误和sbuild错误之间区分错误的能力。
从历史上看，我理解pbuilder的开发最初关注的是开发人员作为最终用户的需求，而sbuild的开发最初关注的是buildd和存档管理员的需求。最近，随着人们基于pbuilder构建存档管理系统，并使用sbuild构建更有帮助的开发人员工具，这些关注点已经转变。
这两个工具（或其常见的衍生版本）都支持将chroot存储为tarball，在系统上解压缩到单独的卷中（可用于特殊挂载的钩子，例如LVM快照），使用覆盖文件系统，使用写时复制语义等。这两个工具都提供了简单的命令行工具来简化常见情况（测试构建软件包），并提供了丰富的钩子语义来支持复杂情况（大型存档）。两者都提供了在chroot中创建测试环境的方法。简而言之，这两个工具几乎提供了您可能认为在软件包构建工具中需要的任何功能（并且两者都有积极的上游开发人员愿意接受错误报告和补丁）。
总结一下：如果你对pbuilder感到满意，就继续使用它。如果你想尝试sbuild，随意去试试。最好的工具是你在做你的工作时感到舒适的工具。
- Emmet Hikory
1
和Emmet意见不合总是很危险的，所以让我先承认他的答案可能更正确。然而，就个人而言，我发现pbuilder更加用户友好且开箱即用的性能更佳。
如果你使用的是Ubuntu 12.10或更高版本，请务必安装优秀的pbuilder-scripts，它们是一组非常友好的包装器，可以轻松使用原始的pbuilder。
如果你使用的是Ubuntu 12.04，你可以从后备存储库中安装pbuilder-scripts。
现在，让我们比较和对比等效操作的用户友好性。在这些示例中，我将演示如何在x86主机上使用ARM chroot，但概念同样适用于在x86主机上使用x86 chroot。请记住，我正在使用pbuilder-scripts包装器。
需要注意的一点是，pbuilder-scripts实现了一些约定，类似于Ruby on Rails为您做出一些决策，以便您可以快速入门。我会尽量在我们进行时指出这些约定。
创建一个chroot
mk-sbuild --arch=armhf quantal
vs
# 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
vs.
# '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。
sudo schroot -c quantal-armhf-source -u root
vs.
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
vs.
# must be invoked when pwd is ~/Projects/quantal-armhf/casper/casper-1.315
pbuild
在chroot中再次构建同一软件包
在上面的例子中，无论是sbuild还是pbuild都会下载并安装其各自chroot中的构建依赖项。然而，pbuild会将已下载的.deb文件保存在/var目录下，所以如果你第二次调用pbuild，就不需要再次下载所有的构建依赖项（尽管它们仍然必须在chroot中安装）。sbuild不会缓存.deb文件（至少默认情况下不会），因此除了等待它们被安装到chroot中，你还必须重新下载所有的构建依赖项。
总结：
从一开始，我发现pbuilder-scripts比sbuild的等效工具更友好、更快速。当然，还有一些方法可以使pbuilder变得更快（在tmpfs中构建，禁用一些chroot钩子），sbuild可能也有相同的技巧，但我不知道。
希望对您有所帮助。
- achiang
5
pget看起来非常类似于ubuntu-dev-tools软件包中的'pull-lp-source'。对于发行版开发，我基本上从不使用apt-get source。它面向用户，让他们可以说“给我这个软件包的源代码”，而不是开发人员。 - SpamapS
1Errr.. uhh...在打包目录中进行的sbuild与pbuild完全相同。抱歉，但是为此给予-1分。请修复并解决此问题，我将取消我的-1。 - SpamapS
此外，“在chroot中更改某些内容并使其持久化”这个用例是误导性的。这是一个不好的主意，因为它会使您的干净chroot与buildd干净chroot不同。这几乎从来不被建议。 - SpamapS
@SpamapS，我实际上使用
pbuilder-dist --login --save-after-login 来微调构建环境，因为例如我需要一个特殊的软件包，但它的 sources.list 条目默认情况下是不存在的。所以调整 chroot 环境似乎是有意义的。 - Alexis Wilke对于批评你的批评，我很抱歉，但是“结论：Pbuild稍微占优势，输入更少字符就意味着少些字符”这个观点非常愚蠢，不够严肃。在比较软件系统时，输入少5个字符并不是一个因素，显然还有更重要的差异存在。 - Tele
sbuild被用来创建Ubuntu的软件包，尽管据我所了解，Launchpad运行的是pbuilder... - Alexis Wilke