JuanjoAlvarez.net

En el artículo anterior vimos que para un usuario novato queriendo instalar cosas que no hayan sido empaquetadas por su distribución las cosas están un poco negras: Por un lado tenemos paquetes de fuentes, por otro paquetes RPM hechos por el autor que no siempre funcionan, por otro el clásico “descomprime esto y ejecuta el binario que se llama tal dentro del directorio que te crea y por Último unos pocos programas (drivers de la Nvidia, instalador de Loki, Real Player, OpenOffice) que vienen como un archivo autoinstalable y que una vez le hemos dado permisos de ejecución nos mostrará un asistente muy al estilo “Windowsâ€?.

En todos los casos anteriores nos encontramos con un problema de integración: La base de datos de paquetes de nuestra distribución no tendrá conocimiento de nada que no hayamos instalado de cualquiera de estas formas por lo que tanto las instalaciones como las actualizaciones de esos paquetes también van a ser manuales (de nuevo, por distintos métodos.)

Autopackage intenta solucionar este problema de los programas no empaquetados en nuestra distribución (programas de terceros) usando una solución que permite instalar programas simplemente dándoles permiso de ejecución y ejecutando un fichero, que mostraría un instalador gráfico o en modo texto sencillo para el usuario pero que además permitiría realizar operaciones similares a las de los gestores de paquetes de las distribuciones, entre ellas:

• Listado de los paquetes instalados
• Desinstalación
• Listado de ficheros de un paquete
• Comprobación de integridad de un paquete instalado

En la implementación actual Autopackage actÚa como un gestor de paquetes “alternativoâ€? y paralelo al nativo de nuestra distribución que no termina de integrarse en el sentido de que los paquetes que el gestor de paquetes nativo no tendrá constancia de los paquetes que instalemos con Autopackage, por ejemplo si instalamos KVIrc mediante autopackage y después le decimos a nuestro gestor de paquetes (por ejemplo APT) que instale KVIrc este Último lo hará incluso si la versión instalada por Autopackage es más nueva que la que instala APT, o existen ficheros conflictivos entre ambas. En cualquier caso es una mejora sustancias sobre la instalación de programas a partir de fuentes porque nos permite realizar cualquier de las operaciones anteriormente enumeradas y porque gestiona las dependencias (¡y porque instalar un binario siempre será más rápido que compilar!)

Dicho esto vamos a ver como se reflejaría Autopackage desde el punto de vista de un usuario, y quien mejor para mostrarnos el camino que nuestro incansable Pepe Novato.

A Pepe le gusta chatear un rato los domingos en un canal de IRC de fotografía digital donde ha hecho algunos amigos. Para ello hasta ahora ha venido utilizando el Xchat pero un amigo le ha comentado que hay un programa también muy potente llamado KVIrc versión 3 que tiene muchísimas características de las que carece Xchat por lo que Pepe se decide a probarlo. Ya experto en el gestor de paquetes de su Mandrake va al centro de control de Mandrake (Drakconf) y pincha “Administración de Softwareâ€? y “Instalarâ€?. Cuando se le abre el diálogo de instalación de programas escribe en la caja de bÚsqueda “kvircâ€? y comprueba que existe, pero en una versión más bastante más antigua que la que le han recomendado.

