Efecto de compilar desde la fuente en aplicaciones ya instaladas

Yo uso Ubuntu 12.04. Digamos que he instalado package xdesde el repositorio (con todas sus dependencias) en la versión 1.7 pero necesito alguna funcionalidad que solo está disponible en la versión 1.8, así que descargo el tar de origen y lo compilo:

./configure  
make  
make install

• ¿Esto sobrescribe los binarios 1.7 existentes?
• Si se sobrescriben los archivos binarios existentes, ¿el administrador de paquetes refleja la nueva versión (1.8) y package xel administrador de paquetes puede actualizarlos en el futuro?
• Si package ytiene una dependencia de package x 1.8, ¿se satisfará?

He estado tratando de encontrar una buena fuente en línea que explique esto. Si tiene alguna recomendación, hágamelo saber.

La gran mayoría de los .debpaquetes, ya sean provistos o no por repositorios oficiales, se instalan con el prefijo /usr.

Lo que eso significa es que los ejecutables destinados a ser ejecutados por el usuario entran /usr/bino /usr/sbin(o /usr/gamessi es un juego), entran las bibliotecas compartidas, entran los /usr/libdatos compartidos independientes de la plataforma /usr/share, entran los archivos de encabezado /usr/includey entra automáticamente el código fuente instalado /usr/src.

Un pequeño porcentaje de paquetes se usa /como prefijo. Por ejemplo, el bashpaquete pone el bashejecutable en /bin, no /usr/bin. Esto es para paquetes que proporcionan los elementos básicos esenciales para ejecutarse en modo de usuario único (como el modo de recuperación) y para iniciar el modo multiusuario (pero recuerde, eso a menudo incluye funcionalidad para montar algunos tipos de recursos compartidos de red ... en caso de que /usrsea un sistema de archivos remoto).

Un pequeño porcentaje de .debpaquetes, en su mayoría aquellos creados con Quickly , crea una carpeta específica de paquete dentro /opty coloca todos sus archivos allí. Aparte de eso, la mayoría de las veces /optes la ubicación utilizada por el software que se instala desde un instalador ejecutable que no utiliza el administrador de paquetes del sistema pero que no implica la compilación desde la fuente. (Por ejemplo, si instala un programa propietario como MATLAB, es probable que lo instale /opt).

En contraste con todo esto, cuando descarga un archivo fuente (u obtiene el código fuente de un sistema de control de revisión como Bazaar o git), lo construye e instala, por lo general se instala en el prefijo /usr/local(a menos que se lo indique) de otra manera). Esto significa que sus ejecutables van en /usr/local/bin, /usr/local/libo /usr/local/games, en sus bibliotecas /usr/local/lib, y así sucesivamente.

Hay algunas excepciones a esto: algunos programas, por defecto, se instalan en el /usrprefijo y, por lo tanto, sobrescriben las instalaciones de los mismos programas de los .debpaquetes. Por lo general, puede evitar esto ejecutándose en ./configure --prefix=/usr/locallugar de ./configurecuando los construye. Nuevamente enfatizo que usualmente esto no es necesario.

(Es por esta razón que tiene mucho sentido poner el código fuente que está creando e instalar para su uso en todo el sistema /usr/local/src, que existe para ese propósito).

Suponiendo que la versión empaquetada está instalada /usry la versión que instaló desde el origen está en /usr/local:

• Los archivos del paquete instalado no se sobrescribirán.

  Normalmente, la versión más nueva se ejecutará cuando invoque manualmente el programa desde la línea de comandos (suponiendo que /usr/local/bino donde estén instalados los ejecutables esté en su PATHvariable de entorno y aparezca antes del /usrdirectorio prefijado correspondiente , como /usr/bin).

  Pero puede haber algunos problemas con los lanzadores que se crean y se hacen accesibles a través de menús o búsquedas. Además, si ha instalado más de una versión de una biblioteca en diferentes lugares, puede ser un poco más complicado determinar qué software utilizará.

  Si en realidad no está utilizando ambas versiones del programa o la biblioteca, a menudo debe eliminar la que no está utilizando, aunque en situaciones limitadas es posible que desee mantener un paquete instalado para satisfacer las dependencias.

Sin embargo, si por algún motivo se sobrescriben los archivos (por ejemplo, si el código fuente está instalado en /usrlugar de /usr/local):

