[ubuntu-ar] Archivos tar.gz

[Pablo Lillia]

El 23/09/15 a las 08:35, Ernesto Rizzardi escribió:
> Gracias, Angel, lo probaré. Saludos
>
> El 22/09/15 a las 21:09, Angel Cadoppi escribió:
>> El 22/09/15 20:37, Ernesto Rizzardi escribió:
>>> Hola amigos
>>>
>>> Despertaré la modorra comunicacional para molestarlos con un tema 
>>> muy remanido como es la instalación de archivos tar.gz. Me dirán que 
>>> hay toneladas de sitios donde se explica el "como", es cierto, pero 
>>> nunca pude dar con la tecla, soy duro de arriba, si existe un modo 
>>> simple para "viejos novatos" como yo, les ruego la bondad de 
>>> facilitarlo. Pido disculpas por "consultas con telarañas" . Abrazos, 
>>> Ernesto.
>>>
>> Hola Ernesto, yo tambien lidié con los tar.gz y los tar.bz2 hasta que 
>> instalé "alien", es un programita que desde consola te permite 
>> transformarlos en .deb y desde ahí todo es mas facil.
>> Espero poder aportar mi granito de arena.
>> Luego conta como te fué.
>> Saludos, Angel
>>
>
>

Con los tar.gz, alien te puede servir algunas veces, y muchas otras no.

El problema con los tar.gz es que no es un formato de paquetes, si bien 
la vieja Slackware alguna vez lo usaba (capaz que todavía los usa... 
todavía existe Slackware?? :D) como tal, pero considerando algunas 
convenciones adicionales.

El tar.gz no es más que un formato de archivos comprimidos y puede 
contener *cualquier* cosa. Es como un zip si se quiere. Puede tener 
imágenes, videos, textos, programas (binarios) de alguna plataforma, 
código fuente compilable, fotos de gatitos, .... cualquier cosa 
imaginable, mezclado, y con cualquier estructura. En realidad el archivo 
tar es solo un formato de archive (que nació en Unix para backups en 
cinta: 'ta'pe a'r'chive = tar), que también se usa para distribuir 
archivos, porque conserva y maneja bien los permisos y estructuras de 
archivos y directorios de Unix. Cuando los archivos tar además están 
comprimidos con gzip, es que terminan en .gz. También pueden comprimirse 
con otras herramientas similares, como el muy común bzip2 (bz2), 7zip 
(7z), o más raro en zip.

Pero veamos los dos casos más habituales de tar.gz:

OPCION 1) tar.gz binario (el programa ya compilado) de un programa.

Hay que bajarse el que sea (más) compatible con tu Linux, y de la 
arquitectura correcta (x86 = 32-bit, x86_64 o AMD64 para 64-bit). Solo 
hay que descomprimirlo y ejecutar el programa. El nombre del 
ejecutable... puede ser cualquier cosa. Lo mejor: seguir las 
instrucciones, o fijarse qué ejecutables tiene y probar. Es normal que 
dentro del .tar.gz exista una carpeta con el nombre del programa.

Un ejemplo:
     $> tar xzvf progama-dist-bin.tar.gz
     $> cd programa/
     $> ./programa

Supongiendo que el tar.gz se llame programa-dist-bin.tar.gz, que los 
archivos están en una carpeta llamada "programa", y que el ejecutable 
del programa se llama "programa", y que ya tiene permisos de ejecución.
Sino, para ver qué archivos tienen permisos de ejecución, basta con 
hacer un:
     $> ls -lh
y ver qué archivos tienen una 'x' en la tripleta de permisos, o si está 
coloreado, pueden ser los que tienen el color verde (puede cambiar según 
la terminal, la distro, y las opciones del usuario).
El "punto barra" de ./programa, es para correr el programa que está con 
ese nombre en el directorio actual.


OPCION 2) tar.gz con código fuente.

Depende del tipo de programa y/o de la sanidad mental del autor, si 
sigue o no las convenciones GNU, y de muchas variables, como la posición 
de los astros. Pero "en general", una gran mayoría se reduce a esos pasos:

     $> tar xzvf progama-dist-src.tar.gz
     $> cd programa/
     $> ./configure
     $> ./make
     $> sudo make install

