Perché gli sviluppatori Linux non possono creare un formato di packaging universale?

Le selezioni del formato del pacchetto binario del fornitore sembrano essere determinate da una forma della Legge di Murphy: tutte le distro che non si usano hanno pacchetti. (Corralary: non esiste alcuna distribuzione che soddisfi le dipendenze di distribuzione dello stack software).

È una questione di politica, o qualcosa di più profondo, che non abbiamo visto emergere un formato di pacchetto "costruisci una volta, corri ovunque"?

Sembra appropriato citare Joel Spolsky su questo:

(A proposito, per quelli di voi che seguono il mondo arcano ma politicamente carico dei formati di feed di syndication dei blog, potete vedere accadere la stessa cosa laggiù. RSS è diventato frammentato con diverse versioni diverse, specifiche imprecise e molti combattimenti politici, e il tentativo di ripulire tutto creando un altro formato chiamato Atom ha portato a diverse versioni di RSS più una versione di Atom, specifiche imprecise e molti combattimenti politici. Quando si tenta di unificare due forze opposte creando una terza alternativa, finisci con tre forze opposte. Non hai unificato nulla e non hai riparato nulla.)

(enfasi aggiunta)

Hai (almeno) due sistemi di packaging per Linux. In realtà è una buona cosa. Un singolo sistema creerà semplicemente un terzo sistema.

Ci sono molte ragioni per questo, e un po 'di storia è al fine di mettere le cose in prospettiva.

Ricorda che quando parliamo di "Linux" ciò a cui ci riferiamo generalmente è una delle molte diverse distribuzioni Linux . "Linux" è in realtà solo un kernel del sistema operativo.

L'obiettivo originale di Linux era quello di creare un sistema basato su Unix che potesse funzionare su PC (inizialmente il 386). Il primo passo è stato creare il kernel stesso. Mentre Linus Torvalds stava lavorando sul kernel Richard Stallman stava lavorando sul suo sistema Free Unix, nell'ambito del progetto GNU (GNU's Not Unix) . Per farla breve, i due in qualche modo convergevano perché GNU aveva le utilità associate (compilatore C / libreria / strumenti di compilazione, shell, editor di testo ecc.) Ma nessun core su cui eseguirlo, e Linux aveva il core ma nessuna utility per corri sopra per renderlo utile per le masse.

Questa convergenza divenne nota in qualche modo ufficialmente come GNU / Linux. Vedrai che molte distro si riferiscono ancora a se stesse come distribuzioni GNU / Linux.

A causa della natura libera e aperta di GNU / Linux, chiunque può prenderlo e creare un sistema in bundle secondo i propri gusti. Il risultato è stato che molti flussi diversi di metodi di configurazione diversi sono stati utilizzati per creare questi sistemi, il che ha avuto l'effetto collaterale di creare quasi tutti i diversi sistemi di gestione dei pacchetti per adattarsi a ciascuno di essi.

Ogni diverso sistema completo aveva i suoi seguaci forti che si sono uniti a loro nel corso degli anni, risultando in ciò che abbiamo oggi: una manciata di sistemi di gestione dei pacchetti ampiamente usati, profondamente radicati e stabili come RPM , APT / dpkg e Portage di Gentoo .

Esistono progetti, come Autopackage , che stanno tentando di risolvere il problema, ma la continua evoluzione dei vari sistemi di gestione dei pacchetti supportati significa che ci sono molti obiettivi mobili da seguire.

Ciò che alcuni produttori di software finiscono per fare è raggruppare i binari specifici e le copie delle dipendenze di cui hanno bisogno in un unico pacchetto di grandi dimensioni che funzionerà su sistemi specifici.

Avere lo stesso formato di pacchetto non sarebbe comunque d'aiuto. Non puoi semplicemente usare lo stesso pacchetto in altre distribuzioni. Spesso non puoi nemmeno usarlo nella diversa versione della stessa distribuzione. E anche la creazione del pacchetto può avere gli stessi problemi.

Per installare un pacchetto è necessario soddisfare le dipendenze che si formano durante la creazione del pacchetto. Per compilare un pacchetto è necessario soddisfare le dipendenze di compilazione. E queste cose cambiano. Per poter implementare le modifiche, è più semplice supportare solo i pacchetti che è possibile modificare per funzionare dopo le modifiche.

Se tutte le dipendenze fossero uguali, non si tratterebbe di una distribuzione diversa o di una versione diversa della stessa distribuzione.

C'è un po 'di "sindrome non inventata qui", credo. Il sistema di packaging di Debian precede RedHat, eppure è superiore in molti modi, ma non vedrai mai il cambio RedHat. Invece, vedi molte persone che usano "apt-rpm" che tenta di darti alcuni dei vantaggi di apt con i file rpm.

Basta andare per .deb :-)

