Nachdem ich dies ein paar Mal mit kommerziellen Produkten durchgemacht habe, denke ich, dass die beste Antwort darin besteht, das native Installationsprogramm für jede unterstützte Plattform zu verwenden. Alles andere führt zu einer unangenehmen Erfahrung für den Endbenutzer, und in der Praxis müssen Sie sowieso auf jeder Plattform testen, die Sie unterstützen möchten, daher ist es nicht wirklich eine große Belastung, Pakete für jede Plattform zu pflegen. Die Idee, dass Sie eine Binärdatei erstellen können, die auf jeder Plattform "einfach funktionieren" kann, einschließlich einiger, von denen Sie noch nie gehört haben, funktioniert einfach nicht so gut.
Meine Empfehlung ist, dass Sie zunächst eine oder zwei Plattformen zur Unterstützung auswählen (Red Hat und Ubuntu wären meine Vorschläge) und dann die Benutzeranforderungen die Erstellung zusätzlicher Installationspakete vorantreiben lassen. Machen Sie vielleicht bekannt, dass Sie bereit sind, zusätzliche Plattformen gegen eine geringe Gebühr zu unterstützen, die Ihre Zeit und Ihren Aufwand beim Packen und Testen auf dieser Plattform abdeckt. Wenn sich eine Plattform als sehr unterschiedlich herausstellt, müssen Sie möglicherweise mehr für den laufenden Support berechnen.
Oh, und ich kann den Wert virtueller Maschinen für Szenarien wie dieses gar nicht genug betonen. Sie müssen VMs für jede Plattform erstellen, die Sie unterstützen, und möglicherweise mehrere VMs pro Plattform, um das Testen verschiedener Konfigurationen zu vereinfachen.
Hier gab es viele gute Antworten (meine eingeschlossen :)). Obwohl es hier mehr um die Binärkompatibilität geht (worüber Sie sich Sorgen machen müssen).
Für den Installer würde ich Autopackage empfehlen (wir haben erfolgreich mehrere Versionen unserer Software damit veröffentlicht), sie haben bereits den Teil "installer.sh" und mehr (zum Beispiel Desktop-Integration) gemacht.
Sie müssen vorsichtig sein und Ihre Upgrade-Szenarien und -Sachen testen, je nachdem, wie komplex Ihre Paketstruktur ist, aber insgesamt ist es ziemlich ordentlich. Ich habe einige Fehler bei der Behandlung von Abhängigkeiten in 1.2.6 behoben, also sollte es in Ordnung sein.
AKTUALISIEREN :Die ursprüngliche Frage wurde gelöscht. Wenn Sie die vollständige Antwort hier erneut veröffentlichen, ignorieren Sie alle Verweise auf das Autopaket, das in Listaller zusammengeführt wurde, und sind sich nicht sicher, ob relevante Teile überlebt haben.
Für Standardbibliotheken (wie Crypto++, pthreads usw.), die wahrscheinlich in einer Distribution verfügbar sind, verknüpfen Sie dynamisch und weisen Sie die Benutzer an, sie aus ihrem Distributions-Repository zu beziehen. Oder statisch verlinken, wenn es machbar ist.
Für seltsame Bibliotheken, deren Version Sie kontrollieren müssen (wenn Sie beispielsweise die Qt4-App auf dem Territorium feindlicher Gnome einsetzen möchten), kompilieren Sie sie selbst und installieren Sie sie an einem privaten Ort, von dem nur Ihre App weiß.
Installieren Sie niemals private Bibliotheken an Standardorten, es sei denn, Sie können sicher sein, dass Sie die Paketsysteme aller von Ihnen unterstützten Distributionen nicht stören. (und dass sie dich auch nicht stören können).
Verwenden Sie rpath anstelle von LD_LIBRARY_PATH und legen Sie es für alle Ihre Binärdateien und alle DLLs, die aufeinander verweisen, richtig fest. Sie können rpath in Ihrer Binärdatei auf "$ORIGIN;$ORIGIN/../lib;/opt/my/private/libs" setzen und Linker diese Orte vor allen Standardpfaden durchsuchen lassen. (Ich denke, ich muss ein Linker-Flag setzen, damit Origin funktioniert). Stellen Sie sicher, dass Sie rpath auch in Ihren Bibliotheken festlegen:Zum Beispiel benötigt QtGui QtCore, und wenn der Benutzer das Standardpaket mit einer anderen Version installiert, möchten Sie absolut nicht, dass es abgeholt wird (exe -> ../lib/QtGui.so ( 4.4.3) -> /usr/local/lib/QtCore.so (4.4.2) -- ein sicherer Weg, früh zu sterben).
Wenn Sie mit einem beliebigen rpath kompilieren, können Sie ihn später mit chrpath ändern, wodurch es möglich wird, den Installationsort als Teil der Nachbearbeitung oder des Installationsskripts zu optimieren.
Behalten Sie die Binärkompatibilität bei. GLIB_C ist für Ihre Benutzer ziemlich statisch, daher sollten Sie gegen eine ausreichend alte Version verlinken. 2,3 ist eine sichere Wette. Sie können APBuild verwenden – einen gcc-Wrapper, der die GLIB_C-Version erzwingt und einige andere binäre Kompatibilitätstricks ausführt, sodass Sie nicht alle Ihre Apps auf einer wirklich alten Distribution kompilieren müssen.
Wenn Sie statisch auf irgendetwas verlinken, muss es im Allgemeinen auch mit APBuild neu erstellt werden, da es sonst zwangsläufig neuere GLIB_C-Symbole zieht. Alle .so's, die Sie privat installieren, müssen natürlich auch damit erstellt werden. Manchmal müssen Sie Bibliotheken von Drittanbietern patchen, um ältere Symbole zu verwenden. (Ich musste Ruby patchen, um echte statt effektiver Berechtigungen zurückzugeben, da es solche Funktionen in älterem GLIB_C nicht gibt. Ich bin mir immer noch nicht sicher, ob ich etwas kaputt gemacht habe :)).
Verwenden Sie zur Integration in Desktop-Umgebungen (Dateizuordnungen, MIME-Typen, Symbole, Startmenüeinträge usw.) xdg-utils. Passen Sie jedoch auf, wie alles unter Linux mögen sie Leerzeichen in Dateinamen nicht wirklich :). Stellen Sie sicher, dass Sie diese Dinge auf jeder Ziel-Distribution testen – xdg-Implementierungen sind voller Fehler und Macken.
Für die eigentliche Installation können Sie entweder eine Vielzahl nativer Pakete (rpm, deb und einige mehr) bereitstellen oder Ihr eigenes Installationsprogramm ausrollen oder ein Installationsprogramm finden, das auf allen Distributionen funktioniert und native Paketmanager umgeht. Wir haben dafür erfolgreich Autopackage (die gleichen Leute, die APbuild gemacht haben) verwendet.
Vielleicht möchten Sie InstallBuilder ausprobieren. Es ist plattformübergreifend (läuft auf Windows, Linux, Mac OS X, Solaris und fast jeder anderen Unix-Plattform da draußen). Es wird von Intel, Motorola, GitHub, MySQL, Nokia/Trolltech und vielen anderen Unternehmen verwendet, Sie befinden sich also in guter Gesellschaft :) Zusätzlich zu binären Installern kann es auch distroübergreifende RPMs und DEB-Pakete erstellen.
InstallBuilder ist kommerziell, aber wir bieten kostenlose Lizenzen für Open-Source-Programme und sehr erhebliche Rabatte für mISVs oder Solo-Entwickler, schreiben Sie uns einfach.