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 g.mascell...@gmail.com
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
pLa rete di buildd è un sottoprogetto di Debian che aiuta a velocizzare
la ricompilazione dei pacchetti per tutte le architetture che
a href=$(HOME)/ports/Debian al momento supporta/a. Questa rete è formata
da svariate macchine (i nodi buildd) che utilizzano uno specifico pacchetto
software, chiamato embuildd/em, per prendere i pacchetti dall'archivio
Debian e ricompilarli per l'architettura richiesta./p
h2Come mai è necessaria la rete di buildd?/h2
pLa distribuzione Debian supporta a href=$(HOME)/ports/un buon numero di
architetture/a, 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./p
pQuando 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./p
pIl 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.
/p
h2Come funziona buildd?/h2
pemBuildd/em è il nome che di solito si dà ai programmi utilizzati
della rete, ma in realtà è però diviso in parti diverse:/p
dl
dta href=http://svn.cyberhqz.com/svn/wanna-build/;wanna-build/a/dt
dd
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.
/dd
dta href=http://svn.cyberhqz.com/svn/wanna-build/;buildd/a/dt
dd
un demone che controlla periodicamente il database mantenuto da
emwanna-build/em e chiama emsbuild/em 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.
/dd
dta href=http://packages.debian.org/sbuild;sbuild/a/dt
dd
è 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.
/dd
dta href=http://packages.debian.org/quinn-diff;quinn-diff/a/dt
dd
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).
/dd
/dl
pTutte queste parti a href=operationoperano/a insieme per far funzionare
la rete di buildd./p
h2Cosa deve fare uno sviluppatore Debian?/h2
pIn 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 emNeeds-Build/em, 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./p
pSe 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
