miércoles, 1 de abril de 2009

HAL y crip (I - Instalar las fuentes)

abcde es más que suficiente para la mayoría de los usuarios y la mayoría de las funciones. No obstante, los acérrimos de la música clásica pueden preferir etiquetar sus CDs de un modo más flexible, pero de forma sencilla y sin necesidad de recurrir a herramientas externas, aunque tengan que consumir para ello algo más de tiempo en la línea de órdenes. crip quiere cubrir esa laguna. Se trata de un guión escrito en el lenguaje Perl, menos elaborado, quizá, y con menos opciones globales que abcde, pero especialmente indicado para el caso que comentamos.

Nos va a servir además para enfrentarnos por primera vez ---si bien en un ejemplo muy simple--- a la instalación de un programa desde las fuentes, es decir, para acometer la instalación del código tal cual ha sido distribuido por el programador, sin acudir al paquete que nuestra distribución ha creado para ese código. Que escojamos este procedimiento tiene, claro está, fines didácticos , pero también obedece al hecho de que la versión de crip empaquetada a día de hoy por Debian (la 3.7) contiene un error que ya ha sido resuelto en la versión original más reciente. Lo normal es que nunca acudamos a esta vía. Es más, lo normal es que cuando la instalación directa a partir del código fuente es la única vía posible ---no es el caso aquí, como veremos más tarde---, nos decidamos por otro programa alternativo. En este momento, como de lo que se trata es de aprender, seguiremos la "senda escarpada".

Lo primero que hay que hacer para instalar un programa desde la fuente es, obviamente, conseguir el código fuente y guardarlo en nuestro ordenador. La última versión de crip se puede obtener visitando la página siguiente:

http://bach.dynet.com/crip/download.html

La versión más reciente a día de hoy es la 3.9. Podemos descargarla directamente acudiendo a HAL, por ejemplo, dentro de un directorio, src (de source, fuente) que crearemos expresamente para guardar todos los archivos fuentes de los programas que instalemos a mano. Construiremos ese directorio, ingresaremos en él y descargaremos ahí el archivo que contiene el código fuente, las tres operaciones en un solo paso:

mkdir src ; cd src ; wget http://bach.dynet.com/crip/src/crip-3.9.tar.gz

Los puntos y comas (;) entre cada orden indican a HAL que las procese una tras otra. El resultado es el mismo que ejecutarlas por separado.

El fichero guardado, crip-3.9.tar.gz es un fichero comprimido. Pero no es un fichero cualquiera. Se trata de un archivo que engloba un directorio completo con sus correspondientes ficheros. Un fichero tar es uno de los más frecuentes tipos de ficheros de esta clase, comunes para archivar y distribuir fácilmente directorios completos. Para crear ficheros tar o para desarchivarlos (extraer su contenido) se utiliza la orden del mismo nombre tar. Por ejemplo, podemos pedirle a HAL que extraiga (--extract) y a la vez descomprima con gunzip (--gunzip) el fichero (--file) crip-3.9.tar.gz, y que se explaye sin miedo para informarnos de cómo transcurre la operación (--verbose):

tar --extract --gunzip --verbose --file crip-3.9.tar.gz

Pero nunca se ha visto a nadie dirigirse tan ceremoniosamente a HAL. En lugar de ello, se utilizan las respectivas opciones abreviadas:

tar -x -z -v -f crip-3.9.tar.gz

Y ni siquiera eso, porque cuando hay varias opciones abreviadas, se prefiere unirlas en un solo taco:

tar -xzvf crip-3.9.tar.gz

HAL nos informa como hemos solicitado:

crip-3.9/
crip-3.9/TODO
crip-3.9/crip
crip-3.9/LICENSE
crip-3.9/README
crip-3.9/editcomment
crip-3.9/CDDB_get.pm
crip-3.9/criprc_example
crip-3.9/editfilenames
crip-3.9/Changelog

¿Qué son todos estos ficheros contenidos en el archivo que el desarrollador de crip tiene la amabilidad de poner a nuestra disposición? El primero es, evidentemente, el propio directorio crip-3.9. ¿Y los ficheros de los que consta? Nada más fácil que preguntárselo a HAL:

