Poté, co jsem to několikrát prošel u komerčních produktů, myslím, že nejlepší odpovědí je použít nativní instalační program pro každou podporovanou platformu. Cokoli jiného vytváří pro koncového uživatele nepříjemnou zkušenost a v praxi stejně musíte testovat na každé platformě, kterou chcete podporovat, takže údržba balíčků pro každou z nich není příliš velká zátěž. Myšlenka, že můžete vytvořit binární soubor, který může „prostě fungovat“ na každé platformě, včetně těch, o kterých jste nikdy ani neslyšeli, prostě opravdu nefunguje tak dobře.
Moje doporučení je, že si nejprve vyberete platformu nebo dvě, které chcete podporovat (mým doporučením jsou Red Hat a Ubuntu), a poté nechte poptávku uživatelů řídit vytváření dalších instalačních balíčků. Možná dejte vědět, že jste ochotni podporovat další platformy za mírný poplatek, který pokryje váš čas a úsilí při balení a testování na této platformě. Pokud se platforma ukáže jako velmi odlišná, možná budete muset účtovat více za trvalou podporu.
Oh, a nemohu přehnaně zdůrazňovat hodnotu virtuálních strojů pro scénáře, jako je tento. Musíte vytvořit virtuální počítače pro každou podporovanou platformu a možná i více virtuálních počítačů na platformu, aby bylo snadné testovat různé konfigurace.
Bylo zde mnoho dobrých odpovědí (včetně mé :)). I když to je spíše o binární kompatibilitě (o kterou se musíte starat).
Pro instalátor bych doporučil autopackage (úspěšně jsme s ním vydali několik verzí našeho softwaru), udělali již část "installer.sh" a další (například integrace s desktopem).
Musíte být opatrní a testovat své scénáře upgradu a podobně, v závislosti na tom, jak složitá je struktura vašeho balíčku, ale celkově je to docela úhledné. Opravil jsem několik chyb se zpracováním závislostí v 1.2.6, takže by to mělo být v pořádku.
AKTUALIZACE :Původní otázka byla smazána, takže znovu zveřejněte úplnou odpověď zde, ignorujte všechny odkazy na autopackage, který byl začleněn do Listaller, nejsem si jistý, zda relevantní části přežily.
U standardních knihoven (jako crypto++, pthreads atd.), které budou pravděpodobně dostupné v distribuci, se dynamicky propojujte a řekněte uživatelům, aby je získali ze svého úložiště distro. Nebo odkaz staticky, pokud je to možné.
U podivných knihoven, které musíte ovládat (pokud chcete například nasadit aplikaci Qt4 na území nepřátelských trpaslíků), si je zkompilujte a nainstalujte na soukromé místo, o kterém ví pouze vaše aplikace.
Nikdy neinstalujte soukromé knihovny do standardních míst, pokud si nejste jisti, že nenarušíte systémy balíčků všech distribucí, které podporujete. (a že vám také nemohou zasahovat).
Použijte rpath místo LD_LIBRARY_PATH a nastavte jej správně pro všechny vaše binární soubory a všechny dll, které na sebe odkazují. Můžete nastavit rpath na vašem binárním souboru na "$ORIGIN;$ORIGIN/../lib;/opt/my/private/libs" a nechat linker prohledat tato místa před všemi standardními cestami. (myslím, že musím nastavit příznak linkeru, aby původ fungoval). Ujistěte se, že jste nastavili rpath i ve svých knihovnách:například QtGui potřebuje QtCore, a pokud uživatel náhodou nainstaluje standardní balíček s jinou verzí, absolutně nechcete, aby byl zvednut (exe -> ../lib/QtGui.so ( 4.4.3) -> /usr/local/lib/QtCore.so (4.4.2) -- jistý způsob, jak zemřít brzy).
Pokud kompilujete s libovolnou cestou rpath, můžete ji později změnit pomocí chrpath, což vám umožní vyladit umístění instalace jako součást postprocessingu nebo instalačního skriptu.
Udržujte binární kompatibilitu. GLIB_C je pro vaše uživatele do značné míry statický, takže byste měli odkazovat na nějakou dostatečně starou verzi. 2.3 je sázka na jistotu. Můžete použít APBuild – obal gcc, který vynucuje verzi GLIB_C a dělá několik dalších triků s binární kompatibilitou, takže nemusíte všechny své aplikace kompilovat na opravdu starém distru.
Pokud na cokoli odkazujete staticky, obecně to bude muset být také přestavěno pomocí APBuild, jinak to nutně přetáhne novější symboly GLIB_C. Všechny .so, které si nainstalujete soukromě, budou přirozeně muset být také vytvořeny s ním. Někdy musíte opravit knihovny třetích stran, abyste mohli používat starší symboly. (Musel jsem opravit ruby, abych vrátil skutečná oprávnění namísto účinných, protože ve starším GLIB_C žádné takové funkce nejsou. Stále si nejsem jistý, jestli jsem něco neporušil :)).
Pro integraci s desktopovými prostředími (asociace souborů, typy MIME, ikony, položky nabídky Start atd.) použijte xdg-utils. Ale pozor, stejně jako všechno na linuxu nemají moc rádi mezery v názvech souborů :). Ujistěte se, že tyto věci otestujete na každé cílové distribuci – implementace xdg jsou plné chyb a podivností.
Pro skutečnou instalaci můžete buď poskytnout různé nativní balíčky (rpm, deb a několik dalších), nebo zavést svůj vlastní instalační program, nebo najít instalační program, který funguje na všech distribucích a obchází nativní správce balíčků. Úspěšně jsme k tomu použili Autopackage (stejní lidé, kteří vytvořili APbuild).
Možná budete chtít vyzkoušet InstallBuilder. Je multiplatformní (běží na Windows, Linux, Mac OS X, Solaris a téměř na jakékoli jiné unixové platformě). Používají ho Intel, Motorola, GitHub, MySQL, Nokia/Trolltech a mnoho dalších společností, takže budete v dobré společnosti :) Kromě binárních instalátorů umí také vytvářet cross-distro RPM a DEB balíčky.
InstallBuilder je komerční, ale nabízíme bezplatné licence pro programy s otevřeným zdrojovým kódem a velmi výrazné slevy pro mISV nebo sólo vývojáře, stačí nám napsat.