"La Gaceta de Linux...¡haciendo de Linux algo un poco más divertido!"


Instalando Software desde el Código Fuente
-o-
¿Que hago con este archivo.tar.gz?

Escrito por Ben Okopnik

Traducción al español por Ernesto Aneiros
el día 16 de Enero 2002, para La Gaceta de Linux


El otro día decidí descargar "cuyo" (puedes dirigirte al resumen de Mike Orr sobre él, está en este mismo número), un juego nuevo que ha estado mencionándose en la lista de administración "Answer Gang". Cuando fui a su sitio WEB, sólo encontré un archivo tarball con el código fuente, en vez de un paquete -incluso cuando en el -mail se mencionaba que estaba disponible un archivo para Debian. No es gran cosa, pensé, he hecho esto antes...

[El archivo cuyo.deb está en la distribución de Debian Unstable. Pero este artículo se aplica a cualquier programa que quieras instalar, que no esté en tú distribución o donde la versión de la distribución esté ya vieja. -Iron]
Para aquéllos que no sepan, un archivo tarball es una colección de archivos fuentes que se han agrupado en un solo archivo con "tar" y usualmente se han compactado con "gzip", estos fuentes se compilan para producir un programa; el nombre de un archivo "tarball" es casi siempre de esta forma "nombre-1.23.tgz" o "nombre-1.23.tar.gz", donde "nombre" obviamente es el nombre del programa y 1.23 la versión del mismo. Cuando instalas un paquete - ya sea RPM o DEB, o cualquiera que tu distribución use - solamente estas poniendo las librerías, documentación y los binarios precompilados en los directorios donde pertenecen, es decir, aquí no se realiza ninguna compilación ya que los programas ya vienen como binarios. La compilación del código fuente es la parte que normalmente nos la hace el organizador de los paquetes.

Después de descargar el tarball al subdirectorio "/home/ben/TGZs", que es donde específicamente guardo los tarballs que descargo, puse luego una copia del mismo en "/tmp", que es donde voy a compilar los fuentes. Nota: algunos prefieren hacerlo en "~/tmp", un subdirectorio debajo del "home". La razón por esto es que "/tmp" usualmente se llena en el proceso de bootup (cuando iniciamos el sistema) y si durante la compilación algo va REALMENTE mal esto podría bloquear la computadora... y luego habría que reiniciar (oops!). Yo apoyo su razonamiento, pero siendo el provocador que soy, confío en mi Linux ;).

El archivo se llamaba "cuyo-1.03.tar.gz" - así que, la pequeña magia que lo convertiría de nuevo a archivos útiles es:

tar xvzf cuyo-1.03.tar.gz

Esto creo un subdirectorio llamado "cuyo-1.03" debajo del "/tmp".

(Está bien, lo que hice en realidad fue mirar dentro del tarball con el Midnight Commander, abrir "/tmp" en el segundo panel y apretar "F5" para copiar el directorio compactado. He descrito como hacerlo desde la línea de comando para aquéllos que les guste hacerlo manualmente).

Nota: algunos programadores no son lo suficientemente "atentos y bien educados" a la hora de crear sus archivos tarball, y cuando lo descompactamos nos suelta todos los archivos en el directorio donde nos encontramos creándonos todo un desastre, especialmente si estamos en el directorio home!! Varias docenas de archivos mezclados hasta la médula con los nuestros, subdirectorios también, y puede ponerse peor si algunos archivos (o directorios) tienen el mismo nombre que los nuestros (no serán sobrescritos nuestros archivos, pero entonces las cosas se mezclarán y habrá que sacarlas más tarde). Complicado eh?. Esto es por lo que prefiero usar el Midnight Commander para mirar los tarballs y copiar sus contenidos sanamente, en vez de descompactar a lo loco. Para aquellos que no usen el Midnight Commander o cualquier otro programa que nos permita explorar los tarballs simplemente pueden hacer:

