instalar programas en linux

Instalar programas en GNU/Linux desde un tarball, ó código fuente

Cuando necesitamos instalar programas adicionales en nuestro GNU/Linux, lo primero que determinamos es el tipo de distribución que tenemos. Para instalar software en estos sistemas se requiere de ciertos tipos de paquete compatibles que lo contenga. Debido a que GNU/Linux es una «ecología» tecnológica rica en diversidad de software (gracias a la libertad de su licenciamiento), las distintas distribuciones tienen sus propios administradores de paquetes; las basadas en Red Hat (CentOS, Fedora, etc) manejan paquetes RPM; las basadas en Debian (Ubuntu, LinuxMint) manejan paquetes DEB.

Sin embargo, a veces no podemos encontrar el software que necesitamos en alguno de esos paquetes. En tale caso, la última opción es acudir a un tipo de paquete universal llamado tarball, el cual se administra con un procedimiento especial para instalarlo. Los tarball en realidad son programas que vienen en forma de código fuente, y requiere de un proceso de conversión a binario (o ejecutable), llamado compilación. O sea, para poder usar ese programa es preciso compilarlo.

Distribución de los programas en el sistema de ficheros


Generalmente los archivos ejecutables se almacenan en el directorio /bin ó en /usr/bin. Los archivos de configuración en /etc. La documentación en /usr/share/doc. Los manuales en /usr/man o /usr/local/man.

Tengamos en cuenta las variables de entorno. Una forma de conocer las variables de entorno definidas en nuestro sistema, es con el comando env. Este comando despliega en pantalla todas las variables de entorno de tu pérfil, tanto locales como globales. Una variable de entorno no es más que un espacio en memoria que contiene información dinámica útil para los procesos.

Instalar software desde el código fuente


El sistema de instalación aquí descrito se llama Autotools. Cuando instalamos un programa desde su código fuente, usualmente seguimos tres pasos:

  • En el primero, un script analiza nuestro sistema verificando que tengamos el software adicional necesario para el éxito de la compilación, y a veces, para configurar algunas facetas opcionales de la misma.
  • En el segundo, el código fuente se compila realmente.
  • El tercer paso instala la aplicación compilada, además de sus librerías y ficheros auxiliares, en su correspondiente lugar en el sistema de ficheros.

En el caso de programas muy simples, el primer paso puede no ser necesario; algunas otras aplicaciones están diseñadas para que podamos hacerlas funcionar sin necesidad de ejecutar el tercer paso

Es importante mantener el código fuente disponible aún después de que hayamos instalado el programa con éxito. Sin ese código será my díficil desinstalarlo. Entonces, es necesario mantener las carpetas del código fuente bien organizadas.

Antes de intentar compilar cualquier aplicación, leamos siempre su archivo de documentación INSTALL, que viene dentro del tarball. Este archivo contiene las instrucciones específicas de instalación e información de la aplicación.

PASO 1


Para la mayoría de aplicaciones este paso consiste en ejecutar un script llamado configure, que viene dentro del tarball. Dicho script verifica que nuestro sistema cumpla con los requerimientos de software necesario para la compilación, y, finalmente, crea los archivos Makefiles para compilarlos. Si el proceso del script configure termina con éxito, no saldrán mensajes indicando errores ó terminará con un resumen de cómo se compilará el programa, y, posiblemente, el lugar donde será instalado el programa.

Proceso de descompresión del tarball y ejecución del script configure del programa Squid Proxy. El punto y la barra diagonal ( ./ ) indican que el script se encuentra en el directorio presente.

Algunos programas más maduros y complejos usualmente tienen varios parámetros opcionales para el script configure. Esos paramétros pueden ser usados para habilitar o deshabilitar funcionalidades del programa. Podemos usar el script de la forma ./configure --help para obtener un listado de esas opciones, y ver si alguna de ellas es útil.

Las opciones más usadas son --prefix, --sysconfdir y --localstatedir,aunque generalmente no tendremos necesidad de especificarlas. Veamos de qué se trata estas opciones:

  • --prefix: índica el directorio donde se instalará el programa.
    --sysconfdir: Define el directorio donde se colocarán sus archivos de configuración.
    --localstatedir: Define el directorio donde se almacenarán los datos variables.

Puedes leer más aquí sobre las opciones de compilado.

Variantes


Existen aplicaciones que usan un sistema de compilación ligera o completamente diferente, del tradiconal aquí detallado. En ese caso, casi con certeza, estará documentado en un fichero README ó INSTALL incluido con el código fuente, o en la página web del autor.

Es el caso de la instalación del entorno de diseño electrónico, Ktechlab, que usa el sistema de compilación CMAKE:

Dale pantalla completa

Fallas


Suele pasar que este primer punto falle. A veces el script configure puede terminar con algún error sugiriendo que un paquete, dependencia o librería no está instalada en nuestro sistema. Incluso podemos encontrarnos con que el paquete del que se queja realmente sí está instalado. Esto se debe al tipo de empaquetado de cada distribución.

Grupos de paquetes


En la mayoría de distribuciones GNU/Linux los paquetes vienen agrupados entre aplicaciones, librerías necesarias para ejecutar la aplicación y librerías necesarias para compilar.

Así que para la típica situación de una aplicación con una librería asociada, Debian y sus derivados, contendrá usualmente tres paquetes. Si la aplicación se llamase «ejemplo», estos tres paquetes se llamarían de forma parecida, así:

ejemplo
libejemplo
libejemplo-dev

Puede existir números de versión en uno, en dos o en los tres paquetes, pero usualmente seguirá este patrón básico.

