¿Cómo instalar realmente un archivo tar.gz en Linux? ¿Cómo administrar aplicaciones instaladas manualmente (o independientes)?

¿Por qué muchas aplicaciones no están disponibles en repositorios de paquetes?

Puede haber muchas razones:

• Nadie se molestó en empaquetar la aplicación.
• Nadie puede empaquetar la aplicación (como Oracle insistiendo en ser el único que distribuye Java).
• El paquete se publica bajo una licencia que contradice los valores de las distribuciones.
• ...

No hay una sola razón. Si desea ver su aplicación favorita en el administrador de paquetes de su distribución, debe tratar cada caso por separado. Intente ponerse en contacto con los desarrolladores (en un canal de IRC o una lista de correo, por ejemplo) y pregunte cómo podría ayudar a empaquetar.

¿Cómo instalar un tarball?

Un tarball (paquete .tar.gz) podría contener cualquier cosa. Hasta que realmente lo abra, no tiene forma de asumir cómo instalarlo. Nuevamente, cada paquete debe abordarse de manera diferente.

¡Busca la documentación! Cualquier paquete (semi) decente proporcionará instrucciones sobre cómo instalar la aplicación. Su primer reflejo siempre debe ser buscar un archivo de texto llamado README, INSTALL o algo así. Consultar el sitio web del editor también podría ayudar.

Dado que cada paquete es diferente, no existe una forma universal de procesar todos los tarball del mundo. Eso es como pedir una receta que funcione con todos los ingredientes del mundo. No está sucediendo.

Un buen conocimiento de su sistema, su distribución y su entorno de escritorio ayudará, por lo que, si esto es tranquilizador, las cosas se verán cada vez más predecibles a medida que pase tiempo en el mundo de Linux.

Un caso especial:Autotools

A medida que los proyectos crecen, deben proporcionar formas fáciles de pasar del código fuente al binario para instalarlo por completo en el sistema. Es por eso que se envían con un sistema de compilación integrado, una colección de scripts para hacer lo necesario.

En el mundo de Linux/código abierto/software libre, un sistema de compilación tuvo una adopción más amplia:GNU Autotools. Si alguna vez trata con un paquete de código fuente (abierto), existe una gran posibilidad de que utilice Autotools.

En el caso más simple, aquí se explica cómo instalar una aplicación empaquetada con autotools:

• ./configure :Un script que generará los Makefiles correspondientes a su sistema (a menudo también verifica la disponibilidad de dependencias).
• make :Compilar el código fuente de acuerdo con los Makefiles generados anteriormente.
• make install :copia los archivos binarios en las ubicaciones adecuadas, crea enlaces simbólicos y cualquier otro paso definido por el desarrollador.

Notas

• configure los scripts suelen tener muchas opciones, como qué compilador usar o cómo definir el directorio de destino. Si necesita flexibilidad, vale la pena mirar ./configure --help .
• Incluso si está seguro de que es Autotools y lo conoce muy bien, siempre Comience leyendo los documentos (LÉAME, INSTALAR, ...)

Respuesta a la actualización en la pregunta

Lo que estás pidiendo no tiene una respuesta definitiva. Todos aquí pueden tener una opinión sobre lo que constituye una "buena práctica", pero al final del día, solo usted puede encontrar lo que funciona para usted . Si hubiera una respuesta fácil, no estarías haciendo la pregunta. Tu distribución lo habría respondido por ti.

Dicho esto, he aquí algunos comentarios personales.

• En mi sistema, reservo /usr/local/bin para los paquetes instalados por mi administrador de paquetes. Todo lo que compilo/instalo a mano va en /opt . Esto es un detalle pero ayuda a evitar grandes dolores de cabeza cuando se trata de varias versiones de un mismo programa.

• xxx.desktop , y los problemas de GUI en general, son específicos del entorno de escritorio que está utilizando. Si funciona para su sistema, genial. Pero no se puede generalizar a todos los entornos disponibles en Unix.

• /usr/local/bin tiene la ventaja de estar ya en tu RUTA. Si desea utilizar otro directorio (como /opt como sugiero), asegúrese de incluirlo en su RUTA. Si no sabe cómo hacerlo, abra una terminal y ejecute lo siguiente en una terminal (no es la forma más bonita de hacerlo, pero sin saber nada sobre su sistema, no puedo sugerir nada más):echo 'export PATH=$PATH:/opt' >> ~/.bashrc

Creo que tienes que aclarar contigo mismo con qué quieres "registrarlo" con .

Para explicar, y no estoy tratando de ser inteligente, "Linux" es, por supuesto, el kernel, y el kernel no conoce ni tiene ningún interés en ningún software de espacio de usuario en su sistema más allá de init. Entonces, ¿de qué estamos hablando aquí?

