Distribuciones evolutivas (y 2)

Decía ayer que hay más fórmulas para tener una distribución evolutiva que la propuesta de tener tanto paquetes "certificados" como "estables". Una de ellas es la de Red Hat, lanzar revisiones de su distribución enterprise en las que hay cambios pero el sistema base es el mismo, con lo que se garantiza la compatibilidad binaria. Algo parecido ocurría en los viejos tiempos de la Red Hat 7.0, 7.1, 7.2 y 7.3. Aunque este sistema sí implica actualizar la distribución, se supone que es un cambio controlado para que no deje de funcionar nada. Al fin y al cabo en Windows los famosos Service Pack también son una actualización masiva de sistema operativo ;-). Las distribuciones tipo RHEL así mismo suelen mantener la versión del kernel, pero portando a lo largo de su ciclo de vida drivers y a veces nueva funcionalidad de versiones del núcleo posteriores.

La otra idea interesante son los "backports" de Debian, también existentes en Ubuntu. Un "backport" es un paquete que se ha portado a una distribución estable, desde otra versión de la distribución lanzada posteriormente, pero muy importante, con las dependencias de la distribución vieja. Sólo hay "backports" de paquetes que no rompen compatibilidad binaria ni afectan a otros paquetes. Es una idea muy interesante, porque permite disfrutar de aplicaciones nuevas, pero ya probadas en otra distribución, sin tener que cambiar de versión toda la distribución. Además el mantenimiento no se dispara: en general es menos costoso mantener una misma versión del paquete para dos versiones de la distribución, que dos versiones distintas de una misma aplicación.

Lamentablemente es una buena idea poco llevada a la práctica. Los backports no están soportados oficialmente, no hay garantía de actualizaciones de seguridad o críticas, ni que se mantengan los paquetes mientras dura la distribución, ni que se tengan en cuenta el día que se migra el sistema a otra versión.

Para el caso concreto de Ubuntu, creo que sería buena idea una mezcla de la idea de los backports con la que comenté de la diferenciación entre "certificada" y "estable". El paquete "backport" portado de una distribución posterior, sería el paquete "estable", mientras que el paquete original sería el paquete "certificado". Aquí va la propuesta:

1. Los backports sólo serían para migrar aplicaciones a las versiones LTS (Long Term Support), utilizando paquetes presentes en las nuevas versiones de ciclo ordinario que surjan posteriormente; por tanto no habrá nuevas versiones de los paquetes como mínimo hasta que surja una nueva distribución (6 meses después), ni volverá a cambiarse salvo para actualizaciones críticas y de seguridad hasta que vuelva a surgir otra distribución al cabo de otros 6 meses. En realidad estos plazos serán más largos, pues hay que dar un plazo para comprobar que el paquete realmente es estable y puede portarse sin problemas.
   
2. Mientras dure la versión LTS estará garantizado que sigue actualizándose el "backport" con actualizaciones críticas y de seguridad. Una ventaja de los "backports" es que como esas actualizaciones críticas hay que hacerlas de todos modos para la versión nueva de la distribución, el mantenimiento es mucho más sencillo. Ahora bien, dado que la distribución LTS tiene más tiempo de vida que las versiones normales, podría darse el caso que un paquete procedente de un backport ya no se actualiza en la distribución de la que se portó. Afortunadamente, con aplicaciones de escritorio esto ocurrirá rara vez y durante poco tiempo, en el peor de los casos un año. Una distribución LTS tiene 3 años de vida en aplicaciones de escritorio frente a 1,5 de una distribución normal, pero la distribución normal como mínimo habrá salido 6 meses después de la LTS. Además, lo normal es que antes que acabe la vida de una distribución se cambie el backport al paquete de la siguiente distribución, salvo que no sea posible por romper compatibilidad.
   
3. Una cuestión deseable, pero no imprescindible, es que sea posible una marcha atrás de un paquete "backport" al original (certificado), o que sea posible tener instalados los dos sin consecuencias. Por ejemplo habría que tener cuidado con los archivos de configuración y posibles opciones nuevas.
4. Se puede considerar ir más allá de la idea original de "backport" y portar todo un bloque concreto, como Gnome. O hacer un "backport" de un componente crítico, como el kernel, que sin embargo afecta a pocos paquetes y rarísima vez a las aplicaciones finales de usuario.

En mi opinión es un buen momento para que en Ubuntu se planteen con más seriedad la fórmula LTS, que ya han confirmado estabilizaran con versiones cada dos años y me parece su aportación más interesante junto con el ciclo predecible de versiones. Lamentablemente Ubuntu entra en todos los frentes (por ejemplo en la de los sistemas "móviles") pero sin demasiada consistencia en comparación con lo que hacen los grandes como Red Hat cuando realmente se ponen con algo.

Mepis decidió volver a estar basada en Debian, por su decepción con Dapper sobre el hecho que no haya más que actualizaciones críticas: Mepis sí pretende tener una distribución más evolutiva, con versiones nuevas de las aplicaciones durante sus dos años de vida de actualizaciones.

La gran pega que veo a Dapper, es que es una versión más sólo que con actualizaciones críticas durante más tiempo, mientras que para Red Hat y Novell su orientación son las versiones enterprise y las otras tienen mucho de campo de pruebas para precisamente que las enterprise sean redondas. Dapper tiene fallos garrafales que no corrigen en temas como que la versión del compilador de c++ y la de gcj no coinciden, o que hay problemas para usar cups desde un sistema remoto. El institucionalizar los backports en las LTS sería un buen punto de inflexión. Tweet