file crip-3.9/*

que devuelve la información que buscamos:

crip-3.9/CDDB_get.pm: Perl5 module source text
crip-3.9/Changelog: UTF-8 Unicode English text
crip-3.9/crip: a /usr/bin/perl script text executable
crip-3.9/criprc_example: ASCII English text
crip-3.9/editcomment: a /usr/bin/perl script text executable
crip-3.9/editfilenames: a /usr/bin/perl script text executable
crip-3.9/LICENSE: ASCII English text
crip-3.9/README: ASCII English text
crip-3.9/TODO: ASCII English text

El asterisco (*) tras el nombre del directorio en la orden file es un comodín que vale por todos y cada una de los ficheros contenidos en crip-3.9. Probablemente empecemos a usarlo más veces a partir de ahora.

Bien, tenemos unos cuantos ficheros que contienen texto en ingles (en codificación ASCII o UTF-8, eso es secundario aquí) y cuatro más escritos en Perl. Estos últimos son el código fuente propiamente dicho y veremos qué hacer con ellos dentro de un momento. Los ficheros en inglés son documentos informativos sobre el programa. Aun sin leer su contenido, cualquiera que esté familiarizado con archivos de fuentes de programas sabe de qué van, porque sus nombres son convencionalmente usados por los programadores para documentar el código que distribuyen:

README
Proporciona informaciones básicas para manejar el programa. Es el fichero que hay que leer en primer lugar.

LICENSE
Describe la licencia bajo la que se distribuye el código. En este caso es GPL. Lo que significa que el código puede modificarse libremente y distribuirse si se mantiene la misma licencia.

TODO
Una lista de las tareas que el programador considera pendientes y que tal vez cumpla en futuras revisiones del código o espera que cumplan posibles colaboradores.

Changelog
Una lista de las características implementadas en cada versión del código hasta ahora realizada y de los errores (bugs) corregidos

criprc-example
Un ejemplo de fichero de configuración para el programa. Recuérdese que nos hemos encontrado ya con varios ficheros de configuración y que el nombre de muchos de ellos se construye con el sufijo rc (de resource) añadido al nombre del programa.


Leamos el fichero README ---se presupone que el lector hace ahora un less crip-3.9/README--- para conocer de qué va la historia. Vemos que contiene instrucciones de instalación y de uso.

Empecemos por la instalación. Lo primero que se nos indica es el software con el que nuestro sistema debe contar para que crip funcione. Casi todas los programas requeridos son conocidos nuestros, los artesanos del sonido que comentamos hace unos días (cdparanoia, oggenc, flac, vorbiscomment y vorbisgain), de sox, otro experto en sonido, podemos prescindir ahora. perl está instalado a buen seguro. Si instalamos abcde, se instalaron muchos de los programas anteriores. Pero no vamos a dar nada por hecho. Trataremos de ver qué paquetes de Debian contienen el software necesario e instalaremos dichos paquetes ---sí, no procederemos a instalarlos desde las fuentes, el lector puede respirar tranquilo.

Como sabemos, aptitude nos permite buscar paquetes que cumplan ciertas funciones, pero lo que ahora necesitamos es algo sustancialmente distinto, queremos conocer en qué paquete de Debian está contenido un determinado programa. Para ello existe la herramienta apt-file, incluida en el paquete del mismo nombre, que se puede instalar como cualquier otro paquete:

aptitude install apt-file

El funcionamiento básico de apt-file es muy sencillo. Los almacenes de paquetes Debian incluyen un fichero comprimido donde se describe el contenido de todos los paquetes allí almacenados. Éste es el fichero que apt-file procesará. Lo primero, por tanto, es tener en nuestro ordenador una copia actualizada suya. Para ello debemos disfrazarnos de root, es decir que previamente hay que hacer su o prefijar la orden siguiente con sudo, dependiendo de nuestro sistema:

apt-file update

Una vez descargado el fichero de contenidos de los paquetes, podemos buscar en él qué paquete o paquetes contiene cada programa u orden que crip define como requisito previo. Por ejemplo:

apt-file cdparanoia

que devuelve:

cdparanoia: /usr/bin/cdparanoia
cdparanoia: /usr/share/doc/cdparanoia/README.gz
cdparanoia: /usr/share/doc/cdparanoia/changelog.Debian.gz
cdparanoia: /usr/share/doc/cdparanoia/copyright
cdparanoia: /usr/share/man/ja/man1/cdparanoia.1.gz
cdparanoia: /usr/share/man/man1/cdparanoia.1.gz
cdparanoia-dbg: /usr/lib/debug/usr/bin/cdparanoia
cdparanoia-dbg: /usr/share/doc/cdparanoia-dbg/changelog.Debian.gz
cdparanoia-dbg: /usr/share/doc/cdparanoia-dbg/copyright
gstreamer0.10-plugins-base: /usr/lib/gstreamer-0.10/libgstcdparanoia.so
gstreamer0.10-plugins-base-dbg: /usr/lib/debug/usr/lib/gstreamer-0.10/libgstcdparanoia.so
gstreamer0.10-plugins-base-doc: /usr/share/gtk-doc/html/gst-plugins-base-plugins-0.10/gst-plugins-base-plugins-cdparanoiasrc.html
gstreamer0.10-plugins-base-doc: /usr/share/gtk-doc/html/gst-plugins-base-plugins-0.10/gst-plugins-base-plugins-plugin-cdparanoia.html
libcdparanoia-dev: /usr/share/doc/libcdparanoia-dev/changelog.Debian.gz
libcdparanoia-dev: /usr/share/doc/libcdparanoia-dev/copyright
libcdparanoia0: /usr/share/doc/libcdparanoia0/README.gz
libcdparanoia0: /usr/share/doc/libcdparanoia0/changelog.Debian.gz
libcdparanoia0: /usr/share/doc/libcdparanoia0/copyright
libcdparanoia0: /usr/share/lintian/overrides/libcdparanoia0
libk3b-dev: /usr/include/kde/k3bcdparanoialib.h
libtritonus-bin: /usr/lib/jni/libtritonuscdparanoia.so
libtritonus-bin: /usr/lib/jni/libtritonuscdparanoia.so.1
libtritonus-bin: /usr/lib/jni/libtritonuscdparanoia.so.1.0
manpages-ko: /usr/share/man/ko/man1/cdparanoia.1.gz
ripperx: /usr/lib/ripperx/ripperX_plugin-cdparanoia
soundkonverter: /usr/share/apps/soundkonverter/plugins/320.cdparanoia.soundkonverter.xml

Demasiada información. Es preciso filtrarla. Como ya indicamos hace bastante, los programas u órdenes no son sino ficheros ejecutables, lo que significa que se instalarán en un directorio de ejecutables como bin o sbin. Para los artesanos del sonido, podemos descartar la última opción (sbin), dado que, a todas luces, se trata de órdenes o programas de usuario. Y, puesto que son ficheros que no contienen programas para administrar el sistema, debemos suponer que, a buen seguro, formarán parte del directorio /usr/bin. En la descripción del contenido de los paquetes que suministra apt-file aparece, como acabamos de comprobar, el nombre del paquete como primer campo y la ruta del fichero como segundo campo, separados ambos campos por dos puntos y espacio. En consecuencia, podemos realizar una búsqueda con apt-file search y filtrar el resultado con grep:

apt-file search cdparanoia | grep -E ':[[:space:]]+/usr/bin'

La respuesta ahora es unívoca y suficiente:

cdparanoia: /usr/bin/cdparanoia

Si ejecutamos dicha búsqueda para todos las órdenes o programas que requiere crip obtendríamos la siguiente información:

cdparanoia: /usr/bin/cdparanoia
vorbis-tools: /usr/bin/oggenc
flac: /usr/bin/flac
flac: /usr/bin/metaflac
vorbis-tools: /usr/bin/vorbiscomment
vorbisgain: /usr/bin/vorbisgain

Por cierto, no es necesario ejecutar apt-file search nombre_programa para cada uno de los programas en los que estamos interesados, se puede hacer de una sola vez con una orden algo compleja, cuyo sentido no se ha explicado todavía, pero que deberemos considerar despacio en algún otro momento:

for file in cdparanoia oggenc flac vorbiscomment vorbisgain; \
do apt-file search $file | grep -E ':[[:space:]]+/usr/bin'; \
done

Podríamos incluso filtrar el resultado de esta orden para que nos devolviese únicamente el primer campo (el nombre del paquete) y suprimiese las repeticiones:

for file in cdparanoia oggenc flac vorbiscomment vorbisgain; \
do apt-file search $file | grep -E ':[[:space:]]+/usr/bin'; \
done \
| cut -d':' -f1 | uniq

Y ya que estamos, podemos enviar el resultado final como lista de argumentos para aptitude, de forma aptitude proceda automáticamente a la instalación de los paquetes correspondientes:

aptitude -s install \
$(for file in cdparanoia oggenc flac vorbiscomment vorbisgain; \
do apt-file search $file | grep -E ':[[:space:]]+/usr/bin'; \
done \
| cut -d':' -f1 | uniq)

¡Eh! ¿qué tal este inopinado reencuentro con nuestros cachivaches de fontanería?

El lector atento habrá notado en la anterior orden una opción extraña para aptitude, la opción -s. Esta opción hace que aptitude simule su comportamiento habitual, sin provocar ningún cambio en nuestro sistema de paquetes. La puede ejecutar cualquier usuario, no hace falta ser root. Es muy recomendable aplicarla antes de proceder a una instalación real, especialmente en casos como el anterior, donde los paquetes que se instalarán son la salida de una orden compleja.

Si ejecutamos como root, y sin la opción -s, la orden citada, se instalarán todos los programas que crip exige para funcionar y que no existen ya en nuestro sistema.

Preparada la infraestructura para crip, continuamos nuestra lectura de su fichero README. Ahí se nos informa del siguiente paso: copiar CDDB_get.pm a algún sitio donde nuestro intérprete del lenguaje Perl pueda encontrarlo. Se nos propone, como opción, copiarlo bajo /usr/lib/perl5/. No vamos a seguir, sin embargo, esta recomendación. La razón es que no es conveniente mezclar ficheros instalados a mano en los directorios que nuestra distribución utiliza para instalar el contenido de los paquetes. Los directorios /usr/bin, /usr/lib, etc. son directorios que debe manejar exclusivamente nuestra distribución. Todas las distribuciones de Linux ofrecen la posibilidad de directorios semejantes a los anteriores para un caso como el nuestro, es decir, para cuando instalamos software desde las fuentes. El directorio típico que existe con este fin es /usr/local. Es ahí donde debemos ubicar el software instalado a mano.

CDDB_get.pm es, como nos notificó file anteriormente, un módulo de Perl, es decir, un conjunto de funcionalidades que pueden usar distintos programas escritos en Perl. Se almacenan normalmente en el directorio /lib/perl/versión, donde versión es el número de versión de nuestra infraestructura Perl. En mi sistema es el 5.10.0. Por tanto, debemos crear como root ese subdirectorio en nuestro /usr/local y copiar allí el fichero CDDB_get.pm:

mkdir -p /usr/local/lib/perl/5.10.0/

La opción -p de mkdir permite crear no sólo el directorio 5.10.0, sino todos los directorios padre bajo /usr/local que todavía no existan. En nuestro caso, tiene el mismo efecto que estas dos órdenes:

mkdir /usr/local/lib/perl
mkdir /usr/local/lib/perl/5.10.0

Ahora copiamos, también como root el fichero CDDB_get.pm en el directorio recién creado:

cp crip-3.9/CDDB_get.pm /usr/local/lib/perl/5.10.0

Finalmente, y si seguimos las instrucciones del README, sólo falta copiar el fichero de configuración criprc_example como nuestro ~/.criprc:

cp crip-3.9/criprc_example ~/.criprc

Con esto sería suficiente para hacer funcionar crip. Sin embargo, tendríamos que llamar con su ruta completa a crip (~/tmp/crip-3.9/crip) cada vez que quisiéramos ejecutarlo. Como esto es incomodo, es mejor disponer los ficheros ejecutables de las fuentes en un ruta que esté en nuestro PATH. Qué mejor que en /usr/local/bin. Las fuentes constan de varios ejecutables, como nos informó file. Tales ficheros no son sino órdenes escritas en lenguaje Perl y son, para el caso que nos ocupa los siguientes:

crip
editcomment
editfilenames

Copiémoslos en /usr/local/bin

cd crip-3.9 ; cp crip editcomment editfilenames /usr/local/bin

Tarea finalizada. Cabe añadir que, en el caso de que se quiera en el futuro recurrir al paquete crip de Debian, habría que asegurarse de que no queda rastro de los ficheros instalados en /usr/local. Es decir, habría que disfrazarse de root y ejecutar las siguientes órdenes:

rm /usr/local/lib/perl/5.10.0/CDDB_get.pm
rm /usr/local/bin/crip
rm /usr/local/bin/editcomment
rm /usr/local/bin/editfilenames

¿Alguien se atreve a escribir el mini guión desinstalar_crip_local para realizar esta operación de desinstalación? Fácil, ¿no?

Si el lector ha llegado hasta aquí sin tropiezos se puede considerar afortunado. Acaba de ingresar en el reducido grupo de usuarios de a pie que todavía tiene el coraje de instalar un programa desde la fuente misma. En los gloriosos y aguerridos días en que las distribuciones de GNU/Linux no eran tantas ni tan bien pertrechadas, era una práctica habitual. Hoy en día sólo los usuarios avanzados y, por supuesto, los programadores, se atreven con estos retos, que, por lo que se ha visto, no son tan duros como los pintan, al menos para casos tan simples como el de crip.


Resumen

  • Los puntos y coma (;) como separadores de órdenes en la línea de órdenes, permiten ejecutar secuencialmente las órdenes separadas por ellos.

  • El asterisco (*), cuando está fuera de una expresión regular, funciona como un comodín que está por cualquier cadena de caracteres. Es frecuente su uso como abreviatura de nombres de ficheros.

  • Un fichero tar es un tipo de fichero que sirve para archivar varios ficheros, incluidos subdirectorios. La orden tar permite crear tales clases de ficheros o extraer el contenido de dichos ficheros.

  • Cuando una orden recibe varias opciones es frecuente agruparlas en un único bloque. Por ejemplo, tar -x -z -v -f fichero se abrevia habitualmente con tar -xzvf fichero

  • Las fuentes de un programa suelen incluir ficheros de documentación con nombres convencionales: README, que proporciona información importante que hay que leer en primer lugar; LICENSE, que indica la licencia bajo la que se distribuye; TODO, que lista las tareas pendientes; Changelog, que informa de los cambios realizados en cada versión.

  • Los ficheros de configuración de un programa suelen terminar con el sufijo rc añadido al nombre del programa. Por ejemplo, bashrc, vimrc, criprc.

  • La orden apt-file permite buscar ficheros en el contenido de los paquetes Debian.

  • Por defecto, la orden uniq devuelve su entrada omitiendo las líneas repetidas.

  • La opción -s de aptitude permite simular el comportamiento de aptitude sin producir ninguna modificación en el sistema.

  • /usr/local es el directorio recomendado para ubicar software instalado manualmente por el usuario.

1 comentario:

  1. Con motivo de estos artículos sobre crip, añadí un comentario a un informe de error relativo al paquete crip en Debian. Dicho informe llevaba ya bastante sin actividad y el error permanecía. Me gusta pensar que reabrir el debate ha hecho que el mantenedor de Debian haya actualizado la versión empaquetada de crip a la última distribuida por la fuente original (la 3.9). (A día de hoy permanece en el almacén de paquetes de sid, la versión inestable de Debian).

    El envío de informes de error es una de esas cosas que un usuario no programador puede hacer en bien de la mejora de su distribución y del software libre, en general.

    ResponderEliminar