Perché usare sbuild su pbuilder?

Esistono numerosi modi per creare pacchetti Debian in un ambiente pulito e riproducibile. Due dei più usati sono pbuilder e sbuild. Personalmente, ho sempre usato pbuilder. Trovo pbuilder molto più facile da usare e mantenere. Non sono stato in grado di trovare alcun confronto parallelo dei due. Cosa mi sto perdendo?

Quali sono i vantaggi nell'usare sbuild rispetto a pbuilder?

sbuild e pbuilder si sono sviluppati nel corso degli anni per avere funzionalità quasi identiche e, man mano che si aggiungono funzionalità a entrambi, tendono ad essere rapidamente adottati dall'altro.

Dato che il pacchetto Debian è un formato guidato dalle politiche, è di grande aiuto nel determinare se un determinato problema di compilazione è un bug nell'implementazione del builder o un problema con il pacchetto che viene creato per avere molteplici implementazioni di un sistema di compilazione. Per mantenere ciò, i principali sistemi di costruzione devono avere tutti forti partigiani che li supportano, in uno spirito di competizione collaborativa per garantire che abbiamo le implementazioni più corrette disponibili della politica.

Le meccaniche interne di sbuild e pbuilder differiscono considerevolmente, quindi precisamente quali pacchetti vengono estratti per soddisfare dipendenze di build o come vengono estratti, il meccanismo preciso con cui vengono chiamati i vari target in debian / regole, ecc. Può differire, causando un leggero differenze di comportamento in casi molto specifici per determinati pacchetti. Il più delle volte ciò rappresenta un bug nell'una o nell'altra implementazione e talvolta riflette una mancanza di chiarezza nella politica di imballaggio: in ogni caso, i cambiamenti di comportamento dovrebbero essere risolti.

I buildd ufficiali sia in Debian che in Ubuntu usano sbuild (sebbene spesso non lo sbuild disponibile dagli archivi), che è considerato un vantaggio da alcuni sviluppatori, poiché hanno una maggiore fiducia che la loro configurazione corrisponda a quella a cui verrà esposto il loro pacchetto una volta compilato, sebbene se tutti lo fanno, perdiamo la capacità di distinguere i bug nella politica dai bug di sbuild.

Storicamente, la mia comprensione è che lo sviluppo di pbuilder inizialmente si concentrava sulle esigenze dello sviluppatore come sviluppo dell'utente finale e sbuild inizialmente concentrato sulle esigenze degli amministratori di buildd e di archivio. Di recente, questi obiettivi sono cambiati, poiché le persone hanno creato sistemi di gestione degli archivi basati su pbuilder e strumenti di sviluppo più utili utilizzando sbuild.

Entrambi gli strumenti (o i loro derivati ​​vicini comunemente disponibili) supportano l'archiviazione di chroot come tarball, spacchettati sul sistema, in volumi separati (con ganci disponibili per il montaggio speciale: ad esempio istantanee LVM), usando filesystem sovrapposti, usando semantica copia-su-scrittura, ecc. Entrambi gli strumenti offrono banali strumenti da riga di comando per semplificare il caso comune (test-build di un pacchetto) e una semantica hook ricca per supportare casi complessi (archivi di grandi dimensioni). Entrambi forniscono un mezzo per creare un ambiente di test in un chroot. In breve, entrambi gli strumenti forniscono praticamente qualsiasi cosa tu possa pensare di desiderare in uno strumento di creazione di pacchetti (ed entrambi hanno flussi attivi attivi felici di accettare bug e patch).

In sintesi: se sei soddisfatto di pbuilder, continua a usarlo. Se vuoi giocare con sbuild, sentiti libero. Lo strumento migliore è quello che ti fa comodo per il tipo di lavoro che svolgi.

È sempre pericoloso non essere d'accordo con Emmet, quindi vorrei iniziare riconoscendo che la sua risposta è probabilmente più corretta. Tuttavia, trovo personalmente pbuilder più user-friendly e più performante.

Se utilizzi Ubuntu 12.10 o versioni successive, assicurati di installare gli eccellenti script pbuilder, che sono un insieme di wrapper estremamente amichevoli attorno a raw pbuilder.

