[Current] Gestione software personalizzato dopo aggiornamento

[joe]

Premetto che mi riferisco ai primi passi su slackware current che ultimamente sto testando.
L’altro giorno dopo aver ricompilato ffmpeg a partire dallo slackbuild della current, mi stavo chiedendo se non fosse il caso in prospettiva, di avere un sistema un po’ più automatizzato per facilitare le ricompilazioni e reinstallazioni in occasione dell’aggiornamento del sistema.

Penso ai pacchetti ricompilati in proprio, come ffmpeg per esempio.
Per ognuno si dovrebbe scaricare il sorgente, il contenuto eventuale presente nella webdir (del repo di current per esempio) con eventuali pathces ma anche slackbuild slack-desc ecc ecc...
Una volta reperito tutto il materiale nella dir di lavoro si può editare lo slackbuild aggiungendo le eventuali opzioni da attivare ecc ecc...
Per fare l’esempio di ffmpeg avevo editato lo slackbuild come segue:

Codice: Seleziona tutto

# Set some VARS to enable user chosen codecs
X264=yes
X265=yes
DC1394=yes
TWOLAME=yes
FDK_AAC=yes
AAC=yes

# disable opencl since current graphic card doesn't support that feature
OPENCL=no

Pensando alle “queues” di sbopkg e alla struttura di SBo pensavo: non sarebbe possibile crearsi un piccolo “repository” locale contenete gli slackbuild e tutto l’occorrente incluse opzioni personalizzate da richiamare all’avvio degli slackbuild stessi? Un repo locale contenente solo i programmi che si vogliono personalizzare rispetto a quelli del repo ufficiale SBo-git che Ponce ha predisposto per utilizzare con la Current?

L’obiettivo sarebbe poter lanciare un comando solo per ricompilare, pacchettizzare e aggiornare tutto il software del repo locale contenente appunto solo i programmi personalizzati. Comando da usare appunto dopo un aggiornamento del sistema, del tipo:

- aggiorno slackware base con slackpkg
- aggiorno i pacchetti _SBo usando sbopkg e ricompilando
- aggiorno i pacchetti personalizzati ricompilandoli lanciando il nostro comando (ok può essere che qualcosa debba essere ritoccato prima a mano, tipo qualche link e potenzialmente anche qualche opzione aggiunta che potrebbe non andar più bene per una nuoova versione del programma, esempio se Pat aggiorna ffmpeg).

Ha senso secondo voi porsi questo problema? O sto prendendo una cantonata?
Come ci si potrebbe organizzare?

[ponce]

se puo' esserti utile ti faccio l'esempio di come gestisco gli aggiornamenti in current: ho una macchina virtuale pulita, senza nessun pacchetto che non sia in Slackware tranne sbopkg, che tengo aggiornata.
quando c'e' un aggiornamento che cambia librerie di uso comune (icu4c, boost, perl, python o che altro) prendo questa macchina pulita e ci ricompilo tutto il software che uso.
una volta finito mi ricompilo ffmpeg e MPlayer, le uniche due cose customizzate di uso comune nelle mie installazioni: per ricompilare ffmpeg, per mia comodita', uso questo comando che lancia la ricompilazione

Codice: Seleziona tutto

AAC=yes \
ASS=yes \
BS2B=yes \
CELT=yes \
DC1394=yes \
DECKLINK=yes \
FDK_AAC=yes \
FLITE=yes \
FREI0R=yes \
GME=yes \
GSM=yes \
IEC61883=yes \
ILBC=yes \
LADSPA=yes \
LAME=yes \
MODPLUG=yes \
NVENC=yes \
OPENAL=yes \
OPENCORE=yes \
OPUS=yes \
RTMP=yes \
RUBBERBAND=yes \
SAMBA=no \
SNAPPY=yes \
SPEEX=yes \
TESSERACT=yes \
TWOLAME=yes \
VIDSTAB=yes \
XVID=yes \
X264=yes \
X265=yes \
ZMQ=yes \
ZVBI=yes \
BUILD=1ponce \
./ffmpeg.SlackBuild

# EBUR128=yes \
# NETCDF=yes \
# CHROMAPRINT=yes \
# OPENCV=yes

per il resto non uso nient'altro.

per chiarire, faccio tutto in una macchina virtuale pulita per evitare che gli aggiornamenti si incasinino linkandosi a versioni vecchie del software installato, e' l'unico modo certo per evitare confusione: mai avuto un problema in 10 anni che uso questo metodo.

[joe]

Per curiosità, il sitema virtualizzato quanto spazio ti occupa? Ma ri-compilando i pacchetti SBo su quel sistema non impiega troppo? e non mette un po' troppo sotto stress il processore? (non sarebbe preferibile un chroot)?

Quindi riguardo la mia domanda se ho ben capito fai tutto a mano visto che hai pochi pacchetti creati con slackbuilds personali.
Alla fine ne ho pochi anche io di pacchetti da ricompilare custom ma alla lunga mi scoccia farlo manualmente.
Crearsi un mini repo tipo SBo in locale da usare poi con "sbopkg -V" no eh?
O in alternativa farsi uno script che lanciato vada a scaricare tutto il necessario e lanci gli slackbuild preceduti da variabili impostate (similmente al tuo comanado per capirci)?

[ponce]

Per curiosità, il sitema virtualizzato quanto spazio ti occupa?

60Gb.

Ma ri-compilando i pacchetti SBo su quel sistema non impiega troppo?

13 ore, ma sono piu' di 500 pacchetti, tra cui bestioni come qt5...

e non mette un po' troppo sotto stress il processore? (non sarebbe preferibile un chroot)?

