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

404

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?

directory-structure fhs Parches
fuente
3
Tengo entendido que /usr/locales una versión local del /usrsistema de archivos, mientras que /optes un marcador de posición para cosas misceláneas.
yasouser
55
Pregunta similar en Ask Ubuntu , superusuario
kenchew
Fuera de tema por razones históricas: Comprender la división bin, sbin, usr / bin, usr / sbin .
Alexey
Linux: Directorio / opt vs / usr / local
El borito

Respuestas:

357

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.

jlliagre
fuente
53
/ usr / local, para software propio, interno, compilado y mantenido. / opt es para el área de instalación de paquetes binarios / de aplicaciones preempaquetados no propios, externos. Hmmm ... no tenemos archivos C: \ program para todo ;-)
Nikhil Mulley
2
"Por otro lado, / opt es un directorio donde instalar paquetes desagregados" ¿Qué significan los paquetes 'desagrupados' aquí?
Kevin Wheeler
1
@KevinWheeler Eso se explica en la siguiente oración. Desagregado significa paquetes que no forman parte de la distribución del sistema operativo, sino que son proporcionados por una fuente independiente.
jlliagre
2
@jlliagre el estado de centos docs * "Por ejemplo, si el directorio / usr / está montado como un recurso compartido NFS de solo lectura desde un host remoto, aún es posible instalar un paquete o programa en el directorio / usr / local /" No sé quién tiene razón, pero esto parece estar en contradicción con su afirmación sobre un área donde FHS es débil. (* fuente centos.org/docs/5/html/5.1/Deployment_Guide/… )
Kevin Wheeler
1
@KevinWheeler Esa es precisamente la debilidad a la que me refiero. Instalar un paquete o un programa en un directorio remoto de solo lectura es simplemente imposible. La solución alternativa sería montar un sistema de archivos local en / usr / local, pero esto se parece más a un trabajo improvisado que a un diseño adecuado.
jlliagre
84

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".

Déjame ser
fuente
12
No estoy de acuerdo con tu punto monolítico. El estándar FHS dice que los paquetes instalados en subdirectorios / opt deben tener sus archivos específicos de host instalados fuera de / opt, respectivamente en / etc / opt / package para archivos de configuración y / var / opt / package para registros, spool y similares. / opt está realmente más cerca de las reglas de implementación de Unix que / usr / local, que coloca todo bajo un directorio que debería ser de solo lectura pero no puede ser por razones obvias.
jlliagre
55
Claro, si estuviera haciendo un paquete opcional y quisiera reclamar el cumplimiento de FHS. De lo contrario, el estándar es más de lo que llamarías "pautas". El hecho de que NetBeans no use / etc / opt / netbeans no me impedirá ponerlo en / opt para todo el sistema o $ HOME / .local / opt para un solo usuario.
jla
1
@jla Supongo que su último comentario fue dirigido a mí, así que use @ xxx cuando responda a otra persona que el OP o el autor de la respuesta. Acerca de / etc / opt, el FHS no dice que sea una ubicación recomendada (como guía) sino una ubicación obligatoria. Usted o el desarrollador de Netbeans son libres de violar ese estándar ya que no hay autoridad para hacerlo cumplir, pero no digan que hacerlo mal es el camino a seguir. Es solo un desafortunado malentendido o una violación deliberada.
jlliagre
8
@jlliagre Como administrador de mi sistema, el FHS es un conjunto de pautas. El directorio / opt es el lugar bien establecido de sentido común para colocar el software monolítico / opt / <package> u / opt / <provider>. Cuando instalo un paquete que quiere usar <package | provider> / all / data / required / to / support, entra en opt / incluso si el proveedor no sigue todos los detalles del último FHS. Podría enviar un correo electrónico o informar un error, pero no voy a poner ese paquete monolítico en otro lugar para sentirme mejor acerca de FHS en mi sistema.
jla
1
@jlliagre He instalado muchas cosas en / opt y no se ha creado ningún archivo en / etc / opt. ¿Debería?
erm3nda
18

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í .

philfr
fuente
99
Oh querido. No quise arrastrarme a una "guerra santa".
Parches
13

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í: - /

pepoluan
fuente
2
¿Cuál sería el punto? Si de todos modos va a hacer el enlace simbólico, ¿por qué no simplemente poner el archivo original allí en primer lugar?
Let_Me_Be
8
Solo para comentar sobre el make installobjetivo al insertar archivos /usr/local; esta funcionalidad es fácilmente cambiable pasando un --prefix=parámetro de línea de comando para la ./configureescritura, o si no hay una ./configuresecuencia de comandos, puede pasar un parámetro a la makemeta de este modo: make --prefix=/usr install.
Sean C.
3
¿Es / opt un directorio estándar incluido en $ PATH? Lo sé / usr / local es.
LawrenceC
55
@Let_Me_Be el beneficio sería que es muy fácil mantener versiones anteriores. Digamos que tengo 2 versiones de 'foo', ubicadas en /opt/foo-1.1y /opt/foo-1.2. Cuando actualizo, fooenlace simbólico en /usr/local/binpuntos a foo-1.2. Si por alguna razón necesito revertir, simplemente reemplazo el enlace simbólico con uno que apunte a foo-1.1. Si 1.2 está bien después de varias semanas, un rápido rm -rf /opt/foo-1.1elimina la versión anterior de forma rápida y limpia.
pepoluan
77
@ultrasawblade no, no lo es. y nunca debería serlo. después de todo, según FHS, / opt debe subdividirse en subdirectorios con el nombre del paquete. meter todo en PATH es una forma segura de desastre. más bien, las aplicaciones deberían instalarse bajo / opt y enlazar simbólicamente sus programas invocados por el usuario en / usr / local / bin (o sbin).
pepoluan
11

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

James Kanze
fuente
1
"" "todo su software se instala a través de un buen administrador de paquetes" "", eso es imposible a menos que use solo software que se usa con frecuencia.
Pacerier
1
@Pacerier es posible, depende de la distribución que estés usando. Cualquiera que sea el software, probablemente esté en el Arch User Repository, y si no lo está, un PKGBUILD es relativamente fácil de escribir.
StarlitGhost
9

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.

Dani_l
fuente