Se sei su Ubuntu 12.04 puoi installare gli script pbuilder dal repository backport.

Ora, confrontiamo e contrapponiamo la facilità d'uso di operazioni equivalenti. In questi esempi, esaminerò usando un chroot ARM ospitato su x86, ma i concetti si applicano ancora anche ad un chroot x86 ospitato su x86. Ricorda, sto usando i wrapper pbuilder-script.

Una cosa da notare è che gli script pbuilder implementano un po 'di convenzione, simile a come Ruby on Rails prende alcune decisioni per te in modo che tu possa iniziare rapidamente. Proverò a segnalarli mentre procediamo.

Crea un 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

verdetto: pareggio , entrambe le righe di comando sono piuttosto semplici ed entrambe possono richiedere opzioni extra per casi d'uso più elaborati, se necessario. Tuttavia, si noti la nuova directory aggiuntiva creata da pcreate.

Scarica un pacchetto sorgente

# 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

verdetto: leggero vantaggio per sbuild , perché stai usando le migliori pratiche standard di debian / ubuntu. All'inizio la convenzione usata da Pget potrebbe sembrare strana, ma dal momento che lavoro su più pacchetti in più versioni di Ubuntu, mi piace l'organizzazione che impone. Nota anche che apt-get source estrae anche il sorgente ovunque esegui il comando, lasciandoti con * .orig.tar.gz, * .debian.tar.gz, * .dsc e la directory espansa, che trovo personalmente essere disordinato. La bellezza dell'organizzazione arriverà presto, lo prometto.

Inserisci la versione chroot, effimera

schroot -c quantal-armhf

vs.

ptest quantal-armhf

verdetto: leggero vantaggio per Pbuild , meno caratteri da digitare sono meno caratteri. Si noti che in questa versione dell'accesso al chroot, eventuali modifiche apportate qui andranno perse una volta usciti dal chroot. Nota anche che in schroot rimarrai un utente normale mentre con ptest sarai nel chroot come utente root.

Inserisci il chroot, salva la versione delle modifiche

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

vs.

ptest quantal-armhf --save

verdetto: leggero vantaggio per Pbuild , meno personaggi e argomenti della riga di comando più intuitivi, secondo me. In questa versione di accesso al chroot, tutte le modifiche apportate verranno salvate per invocazioni future.

Costruisci un pacchetto all'interno del 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

verdetto: pbuild , ora vediamo la prima vittoria significativa quando si usano le convenzioni di pbuild. Questo è un semplice comando morto con nient'altro da ricordare, rispetto a specificare l'architettura, il nome di chroot e che richiede un percorso per un file * .dsc richiesto da sbuild. Inoltre, devi ricordare di generare un nuovo file * .dsc con sbuild mentre pbuild lo farà automaticamente per te.

Costruisci lo stesso pacchetto in chroot, una seconda volta

Nell'esempio sopra, sia sbuild che pbuild scaricheranno e installeranno i build-deps nei rispettivi chroot. Tuttavia, pbuild salva i file .deb scaricati in / var, quindi se si richiama pbuild una seconda volta, non è necessario scaricare nuovamente tutti i build-deps (sebbene debbano comunque essere installati nel chroot). sbuild non memorizza nella cache i file .deb (almeno non per impostazione predefinita), quindi è necessario scaricare nuovamente tutti i build-deps oltre ad attendere che vengano installati nel chroot.

verdetto: costruire da un colpo lungo. La memorizzazione nella cache dei build-deps è un'impostazione predefinita eccezionale e pbuild è abbastanza intelligente da rilevare se esiste una versione più recente di un build-dep nell'archivio e, se necessario, eliminerà la nuova versione. Per un pacchetto complesso con molti build-deps, questa semplice impostazione ti farà risparmiare minuti della tua vita.

Sommario

All'improvviso, trovo che gli script di pbuilder siano molto più amichevoli e più veloci degli equivalenti sbuild. Naturalmente, ci sono modi per rendere pbuilder ancora più veloce (compilare in un tmpfs, disabilitare alcuni degli hook chroot), e probabilmente ci sono gli stessi trucchi anche per sbuild, ma non ne sono consapevole.

Spero che sia di aiuto.