¿Por qué el software se instala en / usr / lib?

11

He estado usando servidores Linux durante años y sigo confundiéndome con el estándar de jerarquía del sistema de archivos. Por lo general, puedo vivir con la confusión. Pero ahora que estoy desarrollando mi propio software para Linux, necesito entender dónde deben instalarlo los administradores de paquetes.

Estaba bastante convencido de que / opt era la ubicación perfecta para mi aplicación. Pero después de haber investigado mi sistema de archivos Debian, ya no estoy seguro: ¡hay muchos softwares instalados en / usr / lib! Por nombrar algunos: MySQL, MySQLWorkbench, Nautilus, Rythmbox ...

Según el FHS, se supone que / usr / lib contiene "Bibliotecas para programación y paquetes" e "incluye archivos de objetos, bibliotecas y archivos binarios internos que no están destinados a ser ejecutados directamente por los usuarios o scripts de shell" ( ver aquí ).

¡Muchos softwares ubicados en / usr / lib de mi servidor Debian no son bibliotecas o binarios internos, sino softwares ejecutables de usuario completos!

Todavía estoy en camino de tener mi aplicación instalada en / opt. Pero realmente me gustaría entender si esto es correcto y, sobre todo, por qué .

Gracias de antemano por sus amables consejos,

Eric

Eric MORAND
fuente
2
Comprobación puntual, por lo que puedo decir, MySQLWorkbench solo instala bibliotecas en / usr / lib. ¿Qué te hace pensar que hay un "software ejecutable de usuario completo" en / usr / lib?
Mark Wagner
El acceso directo real ubicado en el menú de la aplicación apunta a un binario ubicado en / usr / lib, si no recuerdo mal.
Eric MORAND
Parece confundido acerca de dónde está instalado el software que enumeró. Aquí hay enlaces a los listados de los archivos para MySQL y Nautilus. Tenga en cuenta que los archivos se dividen entre / etc, / usr / bin, / usr / lib, etc. tal como FHS dice que deberían estar. packages.debian.org/wheezy/i386/mysql-server-5.5/filelist packages.debian.org/wheezy/i386/nautilus/filelist
sciurus

Respuestas:

6

La verdadera clave para comprender el Estándar de Jerarquía del Sistema de Archivos es saber que está diseñado teniendo en cuenta los sistemas de archivos de red.

Para cada máquina del mismo sistema operativo, versión y arquitectura, puede compartir / usr a través de NFS y montarlo.
/ usr se (re) monta después de que se inicializa la pila de red.

/var <-- local, r/w optimized
/usr <-- can be mounted over network, possibly even read-only!
/opt <-- local, read mostly
/etc <-- local, read mostly
/srv <-- local, r/w optimized

/home <-- either/or
Dan Garthwaite
fuente
¿Le importaría proporcionar un enlace para los estándares locales / remotos y r - r / w?
Capitán Jirafa
¿Significa esto que uno puede tener un único "repositorio" / usr para cada servidor Linux o estación de trabajo en una red?
Eric MORAND
1
Se necesita algo de trabajo, pero sí, puedes. Cuando los discos duros eran caros, esta era la norma para cualquier gran implementación.
Dan Garthwaite
@ eric-morand Del FHS: "/ usr es la segunda sección principal del sistema de archivos. / usr es información de solo lectura que se puede compartir. Eso significa que / usr se debe compartir entre varios hosts compatibles con FHS y no se debe escribir en "Cualquier información que sea específica del host o que varíe con el tiempo se almacena en otro lugar". pathname.com/fhs/pub/fhs-2.3.html#THEUSRHIERARCHY
Dan Garthwaite
Whoops El comentario anterior fue para @CaptainGiraffe
Dan Garthwaite
12

La diferencia es que /usrestá destinado a contener paquetes instalados como parte del sistema . Los paquetes que obtiene de los repositorios Debian / Ubuntu, PPA, etc., vaya aquí. Mientras /optestá destinado a aplicaciones de terceros desglosadas que no se distribuyen a través del proceso de distribución de paquetes de distribución.

