Debian se quita pesos de encima: la propuesta Vancouver


Debian es la distribución de GNU/Linux (y otros kernels) que más
arquitecturas soporta: once hasta el momento, más una de manera no
oficial (amd64). Este hecho se suele mencionar como una de las causas
principales por las que las releases tardan
tanto en ser preparadas. También tiene repercusiones importantes para
los mirrors, que encuentran en Debian un devorador insaciable de
espacio en disco.

A principios de marzo, hubo una reunión en Vancouver, Canadá, en la
que los Release Managers y los encargados de la gestión del archivo de
Debian (ftpmasters) prepararon un plan, a implementar justo
después de Sarge, para aliviar la situación. Hoy han sido anunciadas las
conclusiones
, que aunque generarán un poco de discusión interna en
el Proyecto, pueden considerarse una buena aproximación a lo que pasará.
En este artículo hago un resumen de las mismas.

Análisis de la situación

Debian goza de un gran prestigio en el mundo del Software Libre, e
incluso los no usuarios asumen su excelencia. Es madre de un gran número de distribuciones derivadas, y aunque no realiza
releases todo lo frecuentemente que debiera, proporciona distintas ramas en
desarrollo que alcanzan e incluso superan el nivel de calidad de otras
distribuciones.

Una de las características principales de Debian es el número de
arquitecturas soportadas, once hasta la fecha (siendo Debian, para
muchas de ellas, la única distribución “importante” disponible). La
cantidad de trabajo que este número supone, sin embargo, es elevada.
Entre otros, cabe mencionar:

  • para poder hacer una release, el instalador
    tiene que funcionar en todas las arquitecturas. Esto no es trivial, y
    acaba necesitando grandes cantidades de tiempo (Joey Hess, el principal
    desarrollador del d-i, se lamenta de vez en cuando del tiempo que se le
    va como sysadmin de todas las máquinas que tiene para ir probando
    el installer; tiempo que podría emplear en implementar mejoras para el
    instalador en i386)

  • el Kernel Team tiene que preparar kernels para cada arquitectura y
    subarquitectura, muchas de las cuales están abandonadas por los
    desarrolladores upstream. Preparar un fix de seguridad para las once
    arquitecturas en un tiempo razonable es, prácticamente, un imposible.

  • paquetes cruciales como libc y gcc periódicamente sufren problemas
    en alguna u otra arquitectura, lo cual para completamente el curso
    normal del desarrollo: si no hay un compilador que funcione en las once
    arquitecturas, no hay release

  • aunque de manera casi automática, la compilación en todas las
    arquitecturas de los paquetes según se van preparando quita tiempo a los
    desarrolladores encargados; de vez en cuando, además, las máquinas
    encargadas de esta tarea (autobuilders) tienen problemas, los
    paquetes tardan en ser compilados, y con ello que su entrada a testing
    se retrasa y el trabajo de los Release Managers se multiplica

Por las razones anteriores, no sólo las releases tardan más, sino que
además testing sufre severos retrasos en cuanto a acualizaciones de
seguridad. Por otra parte, y de manera independiente al trabajo a
realizar, el elevado número de arquitecturas impone una severísima carga
en los mirrors en cuanto
a espacio necesario. Ésta es una de las principales razones por las que
amd64 aún no es una
arquitectura oficial: no cabe.

El meeting: quién, dónde, cómo y qué

Se veía venir que algo iba a tener que pasar. Los problemas para hacer
releases se hacían cada vez más grandes, y el éxito de otras
distribuciones derivadas, p.ej. Ubuntu, no era sino otra señal de la
necesidad de “hacer algo”.

Uno de los candidatos en las elecciones a Debian
Project Leader
de este año, Andreas
Schuldei
, se encargó de buscar patrocinadores para una reunión en
Vancouver de las personas más relevantes en el proceso de producir una
nueva release: los actuales Release Managers y ayudantes (Steve
Langasek, Colin Watson, Andreas Barth, Frank Lichtenheld, Joey Hess), y
los encargados de todo lo relacionado con el archivo (los
ftpmasters, entre otros: James Troup, Ryan Murray, Anthony
Towns).

Los problemas para los que se han buscado soluciones son dos:

  • cómo propiciar unas releases más frecuentes (cada 12-18 meses)
  • cómo disminuir la actual carga en los mirrors

Las releases

Todo el problema radica en conciliar las siguientes dos verdades: de un
lado, «no se pueden conseguir releases más frecuentes con 11
arquitecturas», y de otro, «no podemos tirar a la basura las
arquitecturas menos usadas, pues dejaríamos de ser Debian». Seguir como
hasta la fecha sería, desde luego, un desfavor para con los usuarios,
que verdaderamente necesitan una Debian más reciente que 3 años, y
desechar arquitecturas es un desfavor a los usuarios que las necesitan.

La propuesta, entonces, se ha basado en el siguiente análisis: «para las
arquitecturas más marginales, las stable releases no son lo más
importante, y es suficiente con que exista soporte al menos en sid; por
otra parte, el número de arquitecturas por el que existe un “interés
general” no es elevado. Estableceremos unos criterios objetivos para
determinar qué arquitecturas son las “importantes”, y nos concentraremos
en ellas para las releases; el resto, seguirán existiendo en la rama
inestable, y podrán hacer releases independientes».

En la práctica, lo anterior significa que: lá próxima release de Debian,
llamada Etch, sólo saldrá para cuatro arquitecturas: i386, amd64,
ia64 y powerpc. Éstas son las que, a fecha de hoy, cumplen todos los
requisitos necesarios para ser consideradas arquitecturas candidatas.
Para el resto de arquitecturas seguirán compilándose los paquetes de
manera normal, pero no se introducirán retrasos porque por
ejemplo falte una actualización de seguridad en el kernel para arm. La
lista concreta de requisitos se puede consultar en el mail
con las conclusiones
.

Lo anterior no hará felices a algunas personas, entre ellas, incluso,
algunos de los que han decidido que sea así. Sin embargo, la propuesta
ha caído como agua de mayo entre la mayoría de desarrolladores, muchos
de los cuales se desesperaban y sentían impotencia al ver al Proyecto
cada vez más atascado. En el mail, no obstante, se menciona
explícitamente que los desarrolladores que así lo deseen podrán trabajar
en preparar releases de aquellas arquitecturas que les interesen, con la
pleno disponibilidad de las infraestructuras de Debian pero sin afectar
a la línea principal de desarrollo.

Los mirrors

Para solucionar el problema del espacio en los mirrors, se va a realizar
una separación en el archivo, de manera que los mirrors sólo tengan que
almacenar las arquitecturas para las que haya más demanda (i386 y amd64,
principalmente), y puedan de manera opcional incluir alguna de
las otras.

¿Y Sarge qué?

En otro orden de cosas, el mail también menciona que los preparativos
para Sarge van cada vez por mejor camino. Se dice que estamos
aproximadamente a dos semanas de tener soporte de seguridad en testing,
que era hasta la fecha el mayor impedimento, y se pide a los
desarrolladores que se concentren en arreglar los últimos bugs y se
abstengan de subir nuevas versiones al archivo.

Conclusión

En Debian estamos comprometidos con los usuarios, tal y como se recoge
en nuestro Contrato
Social
. Intentamos ser conscientes de nuestras limitaciones y
problemas, y hacemos lo posible por ponerles remedio. El apoyo de
nuestros usuarios nos da fuerzas para seguir.

Este post ha sido traido de forma automatica desde https://web.archive.org/web/20140625063149/http:/bulma.net/body.phtml?nIdNoticia=2164 por un robot nigromante, si crees que puede mejorarse, por favor, contactanos.


Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.