对构建OpenStack软件包感到困惑吗？

我在Ubuntu QA站点上找到了OpenStack构建任务，但对构建步骤有些困惑。

这是构建步骤的链接：https : //jenkins.qa.ubuntu.com/view/Openstack_Testing/view/Grizzly/job/precise_grizzly_keystone_stable/275/consoleText

从jenkins构建日志中，我知道Ubuntu如何构建Openstack软件包的步骤：

1. 从github获取openstack代码，使用 git clone
2. openstack tar.gz使用构建文件python setup.py sdist
3. 用于bzr获取由规范维护的debian控制文件
4. 使用dch命令生成新的构建版本并将其提交到本地
5. 用于bzr builddeb -S -- -sa -us -uc生成源包和相关的控制文件，例如dsc
6. 在包裹上签名
7. 用于mk-build-deps安装依赖项
8. 用于sbuild生成真实的Deb包
9. 上传到测试库

我的问题是：

1. 在第5步中，我们已经可以不用生成deb包了-S，但是为什么我们最终使用sbuild它来生成它呢？这仅用于签名吗？
2. bzr builddeb和之间有什么区别sbuild？

3. 我发现jenkins使用的构建脚本位于：~openstack-ubuntu-testing/openstack-ubuntu-testing，但是当我尝试在下运行任何命令时bin，总是得到：

   root@demo:~/openstack-ubuntu-testing/bin# ./build-package
   Traceback (most recent call last):
     File "./build-package", line 14, in <module>
       from openstack_ubuntu_testing.build.component_build import ComponentBuild
     File "/home/sysadmin/openstack-ubuntu-testing/bin/openstack_ubuntu_testing/build/component_build.py", line 11, in <module>
       from schroot.executor import SchrootExecutor
   ImportError: No module named schroot.executor
   

我尝试使用pip安装schroot，但似乎他们中没有执行程序。

请帮忙。

sbuild使用schroot。在隔离的环境中构建软件包。在这种环境中，仅安装由源程序包声明的构建依赖项，而没有其他安装。这有助于确保该构建不受运行它的开发人员或CI环境的影响。例如，在没有sbuild的情况下，CI环境中软件包的存在可能使构建看起来成功，而实际上它是一个未声明的构建依赖关系，因此在其他任何地方都失败。出于可重复性和稳定性的原因，最好使用sbuild。