Cómo crear módulos para Slax

Crear Nuevos Modulos

Es posible crear módulos Slax de muchas maneras diferentes. Todos los comandos aquí descritos trabajan directamente en Slax, pero pueden también trabajar en su propia distribución. Para ese caso, descargue 'linux-live scripts' y ejecute ./install Obtenga aquí 'Linux-Live scripts'.

El siguiente comando convierte un paquete TGZ de Slackware en un módulo de Slax:

tgz2lzm software.tgz software.lzm

Si desea modificar su paquete de Slackware antes de que el módulo sea creado, use:

installpkg -root /tmp/aaaa software.tgz

Instalará su paquete TGZ en un raíz diferente (/tmp/aaaa aquí). Modifique los archivos que necesite y convierta finalmente el árbol de directorio en un módulo, utilizando:

dir2lzm /tmp/aaaa software.lzm

Modificar módulos existentes

El siguiente comando extraera el contenido de su módulo de Slax a un directorio en /tmp/aaaa:

mkdir /tmp/aaaa
lzm2dir software.lzm /tmp/aaaa

Asegúrese de que tiene suficiente espacio libre allí. Cuando el módulo sea extraido, podrá modificar todo su contenido en /tmp/aaaa/, y cuando haya terminado, empaquete nuevamente el módulo al formato .lzm utilizando:

dir2lzm /tmp/aaaa software.lzm

Si solo desea explorar el contenido de un módulo (sin extraerlo a un disco), puede montarlo utilizando el siguiente comando:

mkdir /mnt/aaaa
mount -t squashfs -o loop /path/software.lzm /mnt/aaaa

Puede crear módulos Slax del modo que usted prefiera, siempre y cuando sea usted el único que los use. Pero si desea compartir sus módulos con otros usuarios, tendrá que seguir las reglas que se describen en este documento. Estas reglas están diseñadas para que el primer beneficiado sea el usuario final; de modo tal que si usted las desobedece, su módulo núnca será aceptado en el repositorio oficial de módulos Slax.
Breve descripción técnica

Un módulo Slax es un sistema de archivos squashfs comprimido, que tiene la extensión .lzm. El módulo es creado por la utilidad mksquashfs y puede ser extraido (descomprimido) utilizando unsquashfs. Ambas herramientas deben ser parchadas (modificadas) para que soporten el algoritmo de compresion LZMA. Estas utilidades ya están incluidas en Slax.

Cada módulo Slax contiene todos los archivos y directorios con su ruta completa. Por ejemplo, un módulo que contenga bash (el binario y algunas páginas del manual) se vería así:

/bin/
/bin/bash
/usr/
/usr/man/
/usr/man/man1/
/usr/man/man1/bash.1

Las reglas

1) Todos los directorios en su módulo tienen que ser accesibles para un usuario común. Configure todos los permisos de directorios a 755 (drwxr-xr-x) a menos que haya una razón importante para usar permisos diferentes sobre un directorio en particular.

find ./ -type d | xargs chmod -v 755;

2) Mantenga pequeño el tamaño de su módulo. Descomprima todos los archivos que con seguridad pueda dejar sin comprimir (por ejemplo las páginas del manual, ya que LZMA las comprimirá muchísimo mejor), borre todos los archivos que no sean necesarios para correr el software (por ejemplo documentación innecesaria, sonidos no utilizados, imágenes png/jpg, traducciones no necesarias en /usr/share/locale) y elimine de los binarios todos los símbolos innecesarios.

ind ./usr/man/ -type l -name "*.gz" | xargs -r gunzip -f
find ./usr/man/ ! -type l -name "*.gz" | xargs -r gunzip
find . | xargs file | grep ELF | cut -f 1 -d : | xargs strip --strip-unneeded

3) Si compila el módulo partiendo del código fuente, provea el script de construcción (build script) que haya sido utilizado para crear el módulo. El script de construcción debe poder realizar la creación total del módulo. No se permite, fuera del script de construcción, ningún trabajo manual (copiar / borrar archivos, etc). El script sirve como documentación sobre cómo crear el módulo; además facilita la tarea de tomar el relevo con su módulo en caso de que usted deje de actualizarlo. Copie el script de construcción de su módulo en:

