Por que usar sbuild over pbuilder?

Question

Existem inúmeras maneiras de construir pacotes Debian em um ambiente limpo e reproduzível. Dois dos mais utilizados são pbuilder e sbuild. Pessoalmente, eu sempre usei pbuilder. Eu acho o pbuilder muito mais fácil de usar e manter. Eu não fui capaz de encontrar qualquer comparação lado a lado dos dois. O que estou perdendo?

Quais são as vantagens de usar sbuild over pbuilder?

    

Answer 1

sbuild e pbuilder se desenvolveram ao longo dos anos para ter uma funcionalidade quase idêntica e, à medida que os recursos são adicionados a ambos, eles tendem a ser rapidamente adotados pelo outro.

Como o empacotamento Debian é um formato orientado por políticas, é um auxílio significativo para determinar se um determinado problema de compilação é um bug na implementação do construtor ou um problema com o pacote sendo construído para ter múltiplas implementações de um sistema de compilação. . Para manter isso, os sistemas líderes de construção devem ter todos os partidários strongs apoiando-os, em um espírito de competição colaborativa para garantir que tenhamos as implementações de políticas mais corretas disponíveis.

A mecânica interna de sbuild e pbuilder difere consideravelmente, então, precisamente quais pacotes são puxados para satisfazer dependências de compilação ou como eles são puxados, o mecanismo preciso pelo qual os vários destinos em debian / rules são chamados, etc. podem diferir, causando algumas pequenas diferenças no comportamento em casos muito específicos para certos pacotes. Na maioria das vezes, isso representa um bug em uma ou outra implementação e, às vezes, reflete uma falta de clareza na política de empacotamento: em qualquer caso, mudanças de comportamento devem ser resolvidas.

Builds oficiais tanto no Debian quanto no Ubuntu usam o sbuild (embora muitas vezes não seja o sbuild disponível nos repositórios), o que é considerado uma vantagem por alguns desenvolvedores, pois eles confiam que sua configuração corresponde àquela à qual o pacote será exposto quando construído, embora se todos fizerem isso, perderemos a capacidade de distinguir bugs na política de bugs no sbuild.

Historicamente, meu entendimento é que o desenvolvimento do pbuilder inicialmente focava nas necessidades do desenvolvedor como desenvolvimento de usuário final e sbuild inicialmente focado nas necessidades dos administradores de buildd e arquivamento. Recentemente, esses focos mudaram, já que as pessoas construíram sistemas de gerenciamento de arquivos baseados no pbuilder e mais ferramentas de desenvolvedor úteis usando o sbuild.

Ambas as ferramentas (ou suas derivadas de fechamento comumente disponíveis) suportam o armazenamento de chroots como tarballs, descompactado no sistema, em volumes separados (com ganchos disponíveis para montagem especial: ex. instantâneos LVM), usando sistemas de arquivos de sobreposição, usando copy-on-write Semântica, etc. Ambas as ferramentas oferecem ferramentas de linha de comando triviais para simplificar o caso comum (test-build um pacote) e uma rica semântica de gancho para suportar casos complexos (grandes arquivos). Ambos fornecem um meio para criar um ambiente de teste em um chroot. Em suma, ambas as ferramentas fornecem praticamente tudo o que você poderia pensar que você queria em uma ferramenta de construção de pacotes (e ambas têm upstreams ativos felizes em aceitar bugs e patches).

Em resumo: se você está feliz com o pbuilder, continue usando-o. Se você quiser jogar com sbuild, fique à vontade. A melhor ferramenta é aquela que você se sente confortável para o tipo de trabalho que faz.

    

Answer 2

É sempre perigoso discordar de Emmet, então deixe-me começar reconhecendo que sua resposta é provavelmente mais correta. No entanto, eu pessoalmente acho pbuilder mais user-friendly e mais performance out-of-the-box.

Se você estiver no Ubuntu 12.10 ou posterior, certifique-se de instalar os excelentes pbuilder-scripts, que são um conjunto de extremamente wrappers amigáveis em torno do pbuilder bruto.

Se você está no Ubuntu 12.04, você pode instalar os pbuilder-scripts do repositório backports.

Agora, vamos comparar e contrastar a facilidade de uso de operações equivalentes. Nestes exemplos, vou percorrer usando um chroot do ARM hospedado no x86, mas os conceitos ainda se aplicam a um chroot x86 hospedado no x86 também. Lembre-se, estou usando os wrappers pbuilder-scripts.