El paquete «ejemplo» contiene la aplicación como tal, con sus ficheros de configuración, entradas de menú y datos asociados con sonidos, graficos, traducciones y así.

El paquete «libejemplo» contiene ficheros de librería asociados a la aplicación, que son útiles para el funcionamiento de la aplicación, algo así como un complemento. 

Si intentamos compilar algo desde el código fuente, y el script configure termina con un error diciendo que «libejemplo» no está instalado, entonces lo más probable es que el paquete que realmente necesitamos es «libejemplo-dev«.

Frecuentemente habrán varios paquetes -dev necesarios que no tendremos instalados. Asi que cuando hayamos instalado uno y volvamos a ejecutar el script configure, y éste volviera a quejarse por falta de otra dependencia o librería, debemos perseverar instalando los paquetes necesarios. Llegará el momento en que habremos superado con éxito este paso.

PASO 2


Seguimos con la compilación como tal. Generalmente este paso se ejecuta con el programa make.

Muchas aplicaciones no están perfectamente codificadas, pues los autores a veces olvidan escribir una verificación en el script configure para una librería necesaria en la compilación. En ese caso, el proceso de compilación fallará repentinamente y mostrará varios mensajes de error. Casi que tendremos que agudizar nuestra intuición para determinar la falla, así como repasar el archivo README ó INSTALL, y acudir a Google para investigarla.

Cuando hayamos instalado el paquete faltante, o que ya hayamos resuelto el error, podemos volver a ejecutar el compilador make, sin necesidad de repetir el paso 1.

Paso 3


Finalmente instalamos el programa recién compilado con el comando make install.

En muchos casos el programa compilado se instalará en el directorio /usr/local/bin; las librerías en /usr/local/lib; los archivos de configuración se copiarán en /usr/local/etc y otros archivos en /usr/local/share. Esta es una valiosa convención para que nada se instale al azar en cualquier lugar, a menos que lo especifíquemos como lo vimos en el paso 1.

Variantes


Seguramente nos encontrarémos con programas que intenten instalarse de forma predeterminada en directorios importantes del sistema; ejecutables en /usr/bin, librerías en /usr/lib y archivos de configuración en /etc, y así. Este es un comportamiento extremadamente malo, dado que las aplicaciones compiladas se mezclarán y se confundirán con herramientas instaladas por la distribución. Este comportamiento debe considerarse un serio error de la aplicación y se le debe informar a su desarrollador.

Problemas


Es bastante inusual encontrarse con problemas durante la ejecución del programa recién instalado. Por ejemplo, podemos descubrir que no podemos ejecutar el programa debido a que las variables de entorno de nuestra distribución, no tienen en cuenta las aplicaciones instaladas en /usr/local/bin.

Si al intentar ejecutar la aplicación el sistema nos devuelve un mensaje de error «command not found«, intente usted primero ejecutar el comando hash -r. Si lo anterior no lo resuelve, puede que el directorio /usr/local/bin no conste en su variable de entorno PATH.

La variable de entorno PATH es un espacio de memoria con una lista de directorios que contienen aplicaciones o ficheros ejecutables. Cualquier ejecutable que esté en PATH puede ser ejecutado con solo escribirlo en la shell.

Por ejemplo, si necesitamos añadir temporalmente el directorio /opt/bin al PATH de nuestro sistema, ejecutamos el siguiente comando:

export PATH=$PATH:/opt/bin

Verificalo con el comando env | grep /opt/bin

En Ubuntu, para que la ruta de nuestro ejemplo quede permanente en PATH, solo basta con incluirla en el archivo /etc/environment, y activarla con el comando source /etc/environment && export PATH .

Libraries not found (librerías no encontradas)


Si usted puede ejecutar la aplicación, pero ésta falla porque no puede encontrar ficheros de librerías, necesitará adicionar el directorio /usr/local/lib al lugar donde el sistema busca las librerías compartidas. En Ubuntu, ese lugar es el archivo /etc/ld.so.conf.d/libc.conf (aunque por lo general Ubuntu ya lo tiene listo). Después, guarde usted los cambios ejecutando el comando ldconfig.

Instalar un programa en Linux desde su tarball. Ejemplo práctico


Bueno, muy bonito y todo, nuestros dedos están que braman sus motores en las pistas de los teclados para compilar. Entonces, veamos cómo funciona esta teoría en la práctica.

Para este ejemplo vamos a compilar a Qalculate, una potente calculadora de código abierto desarrollada en GTK. Podemos descargar su tarball desde su página oficial.

Qalculate

Sabemos que dicha calculadora la podemos encontrar fácilmente como paquete DEB, pero vamos a instalarla desde su código fuente para confirmar lo expuesto en este artículo.

Este proceso de compilación e instalación se ha realizado sobre Ubuntu MATE 18.04 recién instalado, por lo que seguramente nos pasará de todo lo que se describe en esta teoría.

Dale pantalla completa

Concluimos entonces que la instalación de Qalculate requiere una ramificación de dependencias como se ilustra a continuación:

Dependencias ramificadas para Qalculate

Afortunadamente el sistema de gestión de paquetes, APT, de Debian y sus derivados, ó YUM de CentOS y los suyos, hacen todo ese trabajo por nosotros.

Instalar programas en Linux desde un tarball Overall rating: ★★★★★ 5 based on 1 reviews
5 1

 

Su nombre
Email
Titulo
Valoración
Opinión

 

Interesante

★★★★★
5 5 1
Nunca lo había visto de esta forma
Comparte esto en
Publicado en GNU Linux.