Quando installo i pacchetti manualmente, il layout tipico ha il seguente aspetto:
├── conf
├── lib
├── bin
│ ├── mvn
│ ├── mvn.cmd
Ma quando lo installo con homebrew, quasi tutti i file sono posizionati nella cartella libexec :
├── bin
│ └── mvn
└── libexec
├── bin
├── boot
├── conf
└── lib
Perché viene usato questo strano layout? È un po 'di confusione quando leggi la documentazione ufficiale dello strumento e i tuoi percorsi non corrispondono.
Il layout era una deliberata decisione progettuale da parte di Homebrew per mantenere il equilibrio tra usabilità, sanità del manutentore e non rompere le cose.
Un commento nel codice sorgente di Homebrew dice:
Installing JARs to "lib" can cause conflicts between packages. For Java software, it is typically better for the formula to install to "libexec" and then symlink or wrap binaries into "bin".
Perché i conflitti?
Per spiegare quale sia il conflitto specifico e cosa lo causa, diamo un'occhiata a (una semplificazione grossolana di) cosa fa Homebrew quando esegui brew install foo :
Homebrew scarica e decomprime tutto foo richiede in base alla formula.
Homebrew segue le istruzioni di installazione in base alla formula. Ad esempio, copia i file, applica le patch e così via. Alla fine, ottieni un keg, la cartella contenente la nuova installazione.
Per tua comodità, Homebrew guarda le directory bin e lib del tuo barile, quindi associa tutto ciò che trova in /usr/local/bin e /usr/local/lib così non devi.
Nota come in # 3, la formula non ha voce in capitolo. Ciò aiuta a mantenere la complessità fuori dalle definizioni della formula. Un manutentore di formule non può mai dimenticare di creare un link simbolico perché lei o lui non è obbligato a farlo; Homebrew lo fa automaticamente per tutto ciò che è in bin o lib .
La politica di layout era (AFAIK) prima codificata in numero # 678 del repository GitHub precedente di Homebrew, che dice:
This is expected behavior; libexec is assumed to be private-use stuff for that formula.
Fondamentalmente, Homebrew considera i contenuti di bin e lib pubblico artefatti, i. e. cose che dovrebbero essere chiamate al di fuori della formula.
Tutto il resto, compreso l'intero contenuto di libexec , è considerato un dettaglio di implementazione, i. e. cose per uso privato dalla formula stessa.
Ma qual è il grosso problema con questo? Potresti, come autore di una formula come maven , non ignorare semplicemente questi principi e invece vivere con alcuni link simbolici non necessari in /usr/local/lib e dare all'utente lo stesso layout del progetto upstream?
Risulta che sì, è possibile, ma è un'idea orribile, e I manutentori di Homebrew rifiuterebbero giustamente una formula del genere finché non saranno risolti.
Pubblicare materiale privato su /usr/local/lib è una causa tipica di JAR hell . (Immagina una formula Homebrew basata su Java foo che utilizza mylib.jar v1 e un'altra formula Homebrew bar che utilizza mylib.jar v2, con il numero di versione che non fa parte del nome file mylib.jar . Ora vai avanti e prova a capire perché la tua applicazione business-critical - che capita di usare /usr/local/lib/mylib.jar perché si trova nel percorso - funziona solo su quel 50% delle tue macchine dove foo è stato installato dopo bar ma non viceversa. Questo è un esempio del conflitto menzionato all'inizio.)
tl; dr Qualunque cosa tu metta in lib , Homebrew farà un link simbolico a /usr/local/lib per te. Mettere un JAR da cui dipendi in /usr/local/lib è una brutta cosa da fare e porta a JAR hell.
Leggi altre domande sui tag homebrew filesystem