Cuando instalo los paquetes manualmente, el diseño típico es similar al siguiente:
├── conf
├── lib
├── bin
│ ├── mvn
│ ├── mvn.cmd
Pero cuando lo instalo con homebrew, casi todos los archivos se colocan en la carpeta libexec :
├── bin
│ └── mvn
└── libexec
├── bin
├── boot
├── conf
└── lib
¿Por qué se utiliza este diseño extraño? Es un poco confuso cuando lees la documentación oficial de la herramienta y no coinciden tus rutas.
El diseño fue una decisión de diseño deliberada por parte de Homebrew para mantener el equilibrio entre facilidad de uso, cordura del mantenedor y no romper cosas.
¿Por qué conflictos?
Para explicar qué es el conflicto específico y qué lo causa, echemos un vistazo a (una simplificación general de) lo que Homebrew hace cuando ejecuta brew install foo :
Homebrew descarga y desempaqueta todo lo que foo necesita según la fórmula.
Homebrew sigue las instrucciones de instalación de acuerdo con la fórmula. Por ejemplo, copia archivos, aplica parches, etc. Al final, obtienes un barril, la carpeta que contiene la instalación nueva.
Para su comodidad, Homebrew examina los directorios bin y lib de su barril, luego vincula todo lo que encuentra en /usr/local/bin y /usr/local/lib para que no tenga que hacerlo.
Observe cómo en el # 3, la fórmula no tiene voz. Esto ayuda a mantener la complejidad fuera de las definiciones de la fórmula. Un mantenedor de fórmula nunca puede olvidar crear un enlace simbólico porque él o ella no tiene que hacerlo; Homebrew lo hace automáticamente para todo lo que está en bin o lib .
La política de diseño fue (AFAIK) codificada por primera vez en el número 678 del antiguo repositorio de GitHub de Homebrew, que dice:
Este es el comportamiento esperado; Se supone que libexec es un material de uso privado para esa fórmula.
Básicamente, Homebrew considera el contenido de los artefactos bin y lib público , i. mi. cosas que se supone que deben llamarse desde fuera de la fórmula.
Todo lo demás, incluido el contenido completo de libexec , se considera un detalle de implementación, i. mi. Cosas para uso privado por la propia fórmula.
¿Pero cuál es el problema con eso? ¿Podría usted, como autor de una fórmula como maven , no simplemente ignorar esos principios y, en cambio, vivir con algunos enlaces simbólicos innecesarios en /usr/local/lib , y darle al usuario el mismo diseño que tiene el proyecto anterior?
Resulta que sí, podrías, pero es una idea horrible, y los mantenedores de Homebrew rechazarán legítimamente una fórmula de este tipo hasta que se solucione.
Publicar material privado en /usr/local/lib es una causa típica de JAR hell . (Imagine una fórmula Homebrew basada en Java foo que usa mylib.jar v1, y otra fórmula Homebrew bar que usa mylib.jar v2, con el número de versión que no forma parte del nombre de archivo mylib.jar . Ahora siga adelante y intente averiguar por qué su aplicación crítica para el negocio, que utiliza /usr/local/lib/mylib.jar porque está en la ruta, solo funciona en ese 50% de sus máquinas donde se instaló foo después bar pero no al revés. Este es un ejemplo del conflicto mencionado al principio.)
tl; dr. Lo que sea que pongas en lib , Homebrew hará un enlace simbólico a /usr/local/lib para ti. Poner un JAR del que dependes en /usr/local/lib es algo malo y te lleva al infierno de JAR.
Lea otras preguntas en las etiquetas homebrew filesystem