tar tvf <filename>

Esto nos mostrará el contenido del archivo -y si todo no tiene el nombre de un directorio delante, cuidado! Bueno, no realmente, todo lo que hay que hacer cuando esto ocurra es crear algún directorio (si le ponemos el mismo nombre del tarball, luego más tarde no olvidaremos sobre lo que es) y descompactar el tarball en ese directorio:

mkdir rudeprogram-6.66
tar xvf rudeprogram-6.66.tgz -C rudeprogram-6.66

Ahora todos los archivos del tarball "rudeprogram" serán extraídos al directorio especificado.

Afortunadamente el autor de "cuyo" es cortés (cómo casi la mayoría de los programadores), y "cuyo" fue "tarreado" en su propio subdirectorio. Dentro de él había una lista de archivos, incluyendo aquéllos que debemos chequear siempre antes de comenzar las operaciones: "README" e "INSTALL". El primero es casi siempre las instrucciones del autor, las recomendaciones, étc, el segundo nos explica cómo operar "configure", un programa extremadamente bueno que nos chequeará el sistema y correctamente (bueno, casi siempre) actualizará el Makefile, que es necesario para poder compilar el programa. La gran ventaja de esto es que si el programador fue lo suficientemente cuidadoso escribiendo su programa, "configure" creará el Makefile correcto para cualquier versión de Unix - y quizás otros SOs.

Permítanme explicarme por un momento: algunos programas son tan simples que no requieren el uso de "configure", y simplemente vienen con un Makefile (esto puede ser en mayúsculas o viceversa). Otros más simples aún solamente traen un único "progfile.c" o "progfile.cc". Esta compilación consiste en simplemente ejecutar "make" en el primer caso, o "cc progfile.c -o progfile" en el segundo.

De toda formas - Ejecuté "configure" en el subdirectorio de "cuyo", analizó my sistema por un rato, lo cual es su trabajo, y me construyó el Makefile. No estuvo bien eso? :) Hubo un ligero problema, "configure" imprime mensajes mientras se ejecuta y nos avisa en caso de algún error (usualmente detiene la ejecución e imprime el error). El mensaje que me dió -sin detenerse- fue:

checking the Qt meta object compiler... (cached) failure 
configure: warning: Your Qt installation seems to be broken!

Hmm. Bueno, me construyó el makefile de todas formas. Usualmente los errores no fatales sólo significan que no podremos disfrutar de algunas características del programa, pero de todas maneras compilará. Bueno, hagámoslo.

Luego corrí "make" -simplemente tecleando "make" en la línea de comandos, que por defecto lee el "Makefile" (o "makefile") y sigue los comandos especificados en la sección "all" y...

Ooops. Falló.

Cuando llegué a este punto fue que me decidí a escribir este artículo. Yo no estaba pensando en hacerlo; en realidad tenía mucho trabajo en este mes - pero creo que instalar software desde archivos tarball es una habilidad necesaria para cualquier usuario de Linux, y mi idea fue documentar todo el proceso, incluyendo instalaciones problemáticas que pueden ir mal. Es algo con lo que luché en mis primeros días con Linux, y me gustaría ahorrarles a otros un poco de dolor :).

Así que, sigamos adelante. Cuando digo que falló, ¿que fue lo que exactamente vi? Bueno, un "make" debería correr sin problemas. Algunas veces - muy a menudo - encontraremos advertencias, que no son lo mismo que los errores; tus librerías pueden ser un poco diferentes, o quizás tu compilador es un poco más estricto acerca de las declaraciones - pero estos no son fatales casi siempre. Los errores que nos sacan de la compilación sin terminar - esos son los que debemos arreglar. Así es como se vería:

