Come scegliere un formato di pacchetto per la distribuzione del software Linux?

L'RPM è più diffuso nelle distribuzioni business friendly. Sia Debian che Ubuntu usano entrambi aptitude. Mi piace l'attitudine, entrambi lavorano però. Non si escludono a vicenda, però.

Entrambi dovrebbero essere in grado di verificare che le strutture di base del sistema siano presenti. Ad esempio, potresti dipendere da versioni specifiche di librerie condivise. Non ho mai visto questo tipo di supporto in strumenti di auto-estrazione.

L'autoestrazione è meno comune. Mentre è più facile ottenere una versione veloce e sporca fuori dalla porta, non avrai un sistema di supporto su cui appoggiarti. Pensa a quanti soldi paga la gente per InstallShield. Intere compagnie si guadagnano da vivere facendolo. È improbabile che la maggior parte delle organizzazioni spenda gli sforzi per farlo nel modo giusto. I tipi di tuta tendono a pensare che sia gratuito e sia un vero rompicoglioni.

Dovresti fornire un pacchetto per ciascuna distribuzione / versione che desideri supportare. Scegli quali distro e quali delle loro versioni supporti e fornisci il pacchetto appropriato (.deb per Debian / Ubuntu, .rpm per RHEL / Fedora, ecc.). Potresti colpirlo fortunato e, ad esempio, il tuo .deb di Debian può essere al 100% buono in Ubuntu, ma ciò non accade sempre (cioè gli IIRC, gli script di init di Debian e Ubuntu sono diversi).

Per tutti gli altri, fornisci un .tar.gz e istruzioni.

Prima di tutto, se stai facendo un normale pacchetto Linux, non c'è alcun motivo ragionevole per raggruppare JRE con esso. Basta dichiarare una dipendenza da un JRE (penso che sia possibile per la maggior parte delle distro principali, qualcuno mi corregga se sbaglio).

RPM non è lo standard, ma è uno dei principali. Questo è il bello di Linux: tanti standard diversi tra cui scegliere. Dovresti iniziare esaminando i tuoi utenti e vedere quali distro sono più popolari. Potresti riuscire a farla franca con un RPM per tutti i sistemi basati su Redhat e un DEB per tutti i sistemi basati su Debian (questo include Ubuntu). Oppure potresti dover suddividerlo ulteriormente.

Ho una certa esperienza con le applicazioni di packaging per Linux (sono stato un mantenitore di distro per un po '), quindi lascia che ti spieghi questo: sei nei guai, non importa quello che fai. Anche un sistema di packaging avanzato come RPM non ti consente di creare un pacchetto e farlo funzionare su diverse distribuzioni. Ad esempio, un'altra risposta consiglia "dichiarare una dipendenza su JRE". Come si fa? In RPM, aggiungi un requisito

jre > = 1.45

ma se la distribuzione chiamata pacchetto JRE non "jre" ma "java_runtime_environment", non si è fortunati e il pacchetto ha una dipendenza non funzionante. Preparare un pacchetto che non codifica il percorso dei file e delle dipendenze è tutt'altro che banale, e richiede di basarsi sul presupposto che le distro seguano alcuni standard comuni (che non lo fanno, almeno non in modo coerente).

L'approccio di gran lunga più semplice per te e per i tuoi clienti è quello di creare un pacchetto autonomo. Se si desidera risparmiare spazio e larghezza di banda, fornire due versioni: con e senza JRE, con istruzioni chiare su come installare JRE e un collegamento a cui è possibile scaricare una versione compatibile sul sito Web Oracle.

Quando ho iniziato ad usare Arch Linux mi sono innamorato di pacman e makepkg app. Costruisce app da fonti una delle cose più facili in GNU / Linux. Controlla tutte le dipendenze e crea un archivio pronto per l'uso.

Dovresti non vedere l'imballaggio come priorità. L'imballaggio è l'obiettivo dei manutentori dei pacchetti, non degli sviluppatori originali.

Se disponi di risorse umane gratuite, puoi raccogliere le distribuzioni più importanti per te, ma non il formato del pacchetto !, e fornire il software in-house.

Tieni presente, tuttavia, che in questo caso hai è esplicitamente richiesto di tenere traccia di tutte le modifiche in arrivo nella distribuzione prescelta e di conservarle insieme alle modifiche apportate al tuo software , aggiornato. Inoltre, il download di software precompilato (pacchettizzato) al di fuori del proprio repository di distribuzione è considerato un rischio per la sicurezza. Nota che le distribuzioni basate sull'origine si baseranno ancora sul recupero automatico del tarball sorgente dal tuo sito, tuttavia questo viene fatto tramite il gestore dei pacchetti e normalmente viene verificato sommando.

Una delle scelte migliori qui è contattare lo sviluppatore attivo nella distribuzione target di tua scelta e argomento dopo averlo assegnato come packager responsabile per il tuo software all'interno della sua distribuzione. Quindi, dovrai solo citare istruzioni per l'installazione del tuo software su una distribuzione specifica senza binari effettivi, poiché verrà installato utilizzando la gestione del pacchetto nativo di distribuzione.

Vedi Play-On-Linux come esempio.