Funzionamento della rete di buildd
Il cuore del sistema è il database di wanna-build, che tiene traccia
delle versioni e degli stati di ogni pacchetto. quinn-diff confronta
dopo ogni aggiornamento dell'archivio la lista dei pacchetti dell'architettura
considerata con la lista dei pacchetti sorgente, e compila una lista dei
pacchetti che devono essere ricompilati, impostandoli nel database allo stato di
Needs-Build (compilazione necessaria
).
Tutti i demoni di compilazione (ce ne possono essere più di uno) interrogano
regolarmente il database cercando tali pacchetti e ne prendono alcuni facendoli
entrare nello stato Building (in compilazione
). Ovviamente questo può
essere anche fatto manualmente da un utente, per esempio nei casi in cui la
compilazione automatica non sia possibile. Qui possiamo vedere anche un secondo
scopo di wanna-build: si assicura che la stessa versione di un
pacchetto non venga compilata due volte.
Se tutto va a buon fine, il pacchetto terminato verrà caricato sul server ed
entrerà in un altro stato, Uploaded (caricato
). Dopodiché verrà
copiato nell'archivio di Debian, in modo da apparire nella lista dei
pacchetti aggiornati per l'architettura considerata. Questa lista sarà poi
inserita nel database, ed il pacchetto entrerà nello stato Installed
(installato
) e vi rimarrà fino alla prossima versione del pacchetto
sorgente.
Esistono molto altri stati; tra di essi: Failed (fallito
) serve
per i pacchetti la cui compilazione è fallita a causa di errori nei sorgenti.
Si suppone che gli errori saranno corretti in una versione successiva
(ovviamente una volta notificato il problema), quindi una nuova versione del
pacchetto entrerà direttamente nello stato Needs-Build, ma con una
notifica del precedente errore. Insieme a questo stato viene memorizzata una
descrizione dell'errore. Lo stato Dep-Wait (aspetta le dipendenze
)
viene utilizzato quando un pacchetto ha bisogno di un qualche altro pacchetto
per essere compilato, ma tale dipendenza non può essere soddisfatta perché il
secondo pacchetto ancora non è stato compilato. Questo stato memorizza anche una
lista dei pacchetti e delle relative versioni richiesti, e, quando tutte
diventano disponibili, lo stato ritorna a Needs-Build.
Come abbiamo detto prima, il demone di compilazione prende i pacchetti da compilare dall'archivio. Diamoci un'occhiata più da vicino: se ha qualche pacchetto da compilare, utilizza sbuild per l'effettivo processo di compilazione, e per ogni esecuzione viene inviato un log via email al manutentore del demone. Questo lo visiona e decidere cosa fare del pacchetto: caricarlo nell'archvio, impostarlo a Failed o a Dep-Wait e riprovare, ecc... Se il pacchetto viene accettato (tramite l'invio di un file .changes firmato), il demone lo sposta in una directory di upload, dalla quale tutti i pacchetti sono periodicamente caricati sul server.
Controllare i file di log è l'unico intervento umano nell'intero processo, se non ci sono errori. Ci sono due buone ragioni per non eliminare anche questo passaggio: primo, ogni tanto una compilazione sembra essere andata a buon fine, ma in realtà è fallita per ragioni che la macchina non può individuare. Inoltre un upload diretto implicherebbe una firma OpenPGP automatica dei file generati, fatta con una chiave non protetta da una passphrase. Questo sarebbe un problema di sicurezza inaccettabile.
Lo script sbuild sostanzialmente chiama i tool standard di Debian per
compilare i sorgenti. In realtà dà anche una mano effettuando delle operazioni
di ordinaria amministrazione
e installando automaticamente le
dipendenze di compilazione come richiesto dal pacchetto in corso di elaborazione.
Materiale sviluppato da Roman Hodek per il sesto International Linux-Kongress 1999 e poi leggermente aggiornato nel 2009 da Phipipp Kern in modo da rispecchiare più fedelmente la realtà attuale.