Allego due pagine del sito di Debian delle quali mantengo la traduzione
e che sono state recentemente aggiornate. I cambiamenti sono piuttosto
piccoli e sono soprattutto rimozioni di testo, per cui non dovrebbero
esserci troppi errori. In ogni caso li affido alla lista, per revisione
ed aggiornamento sul CVS.
Si tratta di:
italian/devel/buildd/index.wml
italian/devel/buildd/operation.wml
Grazie a tutti, Giovanni.
--
Giovanni Mascellani
Pisa, Italy
Web: http://poisson.phc.unipi.it/~mascellani
Jabber: g.mascell...@jabber.org / giova...@elabor.homelinux.org
GPG: 0x5F1FBF70 (FP: 1EB6 3D43 E201 4DDF 67BD 003F FCB0 BB5C 5F1F BF70)
#use wml::debian::template title="Autobuilder network" BARETITLE="true"
#use wml::debian::translation-check translation="1.19" maintainer="Giovanni Mascellani"
La rete di buildd è un sottoprogetto di Debian che aiuta a velocizzare
la ricompilazione dei pacchetti per tutte le architetture che
Debian al momento supporta. Questa rete è formata
da svariate macchine (i nodi buildd) che utilizzano uno specifico pacchetto
software, chiamato buildd, per prendere i pacchetti dall'archivio
Debian e ricompilarli per l'architettura richiesta.
Come mai è necessaria la rete di buildd?
La distribuzione Debian supporta un buon numero di
architetture, ma i mantenitori dei pacchetti in genere compilano i binari
solo per una sola architettura (di solito i386). Gli sviluppatori di altre
architetture devono prestare attenzione a quando escono nuove versioni di ogni
pacchetto e ricompilarle, se vogliono stare al passo con la distribuzione
Intel.
Quando fu iniziata Debian/m68k (il primo port non Intel) tutto questo veniva
fatto manualmente: gli sviluppatori controllavano sulla mailing list degli
upload la presenza di nuovi pacchetti e ne prendevano alcuni per compilarli.
Annunciando su una mailing list cosa si stava per fare si evitava che un
pacchetto venisse compilato due volte. È evidente che però questo metodo era
facilmente soggetto ad errori ed estremamente costoso in termini di tempo, ma è
stato per lungo tempo l'unico modo di mantenere le distribuzioni non i386.
Il demone di compilazione rende automatica la maggior parte di questo
processo. Consiste di una serie di script (scritti in Perl e Python), che sono
stati modificati molte volte nel corso del tempo in modo da aiutare i porter
in molti compiti. Sono finalmente diventati un sistema che è capace di
mantenere quasi automaticamente una distribuzione Debian non i386 aggiornata.
Come funziona buildd?
Buildd è il nome che di solito si dà ai programmi utilizzati
della rete, ma in realtà è però diviso in parti diverse:
http://svn.cyberhqz.com/svn/wanna-build/";>wanna-build
un tool che coordina la (ri)compilazione dei pacchetti attraverso un database
che mantiene la lista dei pacchetti e del loro stato. C'è un database centrale
per ogni architettura che memorizza lo stato dei pacchetti, la loro versione
e qualche altra informazione.
http://svn.cyberhqz.com/svn/wanna-build/";>buildd
un demone che controlla periodicamente il database mantenuto da
wanna-build e chiama sbuild per compilare i pacchetti. Tiene
traccia delle compilazioni fallite e riuscite e carica i pacchetti nell'archivio
una volta che il log di compilazione è stato accettato dall'amministratore.
http://packages.debian.org/sbuild";>sbuild
è responsabile dell'effettiva compilazione dei pacchetti in chroot isolate.
Per fare questo principalmente utilizza tool standard di Debian, ma tiene anche
conto delle dipendenze di compilazione e di altre sottigliezze.
http://packages.debian.org/quinn-diff";>quinn-diff
riempie il database di wanna-build con i nuovi pacchetti. Confronta la lista dei
pacchetti disponibili ed elenca le differenze (comparando un file Sources ed un
file Packages).
Tutte queste parti operano insieme per far funzionare
la rete di buildd.
Cosa deve fare uno sviluppatore Debian?
In realtà lo sviluppatore Debian medio non deve esplicitamente usare
la rete di buildd. Quando carica un pacchetto nell'archivio (binari
compilati per una certa architettura), questo sarà aggiunto al database di ogni
architettura (nello stato Needs-Build, ossia "compilazione
necessaria"). Le macchine di compilazione interrogheranno il database chiedendo
quali pacchetti sono in quello stato e prenderanno continuamente pacchetti dalla
lista. I criteri di priorità della lista sono lo stato della precedente
compilazione, la priorità del pacchetto, la sua sezione ed infine il suo
nome.
Se la compilazione ha successo su tutte le architetture, il mantenitore
non avrà bisogno di fare niente. Tutti i pacchetti binari saranno caricati
nell'archivio principale della loro architettura. Se la compilazione non finisce
con successo, il pacchetto entrerà in uno stato speciale (Failed,
"fallito", oppure Dep-Wait, "aspetta le dipendenze", se ha dipendenze
di compilazione o di installazione che non sono disponibili). Gli amministratori
della rete di buildd controlleranno i pacchetti che non
