Ubuntu – Confused about building OpenStack Packages

openstackpackage-managementpackaging

I found OpenStack build task on Ubuntu QA site, but I am a little confused about the build steps.

Here's the link for build steps: https://jenkins.qa.ubuntu.com/view/Openstack_Testing/view/Grizzly/job/precise_grizzly_keystone_stable/275/consoleText

From the jenkins build log, I know the steps how Ubuntu build a Openstack packages:

  1. get openstack code from github, use git clone
  2. build openstack tar.gz file using python setup.py sdist
  3. use bzr to get the debian control files which is maintenance by canonical
  4. use dch command to generate a new build release and commit it to local
  5. use bzr builddeb -S -- -sa -us -uc to generate source package and related control file, such like dsc
  6. sign the package
  7. use mk-build-deps to install dependency
  8. use sbuild to generate the real deb packages
  9. upload to testing repos

My questions is:

  1. In step 5, we already can generate the deb packages without -S, but why we finally use sbuild to generate it? Is this only for signature?
  2. What's the difference between bzr builddeb and sbuild?

  3. I found the build scripts which jenkins used is located here: ~openstack-ubuntu-testing/openstack-ubuntu-testing, but when I try to run any commands under bin, I always get:

    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

I tried to use pip to install schroot, but it seems they don't have a executor in it.

Please help.

Best Answer

sbuild builds a package in an isolated environment using schroot. In this environment, only the build dependencies declared by the source package are installed, and nothing else. This helps ensure that the build isn't influenced by the developer or CI environment it is run from. For example, without sbuild, the presence of a package in the CI environment might make it appear that the build succeeds when in fact it was an undeclared build dependency and so fails everywhere else. For reproducibility and stability reasons, it is better to use sbuild.

Related Question