Uma coisa a notar é que os scripts pbuilder implementam um pouco de convenção, semelhante a como o Ruby on Rails toma algumas decisões por você, para que você possa ir rapidamente. Vou tentar apontar isso quando formos.

Crie um chroot

mk-sbuild --arch=armhf quantal

vs

# in addition to the chroot, creates a new, empty directory named ~/Projects/quantal-armhf
pcreate -a armhf -d quantal quantal-armhf

veredicto: empate , ambas as linhas de comando são bastante simples, e ambas podem ter opções extras para casos de uso mais sofisticados, se necessário. No entanto, observe o novo diretório adicional criado pelo pcreate.

Faça o download de um pacote de origem

# standard debian/ubuntu method, works in any directory
apt-get source casper

vs.

# 'quantal-armhf' is the name of the chroot created earlier
# results in downloading package to: ~/Projects/quantal-armhf/casper/
pget quantal-armhf casper

veredito: ligeira vantagem para o sbuild , porque você está usando a melhor prática do debian / ubuntu padrão. A convenção usada pelo pget pode parecer estranha no começo, mas desde que eu trabalho em múltiplos pacotes através de múltiplos lançamentos do Ubuntu, eu gosto da organização que ela impõe. Note também que o apt-get source também extrai a fonte onde quer que você execute o comando, deixando-o com o * .orig.tar.gz, * .debian.tar.gz, * .dsc e o diretório expandido, que eu pessoalmente acho ser confuso. A beleza da organização está chegando em breve, eu prometo.

Digite o chroot, versão efêmera

schroot -c quantal-armhf

vs.

ptest quantal-armhf

ligeira vantagem para pbuild , menos caracteres para digitar são menos caracteres. Note que nesta versão de entrar no chroot, qualquer mudança que você fizer aqui será perdida assim que você sair do chroot. Observe também que, no schroot, você permanecerá um usuário normal, enquanto que com ptest, você estará no chroot como o usuário root.

Digite o chroot, salve a versão das alterações

sudo schroot -c quantal-armhf-source -u root

vs.

ptest quantal-armhf --save

veredicto: ligeira vantagem para pbuild , menos caracteres e argumentos de linha de comando mais intuitivos, na minha opinião. Nesta versão de entrar no chroot, todas as alterações que você fizer serão salvas para invocações futuras.

Construa um pacote dentro do chroot

debuild -S -sa -I -i
sbuild -A --arch armhf -d quantal-armhf /path/to/casper-1.315.dsc

vs.

# must be invoked when pwd is ~/Projects/quantal-armhf/casper/casper-1.315
pbuild

veredicto: pbuild , agora vemos a primeira vitória significativa ao usar as convenções do pbuild. Este é um comando morto simples com mais nada a lembrar, versus especificar a arquitetura, o nome do chroot e requerer um caminho para um arquivo * .dsc que o sbuild requer. Além disso, você deve se lembrar de gerar um novo arquivo * .dsc com o sbuild, enquanto o pbuild o fará automaticamente para você.

Construa o mesmo pacote no chroot, uma segunda vez

No exemplo acima, sbuild e pbuild baixam e instalam os build-deps em seus respectivos chroots. No entanto, pbuild salva os arquivos .deb baixados em / var, então se você invocar pbuild pela segunda vez, você não precisa baixar todos os build-deps novamente (embora eles ainda devam ser instalados no diretório chroot). O sbuild não armazena em cache os arquivos .deb (pelo menos não por padrão) e, portanto, você deve fazer o download de todos os build-deps novamente, além de esperar que eles sejam instalados no chroot.

veredicto: pbuild por um longo período. Armazenar em cache o build-deps é uma ótima configuração padrão, e pbuild é inteligente o suficiente para detectar se há uma versão mais nova de um dep-build no arquivo e irá puxar a nova versão, se necessário. Para um pacote complexo com muitos build-deps, essa configuração simples economizará minutos de sua vida.

Resumo

Fora da caixa, acho pbuilder-scripts para ser muito mais amigável e mais rápido do que os equivalentes sbuild. Claro, existem maneiras de tornar o pbuilder ainda mais rápido (compilar em um tmpfs, desabilitar alguns dos chroot hooks), e provavelmente há os mesmos truques para o sbuild também, mas eu não tenho conhecimento deles.

Espero que isso ajude.