Dopo averlo affrontato un paio di volte con prodotti commerciali, penso che la risposta migliore sia utilizzare il programma di installazione nativo per ogni piattaforma supportata. Qualsiasi altra cosa produce un'esperienza spiacevole per l'utente finale e in pratica devi testare comunque su ogni piattaforma che vuoi supportare, quindi non è davvero un onere significativo mantenere i pacchetti per ciascuna. L'idea che tu possa creare un file binario che possa "funzionare" su tutte le piattaforme là fuori, incluse alcune di cui non hai mai nemmeno sentito parlare, in realtà non funziona molto bene.
La mia raccomandazione è di scegliere una o due piattaforme da supportare inizialmente (Red Hat e Ubuntu sarebbero i miei suggerimenti) e quindi lasciare che la domanda dell'utente guidi la creazione di pacchetti di installazione aggiuntivi. Forse fai sapere che sei disposto a supportare piattaforme aggiuntive, a un costo modesto che copra il tuo tempo e il tuo impegno nella creazione di pacchetti e test su quella piattaforma. Se una piattaforma si rivela molto diversa, potrebbe essere necessario addebitare un costo maggiore per il supporto continuo.
Oh, e non posso enfatizzare troppo il valore delle macchine virtuali per scenari come questo. Devi creare VM per ogni piattaforma supportata e forse più VM per piattaforma per semplificare il test di diverse configurazioni.
Ci sono state molte buone risposte (la mia inclusa :)) qui. Anche se questo riguarda più la compatibilità binaria (di cui devi preoccuparti).
Per l'installer consiglierei l'autopackage (abbiamo rilasciato con successo diverse versioni del nostro software con esso), hanno già fatto la parte "installer.sh" e altro (integrazione desktop per esempio).
Devi stare attento e testare i tuoi scenari di aggiornamento e cose del genere, a seconda di quanto sia complessa la struttura del tuo pacchetto, ma nel complesso è abbastanza pulito. Ho corretto alcuni bug con la gestione delle dipendenze in 1.2.6, quindi dovrebbe andare bene.
AGGIORNA :la domanda originale è stata eliminata, quindi ripubblicare qui la risposta completa, ignorare tutti i riferimenti all'autopackage, che è stato unito a Listaller, non sono sicuro che le parti pertinenti siano sopravvissute.
Per le librerie standard (come crypto++, pthreads, ecc.) che potrebbero essere disponibili in una distribuzione, collegale dinamicamente e chiedi agli utenti di prenderle dal loro repository di distribuzione. O link statico se possibile.
Per le librerie strane di cui devi controllare la versione (se vuoi distribuire l'app Qt4 sul territorio degli gnomi nemici, ad esempio), compilale tu stesso e installale in un luogo privato che solo la tua app conosce.
Non installare mai librerie private in posizioni standard a meno che tu non sia sicuro di non interferire con i sistemi di pacchetti di tutte le distribuzioni che supporti. (e che non possono nemmeno interferire con te).
Usa rpath invece di LD_LIBRARY_PATH e impostalo correttamente per tutti i tuoi file binari e tutte le DLL che fanno riferimento l'un l'altro. Puoi impostare rpath sul tuo binario su "$ORIGIN;$ORIGIN/../lib;/opt/my/private/libs" e fare in modo che il linker cerchi quei posti prima di qualsiasi percorso standard. (penso che sia necessario impostare un flag di linker affinché l'origine funzioni). Assicurati di impostare rpath anche sulle tue librerie:ad esempio QtGui ha bisogno di QtCore e se l'utente installa un pacchetto standard con una versione diversa, non vuoi assolutamente che venga raccolto (exe -> ../lib/QtGui.so ( 4.4.3) -> /usr/local/lib/QtCore.so (4.4.2) -- un modo sicuro per morire presto).
Se compili con qualsiasi rpath, puoi modificarlo successivamente con chrpath, rendendo così possibile modificare il percorso di installazione come parte della post-elaborazione o dello script di installazione.
Mantenere la compatibilità binaria. GLIB_C è praticamente statico per i tuoi utenti, quindi dovresti collegarti a una versione sufficientemente vecchia. 2.3 è una scommessa sicura. Puoi usare APBuild, un wrapper gcc che applica la versione GLIB_C e fa pochi altri trucchi per la compatibilità binaria, quindi non devi compilare tutte le tue app su una distribuzione molto vecchia.
Se ti colleghi a qualcosa in modo statico, generalmente dovrà essere ricostruito anche con APBuild, altrimenti è destinato a trascinare i simboli GLIB_C più recenti. Tutti i .so che installi privatamente dovranno naturalmente essere compilati anche con esso. A volte devi patchare librerie di terze parti per usare simboli più vecchi. (Ho dovuto patchare ruby per restituire i permessi reali invece di quelli effettivi, poiché non ci sono tali funzioni nel vecchio GLIB_C. Ancora non sono sicuro di aver rotto qualcosa :)).
Per l'integrazione con gli ambienti desktop (associazioni di file, tipi mime, icone, voci del menu di avvio, ecc.) utilizzare xdg-utils. Attenzione però, come tutto su Linux a loro non piacciono molto gli spazi nei nomi dei file :). Assicurati di testare queste cose su ogni distribuzione di destinazione:le implementazioni di xdg sono piene di bug e stranezze.
Per l'installazione effettiva puoi fornire una varietà di pacchetti nativi (rpm, deb e pochi altri), o implementare il tuo programma di installazione o trovare un programma di installazione che funzioni su tutte le distribuzioni aggirando i gestori di pacchetti nativi. Abbiamo usato con successo Autopackage (le stesse persone che hanno creato APbuild) per questo.
Potresti voler provare InstallBuilder. È multipiattaforma (funziona su Windows, Linux, Mac OS X, Solaris e quasi tutte le altre piattaforme Unix disponibili). È utilizzato da Intel, Motorola, GitHub, MySQL, Nokia/Trolltech e molte altre aziende, quindi sarai in buona compagnia :) Oltre agli installer binari, può anche creare RPM cross-distro e pacchetti DEB.
InstallBuilder è commerciale, ma offriamo licenze gratuite per programmi open source e sconti molto significativi per mISV o sviluppatori solisti, scrivici.