Ho tradotto un'altra pagina del sito di Debian (quella in oggetto). Allego il mio lavoro per revisione ed aggiornamento sul CVS. Giovanni. -- Giovanni Mascellani <g.mascellani@gmail.com> Pisa, Italy Web: http://giomasce.altervista.org SIP: g.mascellani@ekiga.net Jabber: g.mascellani@jabber.org / giovanni@elabor.homelinux.org GPG: 0x5F1FBF70 (FP: 1EB6 3D43 E201 4DDF 67BD 003F FCB0 BB5C 5F1F BF70)
#use wml::debian::template title="Funzionamento della rete di buildd" BARETITLE="true"
#use wml::debian::translation-check translation="1.8" maintainer="Giovanni Mascellani"
<p>Il cuore del sistema è il database di <tt>wanna-build</tt>, che tiene traccia
delle versioni e degli stati di ogni pacchetto. <tt>quinn-diff</tt> 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 <tt>Needs-Build</tt>
("compilazione necessaria").</p>
<p>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 <tt>Building</tt> ("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 <tt>wanna-build</tt>: si assicura che la stessa versione di un
pacchetto non venga compilata due volte.</p>
<div class="center"><a name="autobuilder34"></a>
<img src="scheme.png" alt="Schema di funzionamento di buildd">
<p><strong>Figura:</strong> Stati dei pacchetti e transizioni</p>
</div>
<p>Se tutto va a buon fine, il pacchetto terminato verrà caricato sul server ed
entrerà in un altro stato, <tt>Uploaded</tt> ("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 <tt>Installed</tt>
("installato") e vi rimarrà fino alla prossima versione del pacchetto
sorgente.</p>
<p>Esistono molto altri stati; tra di essi: <tt>Failed</tt> ("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 <tt>Needs-Build</tt>, ma con una
notifica del precedente errore. Insieme a questo stato viene memorizzata una
descrizione dell'errore. Lo stato <tt>Dep-Wait</tt> ("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 <tt>Needs-Build</tt>.</p>
<p>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 <tt>sbuild</tt> per l'effettivo processo di
compilazione, e per ogni esecuzione viene inviato un log via email al
mantenitore del demone. Questo lo visiona e decidere cosa fare del pacchetto:
caricarlo nell'archvio, impostarlo a <tt>Failed</tt> o a <tt>Dep-Wait</tt>,
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.</p>
<p>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.</p>
<p>Lo script <tt>sbuild</tt> sostanzialmente chiama 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 <tt>sbuild</tt> di cosa ha bisogno ogni pacchetto. Questo può
quindi installare le dipendenze prima di compilare e rimuoverle subito dopo.</p>
<p>Le dipendenze di compilazione possono essere parzialmente generate
automaticamente, controllando le dipendenze del pacchetto binario generato dai
sorgenti. Questo è quello che fa <tt>andrea</tt>: 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.</p>
<hr>
<p><small>Materiale sviluppato da Roman Hodek per il sesto International
Linux-Kongress 1999.</small></p>
Attachment:
signature.asc
Description: PGP signature