Package buildsystem

I miei pacchetti Slackware personali per slackware64-current sono costruiti da una piccola pipeline di strumenti che gira dentro un’unica macchina virtuale QEMU dedicata. Niente qui è un singolo programma: c’è un repository che viene riassemblato, uno strato di dipendenze che viene corretto, un builder che trasforma gli SlackBuild in pacchetti e un passo di pubblicazione che li mette online su packages.danix.xyz. Questa pagina segue l’intero flusso nell’ordine in cui una build avviene davvero.

// La VM

Il buildsystem vive in una macchina virtuale QEMU che esegue slackware64-current, tenuta aggiornata con slackpkg da un mirror locale dei pacchetti di sistema di Slackware. Ha 8 core CPU e circa 8 GB di RAM, abbastanza per compilare comodamente tutti i pacchetti tranne i più pesanti, e vi accedo via SSH. Tenerla in una VM dedicata fa sì che una build, una dipendenza rotta o una rigenerazione completa del repository non tocchino mai la mia macchina di tutti i giorni: quella scatola esiste per essere martellata e, se serve, buttata via e ricostruita.

// Assemblare il repository

Una volta a settimana l’albero degli SlackBuild viene rigenerato da zero. Parte come clone degli slackbuilds di Ponce sul branch current, l’albero della community che segue SlackBuilds.org su slackware-current. Sopra vi sovrappongo le mie due collezioni come git subtree compressi: my-slackbuilds per i pacchetti personali generici e Slackware-Pentesting-Suite per gli strumenti di sicurezza.

Dove un pacchetto personale condivide il nome con uno upstream, la copia upstream viene oscurata: la sua directory viene rimossa perché vinca la mia versione. Il risultato è un unico albero locale che è SBo standard più le mie aggiunte, pronto per la build. Tutto questo assemblaggio è uno script, che avrà una sua pagina qui più avanti.

// Il problema delle dipendenze su -current

Gli SlackBuild di SBo puntano a Slackware stable, quindi alcune delle loro dipendenze di compilazione sono inutili su -current, che le fornisce già come pacchetti di sistema o in versioni più recenti. rust-opt e google-go-lang sono tipiche: servono su stable, sono superflue su -current. Queste dipendenze “fantasma” costringerebbero altrimenti a ricompilazioni inutili.

slackrepo rimuove una dipendenza da un pacchetto con un hint file per pacchetto che contiene DELREQUIRES, ma scriverne uno a mano per ogni pacchetto interessato dopo ogni rigenerazione settimanale è proprio la noia di cui uno script dovrebbe farsi carico. Quel compito spetta a mkhint: il suo sweep -F legge una lista di dipendenze fantasma e, per ogni pacchetto le cui dipendenze ne toccano una, scrive o unisce il DELREQUIRES giusto in tutto l’albero appena ricostruito, in un solo passaggio.

// La build

La compilazione vera e propria è affidata a slackrepo, un builder automatico di SlackBuild per Slackware, ora mantenuto da Andrew Clemons. Compila ogni pacchetto e le sue dipendenze in un chroot pulito, segue le revisioni git upstream per capire cosa è cambiato e va ricostruito, e produce un repository che si aggancia direttamente a slackpkg+. Lo eseguo con un hook iniziale che prima ribasa il mio albero di SlackBuild su upstream, così ogni build parte da un albero aggiornato, e gestisce l’ordine delle dipendenze in modo che un singolo comando ricostruisca tutto ciò che si è mosso.

// Pubblicazione

Quando una build finisce, subentra una catena di hook finali di slackrepo. Rigenerano i metadati del repository per slackpkg+, costruiscono il frontend HTML a tema per il sito dei pacchetti, sincronizzano il risultato sul server live e inviano una notifica di fine esecuzione. Il frontend avvolge il semplice autoindex delle directory di Apache in un header e un footer a tema, così packages.danix.xyz si legge come un vero repository e non come un nudo elenco di file. Anche quel frontend è un suo piccolo progetto e avrà una pagina qui più avanti.

// Test contro 15.0 stable

Alcuni dei pacchetti che scrivo sono destinati a essere proposti a monte su SlackBuilds.org, che punta a Slackware stable, non a -current. Dato che tutto il mio buildsystem è -current, il fatto che un pacchetto compili bene qui non dice nulla su 15.0. Prima di proporne uno, lo testo con uno strumento separato e indipendente pensato esattamente per questo: risolve localmente l’albero delle dipendenze dello SlackBuild, poi costruisce e installa ogni pacchetto in un chroot overlay usa e getta stratificato su una base Slackware 15.0 pulita e in sola lettura. Così emerge lo scostamento tra -current e 15.0 che una build su -current nasconde.

Non tocca né guida slackrepo, e i pacchetti che produce sono usa e getta: l’unica domanda a cui risponde è “compila ancora pulito su 15.0”. Un limite da segnalare: condivide il kernel dell’host, quindi i pacchetti che costruiscono moduli del kernel vogliono comunque una vera VM 15.0. Anche questo strumento avrà la sua pagina qui col tempo.

// Il ritmo settimanale

Messo insieme, la settimana è un unico ciclo ripetibile: rigenerare l’albero degli SlackBuild, spazzare gli hint delle dipendenze fantasma con mkhint -F, costruire e pubblicare con slackrepo e i suoi hook e, per tutto ciò che è diretto a SlackBuilds.org, testarlo prima contro una base 15.0 pulita. Quattro piccoli strumenti, ciascuno che fa bene un solo lavoro, e una VM usa e getta in cui eseguirli. Molto Slackware.

Spero che questo giro nel mio buildsystem ti sia sembrato interessante. Se finisci per metterne in piedi uno simile, o hai domande, idee o suggerimenti su qualunque suo pezzo, scrivimi due righe e sarò felice di risponderti.

Alla prossima.