¿Por qué los repositorios de Ubuntu no tienen las últimas versiones de software?

¿Por qué los paquetes en los repositorios oficiales de Ubuntu son más antiguos que las últimas versiones (anteriores) de Debian Sid, PPA, los autores, etc.

Una versión de Ubuntu pasa por varias etapas antes de que llegue al público como producto terminado:

• Algún tiempo antes de que Ubuntu lance una versión, congela sus paquetes en cierto punto.

• Antes de que salga una versión, pero después de que el paquete se congele, el trabajo se realiza principalmente para solucionar todos los errores y problemas que puedan existir en esos paquetes. Las nuevas versiones de paquetes ya no se importan en los repositorios después de la congelación de paquetes o funciones.

• Una vez que se produce el lanzamiento, solo se producen cambios adicionales en esos paquetes para solucionar errores y problemas de seguridad. No se realizan más actualizaciones a los paquetes en el repositorio oficial, incluso si se lanzan nuevas versiones de los paquetes.

Se están importando constantemente nuevas versiones de paquetes (desde Debian) para la próxima versión de Ubuntu, hasta que ocurra la próxima congelación y se repita el mismo proceso.

Como ejemplo, puede echar un vistazo al calendario de lanzamiento de 12.04 .

Puede ver que a pesar de que 12.04 se lanzó en abril, en enero 12 sucedió algo llamado Debian Import Freeze .

Esta es solo la primera de muchas etapas de congelación que suceden antes del lanzamiento real y significa que en ese momento la importación de paquetes de las pruebas de Debian o las paradas inestables y el trabajo comienza en ellos para personalizar y solucionar problemas con ellos.

No se realizan actualizaciones después de ese punto en muchos paquetes y la versión que ese paquete tenía en ese punto es la versión presente y mantenida durante la vida útil de una versión.

Entonces, aunque hay versiones superiores del mismo paquete en los PPA de los desarrolladores o en los repositorios de Ubuntu + 1 , solo se incluirán en la próxima versión de Ubuntu.

Esto se hace por estabilidad, seguridad y funcionalidad. Los nuevos paquetes de sangrado que se importan todo el tiempo al repositorio principal significarían problemas y muchos más problemas por resolver. Una congelación en la versión de los paquetes ayuda a resolver eso y hacer que Ubuntu sea más seguro y estable para el usuario final.

Se lanza una nueva versión de Ubuntu cada 6 meses, por lo que cada 6 meses se preparan, prueban, personalizan y lanzan nuevos paquetes con una nueva versión. Las versiones futuras de un paquete se pueden instalar en su sistema a través de un PPA o simplemente descargándolo de un sitio web, pero la versión del paquete en el repositorio oficial sigue siendo la misma.

Para una mayor comprensión y una visión general interesante de lo que le sucedió a Ubuntu desde 10.04 hasta el lanzamiento de 12.04, eche un vistazo a ReleaseSchedule - LTS to LTS y la página de actualizaciones de versión estable para obtener una descripción completa y una explicación de una versión estable de Ubuntu.

Dos razones. El primero es bastante obvio: requiere que un humano pase tiempo actualizando el paquete cuando sale un nuevo upstream. La segunda es que si está ejecutando una versión estable en lugar de la versión de desarrollo actual, los paquetes NO se actualizan intencionalmente para evitar roturas. Ver http://wiki.ubuntu.com/StableReleaseUpdates .

Los paquetes se congelan para el lanzamiento y no se actualizan posteriormente por varias razones. Si se presentaron nuevos lanzamientos en el lanzamiento posterior, entonces la nueva versión ...

• podría traer nuevos errores, regresando así la funcionalidad que estaba presente al momento del lanzamiento
• necesita mano de obra para empaquetar, probar y cargar
• necesita su propio conjunto de actualizaciones de seguridad
• necesitaría traducciones actualizadas para su interfaz de usuario
• necesitaría documentación actualizada (y traducciones)
• hace que el soporte técnico sea más desafiante
• podría molestar a los usuarios que se han acostumbrado a las funciones de la versión anterior
• puede requerir dependencias más nuevas que podrían romper otras aplicaciones si se cambiaran en el repositorio
• puede romper otros paquetes que dependen de este
• puede romper scripts de usuario, plantillas, herramientas, etc. creados para la versión anterior

Dicho todo esto, tenga en cuenta que hay casos en los que Ubuntu realiza actualizaciones completas de las versiones de software en el repositorio. Firefox por ejemplo.

Además, hay un repositorio ubuntu-backports que los usuarios pueden optar por las actualizaciones de paquetes de software que no causarán problemas como los enumerados anteriormente. No está habilitado de forma predeterminada, por lo que los usuarios deben optar por él, lo que se hace para eliminar la sorpresa de que su software cambie por debajo de usted. Además, no tiene mucho personal, por lo que no estoy seguro de con qué frecuencia los paquetes realmente reciben actualizaciones.

