Gestire pacchetti in Slackware nel 2026

Ormai scrivo soltanto articoli su vari workflow che ho implementato e migliorato col tempo per gestire vari aspetti della mia giornata al pc 😎

Oggi tocca al workflow che seguo per gestire i miei pacchetti per Slackware. Il repository lo potete trovare in alto nel menu, oppure cliccando sul pulsante quì sotto:

// I miei repo

La maggior parte degli script che scrivo seguono gli standard di slackbuilds.org, tranne dove sia impossibile applicarli. Gestisco i repository degli slackbuild su github, dove mantengo:

• un repository di pacchetti personali (pacchetti che non sono su SBo o che hanno flag di compilazione particolare, sorgenti da repository git, ecc…)
• un repository di pacchetti incentrati sulla cybersecurity, con alcuni pacchetti pubblicati da me o da altri su SBo, altri invece solo sul repo personale.

// Compilare i pacchetti

Per la compilazione dei pacchetti uso 2 VM distinte, una su cui gira slackware64-current e una su cui gira slackware64 15.0, entrambe mantenute aggiornate e con i repository di SBo, oltre ad un clone locale dei miei 2 repo, ovviamente.

La macchina virtuale con la slackware -stable la uso soltanto per testare la compilazione di quei pacchetti che decido di pubblicare su SBo, più che altro per verificare le dipendenze e che la compilazione vada a buon fine.

La macchina con la -current, invece è quella che utilizzo più spesso, in quanto è quella che genera i pacchetti che uso anche sul mio pc fisso; gli stessi pacchetti che poi pubblico su packages.

Per la compilazione dei pacchetti mi affido a slackrepo, un programma originariamente scritto da David Spencer (aka idlemoor), e il cui sviluppo è stato ripreso recentemente da Andrew Clemons (aka aclemons). Grazie a slackrepo posso compilare in maniera pulita anche pacchetti complessi in quanto utilizza chroot per installare le dipendenze necessarie e una volta compilati i pacchetti tramite degli hook posso fargli eseguire altri script che mi generano i file del repository e caricano i file direttamente sul mio spazio web.

// Il repo per slackrepo

Slackrepo permette di gestire dei repository di slackbuilds come quello di SBo, o come quello per -current gestito da Matteo Bernardini (aka Ponce). Io in particolare clono il repo per current, ne creo un branch locale, ci inserisco i miei 2 repository come submodules e poi elimino i pacchetti che andrebbero in conflitto, faccio un rebase con le mie modifiche mantenendo tutto in locale e su questo repo modificato faccio operare slackrepo.

// Il setup iniziale è questo:

1
2
3
4

git clone https://github.com/Ponce/slackbuilds.git /var/lib/sbopkg/SBo-danix
cd /var/lib/sbopkg/SBo-danix
git checkout current
git checkout -b danix-current

Poi aggiungo i miei repo personali:

1
2
3
4

git remote add my-slackbuilds https://github.com/danixland/my-slackbuilds.git
git remote add my-pentesting https://github.com/danixland/Slackware-Pentesting-Suite.git
git subtree add --prefix=personal my-slackbuilds main --squash
git subtree add --prefix=pentesting my-pentesting main --squash

in modo da avere i miei repo come sotto-directory personal/ e pentesting/.

// Operazioni giornaliere

Ho un hook per slackrepo che fa ogni volta:

1
2
3

cd /var/lib/sbopkg/SBo-danix
git fetch origin
git rebase --rebase-merges -X theirs origin/current

l’opzione --rebase-merges si assicura che i miei files rimangano all’interno delle sottocartelle in cui li ho destinati, mentre -X theirs auto risolve eventuali conflitti nel file .gitignore in favore della mia versione così che il rebase non venga bloccato.

Se nel corso della giornata ho caricato delle modifiche su uno dei miei repository su github, mi basterà fare:

1
2

cd /var/lib/sbopkg/SBo-danix
git subtree pull --prefix=personal my-slackbuilds main --squash

per recuperare le modifiche nella mia VM.

// Gestione dei conflitti

siccome mantengo pacchetti nei miei repo personali, che sono presenti su SBo, devo evitare di avere duplicati così che slackrepo sappia sempre dove prendere i sorgenti per i pacchetti che devo compilare.

// Version bump

Se un pacchetto va semplicemente aggiornato, mi basta creare un hintfile per slackrepo con la nuova versione, il nuovo link di download e il md5sum aggiornato e slackrepo compilerà il pacchetto con la mia versione, senza bisogno di aspettare che il maintainer aggiorni su SBo.

Un hintfile è basato sul file .info per quel pacchetto e ne sovrascrive le informazioni:

1
2
3
4

# /etc/slackrepo/SBo-danix/hintfiles/development/hugo/hugo.hint
VERSION="0.159.2"
DOWNLOAD_x86_64="https://github.com/gohugoio/hugo/releases/download/v0.159.2/hugo_extended_0.159.2_Linux-64bit.tar.gz"
MD5SUM_x86_64="a3e27d4b2049a710dbe7d7c1954a827e"

// SlackBuild fix

Se invece ho bisogno di modificare più a fondo lo SlackBuild di un pacchetto, ne farò una copia nel mio repository personale, e rimuoverò la copia di SBo

1
2
3

cd /var/lib/sbopkg/SBo-danix
git rm -r category/pkgname
git commit -m "pkgname: shadow with fixed version from personal/"

senza bisogno di un push su git, lavoro su un branch locale personale. Quando da upstream Ponce aggiorna il pacchetto in questione, al rebase vedrò un conflitto, e potrò verificare se l’aggiornamento è stato inserito e rimuovere la mia versione personale in favore di quella di upstream.

1
2
3

git rm -r personal/pkgname
git commit -m "pkgname: drop local shadow, fix merged upstream"
git subtree push --prefix=personal my-slackbuilds main

Per quanto riguarda la gestione di base questo è tutto, nel prossimo articolo vedremo come gestire un repository di pacchetti locale e remoto usando alcuni shell script molto comodi.

A presto 😉