Baldur:/tmp/cuyo-1.03$ make
make all-recursive 
make[1]: Entering directory `/tmp/cuyo-1.03'
Making all in src 
make[2]: Entering directory `/tmp/cuyo-1.03/src' 
c++ -DHAVE_CONFIG_H -I. -I. -I.. -DPKGDATADIR=\"/usr/local/share/cuyo\" 
	-Wall -ansi -pedantic -c bildchenptr.cpp
In file included from bildchenptr.h:21, 
	from bildchenptr.cpp:18: 
inkompatibel.h:13: qglobal.h: No such file or directory
make[2]: ** [bildchenptr.o] Error 1 
make[2]: Leaving directory `/tmp/cuyo-1.03/src'
make[1]: [all-recursive] Error 1 
make[1]: Leaving directory `/tmp/cuyo-1.03'
make:  * [all-recursive-am] Error 2 
Baldur:/tmp/cuyo-1.03$

El error empieza en la línea que comienza con "In file included...", y termina con (al menos la parte que nos interesa) "...qglobal.h: No such file or directory". Está bien - hay un archivo "header" que falta. Eché una rápida mirada a través del árbol de directorios del código fuente de "cuyo", sólo para estar seguro de que el autor no olvidó incluir alguno de sus archivos (sí, a veces pasa) - parece que no. Debe ser alguno de los míos - eso es, su programa debe estar buscando por un archivo que viene con una librería que debe estar instalada en mi sistema para que el programa pueda compilar. Hmm. ¿Cuál? Cualquiera que contenga "qglobal.h", por supuesto.

En mi sistema, he configurado diversos scripts para que me ayuden con las tareas de instalación normales. Uno de estos es "pkgf" - encuentra cualquier archivo que esté buscando por toda la distribución Debian, y me dice en que paquete se encuentra el archivo (esto no es lo mismo que "dpkg -S <archivo>",que hace esto para los paquetes instalados solamente.) Si usas Debian, puedes obtener la misma funcionalidad descargando "Packages.gz" desde <ftp://ftp.debian.org> y con zgrep buscar a través de él el nombre del archivo que queremos encontrar - o, también puedes ir a <http://www.debian.org/Packages> y usar su utilidad de búsqueda. El objetivo es encontrar que paquete contiene "qglobal.h" e instalarlo.

pkgf "qglobal.h" 
usr/include/qt/qglobal.h 	devel/libqt-dev 
				devel/libqt3-emb-dev 
				devel/libqt3-dev 
				devel/libqt-emb-dev

Bueno, bueno - parece que tengo varios paquetes para escoger. OK, "libqt3-dev" parece ser lo más actualizado:

apt-get install libqt3-dev

La instalación fue rápida, y... obtuve el mismo error cuando ejecuté de nuevo "make". Y así te ocurrirá a ti también. Así que, no lo hagas. Lo principal para recordar aquí (yo sabía que ocurriría - hice esto para que te dieras cuenta) es que ya corriste "./configure": los viejos valores todavía están en el Makefile, así como en otros diversos archivos, así que, en vez de malgastar tiempo tratando de descubrir donde están estos archivos:

ben@Baldur:/tmp/cuyo-1.03$ cd ..
ben@Baldur:/tmp$ rm -rf cuyo-1.03 
ben@Baldur:/tmp$ tar xvzf ~/TGZs/cuyo-1.03.tar.gz -C . 
ben@Baldur:/tmp$ cd cuyo-1.03

En otras palabras, borré el directorio "cuyo" entero y lo reemplacé con una copia fresca del código. Esto es una buena regla: cuando estés en duda, vira para atrás y coge los fuentes originales. Lo crean o no, aprendí este truco de un mecánico de botes que hacía un extraordinario buen trabajo. La forma en que Kenny lo decía era: "regresa atrás a las cosas que tú sabes que están correctas, y luego comienza de nuevo desde ahí." Nunca he tenido problemas con este consejo, admitiéndolo, los clientes tienden a gritar cuando les dices que debes botar la pieza de software que tienen y reemplazarla desde abajo.. pero después de un rato, la palabra se riega "Oigan, este tipo es bueno". Puedes perder algunos trabajos de esa manera - me ha pasado - pero como Kenny, no deseo tener mi nombre en un pedazo de basura.

