Package manager o gestori pacchetti Linux: cosa sono e quali le differenze

Negli ultimi anni, l’ecosistema Linux ha visto un’evoluzione significativa nei formati di pacchetto e nei tool di gestione dei pacchetti, che hanno rivoluzionato il modo con cui le applicazioni sono distribuite e installate. I gestori di pacchetti su Linux hanno tradizionalmente utilizzato formati quali .deb (Debian, Ubuntu) e .rpm (Fedora, Red Hat). I package manager in grado di supportare questi formati sono infatti, rispettivamente, APT e Yum/DNF.

Un gestore di pacchetti è uno strumento software che consente agli utenti di installare, rimuovere, aggiornare, configurare e gestire i programmi caricati su un’istanza di un determinato sistema operativo. Può essere un’applicazione grafica o uno strumento che funziona da riga di comando, come apt-get o pacman.

Che cos’è un pacchetto su Linux

Parlando di software Linux (e non di telecomunicazioni), un pacchetto è un file di archivio contenente l’eseguibile binario, il file di configurazione e talvolta informazioni sulle dipendenze necessarie per il corretto funzionamento del programma corrispondente.

In passato, il software veniva compilato a partire dal suo codice sorgente prima di essere eseguito sui sistemi Unix-like e su Linux. Si faceva riferimento a un file (solitamente denominato readme) e si verificavano i componenti software necessari. Generalmente era possibile beneficiare di uno script di configurazione o un makefile. La gestione delle eventuali dipendenze (ad esempio delle librerie e degli altri componenti software necessari per il caricamento e l’avvio del programma) erano interamente a carico dell’utente.

Per sbarazzarsi di questa complessità, le distribuzioni Linux hanno messo a punto formati di pacchettizzazione propri. Questi mettono a disposizione degli utenti dei file binari pronti all’uso (il software risulta precompilato). Il pacchetto contiene quindi il necessario per l’installazione del software, alcuni metadati (numero di versione, descrizione) e le indicazioni sulle dipendenze.

Intorno alla metà degli anni ’90, Red Hat ha creato il formato RPM (abbreviazione di Red Hat Package Manager) mentre Debian ha sviluppato il suo DEB. Ovviamente è ancora possibile compilare il software a partire dal suo codice sorgente ma la necessità di farlo è diventata piuttosto rara.

Come funziona un gestore di pacchetti Linux

Il concetto di package manager non è certo una prerogativa del mondo Linux. Basti pensare che il linguaggio Python utilizza un suo gestori di pacchetti, chiamato pip, e tante altre applicazioni usano il proprio.

Più di recente i gestori di pacchetti sono sbarcati anche in Windows, con Microsoft che sta promuovendo e aggiornando il suo Winget. Ci sono però diverse alternative come Scoop, che si basa su script PowerShell, e sono nate utilità dotate di interfaccia grafica come UniGetUi che raccoglie tutti i principali package manager per Windows.

La maggior parte delle distro Linux poggiano il loro funzionamento su repository software che sono fondamentalmente raccolte di pacchetti software. Ciascun repository raccoglie anche metadati contenenti informazioni sui pacchetti. È ciò che si ottiene, ad esempio, invocando il comando apt show su un sistema Ubuntu/Debian.

Il gestore di pacchetti crea e gestisce una cache locale dei metadati, sul sistema di ciascun utente. Quando si chiede l’aggiornamento del gestore dei pacchetti, ad esempio con il comando apt update (sempre nel caso di Ubuntu/Debian), tale cache locale è automaticamente aggiornata recuperando i metadati più recenti dai vari repository configurati sulla macchina in uso.

Dopo l’invio del comando apt install (seguito dal nome del pacchetto che si intende installare…), il gestore di pacchetti attinge al contenuto delle cache. Dopo aver raccolto le informazioni necessarie per l’installazione, il package manager si collega alla rete Internet e quindi al repository appropriato per scaricare i file necessari. Come osservato in precedenza, il gestore di pacchetti si occupa di gestire anche le dipendenze, installandole automaticamente sul sistema insieme con il pacchetto richiesto.