Además, el equipo de SRU ha actualizado recientemente las políticas un poco, lo que con suerte hará que sea un poco más sencillo obtener actualizaciones de paquetes solo con corrección de errores.

Normalmente, las actualizaciones en las versiones lanzadas de Ubuntu son para seguridad y corrección de errores, ejemplos de tales errores incluyen:

• Errores que, en circunstancias realistas, pueden causar directamente una vulnerabilidad de seguridad. Estos son realizados por el equipo de seguridad y están documentados en SecurityTeam / UpdateProcedures.

• Errores que representan regresiones severas de la versión anterior de Ubuntu. Esto incluye paquetes que son totalmente inutilizables, como ser desinstalables o fallar al inicio.

• Errores que pueden, en circunstancias realistas, causar directamente una pérdida de datos del usuario Errores que no se ajustan a las categorías anteriores, pero (1) tienen un parche obviamente seguro y (2) afectan una aplicación en lugar de paquetes de infraestructura críticos (como X.org o el núcleo).

• Para las versiones de soporte a largo plazo, queremos habilitar regularmente nuevo hardware. Dichos cambios son apropiados siempre que podamos asegurarnos de no afectar las actualizaciones en el hardware existente. Por ejemplo, las modalidades de los controladores recién introducidos no deben solaparse con los controladores enviados anteriormente. -Nuevas versiones de software comercial en el archivo de socios Canonical.

  -FTBFS (no se puede generar desde la fuente) también se puede considerar. Tenga en cuenta que, en general, el proceso de lanzamiento garantiza que no haya binarios que no se hayan creado a partir de una fuente actual. Por lo general, esos errores solo se deben SRU junto con otra corrección de errores.

  -Para las nuevas versiones ascendentes de paquetes que proporcionan nuevas características, pero no corrigen errores críticos, se debe solicitar un backport.

Tomado de la excelente página wiki StableReleaseUpdates .

Trataré de responder sus preguntas en base a mis experiencias pasadas de los foros de ubuntu y ubuntu planet.

Supongo que me pregunto cómo se actualizan los repositorios de apt y por quién.

Los repositorios APT se actualizan desde el equipo de empaquetado en Ubuntu. El equipo de empaquetado obtiene todos los paquetes ascendentes de los desarrolladores que hacen una prueba de empaque inicial y otras cosas. Luego, el equipo de prueba hace la prueba final dando una señal de ida. Pero el equipo de empaque y los equipos de prueba son muy cautelosos sobre las dependencias y sus efectos secundarios para el sistema estable.

Cuando hay un retraso, ¿es porque el desarrollador no ha introducido la versión más reciente en el servidor relevante?

Si ve los cambios ascendentes, hay miles de desarrolladores que desean impulsar sus paquetes. Pero no todos tienen éxito en la corriente principal, esto se debe a varias razones. Suponga que la aplicación Gedit, una versión 2.2 es adecuada y funciona bien con Dbus 2.1 y Gtk 2.4, etc. Donde la versión Gedit 2.4 (muy nueva) necesita Gtk 2.5 y Dbus2.3 para funcionar. Ahora, el equipo de prueba y empaquetado (el equipo de lanzamiento también) no acepta esto porque cambiar un sistema existente que tiene dbus y gtk viejos con uno nuevo rompe todo lo demás. Espero que tengas el punto de dependencia del infierno.

¿Hay mucho más trabajo para el desarrollador para obtener la versión en una forma que el repositorio pueda usar?

No al canal aguas arriba. Pero para el canal de lanzamiento sí :).

PD: Podría haber algunos cambios en el proceso ahora en el canónico en comparación con lo que se explicó anteriormente. Pero es más o menos lo mismo.

La respuesta aceptada en el enlace fossfreedom publicado como comentario es muy buena.

En general, las versiones de paquetes lanzadas después de la primera parte del proceso de desarrollo de la nueva versión no aparecen en los repositorios principales de esa versión, por lo que una versión confiable de Ubuntu se puede probar a fondo.

Puede encontrar que algunos paquetes se lanzan al repositorio de backports si se incorporan con éxito en una futura versión de Ubuntu y si los desarrolladores creen que también funcionará con los anteriores. Los backports se pueden activar y desactivar en el Centro de software (Edición-> Fuentes de software-> Pestaña Actualizaciones-> Actualizaciones no compatibles)

La respuesta no está completa.

Hay ALGUNOS paquetes, que se pueden instalar en una versión de backport desde el Centro de software. En el lado derecho de la ventana, justo a la izquierda del botón Instalar / Cambiar, hay un cuadro de selección donde puede cambiar la versión.

Ejemplo de agradecimiento: El valor predeterminado conkyes ahora 1.8.xy lo tiene allí 1.9.0 (precise-backports)como backport. Por supuesto, los backports deben habilitarse primero.

Fuente: http://bugs.launchpad.net/ubuntu/+source/conky/+bug/1003727

EDITAR: Como se indica a continuación, no todos los paquetes tienen un backport, pero a veces puede tener un acceso temprano si tiene la suerte.