Seguimiento de¿El binario Ubuntu LTS es compatible con Debian?
Sé que los paquetes binarios de Ubuntu y Debian son incompatibles la mayoría de las veces. Sé que mezclar paquetes de diferentes fuentes es generalmente una mala idea, y a la gente se le advierte que no lo haga todo el tiempo. Así que mantengamos la discusión puramente técnica.
¿Qué introducirá exactamente la incompatibilidad entre paquetes de diferentes fuentes, cuando por supuesto las dependencias no son el problema?
------ Separación, más detalles a continuación ------
Comoel dicho:
sobre compatibilidad binaria (https://wiki.ubuntu.com/MarkShuttleworth#What_about_binary_compatibility_between_distributions.3F): Es probable que los paquetes de Debian se creen con diferentes versiones de la cadena de herramientas, por lo que puede tener problemas
¿Por qué las diferentes versiones de la cadena de herramientas darán problemas? Como
- Sé cómo incorporar el conjunto mínimo de paquetes de Debian sid a mi versión estable de Debian y lo he estado haciendo todo el tiempo.
- Solía llevar paquetes de la versión anterior de Ubuntu/Debian a sus versiones más nuevas, o incluso
- copiar un solo ejecutable de mi Ubuntu/Debian a otra distro, ya sea RedHat o incluso FreeBSD,
ynuncaTuve un problema antes. Entonces, ¿qué está causando exactamente el problema que dice la gente?
¿Es gcc o versión kernel? Es poco probable para mí, ya que se actualizan todo el tiempo durante mi vida usando esa versión.
¿Entonces es la versión de glibc? Pero normalmente será compatible con versiones anteriores y muy probablemente, ¿verdad?
Citando la respuesta de mi primer enlace:
Realmente no hay garantía ni implicación de compatibilidad cruzada. No espere que las comunidades de Debian o Ubuntu le muestren mucha compasión si las cosas salen mal. En ese caso, estarás prácticamente solo. Siempre que estés de acuerdo con eso, no dudes en intentarlo.
Básicamente veo advertencias contra esta práctica en todas partes, pero nadie da más explicaciones técnicas. ¿Alguien puede enumerar los riesgos de hacerlo y esos posibles problemas técnicos, por favor?
Esa respuesta me ayudará, si quiero/necesito mezclar paquetes de diferentes fuentes, digamos Debian o Ubuntu, o dentro de la misma distribución pero con diferentes versiones (si las dependencias no son el problema), a elegir el enfoque más seguro, para extraer un PPA que estoy seguro nunca terminará en Debian, en Debian Bullseye que estoy usando actualmente.
Respuesta1
Las incompatibilidades binarias y de paquetes son diferentes y vale la pena explicarlas por separado.
Incompatibilidad binaria
Esto es a lo que normalmente se hace referencia cuando la gente habla de diferencias en la cadena de herramientas, etc.Cadena de herramientasLas incompatibilidades en sí mismas son inusuales, porque la cadena de herramientas es, junto con el kernel, una de las áreas donde los desarrolladores son más cuidadosos a la hora de preservar la compatibilidad con versiones anteriores. Como resultado, un binario creado en el pasado debería continuar ejecutándose, siempre y cuando subinariolas dependencias siguen estando disponibles; eso se reduce a mantener las bibliotecas que necesita.
Donde las cosas fallan es con la compatibilidad hacia adelante: no se puede garantizar la ejecución de un binario creado "en el futuro". Esto comúnmente se muestra como símbolos faltantes en la biblioteca C (que se detectan precisamente porque los desarrolladores de la biblioteca C tienen mucho cuidado en mantener la compatibilidad). Uno podría pensar que la biblioteca C no cambia mucho, por lo que crear un programa con diferentes bibliotecas C no debería cambiar los símbolos que necesita y debería seguir siendo compatible. Ese no es el caso, y las funciones cambian regularmente de maneras incompatibles con versiones anteriores; la biblioteca C conservahacia atráscompatibilidad al continuar proporcionando versiones de funciones compatibles con interfaces anteriores, con un símbolo de versión apropiado. Por ejemplo, la versión 2.33 de la biblioteca GNU C tiene cambios incompatibles en funciones tan comunes como la statfamilia ( fstat/ lstat/ statetc.); un programa creado con una configuración predeterminada de 2.33, que utilice esas funciones, requerirá la versión 2.33 de la biblioteca C para ejecutarse.
Las bibliotecas relacionadas con la cadena de herramientas y la biblioteca C se mantienen de tal manera que dichas incompatibilidades aparecen como cambios de símbolo de biblioteca o cambios de nombre y, por lo tanto, terminan codificadas en dependencias de paquetes (para software empaquetado) o son detectadas por el vinculador dinámico. (para binarios separados).
En bibliotecas que no se mantienen tan cuidadosamente como la biblioteca C, tales incompatibilidades no aparecen tan inmediatamente, solo aparecen si se prueba la combinación defectuosa (e incluso entonces, tal vez solo en ciertas circunstancias). Los desarrolladores de distribuciones generalmente solo prueban los paquetes en el contexto de la versión que se está desarrollando, por lo que no sabrán que el paquete que crearon para Ubuntu 20.04 se instala correctamente en Debian 10, pero matará a su ardilla mascota si lo usa entre la 1 a.m. y las 2 a.m. CEST en junio. 21.
Esto conduce muy bien a...
Incompatibilidad de paquetes
Ya sea que esto se haga conscientemente o no, los paquetes rara vez se crean en el vacío: son parte de un lanzamiento de distribución. Esto comienza con la fuente del paquete (y más generalmente, la fuente del proyecto): los proyectos y paquetes se crean en los sistemas de sus desarrolladores y, a menos que se ponga un gran esfuerzo en ello, es posible que no codifiquen con precisión sus dependencias.
Esto se traduce en dependencias de paquetes binarios y dependencias descritas en la documentación. Es posible que el mantenedor de un proyecto no se dé cuenta de que su proyecto en su configuración actual solo funciona porque, digamos, la versión 239 de systemd comenzó a configurar el sistema de cierta manera. Es posible que los mantenedores de paquetes tampoco se den cuenta de eso, si el lanzamiento de la distribución en la que están trabajando ya tiene la versión 239 de systemd (tenga en cuenta que los mantenedores de distribuciones generalmente viven en el futuro,es decirse desarrollan en lo que será el próximo lanzamiento).
Todo estopodríapuede quedar atrapado en las pruebas, pero una vez que comience a mezclar y combinar binarios de diferentes distribuciones y lanzamientos, es probable que sea la primera persona en probar su combinación exacta de paquetes y versiones binarias. YesoPor eso no se recomienda: la mayoría de los usuarios quieren usar sus sistemas, no probarlos.
Por supuesto, y esto encaja con tu experiencia, en muchos casos todo simplemente funciona. Esto también contribuye al sesgo que percibe: las personas tienden a no escribir publicaciones (o preguntas, en un contexto de Stack Exchange) explicando cómo instalaron el paquete X de la distribución Y en su sistema Z, y simplemente funcionó. Entonces, la mayor parte del contenido que ves en este dominio son escenarios donde las cosasnofuncionó, o terminó siendo complicado de configurar, o se rompió algo más; y es comprensible que las personas sean reacias a dedicar tiempo a ayudar a alguien a solucionar un problema probablemente único que ellos mismos se provocaron al hacer algo que se recomendó explícitamente.contra.