Il cuore del sistema è il database di wanna-build, che tiene traccia
delle versioni e degli stati di ogni pacchetto. quinn-diff confronta
ogni giorno 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, fare dei cambiamenti alle dipendenze di compilazione e riprovare, ecc... Se il pacchetto viene accettato, il demone lo sposta in un 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 PGP 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
, ma la sua vera specialità sono le dipendenze di
compilazione. Spesso dei pacchetti hanno bisogno di altri pacchetti installati
per poter essere compilati, per esempio compilatori e librerie. Non è molto
intelligente tenere tutti questi pacchetti sempre installati, e spesso non è
neanche possibile per via di conflitti. Le dipendenze di compilazioni dicono
semplicemente a sbuild di cosa ha bisogno ogni pacchetto. Questo può
quindi installare le dipendenze prima di compilare e rimuoverle subito dopo.
Le dipendenze di compilazione possono essere parzialmente generate automaticamente, controllando le dipendenze del pacchetto binario generato dai sorgenti. Questo è quello che fa andrea: analizzare la lista dei pacchetti per i386 e mappare i pacchetti delle librerie nei corrispondenti pacchetti di sviluppo. A queste dipendenze ne aggiunge altre impostate manualmente, quando non possono essere generate automaticamente, come per esempio compilatori o tool speciali.
Materiale sviluppato da Roman Hodek per il sesto International Linux-Kongress 1999.
