En primer lugar, encontré esta pregunta similar.¿Cómo hacer una aplicación portátil de Linux?pero en realidad no responde a mis preguntas, se trata más de cómo compilar para hacer que la aplicación sea portátil, algo que ya sé hacer (al menos eso creo) y no de implementación, como explicaré a continuación.
Esta es mi situación. Nos contrataron para resolver cierto problema para un cliente, por lo que desarrollaremos una aplicación de código cerrado que pretendemos venderle. Sin embargo, no se nos ha dado ningún detalle sobre dónde debería poder ejecutarse, con esto me refiero a qué distribución, versión del kernel o cualquier cosa realmente. La tarea es bastante sencilla y no depende de ningún controlador de bajo nivel ni de nada que pueda complicar su portabilidad. Sin embargo, dependemos de un par de bibliotecas de terceros; el siguiente es un esquema simple de las dependencias:
app --+-- libA
| +-- lib1
+-- libB --+-- lib2
+-- lib3
Donde libA,B y lib1,2,3 son todos proyectos de código abierto con licencias adecuadas (LGPL, ASL y BSD). Una vez compiladas, las dependencias compartidas de nuestro programa se convierten en libA, libB, lib1, lib2, lib3 y un montón de bibliotecas del sistema como libc, libm, libz, libstdc++, libpthread, etc. Todo está vinculado dinámicamente.
Ahora, como no tenemos una distribución objetivo, queremos mantenerla independiente de cualquier sistema de empaquetado como .deb o similar. Las dependencias directas (libA y libB) no son muy comunes, por lo que la opción obvia es entregarlas junto con nuestra aplicación. lib1,2,3 son en realidad más comunes (es decir, uno de ellos es libpng), aunque todavía no estoy seguro de que se instalen en el sistema de destino. Hemos decidido incluir los 5 en el paquete de software final.
Lo que no tenemos idea de qué hacer son las bibliotecas del sistema. ¿Cómo deberíamos manejar esto? ¿Asumimos simplemente que tendrán las bibliotecas correctas y rezamos por lo mejor? En tal caso, ¿qué pasaría en uno o dos años cuando una de esas bibliotecas cambie y nuestra aplicación deje de funcionar?
¿Deberíamos distribuirlos todos (libstdc++, glibc, etc.) con nuestro software? Esto no parece correcto y creo que podría ir en contra de los términos de la licencia que figuran en ellos. Sé que he usado algunos programas en el pasado que en realidad llevaban su propia copia de [al menos] algunas de esas bibliotecas, en realidad me llamó la atención porque era una versión anterior a la que estaba en mi sistema e intercambiarlas hizo que todo se detuviera. trabajando (lo cual descubrí por accidente).
¿Cómo se suele manejar esto?
Respuesta1
El enfoque estrictamente correcto para los ejecutables binarios portátiles en Linux es trabajar en contra de laBase estándar de Linuxy esespecificaciones detalladas. El LSB está diseñado para producir compatibilidad binaria entre distribuciones compatibles especificando versiones de biblioteca específicas (o compatibilidad con esas versiones). La LSB (o al menos una versión anterior) se formalizó comoISO/CEI 23360. Si crea su programa para vincularlo solo con las bibliotecas LSB (y las que él mismo envía), será portátil entre todos esos sistemas.
El LSB especifica el formato RPM para los paquetes, por lo que solo necesita producir uno (estrictamente). Un tarball también será suficiente si renuncia a la integración con el administrador de paquetes.
Con respecto a algunos de sus puntos específicos:
¿Asumimos simplemente que tendrán las bibliotecas correctas y rezamos por lo mejor?
Un programa bastante simple compatible con LSB probablemente se ejecutará en muchos sistemas tal como está, por lo que podría hacerlo.
Además de eso, varias distribuciones intentan cumplir con LSB, incluidas RHEL y SUSE. Algunos otros lo ofrecen a través de un paquete específico que incorpora las dependencias apropiadas. Por ejemplo, Debian tieneun paquetelsbque atrae lsb-corey varios otros, que a su vez atraen las dependencias apropiadas. Es posible que los sistemas de destino necesiten instalar dicho paquete para ejecutar su software.
El LSB es menos popular que antes y la compatibilidad formal ha disminuido para muchos sistemas, pero en la práctica es posible ejecutarlo de forma portátil en una gama bastante amplia. Incluso algunos sistemas que aspiran al cumplimiento pasan por alto algunos de los puntos más oscuros, pero para propósitos comunes a menudo no importa (y los mismos programas pueden funcionar en sistemas quenointentar ser compatible con LSB).
En tal caso, ¿qué pasaría en uno o dos años cuando una de esas bibliotecas cambie y nuestra aplicación deje de funcionar?
Cuando su aplicación deje de funcionar, su aplicación dejará de funcionar. Esta es una pregunta sobre el proceso de negocio.
¿Deberíamos distribuirlos todos (libstdc++, glibc, etc.) con nuestro software?
Probablemente no. Para libc, en particular, puede haber problemas de compatibilidad en tiempo de ejecución cuando se utilizan varias versiones a la vez en un sistema. Sin embargo, existen otras implementaciones de libc que pueden ser más prácticas de agrupar.
Si bien la mayoría de las bibliotecas se pueden agrupar con éxito, la venta de bibliotecas es un problema de mantenimiento y seguridad en general, por lo que desaconsejaría hacerlo siempre que se pueda evitar. Si se descubre un error o falla de seguridad en una biblioteca, actualizarlo en un lugar del sistema, que la distribución abordará, es más fácil y confiable que rastrear cada copia (¡y obtener paquetes de reemplazo de su parte!).
Como paso más práctico, quizás pregunte a su cliente dónde quiere que se ejecute. Quizás estés demasiado entusiasmado.
Respuesta2
En la práctica necesitarás hacervariospaquetes binarios (por ejemplo, .debpara Debian y Ubuntu, .rpmpara Fedora) para las distribuciones (y versiones) de Linux más comunes. Obviamente necesitarás crear paquetes diferentes para Fedora y Ubuntu, y es posible que necesites crear un paquete diferente para Debian Jessie y Ubuntu 16.04. Sin embargo,a vecesEs posible que se instale un paquete para Ubuntu en algún Debian (particular) o viceversa.
Sin embargo, no se nos ha dado ningún detalle sobre dónde debería poder ejecutarse, con esto me refiero a qué distribución, versión del kernel o cualquier cosa realmente.
Necesitas hablar con tu cliente.
En tal caso, ¿qué pasaría en uno o dos años cuando una de esas bibliotecas cambie y nuestra aplicación deje de funcionar?
Necesitará crear y lanzar variantes más nuevas de sus paquetes binarios, y gastará esfuerzos (y dinero) en ello.
Es posible que desee vincular (si es técnica y legalmente posible) algunas bibliotecas de forma estática (recuerde que la licencia LGPL recomienda vincular dinámicamente, o bien poder volver a vincular estáticamente en la máquina cliente). Por ejemplo, libstdc++es mucho más sensible a las versiones que el, libcpor lo que puedes vincularlo estática libstdc++y dinámicamente libc. En realidad YMMV.
Note que tenervariosLas versiones de una biblioteca de sistema determinada pueden funcionar o no en la práctica. Algunas bibliotecas utilizan los recursos del sistema de una manera específica, por lo que los detalles son muy importantes.
PD. Tal vez debería hablar más con su cliente y ofrecerle crear un software gratuito (código abierto). Algunos clientes podrían preferir eso.