El comando (script en realidad) configure analiza si se cumplen las 
dependencias en el sistema: si existen las librerías en el sistema, si 
tienen las versiones correctas, si están los encabezados para poder 
compilar, si están presentes todas las herramientas de compilación, y un 
largo etc muy técnico. Puede terminar con éxito... o reportar problemas. 
Dichos problemas, pueden indicar que antes necesitamos instalar algo, 
llamado por ese motivo una "dependencia", como puede ser una librería o 
un compilador. A veces las dependencias ya están instaladas, pero 
"configure" fue incapaz de encontrarlas porque no están en las rutas 
(path) esperadas. En tal caso, configure tiene muchas opciones para 
forzar un path alternativo. También configure tiene opciones para 
habilitar o deshabilitar opciones del programa. Por ejemplo: tal vez el 
programa soporta varias interfaces gráficas, como Gnome, KDE, y X11, y 
por ahí solo nos interesa compilar una de ellas. O tal vez el programa 
tiene partes opcionales que no nos interesan o no aplican a nuestro 
caso, o que no son compatibles con nuestras dependencias. Con 
"configure" se pueden habilitar y deshabilitar dichos componentes 
opcionales. A veces un programa que no compila, se soluciona 
deshabilitando algo opcional, o forzando alguna configuración.

El comando make, sin entrar en muchos detalles, digamos que procesa un 
script (guión) llamado Makefile, creado por los conjuros mágicos del 
'configure'. Digamos que make interpreta pergaminos de una antigua 
ciencia oscura usada para invocar a los compiladores, ensambladores y 
enlazadores en un orden correcto. Nadie sabe a ciencia cierta como 
funciona, salvo un par de mortales, y quien dice lo contrario, 
probablemente miente, está loco, o hizo un pacto con el lado oscuro. No 
exagero :D

El último comando, sudo make install, hace la instalación (copia) del 
programa y todos sus archivos en las ubicaciones definitivas del 
sistema. Se debe correr con 'sudo', porque suele necesitar permisos 
administrativos para poder copiar en carpetas protegidas.

Para desinstalar un programa instalado así, a veces hay un paso inverso 
que es:
     sudo make uninstall

A veces la desinstalación falla miserablemente, o no deja las cosas en 
orden, resultando en situaciones hilarantes como un sistema inutilizado.

Pero no todos los programas tienen y/o necesitan un "configure", algunos 
programadores están más allá de ello o no comulgan los mismos credos. 
Algunos usan otros sistemas de construcción. O tienen scripts creados 
por el mismo programador a su propio gusto, locura y/o necesidad.

También hay programas en/para Python, PHP, Node.js, etc, que se instalan 
por otros procedimientos y vías.

Después de todo esto, con suerte quedará un programa instalado fuera del 
control del sistema de paquetes de la distribución, la mayoría de las 
veces sin más consecuencias, pero que otras pueden traer problemas 
cuando se actualicen paquetes de la distribución, y hasta podrían 
introducir fallos de seguridad al no recibir actualizaciones periódicas 
por estar instalados por fuera del sistema.

Instalar programas de esta forma, nunca es aconsejable, y debe hacerse a 
conciencia, como última opción. A partir del "sudo make install", si 
algo sale mal, pueden pisarse archivos del sistema y dejar un 
zafarrancho divertido, que en casos extremos puede llevar a una 
reinstalación del sistema operativo. En casos dudosos o con sistemas 
críticos, es buena práctica probar primero en un sistema de pruebas, 
como puede ser una máquina virtual (ejemplo VirtualBox o qemu) que sea 
desechable.

Normalmente todo programa trae un documento README y/o un INSTALL. Si 
existen estos documentos, vale la pena leerlos, porque pueden tener 
instrucciones útiles.

Si bien no existe "una" receta, como aprendizaje está muy bueno, aparte 
de útil para algunas situaciones. Y la mejor forma de aprender, es 
probando (y a veces rompiendo xD). Es cuestión de animarse :)

Saludos,
Pablo