Quali gestori di pacchetti esistono

I gestori di pacchetti variano in base al sistema di pacchetti. Lo stesso formato di pacchetti, tuttavia, può essere supportato da parte di più package manager.

Come visto in precedenza, per esempio, RPM è supportato sia da Yum che da DNF; DEB da apt-get e aptitude.

Tutti quelli sin qui citati sono gestori basati su riga di comando. Gli utenti di Linux hanno però a disposizione strumenti grafici di gestione dei pacchetti come Synaptic. Anche il “Software Center” integrato nella distribuzione prescelta, dotata di desktop environment, è considerabile come un gestore di pacchetti a sé stante, anche se poggia a sua volta le fondamenta su apt-get o DNF.

Stanti le nuove esigenze in termini di portabilità, isolamento delle dipendenze e semplicità di distribuzione, con gli anni sono venuti alla luce nuovi formati di pacchetto e package manager più moderni. Tra questi, i più rilevanti sono Flatpak, Snap e AppImage.

Flatpak: le applicazioni Linux eseguite in un ambiente isolato (sandbox)

Sistema di pacchettizzazione e distribuzione delle applicazioni progettato per funzionare su qualsiasi distribuzione Linux, Flatpak deve la sua nascita al lavoro inizialmente svolto da Alex Larsson, per poi essere successivamente adottato dalla comunità GNOME.

La principale prerogativa di Flatpak, come abbiamo sottolineato nell’articolo sui 5 falsi miti a proposito di Linux, fornisce un ambiente sandbox per le applicazioni, isolandole dal sistema operativo sottostante.

La sandbox permette di eseguire le applicazioni in un contesto sicuro, riducendo il rischio di danneggiare il sistema. Inoltre, Flatpak utilizza una tecnologia chiamata OSTree per la gestione delle versioni e dei rilasci, permettendo aggiornamenti più efficienti e rollback (ripristini delle release precedenti) rapidi in caso di problemi.

Flatpak è diventato particolarmente popolare in ambienti desktop come GNOME e KDE, grazie alla sua integrazione con GNOME Software e KDE Discover, che semplificano l’installazione e la gestione delle applicazioni.

Perché l’esperienza un gestore di pacchetti come Flatpak resta controversa

Flatpak promette una soluzione universale per la distribuzione delle applicazioni, indipendentemente dalla distribuzione Linux in uso. Tuttavia, nonostante i vantaggi offerti e la larga adozione da parte degli utenti, da più parti si registrano strenue “resistenze” a promuovere Flatpak come metodo principale per l’installazione e la gestione del software, specialmente per i nuovi utenti Linux.

Uno dei principali problemi legati ai Flatpak è proprio il sandboxing delle applicazioni. Ma non doveva essere un punto a favore di Flatpak?

In parte sì. Nel senso che una sandbox riesce a isolare le applicazioni dal resto del sistema, limitando l’accesso a file e risorse. Questa caratteristica, un sicuro punto di forza per molti utenti, può diventare un serio ostacolo per altri.

Prendiamo come esempio un caso comune: un nuovo utente installa Linux e, tramite il gestore di pacchetti grafico, installa Steam, la popolare e apprezzata applicazione di distribuzione di giochi. Molte distribuzioni Linux moderne configurano il loro “Software Center” in modo da preferire l’installazione di applicazioni tramite Flatpak. Tanti utenti, senza essere consapevoli delle implicazioni, installano Steam tramite Flatpak.

Il problema sorge quando l’utente cerca di aggiungere la propria libreria di giochi già esistente, magari conservata su un’unità esterna. Per via della sandbox, Steam non può accedere alle risorse indicate. Questa situazione si traduce in un’esperienza utente che può risultare frustrante.