• El administrador de paquetes no sabrá nada acerca de cómo se modificó el software que instaló. Pensará que la versión anterior está instalada. Se pueden producir problemas graves. Deberías evitar esto. Si ha creado esta situación, debe desinstalar el software que instaló desde el origen (generalmente sudo make uninstallen el directorio) y luego desinstalar el paquete o paquetes que proporcionan los archivos que se sobrescribieron (ya que no se restaurarán desinstalando la versión instalada de la fuente). Luego reinstale la versión que desee tener./usr/local/src/program-or-library-name

En cuanto al cumplimiento de dependencias:

• Si hay un .debpaquete que depende del software que instaló desde la fuente y requiere la versión que instaló desde la fuente (o superior), ese paquete no se instalará correctamente. (O, para ser más precisos, es posible que pueda "instalarlo", pero nunca se "configurará", por lo que no podrá usarlo). Las dependencias se resuelven por las versiones de los paquetes instalados, no por qué software tienes realmente.

  Del mismo modo, el software al menos intentará instalarse por completo, incluso si ha eliminado manualmente los archivos proporcionados por los paquetes de los que depende el software que se instala. (Por lo general, no debe tratar de aprovechar eso para ningún propósito. El administrador de paquetes que funciona sobre la base de información falsa es casi siempre algo malo).

Por lo tanto, si no puede encontrar un paquete que proporcione la versión del software que necesita, es posible que necesite crear su propio .debpaquete a partir del software que ha compilado e instalarlo desde ese paquete. Entonces el administrador de paquetes sabrá lo que está sucediendo. Crear un paquete para su propio uso, que no necesita para funcionar bien en las computadoras de otras personas, en realidad no es muy difícil. (Pero creo que puede estar fuera del alcance de su pregunta, ya que está redactado actualmente).

Lo que instale desde el centro de software o con un comando APT ( apt-get, aptitude) o con dpkges conocido por el sistema de administración de paquetes. dpkges la herramienta de manipulación de paquetes de bajo nivel, APT y sus amigos son herramientas de alto nivel que invocan dpkgpara realizar la instalación real y también manejan dependencias y descargas de paquetes.

Si compila un programa desde la fuente, el administrador de paquetes no lo sabrá. La convención sobre Linux, que debe seguir con el dolor de tener dificultades para hacer un seguimiento de las cosas y anular sus instalaciones, es:

• /bin, /lib, /sbin, /usrEstán reservados para el gestor de paquetes;
• excepto que /usr/locales para el administrador del sistema: respete la jerarquía de directorios allí, pero usted es el único que administra los archivos.

¿Ve la mejor manera de actualizar vim / gvim a 7.3 en Ubuntu 10.04? para obtener una lista de formas de obtener versiones más recientes de software. La forma más fácil es obtener un PPA , si lo hay. Si obtiene un paquete binario o una compilación de la fuente, le recomiendo usar stow para administrar su software instalado manualmente. Alternativamente, cree su propio .debpaquete : es más trabajo, pero vale la pena si actualiza con frecuencia (por lo general, rehacer el paquete para la próxima versión menor es muy rápido) o si implementa en muchas máquinas que ejecutan la misma distribución.

Con la mayoría de los programas, si ejecuta ./configure && make && sudo make install, el programa se instala bajo /usr/local. Verifique la documentación provista con la fuente (generalmente en un archivo llamado READMEo INSTALL) o ejecútelo ./configure --helppara verificar que este sea el caso. Si el programa se instala bajo /usr/local, no interferirá con la versión proporcionada por el administrador de paquetes. /usr/local/binviene primero en el sistema PATH. Tenga en cuenta que deberá ejecutar make installcomo administrador (root); No compilar como root. Como se señaló anteriormente, recomiendo usar stow en lugar de instalar directamente en /usr/local.

Esto depende del paquete y de muchas otras cosas.

1. Convenciones de nomenclatura utilizadas: ¿el binario contiene números de versión en los nombres de archivo?
2. ubicación de instalación: es por defecto en opt, pero la versión empaquetada está en / usr
3. muchas más posibilidades

Larga historia corta:
no hay una respuesta genérica. Es altamente dependiente del paquete. Debe usar PPA oficiales de +1 si es posible en lugar de compilar desde la fuente.