Autobuilder network
La rete di buildd è un sottoprogetto di Debian che gestisce la compilazione 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 rete di buildd fornisce una funzionalità di compilazione pacchetti sicura per tutte le architetture supportate. La distribuzione Debian supporta diverse architetture, e i manutentori dei pacchetti spesso non hanno accesso a tutte le macchine con le architetture necessarie. Inoltre, Debian oggi impone che i normali pacchetti binari siano generati da codice sorgente in un ambiente controllato (si veda il requisito di caricamento di solo codice) per evitare l'introduzione di binari malevoli da parte di sviluppatori. La rete di buildd acquisisce il codice sorgente e compila automaticamente i pacchetti binari per ogni architettura supportata. Ogni compilazione fallita è tracciata nel database dell'autobuilder.
La rete di buildd alleggerisce il lavoro ai manutentori dei Debian Ports. Quando fu iniziata Debian/m68k (il primo port non Intel) gli sviluppatori di questo port controllavano l'arrivo di nuove versioni dei pacchetti e dovevano ricompilarle se volevano stare allineati con la distribuzione per 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 le varie distribuzioni Debian aggiornate. Gli aggiornamenti per la sicurezza sono compilati sulle stesso insieme di macchine in modo da assicurare che siano tempestivamente disponibili.
Come funziona buildd?
Buildd è il nome che di solito si dà ai programmi utilizzati della rete, ma in realtà è però diviso in parti diverse:
- 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. È alimentato con i file Sources e Packages recuperati dai vari archivi dei pacchetti Debian (per esempio ftp-master e security-master).
- buildd
- un demone che controlla periodicamente il database mantenuto da wanna-build e chiama sbuild per compilare i pacchetti. Una volta che la compilazione viene approvata da un amministratore, carica il pacchetto nell'archivio appropriato.
- sbuild
- è responsabile dell'effettiva compilazione dei pacchetti in chroot isolate. Si assicura che tutte le dipendenze di compilazione siano soddisfatte, poi, utilizzando comandi standard di Debian, avvia la compilazione. I log di compilazione sono aggiunti al database dei log di compilazione.
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 (Out-Of-Date, "non aggiornato", oppure Uncompiled, "non compilato"), la priorità del pacchetto, la sua sezione ed il suo nome. Inoltre, per evitare che alcuni pacchetti rimangano sempre in fondo alla coda e non vengano mai compilati, le priorità sono aggiustate dinamicamente man mano che il tempo di attesa aumenta.
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 corrispondente. Se la compilazione non finisce con successo, il pacchetto entrerà in uno stato speciale (Build-Attempted, "compilazione tentata", per compilazioni fallite che non sono state ancora revisionate dagli amministratori, Failed, "fallito", una volta che il fallimento è stato revisionato e riportato come bug, oppure Dep-Wait, "aspetta le dipendenze", se presentano dipendenze di compilazione non disponibili). Gli amministratori della rete di buildd controlleranno i pacchetti che non sono stati compilati con successo e ne daranno comunicazione al mantenitore, generalmente aprendo un bug nel Bug Tracking System.
A volte un pacchetto impiega molto tempo per essere compilato per una certa architettura, e questo gli impedisce di entrare in testing. Se un pacchetto sta bloccando una transizione tipicamente le priorità di compilazione vengono aggiustate su richiesta del Team di Rilascio. Altre richieste di questo tipo non saranno accettate, dal momento che il pacchetto guadagna automaticamente priorità man mano che rimane nella coda.
Puoi controllare lo stato di ogni tentativo fatto da buildd per compilare i pacchetti che appartengono ad ogni mantenitore controllando i log di buildd. Questi log possono essere raggiunti anche dal Riassunto dei Pacchetti di un Mantenitore (Packages' Maintainer Overview).
Per maggiori informazioni sui diversi stati dei pacchetti puoi leggere "stati di wanna-build".
Dove posso trovare altre informazioni?
Ovviamente, il miglior modo di capire come funziona la rete i buildd è consultare i codici sorgente e la documentazione disponibile. Inoltre, la sezione Porting and being ported della Debian Developers Reference contiene altre informazioni su come funziona, nonché informazioni sui compilatori di pacchetti e tool per il porting che sono utilizzati nel processo di costruzione e mantenimento della rete di buildd.
Sono disponibili alcune statistiche sulla rete di buildd.
Come faccio a installare il mio nodo buildd personale?
Ci sono molte ragioni per cui uno sviluppatore (o un utente) potrebbe voler metter su e far funzionare un sistema buildd:
- Per aiutare nel port su una certa architettura (quando sono necessari nodi buildd).
- Per valutare l'effetto di una certa patch o ottimizzazione del compilatore su un grande numero di pacchetti.
- Per utilizzare tool che analizzano pacchetti cercando errori comuni e che lavorano sui pacchetti compilati, operazione che può anche essere necessaria per fare analisi sul codice sorgente, per esempio come work-around per pacchetti che usano dpatch.
Qui puoi trovare ulteriori informazioni su come installare un nodo buildd.
Contattare gli amministratori dei nodi buildd
Il principale indirizzo per i potenziali mantenitori del build è debian-wb-team@lists.debian.org (Mailing list)
Gli amministratori responsabili di buildd per una particolare architettura possono essere raggiunti all'indirizzo arch@buildd.debian.org, per esempio i386@buildd.debian.org.
Questa introduzione alla rete di buildd è stata scritta mettendo insieme pezzetti appartenenti a Roman Hodek, Christian T. Steigies, Wouter Verhelst, Andreas Barth, Francesco Paolo Lovergine, Javier Fernández-Sanguino e Philipp Kern.