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

Veo todos estos enlaces que explican paquetes y .debs ... Lo sé ... y hay muchos kludges para hacer que funcionen los archivos tar.gz (por ejemplo: alternativas de actualización para Java o soltar manualmente el archivo en / usr / local / bin (o en otro lugar, que deduje de horas de búsqueda)). Si los paquetes son tan inteligentes, ¿cómo hay tan pocas aplicaciones de Linux disponibles en paquetes o .debs / rpms?

Estoy hablando como un nuevo usuario; Sé que los expertos probablemente lo saben mejor (¿creo que puedo descargar una versión compilable de Eclipse?). Al igual que Netbeans y Chrome .sh, eclipse es un directorio simple y ejecutable, Java requiere este update-alternativesnegocio, pero no creo que se registre en la "lista de programas" de Ubuntu / Debian (solo se registra como un comando), etc. (Sé que estos son a veces disponible en repositorios, pero estoy confundido por qué las páginas de descarga no tienen explicaciones adecuadas).

En pocas palabras: si descargo o compilo un archivo tar.gz, ¿cómo lo registro en el sistema? update-alternativesparece registrarlo como un comando, en Ubuntu, no aparece en la barra de búsqueda. En Debian, puedo agregar manualmente un acceso directo al iniciador de GNOME 2. Pero, ¿qué debería estar haciendo realmente?

Editar:

Entonces, después de jugar un poco más con las nuevas soluciones, puedo refinar mi "problema":

¿Cómo debo administrar mis programas instalados manualmente? Firefox y Eclipse son mis únicos ejemplos hasta ahora (no descargo muchas cosas). Ambos pueden quedarse sin caja, lo que me gusta. Excepto, ¿dónde debería instalarlos? Veo que Eclipse tiene sus propias instrucciones, pero prefiero hacer todos mis "paquetes manuales" de la misma manera.

1. Después de un poco de investigación, decidí poner estos programas en /usr/local/bin.
2. De cómo instalar eclipse , pensé en obtener algo para mostrar en el lanzador, necesito poner un xxx.desktoparchivo ~/.local/share/applications/. ¿Importa el nombre de este archivo .desktop?
3. Cosas con autotools (busco un configureo unix/configurearchivo) saldrá bien. Algunos puntos de investigación que debería utilizar CheckInstallpara realizar un seguimiento de todo esto.
4. Debería usar update-alternativespara registrar caminos. A partir de este hilo de Java , parece que creo un enlace de /usr/bin/javaa /usr/lib/jvm/jdk.... Cuando instalo estas aplicaciones "independientes" como Eclipse o Firefox, ¿siempre debo vincularme /usr/bin/[app]? Y si la afirmación 1 es cierta, estaría haciendo cosas comosudo update-alternatives --install "/usr/bin/[app]" "[app]" "/usr/local/bin/[app]" 1

¿Son correctas estas instrucciones / una buena forma de gestionar las instalaciones manuales? ¿Hay otros pasos que deba seguir? ¿Otras sugerencias?

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

Podrían haber varias razones:

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

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 IRC o en 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.

¡Busque 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í. Visitar el sitio web del editor también podría ayudar.

Como cada paquete es diferente, no hay una forma universal de procesar cada tarball en el mundo. Es como pedir una receta que funcione con todos los ingredientes del mundo. No esta pasando.

Un buen conocimiento de su sistema, su distribución y su entorno de escritorio ayudarán, por lo tanto, 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, necesitan proporcionar formas fáciles de pasar del código fuente a la instalación binaria 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 / Open Source / 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 (n abierto), existe una gran posibilidad de que use Autotools.

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

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

Notas

• configurelos scripts generalmente tienen muchas opciones, como qué compilador usar o cómo definir el directorio de destino. Si necesita flexibilidad, vale la pena mirarlo ./configure --help.
• Incluso si está seguro de que es Autotools y lo sabe muy bien, siempre comience leyendo documentos (README, INSTALL, ...)

