Por que usar sbuild sobre pbuilder?

Existem inúmeras maneiras de compilar pacotes Debian em um ambiente limpo e reproduzível. Dois dos mais usados ​​são pbuilder e sbuild. Pessoalmente, eu sempre usei o pbuilder. Acho o pbuilder muito mais fácil de usar e manter. Não consegui encontrar nenhuma comparação lado a lado dos dois. O que estou perdendo?

Que vantagens existem no uso do sbuild sobre o pbuilder?

O sbuild e o 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 pacote Debian é um formato orientado por políticas, é uma ajuda significativa 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 várias implementações de um sistema de compilação. Para manter isso, os principais sistemas de construção devem ter partidários fortes apoiando-os, em um espírito de competição colaborativa para garantir que temos as implementações políticas mais corretas disponíveis.

A mecânica interna do sbuild e pbuilder diferem consideravelmente; portanto, exatamente quais pacotes são puxados para satisfazer as dependências de compilação ou como eles são puxados, o mecanismo preciso pelo qual os vários alvos do debian / rules são chamados, etc. pode diferir, causando algumas ligeiras diferenças de comportamento em casos muito específicos para determinados 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, as mudanças de comportamento devem ser resolvidas.

As compilações oficiais no Debian e no Ubuntu usam o sbuild (embora muitas vezes não seja o sbuild disponível nos arquivos), o que é considerado uma vantagem por alguns desenvolvedores, pois eles têm maior confiança de que sua configuração corresponde àquela à qual seu pacote será exposto quando compilado, embora se todos fizerem isso, perderemos a capacidade de distinguir erros na política de erros no sbuild.

Historicamente, meu entendimento é que o desenvolvimento do pbuilder se concentrou inicialmente nas necessidades do desenvolvedor, enquanto o usuário final e o desenvolvimento do sbuild se concentrou inicialmente nas necessidades dos administradores de buildd e archive. Recentemente, esses focos mudaram, pois as pessoas criaram sistemas de gerenciamento de arquivos baseados no pbuilder e ferramentas de desenvolvedor mais úteis usando o sbuild.

Ambas as ferramentas (ou seus derivados próximos geralmente disponíveis) suportam o armazenamento de chroots como tarballs, descompactados no sistema, em volumes separados (com ganchos disponíveis para montagem especial: por exemplo, instantâneos LVM), sistemas de arquivos de sobreposição, semânticas de cópia na gravação, etc. Ambas as ferramentas oferecem ferramentas triviais de linha de comando para otimizar o caso comum (criar um pacote de teste) e semântica de gancho rico para suportar casos complexos (arquivos grandes). Ambos fornecem um meio para criar um ambiente de teste em um chroot. Em resumo, ambas as ferramentas fornecem praticamente qualquer coisa que você possa pensar em uma ferramenta de criação de pacotes (e ambas têm upgreams ativos felizes em aceitar bugs e patches).

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

É sempre perigoso discordar de Emmet, então deixe-me começar por reconhecer que sua resposta é provavelmente mais correta. No entanto, eu pessoalmente acho o pbuilder mais fácil de usar e com melhor desempenho.

Se você estiver no Ubuntu 12.10 ou posterior, instale os excelentes scripts pbuilder, que são um conjunto de wrappers extremamente amigáveis ​​para o pbuilder bruto.

Se você estiver no Ubuntu 12.04, poderá instalar os scripts pbuilder a partir do repositório de backports.

Agora, vamos comparar e contrastar a facilidade de uso de operações equivalentes. Nestes exemplos, mostrarei como usar um chroot 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 à maneira como o Ruby on Rails toma algumas decisões para você, para que você possa ir rapidamente. Vou tentar apontar isso à medida que avançamos.

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: tie , as duas linhas de comando são bem simples e, se necessário, ambas podem ter opções extras para casos de uso mais sofisticados. No entanto, observe o novo diretório adicional criado por 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

veredicto: leve vantagem para o sbuild , porque você está usando as melhores práticas padrão do debian / ubuntu. A convenção usada pelo pget pode parecer estranha no começo, mas como trabalho em vários pacotes em várias versões do Ubuntu, gosto da organização que ela impõe. Observe também que o apt-get source também extrai a fonte onde quer que você execute o comando, deixando-o com * .orig.tar.gz, * .debian.tar.gz, * .dsc e o diretório expandido, que eu pessoalmente acho seja bagunçado. A beleza da organização está chegando em breve, prometo.

Digite a versão efêmera do chroot

schroot -c quantal-armhf

vs.

ptest quantal-armhf

veredicto: leve margem para pbuild , menos caracteres para digitar são menos caracteres. Observe que nesta versão da entrada no chroot, todas as alterações feitas aqui serão perdidas quando você sair do chroot. Observe também que no schroot, você continuará sendo um usuário normal, enquanto que com o ptest, você estará no chroot como 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 do pbuild , menos caracteres e argumentos de linha de comando mais intuitivos, na minha opinião. Nesta versão da entrada no chroot, todas as alterações feitas nele serão salvas para futuras invocações.

Crie 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 simples, sem mais nada a lembrar, em vez de especificar a arquitetura, o nome do chroot e exigir um caminho para um arquivo * .dsc exigido pelo sbuild. Além disso, você deve se lembrar de gerar um novo arquivo * .dsc com sbuild, enquanto o pbuild fará isso automaticamente para você.

Crie o mesmo pacote no chroot, pela segunda vez

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

veredicto: pbuild por um longo tiro. Armazenar em cache os build-deps é uma excelente configuração padrão, e o pbuild é inteligente o suficiente para detectar se há uma versão mais recente de um build-dep no arquivo morto e, se necessário, desativa a nova versão. Para um pacote complexo com muitos build-deps, essa configuração simples poupa alguns minutos da sua vida.

Sumário

Fora da caixa, acho os scripts pbuilder muito mais amigáveis ​​e rápidos do que os equivalentes sbuild. Obviamente, existem maneiras de tornar o pbuilder ainda mais rápido (construa em um tmpfs, desative alguns dos ganchos chroot) e provavelmente existem os mesmos truques para o sbuild também, mas eu não os conheço.

Espero que isto ajude.