Aggiornamento software SBo

[joe]

Negli scorsi giorni ho eseguito un "upgrade-all" su Slackware-15.0 in modo da aggiornare tutto il parco ufficiale dei pacchetti.

Su questo sistema aggiornato ho un sacco di pacchetti di terze parti, per lo più compilati in locale negli ultimi anni sia attraverso sbopkg che creati da slackbuilds personali, generati sulla stessa slack 15.0 ma che all'epoca non era aggiornata alla situazione attuale.

Quello che vorrei fare è:

1. ri-compilare tutto il set extra-ufficiale in modo che "appoggi" sull'attuale base aggiornata col repo ufficiale
2. e allo stesso tempo aggiornare i pacchetti SBo alle versioni attuali (questo "banalmente" si ottiene ricompilando con sbopkg -r && sbopkg -i codaSBodeipresentisulsistema)

L'operazione però non è banalissima perché per alcuni slackbuilds presi da SBo, tra cui ad esempio i drivers "nvida-legacy340" ma anche "mpv" e anche altra roba, ho modificato gli Slackbuilds originali per attivare varie funzionalità e risolvere qualche problema.

Un'idea sarebbe quella di utilizzare sbopkg e creare un repository SBo "local" contenente solo gli slackbuilds personalizzati e dargli la priorità rispetto al repo SBo della 15.0, ma non saprei bene come mettere in pratica la configurazione.

Alla fine si tratta di creare la coda con tutti i pacchetti SBo presenti sul sistema, ordinata come si deve, e in qualche modo rispettare le varianti personalizzate rispetto agli script originari. La cosa va anche valutata preventivamente assicurandosi che se su SBo fanno degli upgrade di versione la procedura mi avverta e mi consenta di controllare e modificare il mio slackbuild adeguandolo alla nuova situazione (ad esempio mpv-0.34 che avevo prima dell'aggiornamento veniva compilato con waf, ora invece sono passati a 0.37 e utilizzano "meson", quindi in questo caso io avrei dovuto aggiornare al nuovo slackbuild e modificarlo nuovamente aggiungendo le funzionalità che mi servono in modo aderente ai nuovi comandi di compilazione previsti nello slackbuild, nella fattispecie l'opzione "-Dgl-x11=enable").

Avreste qualche suggerimento su come procedere per cavar fuori una procedura utile?

[ponce]

non entrero' molto nel dettaglio ma ti posso dire che qui per utilizzare script custom con sbopkg uso un fork del repository git di SBo.
fondamentalmente creo un branch basato sul ramo master con un solo commit contenente le modifiche allo script che mi interessa e ripeto questa procedura per ognuno degli script avendo alla fine n branch per n script (li puoi vedere qui).
alla fine creo un branch aggiuntivo (lo puoi chiamare come vuoi) dove faccio il merge di tutti gli altri branch (nell'esempio sopra e' il branch "current").
siccome ogni settimana SBo viene aggiornato di tutti questi branch faccio il rebase con la solita frequenza in modo di avere le mie modifiche applicate sopra al repository di SBo sempre aggiornato: in fase di rebase adatto gli script che danno conflitto perche' modificati contemporaneamente su SBo e nei miei branch.
esempi di configurazione di repository git in sbopkg li puoi trovare nei file /etc/sbopkg/repos.d/60-SBo-current.repo e /etc/sbopkg/repos.d/90-SBo-master.repo.
il consiglio e' quello di fare un fork del ramo master git di SBo e fare anche solo un branch basato su master di cui fai il rebase ogni settimana (a branch separati comunque, secondo me, il rebase e' piu' gestibile).

senno' ti puoi fare un repository locale dove cancelli gli script di SBo che modifichi e metti al loro posto i tuoi custom ma comunque dovresti controllare in qualche modo, come notavi sopra, se quelli che cancelli nel frattempo sono cambiati (in modo da applicare, eventualmente, le modifiche anche ai tuoi custom)...

usare piu' repository allo stesso tempo con sbopkg impostando una priorita' non credo si possa fare (puoi chiedere eventualmente conferma al maintainer).

[joe]

Grazie Ponce!
Ieri sera mi sono rivisto un po' meglio git e in particolare il "rebase". Non usandolo tutti i giorni, avevo intuito quanto spiegavi ma dovrei provare in pratica, così salteranno fuori eventuali dubbi.

Riepilogo i miei obiettivi:

