In questo articolo Indice dei contenuti 3 sezioni
istribuire software su Linux è la parte del lavoro che dovrebbe costare meno fatica e invece finisce spesso per diventare un secondo progetto da mantenere, con calendari, imprevisti e manutenzione propria. Il codice si compila, il binario esiste, funziona. Poi comincia il vero problema: farlo arrivare, uguale a se stesso, sui computer di persone che usano Debian, Fedora, Arch, Ubuntu di tre anni fa oppure un sistema costruito in modo dichiarativo. Lo racconta bene l’autore di Fresh, editor di testo e ambiente di sviluppo per terminale scritto in Rust, dopo aver provato praticamente ogni strada disponibile: npm, Cargo, AppImage, Flatpak, pacchetti DEB e RPM, AUR, Nix, mise, Homebrew per Linux, Gentoo GURU e semplici archivi con binari precompilati.
Il paradosso è che gli strumenti non mancano. Ce ne sono troppi, anzi, ognuno legato alla storia di una famiglia di distribuzioni. Debian e derivate girano attorno a DEB e APT, Fedora e Red Hat usano RPM e DNF, Arch affianca ai repository ufficiali il celebre AUR. Sopra questo si sono aggiunti i formati indipendenti dalla distribuzione, i gestori pensati per sviluppatori e i sistemi dichiarativi. Per un progetto piccolo, tenere in piedi tutti quei canali vuol dire moltiplicare build, metadati, procedure di pubblicazione e punti in cui qualcosa può rompersi. Fresh pesa circa 12 MB da scaricare e circa 35 MB una volta estratto, quindi la questione non è la complessità del programma.
Creare il pacchetto è facile, mantenerlo molto meno
Preparare una volta un file .deb o .rpm è alla portata di chiunque. Garantirne una distribuzione affidabile nel tempo è un altro sport. Cambiano dipendenze, tool di build, certificati, regole dei repository, versioni delle librerie. Una release può funzionare perfettamente e restare comunque irraggiungibile su uno dei canali supportati. Con mise è andata esattamente così: l’integrazione filava liscia finché GitHub non ha modificato il materiale crittografico usato dal proprio sistema di attestazione delle build. Una dipendenza di mise conservava una trust root vecchia, la verifica si è fermata e l’installazione è risultata rotta pur senza che una riga di Fresh fosse cambiata. Chi mantiene un progetto non controlla registry, repository, strumenti di firma e package manager, che si muovono per conto proprio.
Flatpak e AppImage risolvono qualcosa e rompono altro
Flatpak porta con sé buona parte del runtime necessario e rende il comportamento molto più prevedibile fra distribuzioni diverse, con una sandbox che limita l’accesso al sistema host. Ottimo per un’app desktop autosufficiente, complicato per un editor da terminale che deve leggere progetti sparsi in decine di directory, eseguire programmi, aprire terminali, parlare con Git, raggiungere servizi di rete e usare strumenti installati sull’host. I privilegi si possono ampliare dal manifest, certo, ma la documentazione ufficiale invita a tenerli al minimo. Esiste anche un’interfaccia per gli strumenti di sviluppo che consente a software fidato di lanciare processi fuori dalla sandbox, utile per IDE come GNOME Builder, che però equivale ad allentare proprio quel confine.
Con AppImage il ragionamento cambia forma. Un file, permessi di esecuzione, avvio. Le immagini moderne di tipo 2 contengono un filesystem SquashFS che il runtime monta via FUSE in una directory temporanea, meccanismo elegante che aggiunge una dipendenza e un costo all’avvio. Per un editor che deve comparire quasi istantaneamente quella latenza è troppa, e la scelta è stata estrarre una volta il contenuto e usare i file direttamente, modalità che secondo la documentazione del progetto rende l’avvio circa 10 volte più rapido.
Il vero ostacolo si chiama glibc
Nessun contenitore di file risolve la compatibilità binaria con le librerie del sistema. Un programma compilato dinamicamente contro una versione recente di glibc può cercare simboli che una distribuzione vecchia non ha, e il loader dinamico blocca tutto prima che l’applicazione arrivi alla propria funzione main. Compilare su una base sufficientemente datata funziona, ma significa gestire immagini vecchie e toolchain dedicate.
Fresh ha quindi imboccato la via del binario statico compilato con musl, disponibile per x86_64 e aarch64 e installabile in ~/.local senza privilegi di root. Il linking statico taglia le incompatibilità fra versioni di glibc, e gli aggiornamenti li gestisce l’editor stesso, controllando checksum e attestazione della release prima di sostituire il binario. I pacchetti tradizionali restano disponibili, ma il percorso principale di installazione non dipende più da una catena lunghissima di repository e gestori diversi.