Flatpak: carenza di informazioni e integrazione da migliorare

In un caso come quello presentato al paragrafo precedente, Flatpak non mostra messaggi chiari e l’utente non comprende perché non riesca ad accedere alle varie risorse.

Il fatto che gli utenti debbano comprendere concetti come “Flatpak“, “sandboxing“, e “punching hole” (configurazione di eccezioni nella sandbox) per risolvere un problema così comune è qualcosa che resta davvero sullo stomaco.

Un’altra criticità di rilievo ha a che fare con la mancanza di un’integrazione nativa di Flatpak con il desktop environment. Molte applicazioni Flatpak non sono in grado di comunicare efficacemente con il sistema operativo sottostante: ciò significa che, ad esempio, non sono ancora capaci di mostrare notifiche o finestre informative.

Snap: i pacchetti all-in-one con gestione centralizzata di Canonical

Anche Snap è un altro moderno formato di pacchetto, sviluppato da Canonical, l’azienda che si occupa dello sviluppo di Ubuntu. Si differenzia per l’approccio “all-in-one“: ogni pacchetto (chiamato a sua volta “snap”) include tutte le dipendenze necessarie per funzionare, eliminando così i problemi di elementi mancanti o non compatibili. Ogni snap è contenuto e isolato dal resto del sistema, il che migliora la sicurezza e la stabilità.

Uno dei vantaggi principali di Snap è la possibilità di impostare aggiornamenti automatici per le applicazioni. Canonical gestisce un’infrastruttura centralizzata per la distribuzione degli snap attraverso lo Snap Store. L’idea è quella di semplificare il processo di aggiornamento.

Nonostante la sua adozione diffusa, Snap ha ricevuto critiche feroci all’interno di altre comunità Linux. Perché? Principalmente per via del suo approccio centralizzato e per il potenziale impatto sulle performance dovuto all’isolamento delle applicazioni.

AppImage: un file eseguibile con tutte le dipendenze

Tra i formati più in voga in questi ultimi anni, non possiamo non citare AppImage. Formato di pacchetto leggero e indipendente dalla distribuzione, AppImage permette di eseguire applicazioni su qualsiasi sistema Linux senza la necessità di avviare un’installazione vera e propria. Ogni pacchetto AppImage è di fatto un file eseguibile che contiene l’applicazione e tutte le sue dipendenze.

Si tratta di un formato apprezzato per la sua semplicità: l’utente può scaricare un file AppImage, renderlo eseguibile e avviarlo, senza dover affrontare procedure di installazione complesse.

AppImage non richiede privilegi di root per essere utilizzato, il che lo rende ideale per gli utenti che desiderano provare nuove applicazioni senza modificare in profondità il loro sistema.

Di contro, nel caso dei pacchetti AppImage la gestione delle versioni e degli aggiornamenti non è automatizzata come con Flatpak o Snap. AppImage risulta quindi inadatto per gli utenti meno esperti e si rivela una buona scelta per gli utenti avanzati nonché per avviare occasionalmente alcune tipologie di applicazioni.

Conclusioni

I nuovi formati di pacchetto e i moderni package manager rappresentano un significativo passo avanti per l’ecosistema Linux. Ognuno di questi formati offre vantaggi specifici, e la scelta tra Flatpak, Snap, e AppImage dipende spesso dalle esigenze particolari dell’utente o dell’ambiente di lavoro.

È tuttavia fondamentale che i gestori di pacchetti predefiniti, come i “Software Center“, non impongano automaticamente l’uso di Flatpak. Gli utenti, specialmente i nuovi arrivati, dovrebbero essere informati delle differenze tra Flatpak e altri formati di pacchetti, come i pacchetti DEB e RPM. Dovrebbero essere insomma messi nelle condizioni di scegliere consapevolmente il metodo di installazione più adatto alle loro esigenze.

Credit immagine in apertura: Copilot Designer