“Tranquilidadâ€?, se dice Pepe, “quizás los autores de KVIrc han puesto en su página web un paquete RPM para mi versión de Mandrakeâ€?. Pepe carga http://www.kvirc.net y pincha en “Downloadâ€?. Navegando por las distintas alternativas disponibles descubre desolado que no existe ningÚn paquete de la Última versión para su distribución, por lo que está a punto de desistir (no quiere volver a pasar por lo mismo otra vez) pero justo cuando va a cerrar el navegador ve que en uno de los ficheros pone “autopackage autoinstallable file, just download and run itâ€?. Aunque la frase parece estar en hereje antiguo algo le dice en su interior que ese fichero “autopackageâ€? podría evitarle dolores de cabeza así que lo descarga y cuando lo tiene en su directorio de usuario le cambia las propiedades desde su Konqueror para activar la casilla “Es ejecutableâ€? desde la pestaña “Permisosâ€? de las propiedades. Después pulsa aceptar y pincha sobre el fichero lo que le saca una ventanita negra llena de letras que al final parece preguntarle si desea instalar nosequé. Responde que sí y la ventanita negra empieza a hacer algunas cosas pero inmediatamente, y le saca una ventana gráfica en la que pulsa “siguiente siguiente siguienteâ€?. Cuando la ventana gráfica desaparece la ventanita negra dice “Pulse intro para continuarâ€? así que lo pulsa y se le vuelve a mostrar una ventana gráfica que esta vez si parece corresponderse con la instalación del KVIrc. Pulsa siguiente, siguiente, siguiente y cuando el proceso ha terminado se le informa de que se ha añadido una entrada al menÚ del usuario e incluso le pregunta si desea añadir un icono en el escritorio. Pepe no se lo puede creer, responde que si a lo del icono y termina la instalación. Pincha en su nuevo icono y ¡ahí está! Ya puede utilizar tranquilamente KVIrc. Cuando quiera desinstalarlo tan sólo tendrá que ejecutar en una consola “package remove kvircâ€? y para ver todos los paquetes disponibles podrá hacer “package listâ€? pero eso ya tendrá tiempo de aprenderlo después.

Como hemos podido ver en esta ocasión Pepe no ha tenido que luchar contra paquetes .tar.gz indescifrables ni comandos esotéricos. Le ha bastado con descargar un fichero, darle permiso de ejecución y ejecutarlo. La pantallita negra que le ha salida al principio no la volverá a ver en próximas instalaciones porque esa es la pantalla de instalación del propio software de soporte de autopackage (que ha descargado los ficheros necesarios automáticamente a través de Internet.) Además si le hubiera faltado alguna dependencia autopackage se habría encargado de instalársela de estar disponible en formato autopackage (en el futuro autopackage instalará las dependencias utilizando el gestor de paquetes nativo de la distribución siempre que sea posible pero de momento esto aÚn no está soportado.)

¿Cómo funciona este sistema de cara al desarrollador?

Crear un paquete .autopackage es un proceso bastante sencillo. En general el proceso va a consistir en instalarnos autopackage con las herramientas de desarrollo, si no las teníamos previamente y crear un fichero con extensión .apspec que rellenaremos con la información necesaria para crear el paquete. Veremos dos casos distintos de creación del fichero pero primero vamos a ver como se instalaría autopackage con las herramientas de desarrollo.

Obtener AutoPackage con herramientas de desarrollo