Responda 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ía haciendo la pregunta. Tu distribución lo habría respondido por ti.

Dicho esto, aquí hay algunos comentarios personales.

• En mi sistema, reservo /usr/local/binlos paquetes instalados por mi administrador de paquetes. Todo lo que compilo / instalo a mano entra /opt. Este es un detalle, pero ayuda a evitar grandes dolores de cabeza cuando se trata de varias versiones del mismo programa.

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

• /usr/local/bintiene la ventaja de estar ya en tu RUTA . Si desea usar otro directorio (como /optsugiero), 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

Yo creo que hay que aclarar con uno mismo lo que quiere "registro" que 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 ninguno de los 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 a pesar de que está disponible en el repositorio porque quiero establecer algunas opciones de configuración que no están establecidas en la distribución binaria. 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 empaque para evitar instalar accidentalmente el paquete de distribución sobre el 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, simplemente forzo las instalaciones según sea necesario, lo que quizás sea perezoso, parece que hay una mejor manera de hacerlo, al crear un paquete ficticio que pretende cumplir con cualquier requisito previo. Eso es algo así como la sugerencia de m0nhawk de crear realmente un paquete a partir de la fuente .tar.gz, excepto que es un poco más simple (seré sincero y diré que no me gusta en absoluto la sugerencia de m0nhawk).

Parece que tiene otros problemas además del problema con el sistema de empaque. No me queda claro cuáles son, aunque mencione 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 pregunta de "cómo hago esto en ubuntu" o "cómo hago esto en gentoo ": se trata de" cómo hago esto para el escritorio de gnome "o" cómo hago esto en el escritorio XFCE ", etc. En mi opinión, el único problema es el tema 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).

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 relacionadas, potencialmente:

• el sistema de embalaje, por ejemplo, apt o yum
• el sistema init, por ejemplo, systemd o upstart
• el entorno de escritorio, por ejemplo, kde o unity
• el explorador 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 la misma) es que "Linux" no es un sistema operativo unificado simple e 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 navegador de archivos con el que vienen, etc.

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

Creo que la razón básica de su problema general es que un sistema Linux por sí solo no contiene un "registro" como tal. Un archivo ejecutable es todo lo que realmente necesita para que algo se ejecute. 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 ser un poco más complejo con las 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 siguió su propio camino también. 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 facilitar la instalación para todos, probablemente sean los únicos puntos que comience a buscar para construir Varios paquetes.

De hecho, una fuente tar.gz que se construye con gcces probablemente la mejor definición de un "paquete Linux" común. Un kernel de Linux con algunas utilidades GNU y GCC casi el común denominador entre todos los diferentes tipos de sistemas operativos basados ​​en Linux que puede obtener.

No iría tan lejos como para decir "tan pocas" cosas disponibles como paquetes porque algo específico que estás buscando no lo es. (¿o tal vez el distribuidor ha optado por no molestarse con todo este alboroto de paquetes? Al igual que Chrome y su propio proceso de actualización). No son tan muchos paquetes de alrededor de lo que muchos diferentes paquetes de sistemas para tantas arquitecturas de software libre tanto su no es divertido .

Si ha creado algo que no se proporciona como paquete para su distribución de Linux, o admite la opción de construir como paquete, la mejor manera de "registrarlo" como un paquete real es crear un paquete para él, definiendo dónde 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 agregar la ruta binaria a su $PATH?

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

Me gustaría agregar que también puedes hacer un enlace simbólico en ~/bin/lugar de /usr/bin. *.desktoplos archivos se pueden colocar en ~/.local/share/applications/o /usr/share/applications/. Solo uso mi computadora, y me gusta evitar tocar los archivos del sistema (cualquier cosa fuera de mi directorio personal) lo más posible.

Por supuesto, cuando coloca cosas en las contrapartes del "directorio de inicio", no se mostrarán a otros usuarios.

Esto es lo que se incluye en el valor predeterminado ~/.profilepara debian wheezy:

# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/bin" ] ; then
    PATH="$HOME/bin:$PATH"
fi