¿Debo poner la aplicación en / usr / local o / usr / local / share?

¿Cuáles son los "estándares"? ¿Debería poner la aplicación (no solo binaria, sino toda la distribución) en / usr / local o / usr / local / share.

Por ejemplo, scala o weka: contiene ejemplos, binarios, bibliotecas, etc. Entonces sería

/usr/local/scala-2.9.1 

o

/usr/local/share/scala-2.9.1

Como soy el único administrador, no es un gran problema para mí, pero prefiero usar algo que sea ampliamente utilizado, no con mis propias costumbres.

Importante: no estoy preguntando sobre casos, en los que debe dividir la aplicación en / usr / local / bin, / usr / local / lib, etc. Más bien, estoy preguntando sobre el caso cuando tiene que mantener un directorio principal para toda la aplicación.

Creo que / opt es más estándar en este tipo de contexto. La sección relevante en el Estándar de Jerarquía del Sistema de Archivos se cita a continuación.

Las distribuciones pueden instalar software en / opt, pero no deben modificar o eliminar el software instalado por el administrador del sistema local sin el consentimiento del administrador del sistema local.

 Justificación El uso de / opt para el software adicional es una práctica bien establecida en la comunidad UNIX. La interfaz binaria de la aplicación System V [AT&T 1990], basada en la definición de la interfaz System V (tercera edición), proporciona una estructura / opt muy similar a la que se define aquí.

El Estándar de compatibilidad binaria Intel v. 2 (iBCS2) también proporciona una estructura similar para / opt.

En general, todos los datos necesarios para admitir un paquete en un sistema deben estar presentes en / opt /, incluidos los archivos destinados a copiarse en / etc / opt / y / var / opt /, así como los directorios reservados en / opt.

Las restricciones menores en las distribuciones que usan / opt son necesarias porque son posibles conflictos entre el software instalado por distribución y el instalado localmente, especialmente en el caso de nombres de ruta fijos que se encuentran en algún software binario.

La estructura de los directorios a continuación / opt / se deja al empaquetador del software, aunque se recomienda que los paquetes se instalen en / opt // y sigan una estructura similar a las pautas para / opt / package. Una razón válida para divergir de esta estructura es para los paquetes de soporte que pueden tener archivos instalados en / opt // lib u / opt // bin.

Solo debe usar /usr/local/sharepara archivos que no son específicos de una arquitectura particular / versión del sistema operativo.

Después de eso, depende de usted si distribuye los archivos entre los subdirectores existentes de /usr/localo si crea un nuevo directorio dedicado en /usr/local(pero este último ya no existirá en el ejecutable PATH, el LD_LIBRARY_PATH, ni el MANPATH).

Echa un vistazo a la FHS

Hasta que se /opthizo común, el lugar habitual era /usr/local/lib/<package>.

Al instalar aplicaciones locales, hay varias opciones según cómo desee acceder y actualizar. También debe tenerse en cuenta que algunos métodos se parecen más al sistema que ya tiene y otros son más ad-hoc. Sugeriría que las "mejores" soluciones son las que hacen que las cosas sean más fáciles de administrar.

He dividido esta respuesta en función de la cantidad de paquetes para realizar instalaciones personalizadas. La división se basa en mis propias experiencias. Estas experiencias sopesan el tiempo que lleva administrar los paquetes y los riesgos de estropear algo. No quiero decir que tengo el conocimiento de estándares comunes, sino que me refiero a esto como un punto de referencia a tener en cuenta al tomar la decisión.

Por solo unos pocos paquetes , quisiera poner paquetes adicionales en/opt , donde están fuera del camino de todo lo demás para que nada pueda estropearlos y puedan estropear algo más. Este es el método que uso en mi NAS. Sin embargo, este método mantiene los binarios fuera de su RUTA, por lo que deberá agregarlos manualmente. Esto funciona bien si solo hay unos pocos paquetes para instalar, pero se convierte en un desastre si hay muchos.

Actualizar aquí es bastante fácil ya que simplemente sobrescribe el directorio.

Pros:

• simple
• rápido de configurar
• no hay posibilidad de afectar otras partes del sistema
• desinstalar es tan fácil como instalar

Contras:

• Se vuelve bastante tedioso si la cantidad de paquetes a instalar es grande
• Hace que se PATHvea desordenado

Para más de unos pocos paquetes , recomendaría usar el /usr/local/<your package>enlace simbólico y el ejecutable desde /usr/local/bino /usr/local/sbindependiendo de si necesita privilegios de root. Esto le evita cambiar su RUTA cada vez que se agrega algo nuevo para que la RUTA permanezca limpia. Este es el método que uso en mi computadora portátil Arch para todos los paquetes que no son de Pacman y AUR.

La actualización se realiza sobrescribiendo el directorio del paquete y verificando que el enlace simbólico aún sea válido y corrigiendo si no lo es.

Pros

• No hace PATHdesordenado
• No afecta el sistema base
• Todavía es muy simple eliminar todos los complementos y volver a un sistema base limpio

Contras:

• Más trabajo para configurar
• Eliminar solo un paquete tiene alguna búsqueda que hacer

Para muchos paquetes . Como este no es el caso que deseas, lo mantendré breve. Yo recomendaría dividir el paquete en bin, lib, share, etc, y la instalación de ellos a /usr/local. Esto es para mantener limpia la estructura. También puede especificar quién puede escribir dónde y más. Por ejemplo, no desea que otras personas que no sean root modifiquen el ejecutable.

Aquí la actualización se vuelve un poco más complicada ya que necesita escribir en más de un directorio. Recomendaría empaquetar todo y dejar que el administrador de paquetes se encargue del resto.

La cuota

El sharedirectorio en sí mismo es para archivos independientes de la arquitectura como se señala en Faheem de enlace y los archivos dependientes de la arquitectura deben ir a lib, lib32, lib64, etc.