Mencionas varias distribuciones diferentes. A veces construyo software desde la fuente aunque esté disponible en el repositorio porque quiero configurar algunas opciones que no están configuradas en el binario de la distribución. El único problema que tengo con esto es que si el paquete es un requisito previo para otra cosa, de hecho tengo que registrarlo con el sistema de empaquetado para evitar instalar accidentalmente el paquete de distribución encima del que construí. En sistemas basados ​​en fedora/rpm, esto se hace con rpm -i --justdb <package> . No hago esto en sistemas basados ​​en debian/apt; en su lugar, solo fuerzo las instalaciones según sea necesario, lo que quizás sea perezoso:parece haber una forma más agradable de hacerlo, creando un paquete ficticio que pretenda cumplir con cualquier requisito previo. Eso está más o menos en la línea de la sugerencia de m0nhawk de crear un paquete a partir de la fuente .tar.gz, excepto que es un poco más simple (seré honesto y diré que no me gusta nada la sugerencia de m0nhawk).

Parece que tiene otros problemas además del sistema de embalaje. No me queda claro cuáles son, aunque mencionas el entorno de escritorio (por ejemplo, Gnome). Estos son heterogéneos, por lo que simplemente no hay una respuesta a la pregunta "¿cómo hago esto en linux?". Ni siquiera es una cuestión de "¿cómo hago esto en ubuntu" o "¿cómo hago esto en gentoo" -- es una cuestión de "¿cómo hago esto para el escritorio gnome?" o "¿cómo hago esto en el escritorio XFCE?", etc. En mi opinión, el único problema es el asunto de los lanzadores que mencionas, que yo Me gustaría creer que cada DE proporciona un medio simple para hacer esto (pero no será exactamente lo mismo, porque son diferentes). También existe posiblemente el problema de tener algo que proporcione un valor predeterminado para manejar archivos; creo que esa pregunta es "¿cómo registro un comando con mi explorador de archivos" (y los exploradores de archivos en Linux también son una colección heterogénea).

Luego están los servicios, que son administrados por el sistema init (por ejemplo, systemd o upstart). Entonces, esta pregunta es en realidad una serie de preguntas relacionadas con, potencialmente:

• el sistema de empaquetado, p. ej., apt o yum
• el sistema de inicio, por ejemplo, systemd o upstart
• el entorno de escritorio, por ejemplo, kde o unity
• el navegador de archivos, por ejemplo, nautilus o konqueror
• ?????

Parte de la razón por la que no puede haber una solución unificada simple (aunque el estándar XDG puede proporcionar algunas partes de los mismos) es que "Linux" no es un sistema operativo unificado simple y me imagino que la gran mayoría de sus usuarios lo prefieren de esa manera. A menudo no uso un DE en absoluto, y nunca uso el explorador de archivos que viene con él, etc.

Nuevamente, realmente estoy tratando de ser útil con esto y no solo pontificar:si hay problemas que desea resolver aquí, deberá considerar con mayor precisión cuáles son esos problemas y qué software está realmente involucrado con ellos (más allá de solo "linux ") si quieres resolverlos.

Creo que la razón básica de su problema general es que un sistema Linux en sí mismo no contiene un "registro" como tal. Un archivo ejecutable es todo lo que realmente necesita para que algo funcione. Si no desea especificar la ruta completa al ejecutable, la mayoría de los shells los buscarán en los directorios enumerados en la variable $PATH de su entorno. Puede volverse un poco más complejo con bibliotecas vinculadas, etc., pero normalmente no es necesario profundizar tanto.

Diferentes distribuciones de Linux se han estandarizado en varios diseños de sistemas de archivos y sistemas de administración de paquetes, ahí radica el problema. Los Redhats usan rpm, Debians/Ubuntu usan paquetes deb. Arch también siguió su propio camino. Desde la perspectiva de los proyectos de software, a menos que desee ser incluido en una distribución, su base de usuarios está completamente en una distribución, o un producto comercial que apunta a la facilidad de instalación para todos, probablemente sean los únicos puntos que comience a buscar construir. varios paquetes.

De hecho, una fuente tar.gz que se compila con gcc es probablemente la mejor definición de un "paquete de Linux" común. Un kernel de Linux con algunas utilidades GNU y GCC, casi el denominador común entre todas las diferentes versiones de sistemas operativos basados ​​en Linux que puede obtener.

No iría tan lejos como para decir que "tan pocas" cosas están disponibles como paquetes porque algo específico que está buscando no lo está. (¿o tal vez el distribuidor ha optado por no molestarse con todo este alboroto del paquete? Como Chrome y su propio proceso de actualización). Hay tantos paquetes para tantos sistemas de paquetes diferentes para tantas arquitecturas para tanto software libre que no tiene gracia.

Si ha creado algo que no se proporciona como paquete para su distribución de Linux, o admite la opción de compilar como paquete, la mejor manera de "registrar" como un paquete real es crear un paquete para él, definiendo dónde se encuentran todos los archivos deben ir en función del sistema de paquetes que elija e instalarlo de esa manera. Sea un alma y contribuya con su trabajo de empaque al proyecto para que otros puedan beneficiarse de él.

Hay varias guías en la web sobre la creación de paquetes. Debian es uno de ellos.

Si todo lo que quiere hacer es ejecutar un paquete compilado, tal vez agregue la ruta binaria a su $PATH ?

Si estás haciendo otra cosa, ¿qué es?