Para los que no conozcan VegnuX NeonatoX, decir que es una distribución 100% libre (reconocida ya por la Free Software Foundation de Latino América) desarrollada en Venezuela y basada en Linux From Scratch, es decir, que se ha creado desde cero, sin basarse en ninguna otra distribución (a parte de LFS, claro). Además NeonatoX utiliza el sistema de gestión de paquetes Nhopkg desde hace ya varias versiones.

Laguna de Piedra viene con dos sabores: la tradicional versión XFCE y la nueva versión con KDE4 que hará las delicias de lo KDEros. Para ir abriendo boca podéis descargarlas, usando el torrent, desde aquí:

• VegnuX NeonatoX 0.5.1 KDE4 (KDE 4.3.2).
• VegnuX NeonatoX 0.5.1 XFCE (XFCE 4.6.1).

Os dejo unas capturas de mi instalación de NeonatoX KDE4.

Conocí esta aplicación hace unos meses de manos de pragmart, y hace unas semanas, al finalizar los exámenes de febrero, desarrollé los típicos scripts de instalación de software desde las fuentes: configure, Makefile, etc. para contribuir de alguna manera con este proyecto. Aunque el proyecto hace tiempo que dejó de estar activo, su creador publicó en la página del proyecto mi aportación.

Os animo, a todos aquellos que os pueda ser útil que lo descarguéis e instaléis.

Estoy trabajando en los labels que Nhopkg utilizarán para designar los nombres de los paquetes en próximas versiones. Para versiones futuras, y actual versión en desarrollo, hay que considerar que Nhopkg será multiplataforma, llegando a múltiples arquitecturas y sistemas operativos (BSD, Solaris, etc.) y esta información debería ser visible rápidamente.

La mejor forma de dar a conocer esta información es a través del nombre del paquete (package label). El label debe contener la siguiente información: nombre, versión y revisión del paquete, además de la arquitectura y el nombre del kernel del sistema operativo.

El problema, o la dificultad, es elegir la disposición de estos elementos, para facilitar la lectura y la obtención de los datos por parte del mismo programa. En la lista de correo de Nhopkg he propuesto varias alternativas para discutir sus ventajas frente a otras y para pedir sugerencias, ya que al fin y al cabo, a quien interesa, es a los usuarios que lidiarán con dichos paquetes.

Las dos opciones prácticamente descartadas son:

• <name>-<version>-<release>.<os>.<arch>.nho (Ej.: gimp-2.6.7-1.linux.i386.nho) ya que, en principio no es equivalente para los paquetes fuente, en los que la arquitectura y el sistema operativo debería reducirse a src (Ej.: gimp-2.6.7-1.src.nho).

• <name>-<version>-<release>.<arch>_<os>.nho (Ej.: gimp-2.6.7-1.i386_linux.nho) ya que podría haber problemas al trabajar con arquitecturas x86_64 (Ej.: gimp-2.6.7-1.x86_64_linux.nho).

Finalmente, la opción que empieza a tener más fuerza es la de usar:

• <name>-<version>-<release>.<arch>-<os>.nho (Ej:. gimp-2.6.7-1.i386-linux.nho).

Aunque éste no es un tema crucial para el desarrollo de Nhopkg, pero si considero que es bueno conocer la opinión del usuario final y futuros desarrolladores sobre ciertos temas, que les van a tocar directamente. Espero opiniones sobre el tema, y si queréis, podéis apuntaros a la lista de desarrollo de Nhopkg para seguir más de cerca el desarrollo.

Ahora os muestro el diagrama de la base de datos, que en principio usará Nhopkg. Digo en princpio porque al estar en contrinuo desarrollo nunca se sabe si podrá cambiar algunos aspectos de ésta, o quizá completamente. Ahí va un adelanto, cualquier sugerencia será bienvenida.

Para el que quiera curiosear algo más, en el repositorio bazaar puede encontrar los archivos SQL.