/usr/src/slaxbuilds/your_module_name.slaxbuild

4) Cuando compile el software, asegúrese de utilizar los cflags y parámetros correctos. Lo siguiente es recomendado para la utilización de instrucciones i486 (las cuales proveen de la mejor compatibilidad hacia atrás), pero afine el desempeño del código como si la arquitectura objetivo fuese i686. En Slax es posible ejecutar 'configure-for-slax' como un atajo. Hace lo mismo:

CFLAGS="-O3 -march=i486 -mtune=i686" ./configure --prefix=/usr --build=i486-Slackware-linux

5) Nunca incluya en su módulo archivos existentes en Slax, incluso si los hubiese modificado. En otras palabras, su módulo nunca debe 'sobreescribir' ningún archivo existente en Slax, a menos que haya una razón específica para hacerlo. Esto puede hacer que su módulo sea incompatible con nuevas versiones de Slax, e incluso causar problemas con módulos de otros usuarios. Si realmente tiene que sobreescribir un archivo de Slax, (por ejemplo para poder agregar una nueva ruta en /etc/ld.so.conf), es mejor que escriba un script de inicio (startup script), que modifique (actualice) el archivo en particular, en vez de sobreescribirlo con el módulo.

Ejemplo de un script de inicio para borrar una linea de ld.so.conf y añadir una nueva al final:

#!/bin/bash
sed -i -r '\;/usr/local/lib;d' /etc/ld.so.conf
echo '/opt/kde/lib' >> /etc/ld.so.conf

He aquí una lista a modo de ejemplo, de algúnos archivos que núnca deberían ser incluídos en su módulo:

/etc/init.d
/etc/rc.d/rc.S
/etc/rc.d/rc.M
/etc/rc.d/rc.K
/etc/rc.d/rc.local
/lib/modules/2.6.x/modules.dep
/lib/modules/2.6.x/modules.alias
/etc/ld.so.conf
/etc/ld.so.cache
/etc/passwd
/etc/group
/etc/shadow

6) Si necesita ejecutar algo durante la activación del módulo, o durante el inicio del sistema o durante el apagado, utilice los directorios de estilo sysvinit (sysvinit-style directories). La mejor manera es hacer en el directorio /etc/rc.d/init.d/, un script universal que entienda los argumentos 'start' y 'stop'. Todos los scripts en ese directorio serán ejecutados con el argumento 'start' durante la activación del módulo, y con el argumento 'stop' durante la desactivación. Como opción, puede establecer links simbólicos que comiencen con la letra S mayúscula (de Start, para iniciar) y la letra K mayúscula (de Kill, para terminar) dentro de los directorios sysvinit correspondientes al nivel de ejecución (runlevel) deseado; por ejemplo /etc/rc.d/rc3.d/. Toda vez que sea cambiado el nivel de ejecución, Slax ejecutará todos los script que comiencen con K y se encuentren en el directorio del nivel de ejecución anterior (para ternminar), y todos los scripts que comiencen con S y se encuentren en el directorio del nivel de ejecución actual.

En el siguiente ejemplo, Slax ejecutará 'apache.sh start' en el nivel de ejecución 3 (esto significa durante el inicio del sistema) y ejecutará 'apache.sh stop' en los niveles de ejecución 0 ó 6 (es decir, cuando Slax se esté apagando o reiniciando).

# Script universal de ejemplo: /etc/rc.d/init.d/apache.sh

#!/bin/bash
if [ "$1" = "start" ]; then
echo "start apache @ startup"
... start apache here ...
fi
if [ "$1" = "stop" ]; then
echo "stop all apache @ shutdown"
... stop apache processes here ...
fi

# Una vez creado su script universal, agregue los siguientes links simbólicos:

ln -s ../init.d/apache.sh /etc/rc.d/rc3.d/S-apache
ln -s ../init.d/apache.sh /etc/rc.d/rc0.d/K-apache
ln -s ../init.d/apache.sh /etc/rc.d/rc6.d/K-apache