Lo sé, lo sé - estoy hablando de cosas que son más generales que solo una instalación fácil de un archivo tarball. La cosa es que, la filosofía de como haces las cosas debe venir de algún lado - y es mejor que pensemos primero como hacer las cosas, antes de hacerlas, sobretodo la metodología así como cosas específicas del trabajo. OK, volviendo a la pregunta principal: ¿funcionó o no?

ben@Baldur:/tmp/cuyo-1.03$ ./configure
<No errors>
ben@Baldur:/tmp/cuyo-1.03$ make
<lots of output elided> 
make[2]: Leaving directory `/tmp/cuyo-1.03/src'
Making all in data 
make[2]: Entering directory `/tmp/cuyo-1.03/data'
make[2]: Nothing to be done for `all'. 
make[2]: Leaving directory `/tmp/cuyo-1.03/data'
Making all in docs 
make[2]: Entering directory `/tmp/cuyo-1.03/docs'
make[2]: Nothing to be done for `all'. 
make[2]: Leaving directory `/tmp/cuyo-1.03/docs' 
make[2]: Entering directory `/tmp/cuyo-1.03' 
make[2]: Nothing to be done for `all-am'. 
make[2]: Leaving directory `/tmp/cuyo-1.03' 
make[1]: Leaving directory `/tmp/cuyo-1.03' 
ben@Baldur:/tmp/cuyo-1.03$

Ta-daaa!!! Sin errores - y cuando entré en el directorio "cuyo-1.03/src", había un bonito ejecutable llamado "cuyo" esperando ahí. En este punto, si quisiera continuar la instalación (en vez de probar el juego para ver si me gustaba), escribiría:

make install

Esto leerá el Makefile y ejecutará todos los comandos debajo de la seccion "install", que seguramente instalará los ejecutables, las páginas man y la documentación. Como quiera que sea, yo tiendo a jugar con el programa primero para ver si me gusta - la mayoría de los Makefile no tienen una sección "uninstall" (pienso que esto es una vergüenza; eso haría a los paquetes tarball tan fáciles de installar y quitar como, digamos, los RPMs o los DEBs).

Recapitulando todo el proceso para instalar un tarball:

1) Chequear si el tarball contiene un directorio o sólo (¡que rudo!) archivos regados.
2) Descompactarlo dentro de un directorio debajo de "/tmp" o "~/tmp".
3) Ejecutar "configure" si existe.
4) Ejecutar "make", o "cc" si sólo es un archivo "archivo.c" o "archivo.cc".
5) Ejecutar "make install" si obtenemos el resultado que queremos.

Esto es bastante. Notése que no discutí acerca de la seguridad en ningún lugar (¿en realidad confías en el autor de este tarball o paquete? No estabas logueado como root mientras jugabas con ese binario, ¿no?), tampoco muchos artículos acerca de administración del sistema; estos temas son muy importantes pero están fuera del alcance de este artículo. El sabio administrador del sistema - y ese, mi querido usuario casero de Linux, eres ; ¡no hay nadie más en tu máquina! - leerá mucho, pensará profundamente y considerará sabiamente.

Buena suerte, y que todas tus dependencias terminen siendo resueltas. :)

Ben Okopnik

Ben Okopnik

Ben, un cyberjack, recorre el mundo en su bote del 38, construyendo redes y hackeando hardware y software cuando se queda corto de dinero para navegar. Anda jugando y trabajando con las computadoras desde los días de Elder (¿alguien recuerda el Elf II?), y no tiene para cuando parar.


Copyright © 2002, Ben Okopnik.
Copying license http://www.linuxgazette.com/copying.html
Published in Issue 74 of Linux Gazette, January 2002