1. usare sbopkg per ricompilare/aggiornare l'intero set SBo presente sul sistema in seguito ad un aggiornamento massivo di pacchetti ufficiali (come è la mia situazione al momento), il tutto tenendo in conto dei pacchetti "custom" originariamente sì presi da SBo, ma modificati me
2. ottenere dopo questa procedura un sistema aggiornato col repo ufficiale e anche con SBo (fatti salvo i pacchetti customizzati ovviamente, i quali eventualmente potrò decidere di passarli ad una eventuale versione più recente presente su SBo, ma comunque editati e rimaneggiati da me)
3. rifare la stessa procedura dopo tot mesi, anche a prescindere da quello che fa Pat, inclusi aggiornamenti di sicurezza.
4. usare nel frattempo sbopkg per installare eventuali software o aggiornarne eventuali altri di cui per qualche santo me ne serva una versione più recente che nel frattempo anche su SBo hanno preparato, senza dover per questo (nel limite del possibile) ricompilare tutto il set di 440 pacchetti SBo che ho sul sistema al momento.
5. in questa situazione ordinaria (tra un aggiornamento totale e l'altro) disporre di un set di pacchetti SBo installati, potenzialmente non aggiornato con la situazione corrente del repo master SBo, ma comunque funzionante

Quello che vorrei evitare è che facendo il rebase mi venga notificata la necessità di metter mano (perché incoerenti, magari anche solo per versione cambiata dal mio branch "custom" al "master") a mille pacchetti che magari non ho neanche installati. La notifica mi serve solo per i pacchetti che effettivamente ho customizzato sul mio branch "custom"... e neanche ogni volta...
Esempio:
se volessi ad esempio aggiornare "qbittorrent" (di cui uso lo slackbulid ufficiale SBo) perché vedo che su SBo ce n'è una versione più recente di quella installata e mi interessa provarla... in quel caso dovrei fare il "rebase" immagino giusto?
Perché sincronizzerò il branch master con quello remoto e poi però voglio piazzarci sopra il mio branch "custom"... se sbaglio correggi pure eh.
La cosa è accettabile, e nel farlo dovrei quindi controllare i miei script customizzati (ad esempio mpv).
Quello che invece non vorrei dover controllare sono le eventuali discrepanze tra il resto del set di pacchetti dei quali mi va bene che siano sincronizzati col branch master remoto e stop.

La procedura funziona effettivamente così oppure c'è da sbattersi di più ogni volta che si vuole sincronizzare il repo master?

[ponce]

la procedura proposta comportera' di mettere mano solo agli script che hai modificato perche' gli altri saranno aggiornati senza problemi.

tieni di conto pero' che non e' detto che quando aggiorni il sistema operativo o qualche script di SBo tu non debba fare ricompilazioni massive: puo' capitare che in seguito agli aggiornamenti del sistema operativo (ad esempio quello recente di libxml2) o a quelli di alcuni script di SBo (ad esempio mi vengono a mente quelli di fmt) tu debba ricompilare tanta roba.
ovviamente finche "congeli" tutto a una determinata versione del S.O. e del repository SBo dovresti essere relativamente tranquillo, ma non pensare di fare "cherry-picking" di aggiornamenti in /patches o di script nuovi su SBo e che ti vada sempre bene...

comunque, per stare sul sicuro, installa un virtualizzatore e fai le tue ricompilazioni all'interno di macchine virtuali che tieni sempre aggiornate senza nessun pacchetto da SBo, cosi' quando ricompili i pacchetti parti sempre dal pulito (ovviamente tenendo una copia del file immagine della macchina virtuale precedente alle compilazioni).

[joe]

Sì ho capito, insomma comunque la si guardi per dirla in francese è un gran casino...

Compilazioni in virtuale non se ne parla su questo ferro vecchio. Calcola che ho un vetusto quad core (sì, ma core duo!!) e 4GB di ram.
Ho una partizioncina che avevo utilizzato proprio per testare roba del genere, ma capirai bene la scomodità... perché mentre macina praticamente non posso utilizzare il solito ambiente cui son abituato.
Va be' non è questa la sede per consigli sull'hardware, anche lì ne avrei da chiedere!
Magari ne riparliamo in un topic a parte... Certo per un approccio così pesantemente "ricompilativo" nella gestione del sistema sarebbe utile sicuramente qualche consiglio per capire con cosa svecchiare il comparto hardware.

Mettiamo di aver sistemato il discorso repository locale e di averlo bello lindo e pinto aggiornato e customizzato.
E mettiamo a questo punto di voler ricompilare tutti i pacchetti SBo installati sul sistema.
Come creiamo la coda totale dei pacchetti in modo che siano costruiti ed installati nel giusto ordine, così da rispettare le varie dipendenze?

Io ricordo che vi era un tool chiamato horex, mi ero informato anni fa, con l'idea di applicare la procedura al ramo current col tuo repo git... poi fortunatamente Pat aveva rilasciato la 15.0 e alla fine avevo lasciato perdere, facendo tabula rasa dei pacchetti SBo e reinstallando pian piano quelli che mi servivano. Però il tarlo di configurare una procedura per gestire l'operazione in modo più automatico e sperabilmente affidabile m'è rimasto.
In questo senso tu come ti organizzi? O meglio come consiglieresti di organizzarmi visti gli scopi?

[ponce]

sbopkg viene fornito con un tool scritto sempre da Chess Griffin che si chiama sqg.

mettiamo di voler installare vlc: con sbopkg configurato e col suo repository sincronizzato da una console do il comando

Codice: Seleziona tutto

sqg -p vlc

questo comando genera il file /var/lib/sbopkg/queues/vlc.sqf: vediamone il contenuto

Codice: Seleziona tutto

protobuf3
libnfs
x265
x264
chromaprint
libminizip
schroedinger
libdvdcss
rtmpdump
live555
ORBit2
libbonobo
gnome-mime-data
gnome-vfs
dirac
vcdimager
libreplaygain
libcuefile
musepack-tools
libmodplug
libavc1394
faad2
zvbi
libsidplay2
jack
projectM
libdaemon
avahi
libshout
libdca
faac
libkate
libtar
gsm
twolame
portaudio
lua
libmpeg2
libdvbpsi
libdc1394
libass
vlc

ora, usando l'utility sqg il contenuto dei file *.info ricorsivamente, nel file troverai solo le dipendenze obbligatorie, per quelle opzionali devi leggere il README dei vari script e questo continua a rimanere a carico tuo.

mettiamo che tu voglia compilare anche mixxx, ardour e audacity: lanci il comando sqg anche per loro e alla fine

Codice: Seleziona tutto

# cat /var/lib/sbopkg/queues/mixxx.sqf 
vamp-plugin-sdk
ladspa_sdk
rubberband
protobuf3
portmidi
portaudio
opencore-amr
serd
sord
lv2
sratom
python3-flit_core
python3-installer
python3-wheel
python3-pyproject-hooks
python3-build
python3-meson-opt
python3-pyproject-metadata
python3-mesonpy
python3-numpy
lilv
libshout
libmp4v2
libmodplug
hidapi
faad2
chromaprint
mixxx
# cat /var/lib/sbopkg/queues/ardour.sqf 
vst3sdk
serd
sord
lv2
sratom
python3-flit_core
python3-installer
python3-wheel
python3-pyproject-hooks
python3-build
python3-meson-opt
python3-pyproject-metadata
python3-mesonpy
python3-numpy
lilv
cwiid
suil
vamp-plugin-sdk
ladspa_sdk
rubberband
raptor
liblrdf
liblo
jack
aubio
ardour
# cat /var/lib/sbopkg/queues/audacity.sqf 
wxWidgets
serd
sord
lv2
suil
soxr
rapidjson
portsmf
portmidi
portaudio
sratom
python3-flit_core
python3-installer
python3-wheel
python3-pyproject-hooks
python3-build
python3-meson-opt
python3-pyproject-metadata
python3-mesonpy
python3-numpy
lilv
libsbsms
audacity

proviamo a creare una coda unica concatenando tutti questi file

Codice: Seleziona tutto

cd /var/lib/sbopkg/queues/
cat vlc.sqf mixxx.sqf ardour.sqf audacity.sqf | /root/bin/unico.sh > lamiacoda.sqf

faccio processare la lista risultante a uno script che ho fatto io che ho chiamato unico.sh perche' concatenando le code alcuni script sarebbero richiamati piu' volte: questo in realta' non e' un problema per sbopkg perche' se in una coda uno script e' chiamato piu' volte lo compila una volta sola (la prima), pero' a me piace avere una lista ordinata e pulita.
il contenuto dello script unico.sh e' questo (lascia perdere che poteva essere scritto meglio )

Codice: Seleziona tutto

i=0

while read line; do
  list[i]="$line"
  ((i=i+1))
done < "${1:-/dev/stdin}"

elements=${#list[@]}
k=0
b[$k]=""

for (( i=0 ; i<$elements ; i++ ))
do
  canary=0
  for j in "${b[@]}" ; do
    if [ "$j" = "${list[i]}" ]; then canary=1 ; fi
  done
  if [ $canary -eq 0 ] ; then b[$k]="${list[i]}" ; ((k=k+1)) ; fi
done

printf '%s\n' "${b[@]}"

il risultato e' questo file di coda

Codice: Seleziona tutto

protobuf3
libnfs
x265
x264
chromaprint
libminizip
schroedinger
libdvdcss
rtmpdump
live555
ORBit2
libbonobo
gnome-mime-data
gnome-vfs
dirac
vcdimager
libreplaygain
libcuefile
musepack-tools
libmodplug
libavc1394
faad2
zvbi
libsidplay2
jack
projectM
libdaemon
avahi
libshout
libdca
faac
libkate
libtar
gsm
twolame
portaudio
lua
libmpeg2
libdvbpsi
libdc1394
libass
vlc
vamp-plugin-sdk
ladspa_sdk
rubberband
portmidi
opencore-amr
serd
sord
lv2
sratom
python3-flit_core
python3-installer
python3-wheel
python3-pyproject-hooks
python3-build
python3-meson-opt
python3-pyproject-metadata
python3-mesonpy
python3-numpy
lilv
libmp4v2
hidapi
mixxx
vst3sdk
cwiid
suil
raptor
liblrdf
liblo
aubio
ardour
wxWidgets
soxr
rapidjson
portsmf
libsbsms
audacity

a questo punto faccio

Codice: Seleziona tutto

sbopkg -i lamiacoda

[joe]

Ponce, grazie per l'indicazione.
Anch'io ho messo mano ad uno script per gestire le code, però mi serve per tutti i pacchetti installati, nell'ottica di voler eseguire il build di tutto quanto.
In questo caso la situazione è leggermente più complessa. Ad esempio ci sono pacchetti installati non più presenti su SBo.
Ad esempio io ho "wheel" sul sistema, mentre sul repo è stato rimosso ed al suo posto c'è "python3-wheel".
Queste informazioni si vedono dal Changelog.txt del repo/branch. Altri esempi:

Codice: Seleziona tutto

# grep "\/python3-pep517:" /var/lib/sbopkg/SBo/15.0/ChangeLog.txt
python/python3-pep517: Removed: (replaced by python3-pyproject-hooks)
python/python3-pep517: Added (API to call PEP 517 hooks).

# grep "\/hack-font-ttf:" /var/lib/sbopkg/SBo/15.0/ChangeLog.txt
system/hack-font-ttf: Removed (added to Slackware).

# grep "\/wheel:" /var/lib/sbopkg/SBo/15.0/ChangeLog.txt
development/wheel: Removed: (replaced by python3-wheel)
development/wheel: Updated for version 0.37.1.
development/wheel: Removed redundant doinst.sh.

In pratica, il repo SBo, giustamente è "vivo" e quando si crea la coda totale di rebuild occorre un controllo in più, non entro nel dettaglio ma diciamo che se si parte dai pacchetti _SBo installati, sin incappa in queste discrepanze tra la situazione locale e quella del repo remoto aggiornato.

Inoltre ho notato una cosa banale: se un pacchetto SBo non dipende da altri pacchetti SBo, è "senza coda". Per cui se ci si limita a concatenare le code, quel pacchetto non farà parte della lista finale. O meglio, ne farà parte se da lui dipendono altri pacchetti, in quel caso lo si ritroverà nella loro coda sqf, altrimenti se non ha dipendenze e non è dipendenza di altri, sfuggirà alla semplice concatenazione delle code.
Come soluzione ho utilizzato "comm", per fare delle intersezioni tra varie liste di pacchetti, da quella degli installati a quella della concatenazione code ecc... rispettando però l'ordine di dipendenza dei pacchetti in coda.

Insomma, se ne viene fuori una roba utile vi aggiornerò, così magari si commenta.

[ponce]

te ne dico un'altra che non ricordavo (perche' non ho mai usato come opzione) ma che e' documentata anche in /usr/doc/sbopkg-0.38.2/README-queuefiles: puoi anche non creare un file di coda unico con tutti gli script ma lasciare separato per applicazioni.
nell'esempio di sopra il file unico lamiacoda puo' anche essere scritto come

Codice: Seleziona tutto

@vlc
@mixxx
@ardour
@audacity

dove @mixxx dentro al file di coda vuol dire che in quel punto, quando elabora la coda, deve includere un altro file di coda /var/lib/sbopkg/queues/mixxx.sqf.

questo approccio puo' tornare comodo per mantenere le code separatamente e, secondo come, puo' anche creare meno confusione...

[joe]

Non saprei, perché se due code contengono pacchetti in comune, non dovrebbero venire processati due volte come osservavi prima, ma mi sembra più ordinato avere la lista effettiva dei singoli pacchetti che si vogliono lavorare in sequenza. Se non altro per fare poi controlli di vario genere... magari sbaglio eh...

Sto preparando uno script bash per lo scopo del rebuild totale, poi pensavo quasi di clonare la mia partizione root su altro SSD che ho a disposizione, sistemare grub e provare il rebuild avviando dal sistema clone senza paura di scompigliare il sistema in uso. Vedo cosa salta fuori e quando avrò fatto riporterò i dettagli.