1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
|
+++
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:
|
