unidistro


Con Unidistro hemos alcanzado un punto en el que creo que la herramienta comienza a ser bastante útil. De hecho, uno de los problemas que estoy viendo es que, al menos a mi, se me están terminando las ideas para añadir funcionalidad. Es por esto por lo que me he propuesto a mi mismo intentar crear algo de comunidad para el proyecto.

La parte de picar código más o menos va saliendo, lo bueno que tiene es que lo que picas lo puedes probar más o menos rápidamente y si está mal lo corriges y punto. Ahora bien, lo de crear comunidad es algo bastante más difuso. Mucha gente dice que las comunidades aparecen por arte de magia y que no se sabe muy bien qué es lo que tiene que tener un proyecto para que sea bien aceptado por los pares.

Una cosa creo que si está clara, no puede haber comunidad sin una buena documentación y una buena “difusión” del proyecto. Es por esto que he comenzado a soltar por los mentideros de la red perlas sobre Unidistro y a picar algo de documentación en el wiki de Ubuntu.

Eso parece que va teniendo efecto. Cuando hacemos alguna modificación el tipo avisa de a cuántas personas le notifica el cambio y cada vez veo más gente. En ese momento es cuando me entra la vena cotilla y me da por investigar quién es quién, parece toda gente interesante involucrada de alguna manera en cosas parecidas a Bardinux.

La contribución más grande que hemos tenido hasta la fecha es la de usuario del wiki que nos ha puesto algunos comentarios y sugerencias así como una bonita tabla de contenidos en el wiki y algunas correcciones a “nuestro inglés”. Evidentemente hemos hecho caso a las sugerencias de “nuestros usuarios” y ahora tenemos una página de documentación en castellano y la principal en inglés. Además, AzraelNightwalker, nuestro “top contributor”, nos ha publicitado en varios sitios interesantes, ahora estamos listados al menos en la especificación para crear una herramienta para hacer fácilmente una personalización de Ubuntu. Esperamos que siga aumentando el interés de la comunidad por nuestro proyecto. Para ello intentaremos escuchar todos los comentarios que se hagan sobre nosotros e ir rompiendo algunas barreras de entrada para la colaboración.

Desde esta tarde llevo dándole vueltas a como simplificar el proceso de selección de paquetes. La idea estaba clara dpkg --get-selections. He tenido un ratito y he hecho un pequeño script en python que genera un metapaquete que depende de todos los paquetes instalados en el sistema. Mi idea es poder utilizar esto para disponer de versiones iniciales de varias distribuciones, particularmente de gutsy y hardy, generadas por unidistro. En teoría si arranca desde el cdrom y ejecutas este script obtienes lo que va dentro de la sección metapackages, es una manera muy bestia pero debería funcionar.

NOTA: En la siguiente página está el código

(más…)

Ayer fue un día intenso para mi con unidistro. Primero René nos dio una PACO sobre el asunto. Cuando llegué a casa tenía ganas de probarlo y estuve jugueteando un poco. Básicamente hice lo mismo que había hecho René en la charla. Al final, utilizando un isolinux de un CD de Bardinux, logré generar la iso correspondiente, aunque no la llegué a probar.

Tras estar jugando un rato me surgieron muchas cosas que se podrían hacer para mejorar el sistema pero no me había enfrentado al código. Una de las cosas que se me ocurrió era que los scripts en BASH podrían sobrar; pero claro hacer esto sin tener ni idea del código es complicado, así que se lo comenté al maestro de la comunidad y ahí quedó. Después, en mi ratito de unidistro, me puse a cambiar el módulo que se utiliza para parsear la entrada. Antes usábamos getopt, que no parecía ser suficientemente bueno.

Tras googlear un poco vi un módulo llamado optparser que servía para lo mismo y además forma parte del core de python. Siguiendo la documentación del módulo para python 2.3 no fue difícil hacer un par de ejemplitos sencillos aunque tengo instalado python 2.5.1.

Tras las pruebas pruebas me puse a añadir las opciones reales. Hubo algunas que no incluí porque no funcionan en el framework todavía pero en esencia están todas. René llegó y hablando un poco con él nos dimos cuenta de que simplemente con este cambio y llevando a cabo las distintas opciones en el orden correcto podríamos conseguir el objetivo de hacer innecesarios los scripts en bash (al menos algunas veces).

Con una línea como:

python framework.py -r create -i psmisc -i unidistro -i unidistro-live -i unidistro-base -i unidistro-desktop-base -i kubuntu-kde4 -i kubuntu-kde4-desktop -i kubuntu-kde4-live -i kdebase-dev-kde4 -i kdebase-workspace-dev -i kdebase-runtime -i kdm -i kdm-kde4 -i ksmserver -i unidistro-office -m ../unidistro-data/kubuntu-kde4.xml

Hay que tener en cuenta que los múltiples -i son para instalar cada uno de esos paquetes; pero en realidad lo lógico es sólo haya una. Es decir si tu proyecto se llama bardinux tendrás un metapaquete que dependa de todo lo que haga falta para que se instalen todos los paquetes necesarios.

Hoy durante la presentación de unidistro he tenido algunos problemas porque no tenía en ningún repositorio el paquete de unidistro-dev. Estuve intentando subir una y mil veces el dichoso paquete a mi “archivo de paquetes personal” de launchpad pero que no quería el nota aparecer.

Finalmente lo he conseguido hacer. He subido el paquete en lugar de como anónimo como mi usuario de launchpad y en lugar de poner la distro gutsy he puesto hardy. Mañana intentaré subir otra versión del paquete, esta algo más completa, pero al menos ya he entendido cómo demonios subir los paquetitos y que el temita funcione. Espero tener algo presentable para el sábado en hispalinux.

Por ahora el paquete lo puedes descargar desde usando:

deb http://ppa.launchpad.net/agarfu/ubuntu hardy main
deb-src http://ppa.launchpad.net/agarfu/ubuntu hardy main

Espero que todo vaya bien y en unos pocos días se presente Bardinux 2.5, así que ya tenemos en el horizonte bardinux 3.0.

Hay algo más de tiempo para la salida del 3 que el que hubo entre 2.0 y 2.5 por esto intentaremos mejorar un poco más el framework.

Hay algunas cosas sencillas que hacer para ganar en usabilidad, voy a intentar enumerarlas por aqui:

  • Eliminar getopts para parsear la entrada por línea de comandos y sustituirlo por otra cosa más potente o simplemente analizar a mano la línea de comandos.
  • Añadir soporte para listar los paquetes definidos en los ficheros de configuración.
  • Añadir soporte para generar uno sólo de los paquetes que hay definidos en el xml.
  • Añadir soporte para ficheros de configuración locales (Ej: .unidistro). La intención es que podamos sobrrescribir algunos prámetros con la configuración local, por ejemplo, si el project dir en el xml dice que tenemos que generar la distro en /distro/versionx y nosotros queremos hacerlo en otro sitio, poder añadir en nuestra configuración local una ruta sin necesidad de cambiar el xml.
  • Mejorar el sistema de generación de paquetes de configuración. Lo que queda es hacer un dpkg-buildpackage dentro del directorio del paqute.
  • Crear un paquete que contenga el framework, es posible que para eso haya que tocar algo los imports y esas cosas.
  • Añadir soporte para especificar [post|pre]-[install|remove] específicos para cada paquete y para permitir introducir código en los que se generan automáticamente para los paquetes de configuración.

Creo que eso es todo por ahora. Alberto me comentó algunas mejoras que hacer en framework para los paquetes de configuración. La primera idea es la más sencilla, implementar la posibilidad de añadirle documentación a los paquetes. Supongo que lo ideal sería indicarle al framework dónde está la documentación (directorio) y que incluya esa info en el paquete final. La siguiente propuesta es poder añadir una pantalla con información en el proceso de instalación del paquete. Creo que esta también es sencilla, simplemente habrá que ver cómo lo hace cualquier otro paquete de por ahí. Pero en cuanto a la úlitma funcionalidad que propuso no la veo clara. Me dijo que estaría muy bien que el paquete pudiera avisar de lo que va a hacer y que le diera la opción al usuario de continuar con la instalación o no hacerlo. Esto a priori tengo que investigarlo un poco porque no se muy bien cómo hacer esto.

Pues eso, hoy he visto un par de ramas creadas en launchpad.net de Unidistro. Las dos ramas que he visto han sido una de Esaú, compañero jadario y la otra de Jonathan Riddell, el principal desarrollador de Kubuntu. Esto es motivo suficiente como para plantearse darle un lavado de cara al proyecto y hacerlo fácilmente utilizable por más gente.

He comenzado a hacer el paquete para el framework. En mi rama hay algo que funciona, pero no tiene ninguna dependencia. Para hacer el paquete he seguido de alguna manera esta guía que he visto enlazada en el blog de lcabrera en gulic. El paquete es algo castañoso todavía pero ya hay algo, creo que eso es lo primero que sacaré de la lista de todo.