Habiendo pasado por esto un par de veces con productos comerciales, creo que la mejor respuesta es usar el instalador nativo para cada plataforma compatible. Cualquier otra cosa produce una experiencia desagradable para el usuario final y, en la práctica, debe probar en todas las plataformas que desea admitir de todos modos, por lo que no es una carga significativa mantener paquetes para cada uno. La idea de que puedes crear un binario que "simplemente funcione" en todas las plataformas, incluidas algunas de las que nunca has oído hablar, simplemente no funciona tan bien.
Mi recomendación es que elija una plataforma o dos para admitir inicialmente (Red Hat y Ubuntu serían mis sugerencias) y luego deje que la demanda del usuario impulse la creación de paquetes de instalación adicionales. Tal vez haga saber que está dispuesto a admitir plataformas adicionales, por una tarifa modesta que cubra su tiempo y esfuerzo en empaquetar y probar en esa plataforma. Si una plataforma resulta ser muy diferente, es posible que deba cobrar más por el soporte continuo.
Ah, y no puedo dejar de enfatizar el valor de las máquinas virtuales para escenarios como este. Debe crear máquinas virtuales para cada plataforma que admita y quizás varias máquinas virtuales por plataforma para facilitar la prueba de diferentes configuraciones.
Hubo muchas buenas respuestas (la mía incluida :)) aquí. Aunque eso tiene más que ver con la compatibilidad binaria (de lo que sí debe preocuparse).
Para el instalador, recomendaría el paquete automático (lanzamos con éxito varias versiones de nuestro software con él), ya hicieron la parte "installer.sh" y más (integración de escritorio, por ejemplo).
Debe tener cuidado y probar sus escenarios de actualización y demás, dependiendo de cuán compleja sea la estructura de su paquete, pero en general es bastante ordenado. Solucioné algunos errores con el manejo de dependencias en 1.2.6, por lo que debería estar bien.
ACTUALIZAR :La pregunta original se eliminó, por lo que volver a publicar la respuesta completa aquí, ignorar todas las referencias al paquete automático, que se fusionó con Listaller, no estoy seguro de si las partes relevantes sobrevivieron.
Para las bibliotecas estándar (como crypto++, pthreads, etc.) que probablemente estén disponibles en una distribución, vincúlelas dinámicamente y dígales a los usuarios que las obtengan de su repositorio de distribución. O enlazar estáticamente si es factible.
Para las bibliotecas extrañas de las que debe controlar la versión (si desea implementar la aplicación Qt4 en el territorio de los gnomos enemigos, por ejemplo), compílelas usted mismo e instálelas en un lugar privado que solo su aplicación conozca.
Nunca instale bibliotecas privadas en lugares estándar a menos que pueda estar seguro de no interferir con los sistemas de paquetes de todas las distribuciones que admite. (y que tampoco pueden interferir contigo).
Use rpath en lugar de LD_LIBRARY_PATH y configúrelo correctamente para todos sus archivos binarios y todos los archivos DLL que hacen referencia entre sí. Puede establecer rpath en su binario en "$ORIGIN;$ORIGIN/../lib;/opt/my/private/libs" y hacer que el enlazador busque esos lugares antes que cualquier ruta estándar. (creo que tengo que establecer una bandera de enlace para que el origen funcione). Asegúrese de configurar rpath en sus libs también:por ejemplo, QtGui necesita QtCore, y si el usuario instala un paquete estándar con una versión diferente, absolutamente no quiere que lo recoja (exe -> ../lib/QtGui.so ( 4.4.3) -> /usr/local/lib/QtCore.so (4.4.2) -- una manera segura de morir pronto).
Si compila con cualquier rpath, puede cambiarlo más tarde con chrpath, lo que hace posible modificar la ubicación de instalación como parte del procesamiento posterior o el script de instalación.
Mantener la compatibilidad binaria. GLIB_C es bastante estático para sus usuarios, por lo que debe enlazar con alguna versión suficientemente antigua. 2.3 es una apuesta segura. Puede usar APBuild, un envoltorio gcc que aplica la versión GLIB_C y hace algunos otros trucos de compatibilidad binaria, por lo que no tiene que compilar todas sus aplicaciones en una distribución realmente antigua.
Si se vincula a algo de forma estática, generalmente tendrá que reconstruirse también con APBuild; de lo contrario, se verá obligado a arrastrar símbolos GLIB_C más nuevos. Naturalmente, todos los .so que instale de forma privada también tendrán que construirse con él. A veces es necesario parchear bibliotecas de terceros para usar símbolos más antiguos. (Tuve que parchear Ruby para devolver permisos reales en lugar de efectivos, ya que no existen tales funciones en GLIB_C anterior. Todavía no estoy seguro si rompí algo :)).
Para la integración con entornos de escritorio (asociaciones de archivos, tipos MIME, íconos, entradas del menú de inicio, etc.) use xdg-utils. Sin embargo, tenga cuidado, como todo en Linux, realmente no les gustan los espacios en los nombres de archivo :). Asegúrese de probar esas cosas en cada distribución de destino:las implementaciones de xdg están plagadas de errores y peculiaridades.
Para la instalación real, puede proporcionar una variedad de paquetes nativos (rpm, deb y algunos más), implementar su propio instalador o encontrar un instalador que funcione en todas las distribuciones sin pasar por los administradores de paquetes nativos. Usamos con éxito Autopackage (las mismas personas que hicieron APbuild) para eso.
Es posible que desee probar InstallBuilder. Es multiplataforma (se ejecuta en Windows, Linux, Mac OS X, Solaris y casi cualquier otra plataforma Unix). Lo utilizan Intel, Motorola, GitHub, MySQL, Nokia/Trolltech y muchas otras empresas, por lo que estará en buena compañía :) Además de los instaladores binarios, también puede crear paquetes DEB y RPM entre distribuciones.
InstallBuilder es comercial, pero ofrecemos licencias gratuitas para programas de código abierto y descuentos muy significativos para mISV o desarrolladores independientes, solo escríbanos.