1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
|
#use wml::debian::template title="Funzionamento della rete di buildd" BARETITLE="true"
#use wml::debian::translation-check translation="4094875c3a7aafc988b5f218b0a629fab415552a" 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
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
<tt>Needs-Build</tt> (<q>compilazione necessaria</q>).</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> (<q>in compilazione</q>). 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> (<q>caricato</q>). 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>
(<q>installato</q>) e vi rimarrà fino alla prossima versione del pacchetto
sorgente.</p>
<p>Esistono molto altri stati; tra di essi: <tt>Failed</tt> (<q>fallito</q>) 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> (<q>aspetta le dipendenze</q>)
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
manutentore 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>
e riprovare, ecc... Se il pacchetto viene accettato (tramite l'invio di
un file <tt>.changes</tt> firmato), il demone lo sposta in una
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 i tool standard di Debian per
compilare i sorgenti. In realtà dà anche una mano effettuando delle operazioni
di <q>ordinaria amministrazione</q> e installando automaticamente le
dipendenze di compilazione come richiesto dal pacchetto in corso di elaborazione.
<hrline />
<p><small>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.</small></p>
|
