Scorciatoie per ricompilare parco pacchetti extra

[joe]

Ciao a tutti, spero stiate tutti bene!

Avevamo già parlato di questa operazione: mettiamo di usare slackware current (ma il discorso è uguale anche sulla stabile anche se la necessità di affrontarli si presenta meno frequentemente) e sul sistema abbiamo il set di pacchetti ufficiali precompilati che gestiamo dal repo ufficiale di pat (via slackpkg ad esempio, ma anche a mano, il discorso non cambia). Accanto a questi pacchetti abbiamo anche un parco software di qualche centinaio di pacchetti ottenuti da sorgenti, ad esempio attraverso gli slackbuild SBo (io uso sbopkg).

Insomma abbiamo un sistema misto con pacchetti ufficiali che gestiamo senza problemi e pacchetti compilati autonomamente.
Ok, ora vogliamo aggiornare il sistema. Partiamo con l'aggiornamento dei pacchetti ufficiali precompilati usando ad esempio slackpkg o spackpkg+.
Poi, in generale (ok a volte non serve ma non si sa mai), occorre anche ricompilare tutto il parco software installato da sorgenti. Usando sbopkg e una coda ordinata correttamente, la cosa non è così drammatica e se tutto fila liscio si riesce ad eseguire l'operazione lanciando un solo comando.

Ma c'è un problema: l'operazione di ricompilazione di 300 / 400 pacchetti, tra cui anche malloppi ingombranti richiede un sacco di tempo. Si parlava tempo fa con Ponce mi pare e diceva che l'operazione impiegava senz'altro più di 24 ore.
La domanda che volevo porvi è semplice: ci sarebbe qualche espediente per ricompilare il tutto molto più rapidamente?

Esempio, vado a braccio, anni fa avevo letto di un sistema chiamato Ccache o qualcosa di simile che memorizzava in qualche modo la compilazione di un pacchetto e alla prossima compilazione riutilizzava alcuni dati memorizzati senza dover ricompilare tutto da zero, in questo modo a fronte di una certa occupazione di spazio su disco si otteneva un notevole abbattimento dei tempi di ricompilazione.
Esiste qualche sistema similare in vista di una ricompilazione in massa dell'intero parco software installato da sorgenti?

[ilmich]

L'unico modo ad occhio è quello che hai citato anche tu, ovvero velocizzare la compilazione tramite ccache (per i pacchetti in c/c++).
Ccache è un wrapper.. io l'ho usato in modo non spinto per buildare le immagini android ed effettivamente ottieni un grosso beneficio a patto pero' di sacrificare un sacco di spazio disco (per android parliamo di diversi gb)

Per 'non spinto' intendo che la build di android lo prevede... in alternativa per farlo in modo trasparente su tutto il sistema puoi fare un link simbolico che 'sostituisce' il compilatore gcc e di conseguenza qualsiasi cosa tu provassi a compilare sarebbe cachato.
Citando dal man page

Codice: Seleziona tutto

RUN MODES
       There are two ways to use ccache. You can either prefix your compilation commands with ccache or you can let ccache masquerade as the compiler by creating a symbolic
       link (named as the compiler) to ccache. The first method is most convenient if you just want to try out ccache or wish to use it for some specific projects. The second
       method is most useful for when you wish to use ccache for all your compilations.

       To use the first method, just make sure that ccache is in your PATH.

       To use the symlinks method, do something like this:

           cp ccache /usr/local/bin/
           ln -s ccache /usr/local/bin/gcc
           ln -s ccache /usr/local/bin/g++
           ln -s ccache /usr/local/bin/cc
           ln -s ccache /usr/local/bin/c++

       And so forth. This will work as long as the directory with symlinks comes before the path to the compiler (which is usually in /usr/bin). After installing you may wish
       to run "which gcc" to make sure that the correct link is being used.

[joe]

Ok, nel nostro caso però:

Codice: Seleziona tutto

lrwxrwxrwx 1 root root 9 giu 23  2018 /usr/bin/gcc -> gcc-5.5.0
lrwxrwxrwx 1 root root 13 giu 23  2018 /usr/bin/g++ -> g++-gcc-5.5.0
lrwxrwxrwx 1 root root 3 giu 23  2018 /usr/bin/cc -> gcc
lrwxrwxrwx 1 root root 3 giu 23  2018 /usr/bin/c++ -> g++

Quindi bisognerà creare i link simbolici a ccache sovrascrivendo quelli lì sopra, ma poi immagino che si dovrà anche in qualche modo configurare ccache per dirgli dove trovare gli eseguibili veri: gcc-5.5.0 g++gcc-5.5.0.

Fermo restando che per le ricompilazioni questo sistema di cache risulti effettivamente efficace, sia in termini di tempistiche che in termini di corruzione dei pacchetti prodotti, così a spanne sui circa 320 pacchetti SBo che avrei da ricompilare, quanto spazio disco potrebbe richiedere? 10 GB? 30 GB? 50? 100 GB?

[ilmich]

no... se guardi bene viene indicato di fare un link simbolico sotto

/usr/local/bin

che in una installazione tipica di slackware ha precedenza rispetto ad /usr/bin(basta vedere la variabile di environment PATH) e quindi il risultato sarebbe che useresti il link di ccache e non il reale gcc senza intaccare l'installazione.
Il trucco funziona perchè esiste l'argomento 0 che corrisponde al nome dell'eseguibile lanciato.. cchace è fatto in modo tale per cui se questo argomento 0 è gcc (come nel caso di link simbolico) usa quello come compilatore e l'utente finale non deve fare niente

