¿Cuál es la diferencia entre / opt y / usr / local?

De acuerdo con el Estándar de jerarquía del sistema de archivos , /optes para "la instalación de paquetes de software de aplicación complementarios". /usr/locales "para uso del administrador del sistema al instalar software localmente". Estos casos de uso parecen bastante similares. El software que no se incluye con las distribuciones generalmente está configurado de manera predeterminada para instalarse en cualquiera /usr/localo /optsin una rima o razón en particular que elijan.

¿Hay alguna diferencia que me falta, o ambos hacen lo mismo, pero existen por razones históricas?

Si bien ambos están diseñados para contener archivos que no pertenecen al sistema operativo, /opty /usr/localno están destinados a contener el mismo conjunto de archivos.

/usr/locales un lugar para instalar archivos creados por el administrador, generalmente mediante el makecomando (por ejemplo, ./configure; make; make install). La idea es evitar conflictos con los archivos que forman parte del sistema operativo, que de lo contrario se sobrescribirían o sobrescribirían los locales (por ejemplo, /usr/bin/fooes parte del sistema operativo mientras que /usr/local/bin/fooes una alternativa local).

Todos los archivos debajo se /usrpueden compartir entre instancias del sistema operativo, aunque esto rara vez se hace con Linux. Esta es una parte en la que el FHS es ligeramente contradictorio, ya que /usrse define como de solo lectura, pero /usr/local/bindebe ser de lectura y escritura para que la instalación local de software tenga éxito. El estándar del sistema de archivos SVR4, que fue la principal fuente de inspiración del FHS, recomienda evitar /usr/localy usar /opt/localpara superar este problema.

/usr/locales un legado del BSD original. En ese momento, el código fuente de los /usr/bincomandos del sistema operativo estaba en /usr/src/biny /usr/src/usr.bin, mientras que la fuente de los comandos desarrollados localmente estaba en /usr/local/src, y sus binarios en /usr/local/bin. No había noción de empaque (fuera de las bolas de alquitrán).

Por otro lado, /optes un directorio para instalar paquetes desagregados (es decir, paquetes que no forman parte de la distribución del sistema operativo, sino que son proporcionados por una fuente independiente), cada uno en su propio subdirectorio. Ya están construidos paquetes completos proporcionados por un distribuidor de software independiente de terceros. A diferencia de las /usr/localcosas, estos paquetes siguen las convenciones de directorio (o al menos deberían). Por ejemplo, someappse instalaría /opt/someapp, con uno de sus comandos /opt/someapp/bin/foo, su archivo de configuración /etc/opt/someapp/foo.confy sus archivos de registro /var/opt/someapp/logs/foo.access.

La diferencia básica es que /usr/locales para el software no administrado por el empaquetador del sistema, pero que sigue las reglas de implementación estándar de Unix.

Es por eso que tienes /usr/local/bin, /usr/local/sbin /usr/local/includeetc.

/optpor otro lado es para software que no sigue esto y se implementa de manera monolítica. Esto generalmente incluye software comercial y / o multiplataforma que se empaqueta en el estilo "Windows".

De hecho, son muy similares, y el uso de uno u otro es más una cuestión de opinión. La revista Linux tuvo esta discusión de punto / contrapunto sobre este tema exacto aquí .

Para mí, personalmente, es lo que dijo Bill en el enlace de @ philfr:

En un sistema de desarrollo, o en un sandbox, tener un directorio / opt en el que puedas tirar cosas y ver si funcionan tiene mucho sentido. Sé que no voy a pasar por el esfuerzo de empaquetar cosas para probarlas. Si la aplicación no funciona, simplemente puede ejecutar el directorio / opt / mytestapp y esa aplicación es el historial. El empaquetado puede tener sentido cuando está ejecutando una implementación grande (hay veces en que hago paquetes de aplicaciones), pero muchas veces, es bueno arrojar cosas en / opt.

Desafortunadamente, la mayoría de los make installscripts empujan archivos en /usr/locallugar de simplemente hacer un enlace simbólico allí: - /

Primero, no creo que haya una respuesta estricta; diferentes administradores tendrán diferentes opiniones, de acuerdo con sus antecedentes. Históricamente, /usr/localvino primero; fue la convención en Berkley, IIRC. En un momento durante el desarrollo del Sistema V, si no me equivoco (todo esto fue hace mucho tiempo y no tomé notas), hubo una decisión o un deseo de poder montar /usrsolo lectura, lo que significaba que no podías agregarle un nuevo software; eso pudo haber sido por qué /opt fue inventado. De hecho, había tanto software existente que escribió /usrque esa idea nunca despegó.

Mi preferencia personal es /opt, con un subdirectorio separado para cada producto; Esto hace que eliminar un producto sea un caso simple rm -fr. Pero si todo su software se instala a través de un buen administrador de paquetes, no importa, y si el software que instala no obedece estrictamente estas convenciones, y escribe configuraciones y /usrdemás en algún lugar debajo , tampoco importa, aunque por las razones opuestas

Tengo una opinión ligeramente diferente sobre este tema.
Si bien todo en la respuesta de jlliagre es correcto, la aplicación práctica para mí, al implementar software en un clúster, se reduce a las variables de entorno predeterminadas y la reutilización predeterminada de libs.

En pocas palabras, /usr/localy todos sus directorios secundarios están en los entornos apropiados, como PATHy MANPATH, y /usr/local/lib{,64}están en ldconfig's ( /etc/ld.so.conf.d/).

/opt/OTOH no lo es, lo cual es ventajoso cuando se requieren múltiples versiones o paquetes conflictivos para coexistir en el sistema, pero requiere algún tipo de gestión del entorno (por ejemplo, módulos de entorno o colecciones de software ), y es desventajoso porque potencialmente "desperdiciaría" "espacio de almacenamiento duplicando bibliotecas compartidas, ya que cada instalación /optpuede ser completamente autónoma.

Por la naturaleza compartida de /usr/localtrabajar, se supone que, por ejemplo, los binarios se instalan directamente en /usr/local/bin(y las páginas de manual según corresponda /usr/local/share/man/...) en lugar de /usr/local/app/{bin,share/man,...}etc.