Confuso sobre a construção de pacotes OpenStack?

Question

Encontrei a tarefa de compilação do OpenStack no site do Ubuntu QA, mas estou um pouco confuso sobre as etapas de criação.

Aqui está o link para as etapas de criação: link

Do log build do jenkins, eu sei os passos como o Ubuntu constrói os pacotes do Openstack:

1. obtenha o código openstack do github, use git clone
2. compilação openstack tar.gz arquivo usando python setup.py sdist
3. use bzr para obter os arquivos de controle do debian, que é a manutenção por canonical
4. use o comando dch para gerar uma nova versão de compilação e confirme-a no local
5. use bzr builddeb -S -- -sa -us -uc para gerar o pacote de origem e o arquivo de controle relacionado, como dsc
6. assine o pacote
7. use mk-build-deps para instalar dependência
8. use sbuild para gerar os pacotes deb reais
9. carregar para repos de teste

Minhas perguntas são:

1. Na etapa 5, já podemos gerar os pacotes deb sem -S , mas por que finalmente usamos sbuild para gerá-lo? Isso é apenas para assinatura?
2. Qual é a diferença entre bzr builddeb e sbuild ?

3. Eu encontrei os scripts de compilação que o jenkins usou aqui: ~openstack-ubuntu-testing/openstack-ubuntu-testing , mas quando eu tento executar qualquer comando em bin , eu sempre obtenho:

   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
   

Eu tentei usar o pip para instalar o schroot, mas parece que eles não têm um executor nele.

Por favor ajude.

    

Answer 1

sbuild cria um pacote em um ambiente isolado usando schroot . Nesse ambiente, apenas as dependências de construção declaradas pelo pacote de origem são instaladas e nada mais. Isso ajuda a garantir que a construção não seja influenciada pelo desenvolvedor ou pelo ambiente de IC de onde é executada. Por exemplo, sem sbuild, a presença de um pacote no ambiente do IC pode fazer com que pareça que a compilação teve êxito quando, na verdade, era uma dependência de construção não declarada e, portanto, falha em qualquer outro lugar. Por razões de reprodutibilidade e estabilidade, é melhor usar o sbuild.