C'erano diversi formati di tentativi, come zero-install e autopackage . Sfortunatamente nessuno ha guadagnato alcuna trazione.

Penso che Cletus, Wayne e Iny abbiano risposto abbastanza bene. Vorrei aggiungerlo davvero, non è un grosso problema. Lavoro in un ambiente misto in cui abbiamo Gentoo (portage), SUSE (rpm / zypper) e OpenBSD (pacchetti e porte). Installare pacchetti su uno di essi non è difficile e non mi interessa davvero quale formato stiano usando.

Dal punto di vista del software di packaging, non è nemmeno palesemente difficile. Che si tratti di Gentoo, una distro basata su RPM o una distro basata su deb, si riduce davvero ad avere ricette per la creazione del software e l'aggiunta di alcuni metadati. A condizione che il sistema di compilazione di ciò che si sta tentando di impacchettare non sia del tutto folle, di solito ci vuole poco più che scrivere uno script di shell glorificato per creare un pacchetto.

Bene ci sono sempre binari compilati staticamente in tar ball .... ;-)

Non esiste una definizione di un'interfaccia binaria standard per "Linux" poiché si tratta solo di un kernel. Probabilmente il tuo stack software dovrà interfacciarsi con qualcosa di più del semplice kernel, presentando una sfida particolare nel mantenere un ABI standard tra centinaia di alberi di sorgenti disparate.

Per quanto riguarda i buoni strumenti di packaging, preferisco Debian GNU / Linux per il suo eccellente formato binario di packaging. Ha soddisfatto il 90% delle mie esigenze di strumenti e applicazioni standard. Il restante 10% viene generato dall'origine a causa dell'inclusione di componenti non liberi o dipendenze di librerie condivise con errori. Quando è necessario distribuire tali applicazioni, creo binari personalizzati per i cluster di produzione.

Per ottenere un build-once, esegui ovunque il formato del pacchetto senza forzare tutti a utilizzare la stessa distribuzione di cui hai bisogno di un paio di funzionalità importanti:

• Denominazione dei pacchetti univoca a livello globale, in modo che due persone / distribuzioni non possano creare indipendentemente pacchetti diversi con lo stesso nome.

• La possibilità di installare in parallelo diverse versioni di librerie quando i pacchetti hanno requisiti contrastanti. Una distribuzione può decidere quale versione di ciascuna libreria utilizzare e forzare tutti i pacchetti a utilizzare quella versione. Un sistema che funziona attraverso le distribuzioni deve essere più flessibile.

Zero Install fornisce entrambe queste funzionalità:

• I nomi sono URI (ad es. Http://rox.sourceforge.net/2005/interfaces/ROX-Filer ). Solo il proprietario di un dominio può creare pacchetti all'interno di quello spazio dei nomi per impostazione predefinita.

• Ogni versione di ciascun pacchetto va nella sua directory. Ogni applicazione vede solo quelle librerie di cui ha bisogno, con le versioni con cui è compatibile.

Ad esempio, l' applicazione Modifica dipende da Python <3 in questo modo:

<command name="run" path="Edit/AppRun">
  <runner interface="http://repo.roscidus.com/python/python">
    <version before="3"/>
  </runner>
</command>

Vedi anche: http://www.osnews.com/story/16956/Decentralised-Installation-Systems

[Nota: sono uno sviluppatore 0install]