Después de ver que hay bastante gente empezando a usar TCOS había
que cambiar la forma de sacar nuevas versiones. Necesitamos tener algo
estable (que no cambie 2 veces por semana) si queremos que esto se use
en producción.
Hasta ahora todo el trabajo estába enfocado en el trunk del SVN, y según se iban añadiendo parches y mejoras se compilaba y se subía al repositorio.
En
un principio no era demasiado trabajo generar varios paquetes pero esto
se ha vuelto una carga de trabajo bastante grande. Recuerdo que los
paquetes de TCOS se compilan para i386 y amd64 y para las
distribuciones Ubuntu daper, edgy, feisty, gutsy, hardy y Debian etch,
testing y unstable.
Ocho versiones distintas de cada paquete y los que no son «arquitecture all» tenemos 16, ¡una locura!
El proceso de compilación es un tanto especial y siempre he querido escribir sobre él.
Hay un Makefile,
que se encarga de hacer una copia del paquete en cuestión del trunk a
un directorio temporal (build) donde se borran los directorios ocultos
del SVN, se renombra el directorio de fuentes con la versión tomada del
changelog y se llama a pdebuild (wrapper de debuild con pbuilder) para
compilar cada paquete en su versión y con las dependencias correctas.
Además
se aplican parches si la distribución objetivo tiene problemas, por
ejemplo en dapper o etch se cambian las dependencias de compilación
(Build-Depends) de usplash-dev a libbogl-dev y libgd-dev ya que se usa
una versión bastante antígua de usplash.
Estos parches vienen en los Makefile de cada paquete (al final) y son opcionales, se puede ver este ejemplo en el paquete initramfs-tools-tcos. En otros se parsean variables (como el número de versión) o se fuerza que use python2.4 cuando el que viene en el sistema es python2.3 (otra vez etch y dapper).
Como
se puede ver no es muy dificil mantener un paquete y que sea compatible
con cosas tan distintas como Ubuntu Dapper o Debian unstable, pero
requiere saber los trucos de cada una y hacer muchas pruebas.
Como ejemplo práctico si queremos generar el paquete tcosmonitor para Debian testing:
1.- Descargamos el trunk
svn co https://www.tcosproject.org/svn/tcos/trunk
2.- Preparamos (sino lo tenemos ya, nuestro chroot de testing)
pbuilder --create --basetgz /var/cache/pbuilder/testing.tgz --distribution testing
3.- Deberiamos tener en /usr/local/sbin un script llamado pdebuild-testing con este contenido:
#!/bin/bash
pdebuild --auto-debsign $@ -- --basetgz /var/cache/pbuilder/testing.tgz
4.- Ejecutamos dentro del directorio trunk:
make pkg PKG=tcosmonitor VER=testing
Aparecerá un mensaje que indica que estamos compilando para testing, pulsando enter se abrirá nuestro editor de texto por defecto con el debian/changelog.
En él hay que añadir una línea del tipo "* Rebuild in Debian testing", cambiar el número de versión a algo del estilo x.xxtesting1, y cambiar el codename (donde pone unstable) a testing. Guardamos y cerramos ese archivo.
Nos dejará en un nuevo shell dentro del directorio de las fuentes (ya limpio de la basura del svn), normalmente no hay que hacer nada allí, así que escribimos exit o pulsamos Ctrl+D, en ese momento es cuando se llama a pdebuild-testing, y si todo va bien firmaremos el paquete con nuestra clave GPG y lo tendremos listo en /var/cache/pbuilder/results
Tengo otro directorio que sincronizo con rsync+ssh en el mirror principal, donde con un script escaneo /var/cache/pbuilder/results/ en busca de archivos *changes que son los que se inyectan en el repositorio con reprepro (por cada paquete y versión hay que volver a firmar con GPG los cambios) y por último sincronizo mi copia del mirror local con la oficial.
Todo este proceso tan complicado hay que hacerlo 8 veces por cada paquete «arch all» y 16 por cada paquete que contiene binarios específicos de la arquitectura: «arch any». La compilación para amd64 la hago en una máquina virtual con una Debian unstable amd64 y con pbuilder de máquinas de 64.
Por lo que tengo 3 mirror, el oficial (desde donde descargais TCOS), la copia en el servidor de 32bits y la copia del de 64bits. Tengo que tener cuidado cuando los sincronizo porque una mala sincronización puede borrar paquetes que ya estaban y poner unos más antíguos.
Después del tocho de explicación vienen las novedades.
Ayer estuvimos pensando en el IRC, que deberíamos trabajar con una copia (que hemos etiquetado como experimental) y hacer los cambios alli, cuando el sistema sea estable se libera una versíon estable para todos y con esto evitamos tener que compilar paquetes nuevos por cada cambio de 2 o 3 líneas.
A partir de ahora (y si nadie dice lo contrario) las versiones del mirror oficial de paquetes y del trunk se congelan y no se actualizarán tan a menudo, si queremos tener un aula de terminales no es lógico actualizar su software 2 veces a la semana.
Si quieres usar siempre las últimas versiones tendrás que compilar desde el «branch experimental», que funciona exactamente igual a lo explicado aquí con el Makefile, o esperar a que experimental se funda con trunk (cosa que pasara cada mes o dos meses, depende)
Eso es todo... :wq
