[ubuntu-ar] Archivos tar.gz

[Ernesto Rizzardi]

Gracias, Pablo
Al intentar instalar archivos tar.gz, me "sugieren" hacerlo con Unetbootin.
Pero ya metí la pata al usar Unetbootin para instalar Libreoffice 5 , y 
no me permite actualizar nada, sale un cartel "E: El paquete unetbootin 
necesita ser reinstalado, pero no se encuentra un archivo para éste.E: 
Error interno al abrir el caché (1). Por favor informe de este error. Y 
ahora estoy en el horno, te molesto por una ayuda? Gracias, Ernesto






El 23/09/15 a las 19:04, Pablo Lillia escribió:
>
> 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
>