content: add Package buildsystem Slackware pageHEADrelease_04072026-1101productionmaster

New bilingual system/architecture page narrating the whole
slackware64-current build pipeline: the QEMU VM, repo assembly
(slackrepo_setup), the phantom-dep hint layer (mkhint), building
(slackrepo, aclemons fork), publishing (finish hooks +
pkgs-html-structure), and the separate 15.0 stable-testing safety
net (sbo-batch-tester). Includes a theme-styled SVG pipeline
flowchart, three inline repo CTAs, and a closing sign-off.
Menu entry under the Slackware parent (weight 20). Spec and plan
updated to match.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

1 files changed, 128 insertions, 0 deletions

diff --git a/content/it/slackware/buildsystem/index.md b/content/it/slackware/buildsystem/index.md
new file mode 100644
index 0000000..7b02412
--- /dev/null
+++ b/content/it/slackware/buildsystem/index.md
@@ -0,0 +1,128 @@
++++
+title    = "Package buildsystem"
+tagline  = "Come costruisco e pubblico il mio repository personale di pacchetti per slackware64-current."
+status   = "active"
+tags     = ["slackware", "slackrepo", "packaging", "buildsystem"]
+
+[menus.main]
+  name   = "buildsystem"
+  parent = "slackware"
+  weight = 20
++++
+
+I miei pacchetti Slackware personali per **slackware64-current** sono costruiti da
+una piccola pipeline di strumenti che gira dentro un'unica macchina virtuale QEMU
+dedicata. Niente qui è un singolo programma: c'è un repository che viene
+riassemblato, uno strato di dipendenze che viene corretto, un builder che
+trasforma gli SlackBuild in pacchetti e un passo di pubblicazione che li mette
+online su [packages.danix.xyz](https://packages.danix.xyz). Questa pagina segue
+l'intero flusso nell'ordine in cui una build avviene davvero.
+
+{{< image src="buildsystem-flow.svg" alt="Diagramma di flusso del buildsystem: assemblaggio del repository con slackrepo_setup, correzione delle dipendenze -current con mkhint, build con slackrepo e pubblicazione tramite gli hook finali, con un ramo laterale verde separato per il test su Slackware 15.0 stable prima dell'invio a SBo." caption="La pipeline dall'inizio alla fine. Il ramo laterale verde è il test su 15.0 stable, eseguito solo per i pacchetti diretti a SlackBuilds.org." />}}
+
+## La VM
+
+Il buildsystem vive in una macchina virtuale QEMU che esegue
+**slackware64-current**, tenuta aggiornata con `slackpkg` da un mirror locale dei
+pacchetti di sistema di Slackware. Ha 8 core CPU e circa 8 GB di RAM, abbastanza
+per compilare comodamente tutti i pacchetti tranne i più pesanti, e vi accedo via
+SSH. Tenerla in una VM dedicata fa sì che una build, una dipendenza rotta o una
+rigenerazione completa del repository non tocchino mai la mia macchina di tutti i
+giorni: quella scatola esiste per essere martellata e, se serve, buttata via e
+ricostruita.
+
+## Assemblare il repository
+
+Una volta a settimana l'albero degli SlackBuild viene rigenerato da zero. Parte
+come clone degli [slackbuilds di Ponce](https://github.com/Ponce/slackbuilds) sul
+branch `current`, l'albero della community che segue SlackBuilds.org su
+slackware-current. Sopra vi sovrappongo le mie due collezioni come git subtree
+compressi: [my-slackbuilds](https://github.com/danixland/my-slackbuilds) per i
+pacchetti personali generici e
+[Slackware-Pentesting-Suite](https://github.com/danixland/Slackware-Pentesting-Suite)
+per gli strumenti di sicurezza.
+
+Dove un pacchetto personale condivide il nome con uno upstream, la copia upstream
+viene *oscurata*: la sua directory viene rimossa perché vinca la mia versione. Il
+risultato è un unico albero locale che è SBo standard più le mie aggiunte, pronto
+per la build. Tutto questo assemblaggio è uno script, che avrà una sua pagina qui
+più avanti.
+
+## Il problema delle dipendenze su -current
+
+Gli SlackBuild di SBo puntano a Slackware **stable**, quindi alcune delle loro
+dipendenze di compilazione sono inutili su -current, che le fornisce già come
+pacchetti di sistema o in versioni più recenti. `rust-opt` e `google-go-lang` sono
+tipiche: servono su stable, sono superflue su -current. Queste dipendenze
+"fantasma" costringerebbero altrimenti a ricompilazioni inutili.
+
+slackrepo rimuove una dipendenza da un pacchetto con un hint file per pacchetto che
+contiene `DELREQUIRES`, ma scriverne uno a mano per ogni pacchetto interessato
+dopo ogni rigenerazione settimanale è proprio la noia di cui uno script dovrebbe
+farsi carico. Quel compito spetta a [mkhint](/it/slackware/mkhint/): il suo sweep
+`-F` legge una lista di dipendenze fantasma e, per ogni pacchetto le cui dipendenze
+ne toccano una, scrive o unisce il `DELREQUIRES` giusto in tutto l'albero appena
+ricostruito, in un solo passaggio.
+
+{{< actions use="repo" url="https://git.danix.xyz/mkhintfile/" desc="Leggi il sorgente di mkhint" caption="Curioso di come funziona davvero lo sweep delle dipendenze fantasma? È tutto un singolo script Bash." >}}
+
+## La build
+
+La compilazione vera e propria è affidata a
+[slackrepo](https://github.com/aclemons/slackrepo), un builder automatico di
+SlackBuild per Slackware, ora mantenuto da Andrew Clemons. Compila ogni pacchetto e le sue dipendenze in un chroot
+pulito, segue le revisioni git upstream per capire cosa è cambiato e va
+ricostruito, e produce un repository che si aggancia direttamente a `slackpkg+`.
+Lo eseguo con un hook iniziale che prima ribasa il mio albero di SlackBuild su
+upstream, così ogni build parte da un albero aggiornato, e gestisce l'ordine delle
+dipendenze in modo che un singolo comando ricostruisca tutto ciò che si è mosso.
+
+## Pubblicazione
+
+Quando una build finisce, subentra una catena di hook finali di slackrepo.
+Rigenerano i metadati del repository per `slackpkg+`, costruiscono il frontend HTML
+a tema per il sito dei pacchetti, sincronizzano il risultato sul server live e
+inviano una notifica di fine esecuzione. Il frontend avvolge il semplice autoindex
+delle directory di Apache in un header e un footer a tema, così
+[packages.danix.xyz](https://packages.danix.xyz) si legge come un vero repository e
+non come un nudo elenco di file. Anche quel frontend è un suo piccolo progetto e
+avrà una pagina qui più avanti.
+
+{{< actions use="repo" url="https://git.danix.xyz/pkgs-html-structure/" desc="Guarda il generatore del frontend" caption="È soprattutto un hook shell che percorre l'albero dei pacchetti e scrive l'HTML di header e footer. Dai un'occhiata sotto il cofano." >}}
+
+## Test contro 15.0 stable
+
+Alcuni dei pacchetti che scrivo sono destinati a essere proposti a monte su
+SlackBuilds.org, che punta a Slackware **stable**, non a -current. Dato che tutto
+il mio buildsystem è -current, il fatto che un pacchetto compili bene qui non dice
+nulla su 15.0. Prima di proporne uno, lo testo con uno strumento separato e
+indipendente pensato esattamente per questo: risolve localmente l'albero delle
+dipendenze dello SlackBuild, poi costruisce e installa ogni pacchetto in un chroot
+overlay usa e getta stratificato su una base Slackware 15.0 pulita e in sola
+lettura. Così emerge lo scostamento tra -current e 15.0 che una build su -current
+nasconde.
+
+Non tocca né guida slackrepo, e i pacchetti che produce sono usa e getta: l'unica
+domanda a cui risponde è "compila ancora pulito su 15.0". Un limite da segnalare:
+condivide il kernel dell'host, quindi i pacchetti che costruiscono moduli del
+kernel vogliono comunque una vera VM 15.0. Anche questo strumento avrà la sua
+pagina qui col tempo.
+
+{{< actions use="repo" url="https://git.danix.xyz/sbo-batch-tester/" desc="Esplora sbo-batch-tester" caption="La logica dell'overlay-chroot e della risoluzione delle dipendenze è qui, se vuoi leggere come è costruito il test su 15.0." >}}
+
+## Il ritmo settimanale
+
+Messo insieme, la settimana è un unico ciclo ripetibile: rigenerare l'albero degli
+SlackBuild, spazzare gli hint delle dipendenze fantasma con `mkhint -F`, costruire
+e pubblicare con slackrepo e i suoi hook e, per tutto ciò che è diretto a
+SlackBuilds.org, testarlo prima contro una base 15.0 pulita. Quattro piccoli
+strumenti, ciascuno che fa bene un solo lavoro, e una VM usa e getta in cui
+eseguirli. Molto Slackware.
+
+Spero che questo giro nel mio buildsystem ti sia sembrato interessante. Se
+finisci per metterne in piedi uno simile, o hai domande, idee o suggerimenti su
+qualunque suo pezzo, scrivimi due righe e sarò felice di risponderti.
+
+Alla prossima.
+
+{{< actions use="repo" url="https://packages.danix.xyz" desc="Sfoglia il repository dei pacchetti" caption="Tutto ciò che il buildsystem produce finisce qui. Se usi slackware64-current, puoi puntarci slackpkg+ e tirare dentro i miei pacchetti direttamente." >}}