Ayant vécu cela plusieurs fois avec des produits commerciaux, je pense que la meilleure réponse est d'utiliser le programme d'installation natif pour chaque plate-forme prise en charge. Tout le reste produit une expérience désagréable pour l'utilisateur final, et dans la pratique, vous devez de toute façon tester sur chaque plate-forme que vous souhaitez prendre en charge, donc ce n'est pas vraiment une charge importante de maintenir des packages pour chacun. L'idée que vous pouvez créer un binaire qui peut "fonctionner" sur toutes les plates-formes, y compris certaines dont vous n'avez même jamais entendu parler, ne fonctionne vraiment pas très bien.
Ma recommandation est que vous choisissiez une plate-forme ou deux à prendre en charge initialement (Red Hat et Ubuntu seraient mes suggestions) et que vous laissiez ensuite la demande des utilisateurs conduire la création de packages d'installation supplémentaires. Faites peut-être savoir que vous êtes prêt à prendre en charge des plates-formes supplémentaires, moyennant des frais modestes qui couvrent votre temps et vos efforts pour empaqueter et tester sur cette plate-forme. Si une plate-forme s'avère très différente, vous devrez peut-être facturer davantage pour une assistance continue.
Oh, et je ne saurais trop insister sur la valeur des machines virtuelles pour des scénarios comme celui-ci. Vous devez créer des VM pour chaque plate-forme que vous prenez en charge, et peut-être plusieurs VM par plate-forme pour faciliter le test de différentes configurations.
Il y avait beaucoup de bonnes réponses (la mienne incluse :)) ici. Bien qu'il s'agisse davantage de compatibilité binaire (dont vous devez vous soucier).
Pour l'installateur, je recommanderais l'autopackage (nous avons publié avec succès plusieurs versions de notre logiciel), ils ont déjà fait la partie "installer.sh" et plus encore (intégration au bureau par exemple).
Vous devez être prudent et tester vos scénarios de mise à niveau et tout, en fonction de la complexité de la structure de votre package, mais c'est plutôt bien dans l'ensemble. J'ai corrigé quelques bugs avec la gestion des dépendances dans 1.2.6, donc ça devrait aller.
MISE À JOUR :La question d'origine a été supprimée, donc republiez la réponse complète ici, ignorez toutes les références à l'autopackage, qui a été fusionné dans Listaller, pas sûr que les parties pertinentes aient survécu.
Pour les bibliothèques standard (telles que crypto++, pthreads, etc.) susceptibles d'être disponibles dans une distribution, créez un lien dynamique et indiquez aux utilisateurs de les obtenir à partir de leur référentiel de distribution. Ou un lien statique si c'est faisable.
Pour les bibliothèques étranges dont vous devez contrôler la version (si vous souhaitez déployer l'application Qt4 sur le territoire de gnomes ennemis par exemple), compilez-les vous-même et installez-les dans un endroit privé que seule votre application connaît.
N'installez jamais de bibliothèques privées dans des emplacements standard, sauf si vous êtes sûr de ne pas interférer avec les systèmes de paquets de toutes les distributions que vous supportez. (et qu'ils ne peuvent pas non plus interférer avec vous).
Utilisez rpath au lieu de LD_LIBRARY_PATH et définissez-le correctement pour tous vos fichiers binaires et toutes les dll qui se référencent les unes les autres. Vous pouvez définir rpath sur votre binaire sur "$ORIGIN;$ORIGIN/../lib;/opt/my/private/libs" et demander à l'éditeur de liens de rechercher ces emplacements avant tout chemin standard. (il faut définir un indicateur de lien pour que l'origine fonctionne, je pense). Assurez-vous également de définir rpath sur vos bibliothèques :par exemple, QtGui a besoin de QtCore, et si l'utilisateur installe un package standard avec une version différente, vous ne voulez absolument pas qu'il soit récupéré (exe -> ../lib/QtGui.so ( 4.4.3) -> /usr/local/lib/QtCore.so (4.4.2) -- un moyen sûr de mourir tôt).
Si vous compilez avec n'importe quel rpath, vous pouvez le modifier ultérieurement avec chrpath, ce qui permet de modifier l'emplacement d'installation dans le cadre du post-traitement ou du script d'installation.
Maintenir la compatibilité binaire. GLIB_C est à peu près statique pour vos utilisateurs, vous devez donc établir un lien avec une version suffisamment ancienne. 2.3 est une valeur sûre. Vous pouvez utiliser APBuild - un wrapper gcc qui applique la version GLIB_C et fait quelques autres astuces de compatibilité binaire, vous n'avez donc pas à compiler toutes vos applications sur une très ancienne distribution.
Si vous créez un lien vers quelque chose de manière statique, il devra généralement être reconstruit avec APBuild également, sinon il est obligé de faire glisser les nouveaux symboles GLIB_C. Tous les .so que vous installez en privé devront naturellement être construits avec lui aussi. Parfois, vous devez patcher des bibliothèques tierces pour utiliser des symboles plus anciens. (J'ai dû patcher ruby pour retourner les permissions réelles au lieu des permissions effectives, car il n'y a pas de telles fonctions dans l'ancien GLIB_C. Je ne sais toujours pas si j'ai cassé quoi que ce soit :)).
Pour l'intégration avec les environnements de bureau (associations de fichiers, types MIME, icônes, entrées du menu Démarrer, etc.), utilisez xdg-utils. Attention cependant, comme tout sur Linux, ils n'aiment pas vraiment les espaces dans les noms de fichiers :). Assurez-vous de tester ces choses sur chaque distribution cible - les implémentations xdg sont criblées de bogues et de bizarreries.
Pour une installation réelle, vous pouvez soit fournir une variété de packages natifs (rpm, deb et quelques autres), soit déployer votre propre programme d'installation, soit trouver un programme d'installation qui fonctionne sur toutes les distributions en contournant les gestionnaires de packages natifs. Nous avons utilisé avec succès Autopackage (les mêmes personnes qui ont créé APbuild) pour cela.
Vous voudrez peut-être essayer InstallBuilder. Il est multiplateforme (fonctionne sous Windows, Linux, Mac OS X, Solaris et presque toutes les autres plates-formes Unix). Il est utilisé par Intel, Motorola, GitHub, MySQL, Nokia/Trolltech et de nombreuses autres sociétés, vous serez donc en bonne compagnie :) En plus des installateurs binaires, il peut également créer des packages RPM et DEB inter-distributions.
InstallBuilder est commercial, mais nous offrons des licences gratuites pour les programmes open source et des remises très importantes pour les mISV ou les développeurs solo, écrivez-nous.