conundrum

Ikitt, su <a title="geek dump – su autopackage (ancora)" href="http://geekdump.blogspot.com/2006/03/su-autopackage-ancora.html">autopackage</a> (in particolare, penso si riferisca a <a href="http://plan99.net/autopackage/Linux_Problems">questa pagina</a>.

Il vero problema di autopackage non è l’attitudine dei programmatori di autopackage – in fondo, progetti <acronym title="Free and Open Source Software">F/OSS</acronym> portati avanti da persone che non riescono a comportarsi come degli adulti razionali ne abbiamo avuti e ne avremo ancora; pensiamo a MPlayer: nato male, portato avanti con arroganza e spocchia, sta finalmente per finire nel dimenticatoio, sorpassato da soluzioni tecnicamente superiori e sviluppate da gente che, almeno, non dice che tutto il resto fa schifo. Questo perché MPlayer copriva una nicchia nell’ecosistema del <i>free software</i> che <b>doveva</b> essere coperta.

Autopackage, al contrario, non risponde ad alcuna esigenza vera e propria, se non al bisogno di alcuni sviluppatori per Windows (che non hanno ancora capito come funzionano le cose sotto *nix e Linux) di avere un unico pacchetto da installare su tutte le macchine che hanno sotto mano. È un’esigenza sentita da qualcuno? Si – ovviamente. È un’esigenza <b>rilevante</b>? No, altrettanto ovviamente. Altrimenti avremmo molti altri progetti simili ad autopackage – mentre l’unico che mi viene in mente è Klik, ovvero un altra soluzione messa a punto da e per programmatori per Windows.

Secondo gli sviluppatori di autopackage l’onere di far funzionare il proprio software con tutte le distribuzioni dovrebbe ricadere sugli sviluppatori delle applicazioni; questo non solo è dimostrabilmente inutile, ma pure dannoso. Io uso Ubuntu e conosco il sistema di pacchettizzazione della Debian a sufficienza per poter fare pacchetti <code>.deb</code>; tuttavia, uno sviluppatore Debian che abbia finito la <acronym title="New Maintainer">NM</acronym> ne sa <b>indiscutibilmente</b> più di me riguardo alle <i>policy</i> della Debian; stesso discorso vale per pacchetti <acronym title="Red Hat Package Manager">RPM</acronym> e per uno sviluppatore della Fedora Core 5. Anche se quelli di autopackage mi forniscono un’<acronym title="Application Programming Interface">API</acronym> per astrarmi dal lavoro pesante di aver ca che fare con <i>relocation</i> di librerie e binari, le <i>minutie</i> del <i>package management</i> non le posso (e non le voglio) imparare. In più, a meno di non ricorrere alla Fatina dai Capelli Turchini, e di sostituire tutto l’installato planetario con pacchetti basati su Autopackage in un microsecondo, avremo sempre a che fare con pacchetti autopackage che rompono inesorabilmente i pacchetti legittimi delle distribuzioni.

Quindi, il vero e serio problema di autopackage è la completa inutilità del fine prefisso ("un solo package manament system per tutte le distribuzioni gestito dagli sviluppatori stessi"); a questo si deve aggiungere una ignoranza di base sui meccanismi delle distribuzioni e dei loro package manager; poi, ma solo alla fine, una manifesta arroganza da "noi abbiamo la soluzione per tutti i vostri problemi, e tutti gli altri sono solo dei perfetti stronzi", che fa risultare gli sviluppatori di autopackage automaticamente dalla parte del torto.