Si distribuye paquetes .deb o .rpm, con el objetivo de incluir su software en los repositorios oficiales, debe instalarlo en /usr. De lo contrario, instale en /opt. En cualquier caso, su aplicación debería poder compilarse para ejecutarse en cualquier ubicación arbitraria (por ejemplo, con la ayuda de las herramientas automáticas GNU).

Michael Hampton
fuente
Gracias. En este momento, no tengo planes de incluir mi aplicación en el repositorio oficial.
Eric MORAND
¿Qué pasa con / usr / local, entonces? ¿O es eso discreto
Aaron Copley
@AaronCopley /usr/localno estaba al alcance de esta pregunta. Pero está destinado a software de terceros que el administrador local compila e instala.
Michael Hampton
Por eso pregunté si se consideraría discreto.
Aaron Copley
2

Instala sus bibliotecas <prefix>/lib, sus archivos binarios <prefix>/bin, sus archivos de encabezado, sus <prefix>/includepáginas de prefix/[share/]manmanual, sus archivos pkgconfig <prefix>/lib/pkgconfigo <prefix/share/pkgconfigsus archivos cmake .m4 en<prefix>/share/aclocal

Luego, deje que el administrador de paquetes decida el prefijo. Si está distribuyendo rpm / deb usted mismo, /usres una buena opción para un prefijo.

./configure --prefix=~/.local/ Todavía debería funcionar, ¡así que no vayas a codificar tu camino en ningún lado, por favor!

Algunas bibliotecas están envueltas en alguna otra herramienta que las hace también ejecutables y utilizables como biblioteca, pero siguen siendo bibliotecas, y no en su $ PATH, por lo que está bien ponerlas en / lib, supongo.

Jens Timmerman
fuente
1

Sugeriría evitar instalar su aplicación en / opt. Razón 1: algunas distribuciones no tienen / opt por defecto Razón 2: / usr / lib es una ruta estándar para bibliotecas {Si otras aplicaciones necesitan usar su biblioteca, debe agregar su ruta de biblioteca manualmente a / etc / ldconfig} / opt es más conveniente cuando tienes aplicaciones independientes que instalas manualmente y quieres saber dónde están ubicadas

Una de las razones por las que los archivos ejecutables completos se encuentran en / usr / lib podría ser que se usan desde otros scripts. {Por ejemplo, los scripts de bash no pueden usar una API directamente. Por esta razón, un truco común es construir un "envoltorio" alrededor de esta API e insertar parámetros como argumentos del script}

Nikolaidis Fotis
fuente
2
Estoy en desacuerdo. Si desea instalar en / opt, el administrador de paquetes creará el directorio, por lo que no es un problema. Además, los binarios instalados en / usr / lib son una mala idea.
Walter
Gracias @Nikolaidis Fotis. Pero en mi caso, mi aplicación no contiene una biblioteca pública y no será utilizada por otras aplicaciones.
Eric MORAND
0

Por favor, instálelo en / opt.

Demasiadas aplicaciones Linux hacen la misma marca que los desarrolladores de Windows en los años 90.

Vamos a instalar nuestras cosas en C: \ windows para que sea simple y fácil de encontrar (y un poco más rápido). Luego llegaron 15 años de infierno de DLL ya que diferentes paquetes de software necesitaban diferentes versiones de las mismas bibliotecas (que en Windows no tenían versiones de las bibliotecas).

A menos que esté escribiendo software de sistema real, póngalo en / opt, para que las personas puedan rastrear mejor quién instaló qué.

Walter
fuente
44
Esto no es Windows. Tenemos gestores de paquetes que funcionan y esto realmente no es un gran problema.
Michael Hampton
Si realmente le preocupa que todo esté en el mismo árbol, consulte el administrador de paquetes de Nix . Lo mejor de ambos mundos, si me preguntas.
TheSola10