Ya hemos visto que la versión de Autopackage de usuario (la parte necesaria para instalar y gestionar los paquetes) se puede instalar automáticamente en cuanto instalemos por primera vez un .package. Sin embargo para disponer de las herramientas necesarias para crear paquetes debemos descargar e instalar las herramientas para desarrolladores de la página de descargas de Autopackage (http://www.autopackage.org/downloads.html). Cuando hayamos terminado la instalación podremos usar el programa “makeinstallerâ€? que es prácticamente el Único que vamos a tener que usar para crear los paquetes autoinstalables.

Crear el fichero .apspec

Aquí es donde realmente está la “chichaâ€? del asunto. No voy a detallar totalmente la forma de crear estos ficheros (para eso ya está la extensiva documentación(http://www.autopackage.org/docs.html) del proyecto y en concreto la guía para desarrolladores. En lugar de eso, vamos a ver dos ejemplos prácticos (y algo incompletos) de ficheros .apspec.

Fichero .apspec para KVIrc, una herramienta en C++ basada en autotools

En este ejemplo vamos a crear un (incompleto) fichero .apspec para el potente cliente de IRC KVIrc. Esta aplicación se corresponde con el tipo más fácil de aplicación que puede “autopackaizarseâ€? porque usa las autotools para su configuración y compilación. Para no perder el tiempo pondré el contenido del fichero default.apspec con comentarios explicando el porque de cada cosa:

# -*-shell-script-*-

# Como puede verse el formato es similar al de los ficheros .ini de windows
# con cabeceras entre corchetes y entradas con el formato Clave: valor

# La sección meta contiene información sobre el paquete
[Meta]

# El root name tiene el formato @organizacion/paquete. @Organizacion puede ser lo 
# que queramos pero es importante que sea consistente. Después va el nombre 
# del paquete y finalmente tras unos : la versión exacta del mismo.
RootName: @kvirc.net/kvirc:3.0.1.99

#El DisplayName es una descripción de una linea que aparecerá en el instalador
DisplayName: KVIrc Graphical IRC Client

# El shortname es un nombre corto y sin espacios (puede contener guiones) que 
# constituirá el nombre del paquete.
ShortName: kvirc

# El maintainer es la persona a cargo del programa 
Maintainer: Szymon Stefanek 

# El packager es la persona a cargo del paquete
Packager: Juanjo Alvarez 

# Resumen de la utilidad
Summary: Powerfull GUI IRC client

# Versión
SoftwareVersion: 3.0.1.99

# InterfaceVersion sólo es necesaria para programas que exporten una interfaz
# (sea del tipo que sea) para que otros módulos puedan usarla. En el caso de KVIrc 3
# tiene librerías dinámicas así que definimos la interfaz:
InterfaceVersion: 3.0.0

# Versión del paquete
PackageVersion: 1

# Descripción larga que aparecerá en la primera página del instalador
[Description]
KVIrc is the most powerfull IRC client on the place. This version is compiled without KDE support.

# Aquí se especifican las acciones que deben realizarse para preparar la construcción del paquete.
# Podemos poner cualquier script que hayamos escrito o comando y además los comandos
# proporcionados por autopackage que pueden consultarse en http://autopackage.org/api. Para 
# paquetes basados en autoconf suele bastar con poner “prepareBuildâ€? con los parámetros que 
# queremos que se le pasen al ./configure (en este caso –without-kde-support).
[BuildPrepare]
prepareBuild --without-kde-support

# Aquí se hemos puesto en [BuildPrepare] algo que no fuera el prepareBuild aquí tendremos
# que poner los scripts/comandos que lo deshagan (antes de la instalación). Si hemos puesto
# prepareBuild pondremos unprepareBuild
[BuildUnprepare]
unprepareBuild

# Aquí especificamos que ficheros de los que se instalan con un make install irán en el paquete.
# Normalmente lo dejaremos así.
[Imports]
echo '*' | import

# En la sección prepare se especifican las dependencias. Estás deben especificarse con un nombre
# “autopackage�. Para ello es necesario que exista un fichero skeleton para dicha dependencia. En 
# ese fichero se van a especificar los comandos necesarios para comprobar si la dependencia está
# instalada en el sistema (con o sin autopackage) y en caso de no estarla la descargaría (si hay un
# autopackage hecho para ella) y la instalaría. En versiones futuras autopackage tendrá la posibilidad 
# de intentar instalar las dependencias primero usando el gestor de paquetes nativo y luego 
# en caso de no estar instalar el autopackage.
# En este caso existe un fichero skeleton que especifica como encontrar las Qt así que sólo tendremos 
# que definir el nombre autopackage de la misma.
# En esta sección también podemos ejecutar cualquier shell script que deseemos para comprobar 
# dependencias, si alguno de los scripts devuelve 1 (fallo) el proceso abortará.

[Prepare]
require @trolltech.com/qt 3.2

# Comandos que realizan la instalación. Aquí casi siempre nos vamos a limitar a llamar a installExec 
# para instalar ejecutables, installLib para instalar librerías, installMan para instalar páginas man, 
# installDesktop para instalar fichero .desktop o copyFiles para todo lo demás. Existen muchos más
# comandos de instalación que ponemos consultar en http://autopackage.org/api
# Una forma bastante cómoda de saber que debemos instalar es ejecutar nosotros el ./configure con un
# --prefix=/foo y luego mirar en /foo que ficheros ha instalado.

[Install]
installExe bin/*
installLib lib/libkvilib.so.3.0.0
installMan 1 man/kvirc.1
copyFiles share/kvirc "$prefix/share"
installDesktop "" ./share/applnk/kvirc.desktop

# Aquí se especifican las acciones de desinstalación. Normalmente basta con especificar 
# uninstallFroomLog que desinstalará todos los ficheros que se hayan creado durante la 
# instalación

[Uninstall]
uninstallFromLog

¿Ta claro? Si no lo está, ya sabeis donde está la documentación. Veamos otro ejemplo, en este caso un poco más “exóticoâ€?: Vamos a crear el .package para el
Animail que no utiliza autotools (no necesita compilar nada, es Python) sino un sencillo fichero Makefile para instalar con “make installâ€?. Sólo se comentarán aquellas partes que difieran de lo anterior:

# -*-shell-script-*-

[Meta]
RootName: @juanjoalvarez.net/animail:2.0.9
DisplayName: Animail Mail Downloader
ShortName: animail
Maintainer: Juanjo Alvarez Martinez 
Packager: Juanjo Alvarez 
Summary: Mail downloader utility and spam filter aggregator
SoftwareVersion: 2.0.9

# En este caso el programa no exporta ninguna interfaz externa por lo que no hace falta
# poner InterfaceVersion:
# InterfaceVersion: 0.0

# Autopackage soporta traducciones de los instaladores. Para ello primero espeficiamos que idiomas 
# adicionales (aparte del inglés) vamos a completar con el comando “Languageâ€? y una lista de 
# los idiomas.

Language: es


# Ahora podemos poner también un DisplayName en español poniendo [es] tras el comando.

DisplayName[es]: Programa de descarga de correo Animail

PackageVersion: 1

[Description]
Animail is a mail downloader utility that understand POP3/POP3-SSL IMAP4/IMAP4-SSL
and maildir/mbox/sendmail/local SMTP as delivery options. What makes it interesting is
the nice output, the easy configuration and the way it can be quickly setup to use use
any number of external (and some internal) spam filters together.

# Descripción, especificamos q es en español poniendo :es

[Description:es]
Animail es un programa para descargar el correo que entiende los protocolos POP3/POP3-SSL,
IMAP4/IMAP4-SSL y los métodos de entrega a maildir/mbox/sendmail o SMTP local. Lo que lo
hace interesante es la salida con formato y colores, la configuración sencilla y que
permite ser configurado rápidamente para usar varios filtros de spam (publicidad) externos y
algunos internos combinados.

# En este caso Animail no usa un ./configure pero si un Makefile así que llamaremos 
# de todas formas a prepareBuild pero cuando vayamos a construir el paquete con makeinstaller
# debemos pasarle a este comando el parámetro -c para que no intente ejecutar un ./configure
[BuildPrepare]
prepareBuild

[BuildUnprepare]
unprepareBuild

[Imports]
echo '*' | import

# En este caso lo que necesitamos es que el usuario tenga Python 2.0 o superior

[Prepare]
require @python.org/python 2.0

# La Única diferencia de concepto con respecto al ejemplo anterior es que aquí estamos 
# especificando como instalar los ficheros de traducciones y en el caso anterior no porque era
# más sencillo dejar que los instalara en /usr/share/kvirc (kvirc sabe buscarlos allí también)

[Install]
installExe bin/*
mkdirs "$prefix/lib/animail"
copyFiles lib/animail/* "$prefix/lib/animail"
mkdirs "$prefix/share/locale/es/LC_MESSAGES" "$prefix/share/locale/de/LC_MESSAGES"
copyFiles share/locale/es/LC_MESSAGES/animail.mo "$prefix/share/locale/es/LC_MESSAGES/"
copyFiles share/locale/de/LC_MESSAGES/animail.mo "$prefix/share/locale/de/LC_MESSAGES/"
copyFiles share/doc "$prefix/share"
installMan share/man/man2/animail.2.gz

[Uninstall]
uninstallFromLog

Como puede verse, crear el fichero .apspec para crear autopackages no es ciencia espacial. Una vez tenemos estos ficheros lo Único que nos queda por hacer es ponernos en el directorio principal de las fuentes, crear un directorio “autopackageâ€? y copiar el fichero dentro con el nombre default.apspec. Finalmente ejecutamos “makeinstallerâ€? (en el directorio superior del proyecto, no en el autopackage) y se debería configurar, compilar (donde corresponda) y crear el fichero .package que ya podemos distribuir a nuestros usuarios con total tranquilidad (ni siquiera es necesario preocuparnos de que tengan instalado autopackage porque como se ha dicho los ficheros .autopackage instalarán autopackage automáticamente si no lo encuentran instalado. Espectacular ¿verdad?

Con respecto a los detalles de implementación, el proyecto parece que se está acercando a la versión 1.0 a buena velocidad, cuenta con tres instaladores (en consola con colores, Gnome y Qt) y es perfectamente usable aunque los autores no garantizan que la forma de usarlo no vaya a cambiar hasta la versión 1.0 (de todas formas es improbable que lo hagan teniendo en cuenta lo poco que queda.)