Relativamente allo spazio dipende.. cosi su 2 piedi non saprei darti indicazioni... tieni presente che puoi indicare un tetto massimo alla cache quindi rischio di 'rompere' il sistema è praticamente nullo.

Io ti consiglio di partire con una 20-30GB.

[joe]

Ok, più o meno ho capito, poi quando proverò in pratica vedrò come si comporta.

Il problema spazio potrebbe essere rilevante nel mio caso:
ho un SSD da 250 GB di cui 100 GB occupati da slackware 14.2 che per ora sto ancora usando come sistema principale. Poi ci sono 127 GB per la partizione di current di cui attualmente sono occupati 21 GB che comprendono tutti i pacchetti slackware ufficiali tranne le serie kde xfce e tipo emacs e qualcos'altro, vi ho aggiunto qualche pacchetto da SBo ma davvero poca roba per il momento.
Quindi in pratica avrei 100 GB di spazio libero in cui dovranno stare i 300 e passa pacchetti compilati via SBo, i sorgenti degli stessi più i files di lavorazione in fase di compilazione e va considerato anche lo spazio che occuperanno una volta installati. A tutto ciò se ho ben capito bisogna sommare questa particolare cache. Boh potrei provare ed eventualmente cercare un modo per impostare come directory in cui stoccare i pacchetti prodotti un percorso esterno su un altro disco meccanico dove ho un po' più spazio... Non so bene come farlo con sbopkg ma non dovrebbe essere difficile ci sarà il modo già previsto.

Il secondo problema che ho il sospetto potrebbe presentarsi è relativo alla ricompilazione di un certo pacchetto SBo invariato, lui, ma eseguita dopo l'aggiornamento di qualche libreria importante che invece ha subito un aggiornamento.
Del tipo:
- installo ffmpeg da repo ufficiale - versione 1
- compilo mpv versione 1 che si appoggia a ffmpeg
- ccache salva tutto il salvabile in cache
- al secondo giro aggiorno ffmpeg alla versione 2 aggiornata da Pat sul repo ufficiale
- poi ricompilo mpv perchè altrimenti cercherà la vecchia versione di ffmpeg e non la troverà dando errore
- entra in gioco ccache che utilizzerà i file oggetto già prodotti al primo giro....

Ma domanda: questi files oggetto saranno basati su una versione di ffmpeg diversa dalla attuale... Il pacchetto mpv che ne salterà fuori sarà corretto lo stesso?
Non so se ho spiegato chiaramente il mio dubbio...
Mi sapete dare un chiarimento su questo punto?

[ilmich]

Ma domanda: questi files oggetto saranno basati su una versione di ffmpeg diversa dalla attuale... Il pacchetto mpv che ne salterà fuori sarà corretto lo stesso?

rispondo solo a questo..
non conosco gli internals di ccache ma per essere effettivo credo che si basi sul sorgente... cioe a parita di sorgente lui va a prendere il compilato dalla cache (se lo trova)
In altre parole supponiamo di avere

- un file pippo.c
- il suo compilato pippo.o

ccache crea una sorta di firma del file sorgente (pippo.c) e va a vedere nella sua cache...se non la trova lancia effettivamente il compilatore.. se la trova restituisce direttamente il compilato. e cosi via.

Di conseguenza se due versioni di un software cambiano.. ma non tutti i file sorgente vengono modificati, quelli che ccache trova nella sua cache li skippa.

Tecnicamente nell'esempio che hai riportato potrebbe darsi che ffmpeg venga ricompilato solo per quel delta che è cambiato da una versione all'altra e mpv non ricompilato affatto (perchè preso completamente dalla cache)
Certo questa è la teoria.. la pratica è un altra storia.. comunque ti consiglio di provare... magari con cose 'piccole' inizlamente

[joe]

Intanto grazie delle risposte...
Nel mio esempio ffmpeg non viene ricompilato solo aggiornato da repo ufficiale, ed è dipendenza per mpv (che invece deve essere ricompilato... proprio perchè ffmpeg è cambiato).
Quindi mpv a livello di sorgente è invariato, ma deve essere ricompilato "contro" il nuovo ffmpeg.
Siamo sicuri che ccache riesca a non far casini?

Certo vedrò di fare qualche prova con la coda di pacchetti da ricompilare che ho attualmente su current ed è non troppa roba.

[ilmich]

non so quanto sei avvezzo in fatto di compilazione (nn parlo di lanciare uno slackbuild) pero la compilazione di un sorgente c avviene in due fasi

- compilazione del singolo file
- link alle librerie dipendenti

ccache agisce solo nel primo caso quindi nel tuo esempio il link dell'eseguibile MPV a ffmpeg avviene sempre e comunque. Perciò il tuo binario finale è corretto in ogni caso.

[joe]

Ok sì no sono troppo esperto in effetti, sapevo solo che aggiornando ffmpeg senza ricompilare mpv, quest'ultimo smette di funzionare per mancanza di dipendenza.
Bene, quindi non ci sono problemi neanche in seguito all'aggiornamento di nuove librerie: cioè ccache interviene nello sveltimento della compilazione dei sorgenti (se non sono variati), mentre la fase di "aggancio" ai nuovi software eventualmente aggiornati da cui quel "sorgente" dipende, avviene sempre e comunque in una fase indipendente da ccache, che quindi non dovrebbe fare casini in questo frangente.

[ilmich]

provaci.. simula lo scenario che hai descritto, e magari proprio con i pacchetti che hai citato.. la cosa peggiore che ti puo' succedere è... boh non me ne viene in mente nessuna in effetti