7) Si su software puede ser iniciado en una interfaz gráfica GUI (por ejemplo en KDE, XFCE, etc.), debe incluir en su módulo un ícono y agregar un archivo de entrada de menú para que el usuario pueda iniciar la aplicación facilmente buscandola en su menú. Para agregar una entrada de menú, simplemente cree dos archivos:

/usr/share/applications/your-application.desktop
/usr/share/pixmaps/your-applications-icon.png

El primer archivo (*.desktop) describe la entrada de menú. Podría verse así:

[Desktop Entry]
Encoding=UTF-8
Exec=firefox %u
Icon=/usr/share/pixmaps/firefox.png
Type=Application
Categories=Application;Network;
Name=Firefox
Name[cs]=Firefox
GenericName=Web Browser
GenericName[cs]=Webovy prohlizec
MimeType=text/html
X-KDE-StartupNotify=true

Cuando sea iniciado el software contenido en su módulo, este deberá correr directamente y sin diálogos innecesarios, sugerencias del día o acuerdos de licencia. Tenga en mente que si el usuario incluyó su módulo en un CD de solo lectura, no tiene manera de recordar la configuración (para deshabilitar las sugerencias, acordar la licencia, etc), por tanto, el módulo no debería molestarlo cada vez que se inicia.

9) Las dependencias de su módulo deben ser tan pocas como sea posible. Eso significa, que otros pocos módulos serán requeridos por el suyo, lo mejor, pero también recuerde mantener el tamaño de su módulo tan pequeño como sea posible. Por ejemplo, si su módulo puede correr en forma segura sin python, entonces asegúrese de borrar todos los scripts python de su módulo, en lugar de incluir python en él.

Si su módulo requiere algunas librerías, que prácticamente funcionarían de manera exclusiva para su módulo, entonces incluya las librerías directamente en su módulo y no las agregue por separado. Como un ejemplo, XFCE requiere bastantes librerías xfcelib*, mientras estas prácticamente son innecesarias para algo más. Luego entonces, inclúyalas en el módulo XFCE.

En contraste, si su modulo necesite algunas librerías o programas, que puedan ser de utilidad para otros módulos, nunca las agregue en el módulo, pero inclúyalas por separado. Por ejemplo, los binarios de python siempre deberán agregarse por separado y nunca incluirlos dentro de ningún modulo.


Subir sus módulos

Cuando su módulo siga las reglas, entonces lo podrás compartir con otros. El repositorio oficial de módulos deberá ser lo más amigable posible para el usuario final; por esta razón, es muy importante que cada módulo tenga un buen icono, una captura de pantalla que represente como luce el software ejecutándose bajo Slax (utilizando el estilo por defecto de KDE y la decoración de las ventanas), y es necesario proveer de una descripción significativa, que permita a los usuarios entender más acerca del módulo.

Algunas librerías o programas no muestran ninguna interfaz grafica de usuario, en tal caso la captura de pantalla no es necesaria. Pero tiene que proveerse un buen y colorido icono. Los módulos sin icono raramente son aceptados. Si usted piensa que no es posible encontrar un icono para su módulo, entonces piénselo nuevamente. No es necesario que el icono sea único para su módulo, pero los usuarios deberán ser capaces de distinguir entre un editor de texto y un cliente de correo con solo mirar los iconos.

El nombre no deberá contener ningún guión o guión bajo innecesario, simplemente ponga el nombre del programa seguido del número de versión. El siguiente es correcto: vim 7.1. El siguiente no es correcto: vim_7.1-112-i486-15

La descripción debe ser lo suficientemente larga para hacer que la descripción de la categoría se vea agradable, pero debe contener solamente información útil para el usuario. Significa describir el módulo para alguien que no tiene ninguna idea de lo que hay dentro, ni para qué sirve. Nada de textos falsos, enlaces, errores gramaticales o sintácticos, signos de exclamación, ni historiales de cambios. La longitud recomendada es 40 palabras o más.