Shelly 3.1 costruisce pacchetti Arch mentre Vanilla OS 3 diventa riproducibile

🐧 Novità principali

• Shelly 3.1 costruisce direttamente pacchetti Arch compatibili con pacman, eliminando makepkg dal percorso AUR predefinito.
• Il nuovo builder verifica PKGBUILD, sorgenti e firme, supporta Landlock e integra dipendenze AUR dentro lo stesso flusso.
• Vanilla OS 3 Reunion introduce immagini riproducibili bit-for-bit, supporto ARM64, GNOME 50 e una nuova generazione di Apx e VSO.

Shelly 3.1 e Vanilla OS 3 “Reunion” aggiornano due approcci molto differenti al desktop Linux, ma condividono la stessa direzione: spostare sempre più logica critica dentro strumenti controllabili e riproducibili. Shelly amplia il proprio ruolo nell’ecosistema Arch Linux costruendo direttamente i pacchetti a partire dai PKGBUILD, senza delegare automaticamente la fase finale a makepkg. Vanilla OS rende invece riproducibili le proprie immagini di sistema, aggiunge il supporto ufficiale ARM64 e rinnova l’architettura della distribuzione immutabile. Nel primo caso cambia il modo in cui viene costruito il software; nel secondo cambia il modo in cui viene costruito l’intero sistema operativo.

Shelly 3.1 non delega più la build dei pacchetti a makepkg

La novità centrale di Shelly 3.1 è il nuovo comando shelly build, capace di trasformare direttamente un PKGBUILD in un archivio installabile da pacman. Nella release ufficiale di Shelly 3.1 Seafoam Labs chiarisce che non si tratta di un semplice wrapper intorno a makepkg: il builder fa parte della libreria nativa del package manager e gestisce internamente parsing, sorgenti, dipendenze, funzioni prepare(), build(), check() e package(), metadati, firma e pubblicazione degli artefatti. È il passo successivo rispetto a Shelly 3.0, che aveva già riscritto il core in Zig e consolidato la gestione di Arch, AUR, Flatpak e AppImage. Con la 3.1 il progetto smette quindi di essere soltanto un’interfaccia più accessibile per libalpm e AUR e inizia a controllare direttamente anche la fase più delicata della produzione del pacchetto.

Il PKGBUILD viene analizzato prima di essere eseguito

Il nuovo builder punta molto sul controllo del codice che arriva dall’AUR. Prima di eseguire il PKGBUILD, Shelly ne analizza il contenuto, mostra all’utente file locali, script di installazione, changelog e possibili indicatori sospetti, quindi calcola un digest di integrità dei materiali approvati. Se un file cambia tra revisione ed esecuzione, la build viene rifiutata. Il sistema controlla inoltre firme PGP, checksum, sorgenti Git, split package e dipendenze architetturali. È un’estensione naturale del lavoro già visibile nell’integrazione di Shelly dentro CachyOS e nella riscrittura da C# a Zig, ma la 3.1 interviene proprio sul punto più sensibile dell’AUR: il PKGBUILD è codice eseguibile mantenuto dalla comunità, non un pacchetto binario verificato direttamente dal progetto Arch. Rendere la revisione una fase strutturale e non opzionale modifica quindi il modello di fiducia dell’intero workflow.

Landlock limita ciò che il codice della build può leggere e modificare

Shelly 3.1 aggiunge anche un isolamento opzionale basato su Linux Landlock. Quando viene abilitato, le funzioni del PKGBUILD lavorano dentro una sandbox filesystem che consente l’accesso alle directory necessarie alla compilazione e al toolchain, ma non lascia il codice libero di attraversare la home dell’utente. Le directory aggiuntive per cache come Cargo, npm, Gradle o ccache possono essere autorizzate esplicitamente. Il networking non viene però isolato e /proc resta visibile, quindi non si tratta ancora di una clean build completamente segregata. Lo stesso progetto avverte che l’opzione --isolated è riservata a un futuro builder con root separata e non deve ancora essere considerata funzionale. La trasparenza su questi limiti è importante: Shelly migliora la sicurezza rispetto a un’esecuzione indiscriminata del PKGBUILD, ma non pretende di sostituire completamente i chroot utilizzati dai maintainer Arch.

Le dipendenze AUR entrano nello stesso motore di build

Il comando --sync-deps utilizza il package manager Shelly per risolvere non soltanto le dipendenze presenti nei repository ufficiali, ma anche quelle disponibili esclusivamente nell’AUR. Il builder distingue dipendenze runtime, build e check, mantiene quelle necessarie al pacchetto installato e rimuove automaticamente quelle introdotte soltanto per la compilazione, anche quando la build fallisce. Gli artefatti finali mantengono il formato previsto da Arch con .PKGINFO, .BUILDINFO, .MTREE, .INSTALL e .CHANGELOG, quindi rimangono leggibili da pacman e dagli altri strumenti dell’ecosistema. È un’evoluzione significativa per una distribuzione come Arch, la cui ISO recente è già passata alla generazione Linux 7.1 mantenendo il tradizionale modello rolling: Shelly prova a semplificare l’esperienza senza creare un formato di packaging parallelo.

Vanilla OS 3 Reunion rende riproducibile l’intera immagine del sistema

Sul versante opposto dell’ecosistema Linux, Vanilla OS 3 Reunion lavora non sul singolo pacchetto ma sulla riproducibilità dell’intero sistema. La release ufficiale pubblicata dal progetto introduce immagini completamente riproducibili, costruite affinché gli stessi sorgenti e la stessa configurazione producano output identici bit per bit. Il risultato aumenta la possibilità di verificare che una build distribuita agli utenti corrisponda realmente al codice e alle ricette dichiarate.

Reunion continua il percorso immutabile inaugurato da Orchid, ma lo accompagna con una base aggiornata, Linux 7.1.3 e GNOME 50 esclusivamente Wayland. La scelta si inserisce nell’evoluzione recente di GNOME, che con GNOME 50.4 ha consolidato rendering, HDR e gestione HiDPI su Wayland, rendendo sempre meno necessario mantenere una sessione X11 parallela.

ARM64 porta Vanilla OS oltre il tradizionale desktop x86

Reunion aggiunge anche supporto ufficiale ARM64, ampliando la distribuzione oltre il desktop x86-64. Non significa compatibilità automatica con qualsiasi scheda ARM, perché firmware, bootloader e supporto hardware continuano a dipendere dal dispositivo, ma l’architettura entra finalmente nel percorso di build ufficiale del progetto. È un passaggio coerente con l’espansione di Linux ARM nelle workstation, nei mini PC e nei sistemi di sviluppo e con la progressiva maturazione della piattaforma già visibile nelle distribuzioni che affiancano immagini x86 e ARM64. Vanilla OS mantiene inoltre la propria base Debian-oriented, all’interno di un ecosistema che continua a beneficiare della stabilità e dell’enorme disponibilità di pacchetti della distribuzione madre.

Apx e VSO vengono riscritti sopra il nuovo Vanilla OS SDK

La nuova release interviene profondamente anche sui componenti proprietari della distribuzione. Apx e VSO, Vanilla System Operator, sono stati riscritti utilizzando il nuovo Vanilla OS SDK, che unifica logging, configurazione, privilegi e interazione con il sistema. Apx continua a gestire ambienti containerizzati nei quali installare software proveniente da ecosistemi differenti, mentre VSO coordina attività e funzioni di sistema. Anche Distrobox entra nella nuova generazione con la riscrittura in Go, mentre First Setup ottiene una modalità di aggiornamento che permette di installare nuove applicazioni e rimuovere quelle non più desiderate durante la configurazione iniziale. Reunion aggiorna inoltre le applicazioni predefinite con Ptyxis, Papers e Resources, seguendo il nuovo stack GNOME.

Shelly e Vanilla OS arrivano allo stesso obiettivo da due direzioni opposte

Shelly 3.1 e Vanilla OS 3 mostrano due idee molto diverse di controllo del sistema. Arch Linux rimane un ambiente nel quale l’utente gestisce direttamente pacchetti, dipendenze e configurazione; Shelly cerca di rendere quel controllo più sicuro e comprensibile senza sottrarlo all’utente. Vanilla OS preferisce invece immagini atomiche, componenti immutabili e riproducibilità dell’intero sistema, spostando una parte maggiore della complessità nella pipeline di build. La convergenza è però evidente: sapere esattamente quale codice viene eseguito, da dove proviene e come è stato costruito sta diventando una caratteristica centrale del desktop Linux moderno. Shelly applica questo principio al PKGBUILD; Vanilla OS lo estende all’immagine completa del sistema operativo. Due modelli differenti che finiscono per rispondere alla stessa domanda: rendere il software più verificabile senza rinunciare alla flessibilità che ha sempre distinto Linux.