有多种方法可以在干净且可复制的环境中构建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存储，在系统上解压缩后存储在单独的卷中（带有用于特殊安装的可用钩子：例如LVM快照），使用覆盖文件系统，使用写时复制语义等。两种工具都提供了简单的命令行工具来简化常见案例（测试构建程序包），并提供丰富的钩子语义来支持复杂案例（大型档案）。两者都提供了在chroot中创建测试环境的方法。简而言之，这两个工具都提供了您可能认为在软件包构建工具中想要的任何东西（并且两个工具都有活跃的上游工具，它们很乐意接受错误和补丁）。
总结：如果您对pbuilder感到满意，请继续使用它。如果您想玩sbuild，请放心。最好的工具是您愿意使用的一种工具。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句