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
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
|
+++
title = "Templates Slackware per i pacchetti"
author = "Danilo M."
type = "tech"
date = "2026-05-11T18:51:37+02:00"
draft = true
excerpt = "slackpkg e la gestione delle dipendenze in slackware."
image = "/uppies/2026/05/water-02-1024x768.jpg"
tags = ["linux", "howto", "do it yourself"]
categories = ["Code", "DIY"]
+++
Slackware è fantastica per gestire il sistema in quanto ti permette di modificare facilmente qualsiasi cosa, semplicemente andando a cambiare un valore in un file di testo.
Slackware è un po' meno fantastica quando devi andare ad installare un pacchetto per un software che si porta dietro svariate dipendenze :sweat:. Non ha di default la gestione automatica delle dipendenze e quindi tutto il lavoro ricade sull'utente che gestisce il sistema.
Lo stesso discorso vale per la compilazione dei pacchetti, infatti non gestendo le dipendenze, anche in fase di compilazione bisogna fare tutto a manina, compilando i pacchetti nel giusto ordine per poter ottenere il software che ci interessa installare.
## SlackRepo
per risolvere quest'ultimo problema, esistono software come [sbopkg](https://www.sbopkg.org/) che permettono di generare delle code di compilazione per andare a compilare nel corretto ordine i pacchetti necessari al software che ci interessa.
Uno step ulteriore rispetto a sbopkg, lo fa **slackrepo**, software di cui ho già parlato nel mio [articolo sulla gestione dei pacchetti nel 2026](../manage-slackware-packages-2026/), in quanto permette anch'esso di compilare i pacchetti nell'ordine corretto rispetto alle dipendenze di ogni singolo programma, ma in più, va ad installare le dipendenze già compilate di volta in volta per poi rimuoverle una volta finita la compilazione del software che la richiedeva.
La funzionalità più interessante di slackrepo è però la possibilità di accodare all'esecuzione del programma degli "hook", ovvero di eseguire del codice che non fa parte di slackrepo, per estenderne le funzionalità. In particolare nel mio setup, io uso diversi hook:
- aggiorno il repository via git eseguendo il rebase di volta in volta.
- genero i file html che vengono poi inseriti nel [repository](https://packages.danix.xyz/).
- genero i files .template per quei software che hanno una o più dipendenze
- carico i files sul repository usando rsync.
{{< actions url="https://packages.danix.xyz" desc="I miei pacchetti" use="site" caption="Il mio repository di pacchetti per slackware64-current" >}}
### hook "git fetch"
questo hook si occupa di aggiornare il repository locale clonando il git di Ponce (sono su *-current*), poi esegue il rebase e interrompe l'esecuzione in caso ci siano dei conflitti, così so se qualche mio pacchetto personale contrasta con quelli di SBo. In caso di conflitti posso andare a risolvere eliminando il mio pacchetto o quello ufficiale a seconda delle situazioni.
```bash
function danix_gitfetch_hook
{
local upstream_branch='current'
local personal_branch='danix-current'
cd "$SR_SBREPO" || return 1
local currbranch
currbranch=$(git rev-parse --abbrev-ref HEAD)
if [ "$currbranch" != "$personal_branch" ]; then
echo "slackrepo: WARNING: SBREPO is on branch '$currbranch', expected '$personal_branch'. Skipping git update."
return 0
fi
local muck
muck=$(git status -s .)
if [ -n "$muck" ]; then
echo "slackrepo: WARNING: SBREPO has uncommitted changes. Skipping git update."
return 0
fi
echo "slackrepo: Fetching upstream SBo..."
git fetch origin || { echo "slackrepo: WARNING: git fetch failed."; return 1; }
echo "slackrepo: Rebasing $personal_branch onto origin/$upstream_branch..."
git rebase --rebase-merges -X theirs origin/"$upstream_branch" || {
echo "slackrepo: ERROR: rebase failed. Resolve conflicts in $SR_SBREPO and run 'git rebase --continue'."
return 1
}
return 0
}
```
### hook "gen web files"
Questo hook si occupa di lanciare il mio script `gen_web_hook.sh` (visibile sul [mio git](https://git.danix.xyz/pkgs-html-structure/tree/gen_web_hook.sh)) per generare i file html che verranno poi caricati online nel repository dei pacchetti e che servono per la visualizzazione del repo online.
```bash
function gen_web_hook
{
if [ "$OPT_DRY_RUN" = 'y' ] || [ ! -s "$CHANGELOG" ]; then
return 0
fi
SR_PKGREPO="$SR_PKGREPO" /usr/local/bin/gen_web_hook.sh
local stat=$?
[ $stat -ne 0 ] && log_warning "gen_web_hook failed, status $stat"
return $stat
}
```
{{< actions url="https://git.danix.xyz" desc="Il mio repository git" use="repo" caption="Dai un'occhiata al mio codice sul repo git." >}}
### hook "template generator"
Ecco la funzione che si occupa di generare i files .template usati da slackpkg per installare i pacchetti.
```bash
function dep_template_hook
{
local template_dir="${TEMPLATE_DIR:-/repo/templates}"
[ "$OPT_DRY_RUN" = 'y' ] && return 0
[ ${#OKLIST[@]} -eq 0 ] && return 0
mkdir -p "$template_dir" || return 1
local itemid prgnam dep depname outfile
for itemid in "${OKLIST[@]}"; do
[ -z "${FULLDEPS[$itemid]}" ] && continue
prgnam="${ITEMPRGNAM[$itemid]}"
outfile="$template_dir/${prgnam}.template"
{
for dep in ${FULLDEPS[$itemid]}; do
depname="${ITEMPRGNAM[$dep]}"
printf '%s\n' "${depname:-$dep}"
done
printf '%s\n' "$prgnam"
} > "$outfile"
log_normal "dep_template_hook: wrote $outfile"
done
return 0
}
```
### hook "rsync push"
Infine l'hook che si occupa di caricare i files modificati sul mio repository online:
```bash
function rsync_push_hook
{
# RSYNC_TARGET/RSYNC_EXCLUDES are unset by slackrepo after config sourcing;
# use hardcoded values here since they can't be passed via SR_ prefix mechanism.
local rsync_target='<SERVER_RSYNC>'
local rsync_excludes='<FILES_ESCLUSI.txt>'
local rsync_password_file='<PASSWORD_SERVER_RSYNC>'
if [ "$OPT_DRY_RUN" = 'y' ] || [ ! -s "$CHANGELOG" ]; then
return 0
fi
local rsync_bin
rsync_bin=$(which rsync 2>/dev/null)
if [ ! -x "$rsync_bin" ]; then
log_warning "rsync not found, skipping rsync_push_hook"
return 1
fi
local args=( -havz --delete-after )
[ -n "$rsync_excludes" ] && [ -f "$rsync_excludes" ] && \
args+=( --exclude-from="$rsync_excludes" )
[ -f "$rsync_password_file" ] && args+=( --password-file="$rsync_password_file" )
log_normal "Pushing packages to $rsync_target ..."
"$rsync_bin" "${args[@]}" "$SR_PKGREPO"/ "$rsync_target"
local rsyncstat=$?
if [ "$rsyncstat" != 0 ]; then
log_warning "rsync_push_hook failed, status $rsyncstat"
return 1
fi
log_normal "rsync push complete."
return 0
}
```
## I file .template e slackpkg
Alla fine della compilazione di un software che ha qualche dipendenza, nel mio repository, verrà generato il file `<nome_pacchetto>.template`, che potrò copiare in `/etc/slackpkg/templates` e richiamare con:
```bash
slackpkg install-template nome_pacchetto
```
e slackpkg andrà automaticamente a propormi di installare anche tutte le dipendenze elencate nel template, di fatto semplificando molto la gestione delle dipendenze.
Un esempio di template, direttamente dal mio repository è [waybar.template](https://packages.danix.xyz/templates/waybar.template):
```
date
jsoncpp
Catch2
spdlog
waybar
```
Spero che quest'articolo possa tornare utile a qualcuno, anche solo come spunto per semplificare un po' la vita :wink:
{{< actions url="/it/is/here/" desc="Scrivimi" use="site" caption="Se hai dei commenti, lasciami pure un messaggio" >}}
|
