Cuando instalo paquetes manualmente, la disposición típica es la siguiente:
├── conf
├── lib
├── bin
│ ├── mvn
│ ├── mvn.cmdPero cuando lo instalo con homebrew, casi todos los archivos se colocan en el libexec carpeta:
├── bin
│ └── mvn
└── libexec
├── bin
├── boot
├── conf
└── lib¿Por qué se utiliza esta extraña disposición? Es un poco confuso cuando lees la documentación oficial de la herramienta y tus rutas no coinciden.
La disposición fue una decisión de diseño deliberada por parte de Homebrew para mantener la equilibrio entre la usabilidad, la cordura del mantenedor y no romper cosas.
Un comentario en Homebrew's código fuente dice:
La instalación de JARs en "lib" puede causar conflictos entre paquetes. Para el software Java, normalmente es mejor que la fórmula instalar en "libexec" y luego hacer un enlace simbólico o envolver los binarios en "bin".
¿Por qué los conflictos?
Para explicar cuál es el conflicto específico y qué lo causa, echemos un vistazo a (una burda simplificación de) lo que hace Homebrew cuando ejecuta brew install foo :
Homebrew descarga y desempaqueta todo foo necesita según la fórmula.
Homebrew sigue las instrucciones de instalación según la fórmula. Por ejemplo, copia archivos, aplica parches, etc. Al final, se obtiene un barril, la carpeta que contiene la nueva instalación.
Para su comodidad, Homebrew mira el bin y lib directorios de su barril, entonces symlinks todo lo que encuentra en /usr/local/bin y /usr/local/lib para que no tengas que hacerlo.
Obsérvese cómo en el número 3, la fórmula no puede opinar. Esto ayuda a mantener la complejidad de las definiciones de las fórmulas. Un mantenedor de fórmulas nunca puede olvidarse de crear un enlace simbólico porque no tiene que hacerlo; Homebrew lo hace automáticamente para todo lo que está en bin o lib .
La política de diseño se codificó por primera vez (AFAIK) en número 678 del repositorio GitHub de Homebrew, que dice:
Este es el comportamiento esperado; se supone que libexec es algo de uso privado para esa fórmula.
Básicamente, Homebrew considera el contenido de bin y lib público artefactos, es decir, cosas que se supone que son llamadas desde fuera de la fórmula.
Todo lo demás, incluyendo todo el contenido de libexec se considera un detalle de implementación, es decir, cosas para uso privado de la propia fórmula.
Pero, ¿cuál es el problema con eso? ¿Podría usted, como autor de una fórmula como maven no ignorar esos principios y vivir con unos cuantos enlaces simbólicos innecesarios en /usr/local/lib y dar al usuario el mismo diseño que tiene el proyecto anterior?
Resulta que sí, se puede, pero es una idea horrible, y Los mantenedores de Homebrew rechazarían, con razón, una fórmula de este tipo hasta que se arregle.
Publicar cosas privadas en /usr/local/lib es una causa típica de El infierno JAR . (Imagine una fórmula de Homebrew basada en Java foo que utiliza mylib.jar v1, y otra fórmula de Homebrew bar que utiliza mylib.jar v2, sin que el número de versión forme parte del nombre del archivo mylib.jar . Ahora intente averiguar por qué su aplicación crítica para el negocio - que resulta que utiliza /usr/local/lib/mylib.jar porque está en la ruta - sólo funciona en ese 50% de sus máquinas donde foo se ha instalado después de bar pero no a la inversa. Este es un ejemplo del conflicto mencionado al principio).
tl;dr Cualquier cosa que pongas en lib Homebrew hará un enlace simbólico a /usr/local/lib para ti. Poner un JAR del que depende en /usr/local/lib es algo malo y lleva al infierno JAR.
AppleAyuda es una comunidad de usuarios de los productos de Apple en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros usuarios, hacer tus propias preguntas o resolver las de los demás.
