Bootstrap? Quale bootstrap? Io voglio la ISO di Mageia!

Avevamo annunciato che la nostra prima alpha ISO sarebbe stata disponibile dalla fine di Gennaio… e ancora niente ISO. Dannazione! Cosa sta succedendo? Lasciatemi spiegare.

C’era una volta un Bootstrap…

Come indicato nel post precedente, il nostro sistema di compilazione ha lavorato a pieno regime durante le ultime settimane e più di 4000 pacchetti sono stati prodotti. Questo insieme di pacchetti è quello che noi chiamiamo bootstrap.

Guardando Wikipedia, vedrete che un bootstrap è definito come un piccolo bootloader utilizzato per avviare un sistema più grande. Nel caso di Mageia: il bootstrap è l’attuale fase nella quale viene approntato il sistema di base e risolte le principali dipendenze per consentire alle altre applicazioni di essere compilate utilizzando gli strumenti ed i pacchetti propri di Mageia. Tutte le distribuzioni Linux utilizzano i propri pacchetti per costruire tutti i pacchetti presenti nei repositories.

Poi arriva la parte più difficile della storia, una sorta di dilemma del tipo “è venuto prima l’uovo o la gallina?”. Alcuni pacchetti di basso livello, tipicamente chiamati toolchains (n.d.t. insiemi di applicazioni finalizzate alla compilazione/creazione di un prodotto, l’output di uno è l’input di un altro), necessitano di se stessi per essere compilati : gcc, glibc… Questi pacchetti esistono già in molte distribuzioni. Quindi il processo di bootstrap parte semplicemente da una di queste distribuzioni.

Per quanto riguarda Mageia, abbiamo deciso di utilizzare i pacchetti di Mandriva dato che la prima release è basata su Cooker. Per poterli utilizzare, occorre ripulirli:

• rimuovendo parti e pezzi specifici di Mandriva (macro RPM, oggetti tutelati da copyright come immagini e icone, roba obsoleta…)
• rimuovendo condizioni non necessarie nella definizione dei requisiti per la compilazione
• inviando le correzioni upstream (n.d.t. con upstream ci si riferisce in generale al produttore principale di un software per il quale sono state prodotte le correzioni) al fine di non doverle mantenere e renderle fruibili anche a tutti gli altri qualora l’upstream le accettasse
• disabilitando temporaneamente qualche dipendenza ad alto livello dato che queste non sono state ancora risolte e non sono quindi disponibili per Mageia (Java, Mono).

Quando tutto questo sarà fatto, ogni pacchetto sarà pronto per essere ricostruito nel sistema di compilazione di Mageia. Una volta che il pacchetto sarà ricostruito come uno di Mageia, il packager controllerà ed aggiungerà, se necessarie, le dipendenze di compilazione non appena saranno disponibili.

Facciamo un esempio

gcc è un compilatore C, una parte importante del sistema base dato che è necessario per compilare i sorgenti di molte applicazioni.

Mageia richiede il proprio pacchetto gcc per generare tutte le applicazioni utilizzando il linguaggio C (ciò prende anche il nome di dogfooding – n.d.t. leggasi autosufficienza). Questa è un’operazione cruciale per Mageia in quanto il corretto svolgimento di questa assicura che tutto funzioni bene e al contempo permette di identificare potenziali problemi permettendone quindi la correzione.

Il gcc di Mageia viene quindi generato.

Una volta costruita la toolchain possiamo ricompilare il kernel di Mageia, i drivers X, il server X, ecc così come le applicazioni di più alto livello. Un sistema appena avviato non offre molti pacchetti oltre a qualche libreria ed un compilatore. Tutto ciò necessiterà successivamente di ulteriori ed essenziali pacchetti di sistema  prima di consentire ai team di packagers di iniziare a lavorare sul serio. Molti pacchetti necessitano per dipendenza di ulteriori pacchetti che andranno quindi compilati a loro volta.

In conclusione migliaia di pacchetti sono necessari per compilare i componenti principali che saranno a loro volta necessari alle applicazioni ad un più alto livello.

Certamente questa è la storia semplificata, privata di tutte quelle cose simpatiche che possono accadere durante il processo di ricompilazione, ma questo è il quadro generale.

Perchè il bootstrap è così importante?

Come indicato precedentemente, il bootstrap è una fase dove i packagers e gli specialisti del sistema base possono prendere del tempo per verificare la consistenza delle varie parti ad un livello veramente basso della distribuzione, definire i requisiti e renderli idonei alle politiche della distribuzione. Quindi il bootstrap non è dedicato esclusivamente alle persone interessate nei fork 🙂

Ad ogni modo, migliorare e scrivere documentazione appropriata sulla fase di bootstrap sarà inoltre di grande aiuto quando nuove architetture verranno aggiunte e supportate. Occorreranno infatti una toolchain appropriata, un sistema di base…. insomma la stessa storia.

Le ISO

Tornando quindi alla nostra prima domanda: per quando possiamo aspettarci una prima ISO di prova? La fase di bootstrap è iniziata un mese fa e dovrebbe terminare entro domani. Ci sono volute circa 1,500 hours per compilare i pacchetti disponibili, prendere in carico le compilazioni andate a buon fine ma anche quelle fallite e quelle ricompilate, prendere le decisioni tecniche che andavano prese, gli inconvenienti, le discussioni…

Ora ci siamo :-). Il repository è pronto per le prime prove di compilazione, la nostra macchina per la costruzione delle ISO è configurata a dovere e la Alpha 1 è prevista per il 15 di Febbraio; restate sintonizzati,  ulteriori news sulla futura roadmap verranno presto rilasciate!