Запутались в создании пакетов OpenStack?

Я нашел задачу сборки OpenStack на сайте Ubuntu QA, но меня немного смущают этапы сборки.

Вот ссылка на этапы сборки: https://jenkins.qa.ubuntu.com/view/Openstack_Testing/view/Grizzly/job/precise_grizzly_keystone_stable/275/consoleText

Из журнала сборки jenkins я знаю шаги, как Ubuntu собирает пакеты Openstack:

1. получить код openstack из github, используйте 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.