e' una macchina virtuale a cui ho assegnato 12 cpu (il virtualizzatore ne ha 12) e 10 Gb di ram (il virtualizzatore ne ha 64).
anche un chroot va bene, come preferisci: magari puoi avere qualche inconveniente se fai un chroot a 32bit su un sistema operativo a 64bit, visto che il kernel rilevato dal chroot e' a 64bit.

comunque anche se ci mettesse di piu' non sarebbe un grosso problema, tanto finche' non ha finito non aggiorno le mie installazioni desktop di current con i pacchetti nuovi rilasciati da Pat (senno' le cose potrebbero smettere di funzionare)...

Quindi riguardo la mia domanda se ho ben capito fai tutto a mano visto che hai pochi pacchetti creati con slackbuilds personali.
Alla fine ne ho pochi anche io di pacchetti da ricompilare custom ma alla lunga mi scoccia farlo manualmente.
Crearsi un mini repo tipo SBo in locale da usare poi con "sbopkg -V" no eh?
O in alternativa farsi uno script che lanciato vada a scaricare tutto il necessario e lanci gli slackbuild preceduti da variabili impostate (similmente al tuo comanado per capirci)?

boh, a seconda di quanti script hai puo' tornarti utile: qui non me ne faccio di niente, visto che fino a poco fa lo script personalizzato era uno, MPlayer, a cui recentemente si e' aggiunto ffmpeg quando Pat lo ha messo in current.
tra l'altro sto usando mpv da un po' quindi tra poco gli script personalizzati torneranno uno (ffmpeg).

[joe]

E quando la macchina virtuale ha finito tutta la ricompilazione, come "porti" il tutto sul tuo sistema reale?

Per curiosità, di che virtualizzatore stiamo parlando?

[ponce]

E quando la macchina virtuale ha finito tutta la ricompilazione, come "porti" il tutto sul tuo sistema reale?

sposto i file con rsync e poi li installo tutti con

Codice: Seleziona tutto

upgradepkg --install-new --reinstall *.txz

Per curiosità, di che virtualizzatore stiamo parlando?

macchine virtuali kvm (qemu) che girano sotto libvirt e che uso via ssh.

[joe]

Ah quindi sono macchine remote. E a livello hardware di cosa si tratta?
Libvirt l'ho già incontrato di striscio in qualche lettura mentre cercavo altro inerente qemu se non ricordo male... Ma non ho capito bene a cosa serva.

[ponce]

libvirt e' un sistema per gestire vari virtualizzatori: io lo uso principalmente con qemu, ma ha api per gestirne anche altri.

a volte uso macchine remote, a volte locali, non e' rilevante: su tutte le mie installazioni gira libvirt e le macchine virtuali linux possono essere spostate agilmente ovunque.
se ho bisogno dell'interfaccia grafica mi ci posso collegare anche con virt-manager (sempre in remoto o in locale).

se possono essere utili qualche mese fa ho preparato delle slide per un seminario al Linux Day locale
https://slides.com/ponce/virtualizzazione-con-libvirt/

comunque le caratteristiche della macchina (su cui faccio sviluppo e uso come backup) sono quelle sopra, cioe' 12 core, 64 Gb RAM, e un po' di spazio disco: non sono molto dissimili da quelle di un portatile moderno...

[joe]

12 core... ma precisamente che CPU è ?

[ponce]

uno Xeon, ma, come dicevo, questi sono i risultati di due comandi sul portatile che ho preso col Black Friday (cambiando quello che avevo da ormai quasi 10 anni)

Codice: Seleziona tutto

$ nproc 
12
$ grep ^model\ name /proc/cpuinfo | uniq
model name	: Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz

[joe]

Capito.... Grazie per i dettagli, può sempre tornare utile sbirciare nelle soluzioni adottate dagli utenti salcky.

Personalmente sinceramente vorrei evitare di mettere in piedi tutta quella roba, ma anche solo per il discorso spazio disco usato per l'ambiente pulito.
Tornando all'idea di un mini repo, chiamaiamolo "local" per capirci, da usare con una cosa tipo:

Codice: Seleziona tutto

sbopkg -V local -i tutti-i-software-compilati-da-me.queue

Sarebbe fattibile una cosa del genere?
Chiedevo a te perché di fatto hai fatto una cosa del genere alla fine col repo SBo-git per current. Solo che nel tuo caso hai incluso tutti i pacchetti dell'ultima stabile come base di partenza, mentre il mio obiettivo è quello di includere solo i paccheti che mi compilo "custom". Quindi non mi interessa fare il fork dello SBo completo, anzi vorrei che il repo "local" fosse completamente indipendente dal resto dell'utilizzo di sbopkg.

Se fosse possibile sarebbe comodo perché:
- sfrutterei i files .info per reperire i sorgenti aggiornati (tipo di ffmpeg potrei mettere l'indirizzo del tarball sul repo ufficiale della current)
- mi scriverei la coda di compilazione una volta per tutte e lancerei un comando simile a quello sopra dopo l'aggiornamento e la ricompilazione dei pacchetti SBo-git
- metterei un $BUILD differente da SBo per non creare sovrapposizioni

Se la cosa ha senso, come si potrebbe mettere in piedi?

[ponce]

non ti posso aiutare perche' non ho mai fatto un repository locale con solo qualche pacchetto...
ma in teoria, se rispetti tutte le convenzioni di SBo (le puoi desumere da come sono organizzati gli altri pacchetti), usando le stesse variabili negli script che ci metterai, usando i soliti file, ecc. dovrebbe funzionare.
tieni di conto che sbopkg ha una mailing list e un canale irc (#sbopkg su irc.freenode.net) ed e' molto probabile che tu ci trovi qualcuno che lo ha gia' usato cosi': infatti, da una rapida ricerca su google, ho trovato questo thread.