+++
title = "Gestire pacchetti in Slackware nel 2026"
date = "2026-05-04"
type = "tech"
image = "/uppies/2026/05/ascii-1920x1080.png"
excerpt = "Il mio workflow aggiornato per gestire i pacchetti in Slackware64 current"
tags = ["linux", "git"]
categories = ["Code", "DIY"]

+++

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

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:

{{< Actions url="https://packages.danix.xyz" desc="packages.danix.xyz" use="site" caption="Il mio repository di pacchetti per Slackware" >}}

## I miei repo

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

- un repository di [pacchetti personali](https://github.com/danixland/my-slackbuilds) (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](https://github.com/danixland/Slackware-Pentesting-Suite), 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**.

{{< callout type="warning" >}}
I pacchetti presenti nel [mio repository](https://packages.danix.xyz) sono tutti compilati per slackware64-current e non funzioneranno su slackware64-stable.
{{< /callout >}}

Per la compilazione dei pacchetti mi affido a [slackrepo](https://github.com/aclemons/slackrepo), un programma originariamente scritto da [David Spencer](https://github.com/idlemoor/) (aka idlemoor), e il cui sviluppo è stato ripreso recentemente da [Andrew Clemons](https://github.com/aclemons) (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](https://github.com/Ponce/) (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:

```bash 
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:

```bash
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:

```bash
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:

```bash
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:

```sh
# /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

```bash
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.

```bash
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 :wink: