Il passaggio verso sistemi Linux basati su immagini sta modificando profondamente il modo in cui vengono gestiti sistema operativo, applicazioni e aggiornamenti. In questo scenario GNOME sta affrontando un problema meno evidente rispetto alla distribuzione delle applicazioni desktop: come fornire agli sviluppatori strumenti come strace, ripgrep o qemu senza legarli direttamente al sistema operativo e senza limitarne eccessivamente le funzionalità.
È questo il contesto nel quale nasce l’idea di Toolpak, descritta da Jordan Petridis in un nuovo articolo pubblicato sul blog GNOME. Il progetto è ancora in fase di progettazione e prototipazione, ma propone un modello differente rispetto a pacchetti tradizionali, container, Toolbox, Distrobox e Flatpak.
L’obiettivo è separare gli strumenti utilizzati dagli sviluppatori dal sistema operativo principale, mantenendo però un livello di accesso alle risorse molto vicino a quello offerto dagli strumenti installati tradizionalmente. Questo aspetto è particolarmente importante per attività come debugging, sviluppo del kernel e amministrazione del sistema, dove un ambiente fortemente confinato può creare limitazioni.
Il problema diventa ancora più evidente con le distribuzioni image-based. Installare globalmente una nuova dipendenza attraverso il normale gestore dei pacchetti può infatti entrare in contrasto con il modello immutabile o aggiornabile tramite immagini. Secondo Petridis, le soluzioni esistenti risolvono solo una parte del problema e spesso introducono compromessi tra isolamento e funzionalità.
Perché GNOME vuole un nuovo modello per gli strumenti di sviluppo
Nel modello tradizionale di Linux, uno sviluppatore può installare compilatori, librerie e utility direttamente nel sistema tramite il gestore dei pacchetti della distribuzione. È un approccio semplice e consolidato, ma crea una dipendenza diretta tra ambiente di sviluppo e sistema operativo.
Con sistemi basati su immagini, invece, modificare continuamente l’installazione principale non rappresenta necessariamente la soluzione ideale. GNOME cita diverse strategie già disponibili, evidenziandone i rispettivi limiti.
Gli overlay basati su rpm-ostree, ad esempio, permettono di aggiungere pacchetti a sistemi come Fedora Silverblue, ma possono introdurre problemi durante gli aggiornamenti o compromettere l’integrità dell’installazione. Toolbox e Distrobox spostano invece l’ambiente di sviluppo all’interno di container, mantenendo però parte delle problematiche legate ai tradizionali sistemi di pacchettizzazione e aggiungendo i limiti propri dell’ambiente confinato.
Anche Flatpak, pur essendo considerato una soluzione efficace per le applicazioni desktop, non è stato progettato specificamente per utility da riga di comando che devono interagire direttamente con numerose risorse del sistema. Strumenti di debugging e altre utility a basso livello possono quindi incontrare difficoltà quando vengono confinati secondo il modello pensato per le applicazioni grafiche.
Toolpak punta a occupare proprio questo spazio. L’idea è distribuire strumenti indipendenti dal sistema operativo, evitando che un problema in uno di essi possa compromettere l’installazione principale, ma lasciando allo stesso tempo agli strumenti l’accesso necessario per svolgere il proprio lavoro.
Toolpak punta su immagini indipendenti, dipendenze integrate e sicurezza
Il modello immaginato per Toolpak utilizza le Discoverable Disk Images conformi a UAPI.3 come formato per le immagini. Questo dovrebbe consentire di sfruttare meccanismi di sicurezza come Verity e offrire una base adatta alla realizzazione di build riproducibili.
Un elemento centrale è inoltre la separazione tra /usr e /app. Il runtime condiviso potrebbe fornire /usr, mentre l’immagine dello specifico strumento conterrebbe principalmente il proprio contenuto in /app. In questo modo più strumenti potrebbero condividere una base comune senza dover dipendere direttamente l’uno dall’altro.
Toolpak immagina inoltre strumenti capaci di includere le proprie dipendenze. Questa scelta punta a evitare i problemi tipici della risoluzione delle dipendenze dei pacchetti tradizionali e permette a ciascuna utility di utilizzare le versioni delle librerie con cui è stata testata.
Un altro dettaglio riguarda il PATH: gli strumenti Toolpak potrebbero essere anteposti ai programmi di sistema, consentendo per esempio di utilizzare una versione specifica di un comando senza modificare realmente i file del sistema operativo. Un componente di avvio si occuperebbe di predisporre il mount namespace e avviare il programma contenuto nell’immagine.
Questo modello richiede però particolare attenzione alla sicurezza. Gli strumenti avrebbero infatti accesso molto ampio alle risorse del sistema. Per questo le immagini dovrebbero essere firmate attraverso chiavi affidabili, verificate con Verity e sottoposte a un processo di revisione prima della distribuzione attraverso un eventuale catalogo ufficiale.
Il progetto prevede anche strumenti dedicati alla creazione dei pacchetti Toolpak, con caching degli artefatti tramite Content Addressable Storage, build riproducibili, verifica degli output e gestione di licenze e SBOM. Una possibile integrazione con Buildstream potrebbe contribuire a coprire queste esigenze.
Al momento Toolpak non è ancora una tecnologia pronta per l’uso quotidiano. GNOME sta lavorando a un prototipo nell’ambito di un progetto Prototypefund e prevede di condividere ulteriori informazioni nelle prossime settimane, raccogliendo nel frattempo feedback dalla comunità.