I sistemi attuali sono equivalenti, pur variando in funzionalità e utilizzo: RPM e DEB si contendono la scena come motori principali, mentre varie interfacce utente hanno il compito di nascondere all’utente tutto il lavoro sporco da essi svolto.
Ci sono stati parecchi tentativi di semplificazione, tra soluzioni precarie, tradizionaliste, rivoluzionarie, sperimentali o semplicemente insostenibili. Nomi come Autopackage, PackageKit, Klik/Glick e vari strumenti che ogni distributore è stato obbligato ad escogitare di volta in volta.
Adesso, in quella che potrebbe essere una svolta storica, finalmente sembra aprirsi uno spiraglio di luce in fondo al tunnel affettuosamente denominato “dependency hell”…
Il problema
Installare software è un compito abbastanza complesso in ogni sistema operativo. Idealmente si tratta solo di copiare qualche file, e in alcuni casi non ci si scosta troppo da questa semplice operazione; nella realtà però una gestione dei pacchetti deve tenere conto di molte esigenze:
- Installazione, rimozione e aggiornamento dei pacchetti
- Gestione di un database di pacchetti installati/installabili/aggiornabili
- Risoluzione di eventuali (inter)dipendenze e/o conflitti
- Esecuzione di script di autoconfigurazione e/o d’avvio
- Già detto “Risoluzione di eventuali (inter)dipendenze e/o conflitti”?
Tali esigenze rendono difficoltosa l’idea di affidarsi ad una semplice copia dei file da installare, specialmente se consideriamo che nei sistemi unix è tradizione suddividere e spargere il contenuto di ogni pacchetto per tutto il filesystem, in base al tipo di file: i binari vanno in /bin, /usr/bin /usr/share/bin e altro ancora, le librerie in /lib, /usr/lib, ecc, secondo un complicato sistema di precedenze e di criticità delle singole componenti.
Se consideriamo che ogni distributore si è sempre trovato a creare un’albero delle directory leggermente diverso dall’altro, un sistema di script di init leggermente diverso dall’altro, un sistema di configurazione leggermentediverso dall’altro, un naming scheme dei pacchetti leggermente diverso dall’altro, una politica di aggiornamento dei pacchetti leggermente diversa dall’altro… capirete bene come si sia arrivati alla situazione attuale, in cui praticamente non esistono due distribuzioni compatibili.
Le soluzioni tradizionali
Ogni distributore ha dunque sviluppato un sistema di gestione dei pacchetti, magari storicamente legato al nome della distribuzione o dell’azienda sviluppatrice, magari con corredo di spunti per garantire anni di ferocissime, intense e inutili dispute su quale sia il migliore, più tecnologicamente avanzato, veloce, affidabile, sicuro, eccetera.
Ciascuno di noi ha le sue preferenze, che – come tutte le religioni – non è il caso di mettere in dubbio, possiamo però ostentatamente ignorare i gestori di pacchetti più casalinghi o legati a distribuzioni minori ed evidenziare i due principali sistemi, gli unici contemplati dalla idealmente importante quanto in pratica inutile Linux StandardBase: RPM e DEB. Il primo viene da Red Hat ed è adottato da distribuzioni quali Fedora, openSUSE, Mandriva/Magiea e altre; il secondo da Debian ed è adottato da Debian stessa e dalle innumerevoli distribuzioni derivate, tra cui Ubuntu.
Anche annullando il motivo d’esistere di ogni buon troll e ponendo che RPM e DEB siano equivalenti (grosso modo lo sono), per tutta la serie di motivi elencati più su, ugualmente non esistono due distribuzioni che usano lo stesso gestore esatto, in quanto molto raramente un pacchetto rpm per openSUSE potrà essere installato su Fedora, o allo stesso modo un deb di Debian su Ubuntu. Dunque due principali tecnologie, usate per creare decine di implementazioni leggermente incompatibili, quel che basta a non permettere l’uso di uno stesso pacchetto su più di una distribuzione. Ma non è questo il punto.
Per rendere meno anale la gestione dei pacchetti da parte dei semplici utenti che vogliono semplicemente installare Firefox, fregandosene bellamente di librerie e dipendenze, sono stati escogitati varie interfacce ad RPM e DEB. Da APT a Synaptic, da YAST a YUM alle decine di altre utilità create con questo scopo. Un primo tentativo sensato di unificare tutte queste piccole divergenze sotto un ombrello che garantisse delle API un’esperienza d’uso uguali e coerenti, a prescindere dal funzionamento reale del motore, è stato PackageKit, tuttora non del tutto implementato.
Le soluzioni sperimentali
Oltre a questo, molto oltre a questo, c’è sempre stato un impulso al rinnovamento, da parte di utenti e sviluppatori insoddisfatti da alcuni aspetti della gestione dei pacchetti in GNU/Linux, principalmente dalla intensa frammentarietà che porta alla compatibilità suddetta. Sono dunque nati diversi sistemi alternativi, ma semprecomplementari, per gestire pacchetti in maniera più omogenea e pratica per tutte le distribuzioni o quasi.
Uno degli esempi più riusciti, ma sempre largamente fallimentare, è/era Autopackage, un gestore che offre un leggero strato di compatibilità con il gestore della distribuzione, e ponendosi come gestore ulteriore, da usare per quei pochi progetti che nel tempo hanno fornito versioni autopackage dei loro software. Non è mai stato nemmeno ufficiosamente supportato da alcun distributore, che io sappia.
Se Autopackage è stato largamente ignorato, pur essendo forse il migliore esempio, potete immaginare gli altri. Un progetto che ho seguito con molta attenzione è stato Klik, che a differenza di Autopackage e dei sistemi tradizionali, si rifà al concetto di app bundle tipico di Mac OS e implementa un paradigma di 1 file = 1 app, nell specifico si tratta di una immagine in cramfs contenente un piccolo albero di directory con tutte le librerie e i binari dell’applicazione, che in quel modo non vengono sparsi per il filesystem ma rimangono appunto contenute nel file. In maniera simile funziona(va) anche Glick e così pure un progetto italianissimo: SpatialBundle di Luca Cappelletti.
LA soluzione?
Tutte queste soluzioni sono sempre state caratterizzate dall’assoluta mancanza di coordinazione tra i distributori: quelle tradizionali per motivi che a mio avviso, ripetuto in varie occasioni, possono solo essere visti come la mancanza di prospettiva di chi imbriglia soluzioni aperte in strategie chiuse; quelle sperimentali perché semplicemente non interessavano davvero a nessuno.
Oggi però Frafra ha segnalato una notizia che non esito a definire storica. Sviluppatori di Red Hat, Fedora, Debian, Ubuntu, openSUSE, Mandriva e Mageia si sono incontrati per discutere le caratteristiche di un nuovo gestore di pacchetti universale. Al momento si chiamerebbe AppStream e sarebbe basato sull’interessante progetto Bretzn, presentato dal team di KDE, per quanto riguarda le funzionalità multipiattaforma e multiarchitettura, e idealmente su Ubuntu Software Center per quanto riguarda l’interfaccia utente. Funzionalità molto interessanti, quali la possibilità da parte degli utenti di attribuire e condividere votazioni o commenti ai pacchetti sarebbe prevista tramite Open Collaboration Services.
La parte più interessante è che l’intero progetto non sarà un sistema per distribuire i tanto temuti et famigerati Universal Binaries From Hell, ma si limiterà a fornire metadati, che saranno interpretati da cliente per scaricare i bit necessari. Questo significa che il sistema di installazione dei pacchetti rimarrà di tipo tradizionale, e che dunque le parti che verranno innovate saranno solo quelle che permetteranno di avere un installer universale per tutte le distribuzioni.
Nessuna rivoluzione, ok, ma una benvenuta evoluzione all’insegna della razionalità.
Fonte: http://pollycoke.org/2011/01/25/un-gestore-di-pacchetti-universale-per-linux/