Dlaczego istnieje katalog/usr/local/opt utworzony przez Homebrew i czy powinienem go używać?

Question

Jestem całkiem nowy w użyciu homebrew i staram się dowiedzieć, jak to działa, aby korzystać z niektórych bibliotek (boost, gsl, openblas na przykład) w moim własnym projekcie.

Zrozumiałem, że każda formuła jest instalowana przez Homebrew w/usr/local/Cellar /, a następnie dowiązana symbolicznie w usr/local/bin, usr/local/lib, usr/local/include, więc wygląda na to, że z wyjątkiem tylko formuły beczkowe, więc nie zadaje się z już zainstalowanymi bibliotekami przez system operacyjny (na przykład: Understand homebrew and keg-only dependencies). Okazało się jednak, że każda formuła jest również powiązana z katalogiem/usr/local/opt.

Moje pytanie brzmi: dlaczego istnieje katalog/usr/local/opt (jest on zbyteczny) i jaką ścieżkę należy użyć do korzystania z formuł (usr/local/Cellar lub usr/local/lub usr/local/opt w zasadzie)?

Answer 1

Zawiera ścieżkę do treści formuły, która nie zmienia się w przypadku aktualizacji wersji.

Rozważmy następujący scenariusz: Załóżmy, że zbudowaliśmy libfoo.dylib z Homebrew. Jest to wersja 2.0.0, a więc żyje w /usr/local/Cellar/libfoo/2.0.0/lib/libfoo.dylib. Chcesz połączyć się z nim z innego budowanego programu, aby przekazać -L/usr/local/Cellar/libfoo/2.0.0/lib -lfoo do gcc. Twój program się kompiluje. Później uaktualnisz do libfoo 2.0.1 i usuniesz v2.0.0. Teraz /usr/local/Cellar/libfoo/2.0.0/lib/libfoo.dylib już nie istnieje, a Twój program nie działa, ponieważ nie może dynamicznie ładować libfoo.

W porządku. libfoo.dylib jest również dostępny pod adresem /usr/local/lib/libfoo.dylib. Jest to dowiązanie symboliczne do najnowszej wersji libfoo, więc zawsze powinno być obecne. Przekazujesz -L/usr/local/lib -lfoo do swojego programu i kompilujesz go. Później uaktualnisz do libfoo 2.0.1. Nie ma problemu, ponieważ /usr/local/lib/libfoo.dylib jest nadal obecny i wskazuje na kopię v2.0.1.

To świetnie, a Homebrew istniał z tym systemem przez jakiś czas. Problem polega na tym, że niektóre formuły są "tylko w keg", więc nie są one połączone dowiązaniem symbolicznym z /usr/local. (Zwykle są one tylko w keg, ponieważ śledzą wersję biblioteki dostarczanej z systemem OS X, a zastąpienie bibliotek OS X może powodować problemy). Powiedz, że chcesz utworzyć łącze do wersji biblioteki tylko w wersji beczkowej. Nie jest on połączony symbolicznie z /usr/local/lib, więc musisz podać pełną ścieżkę do wersji zainstalowanej w /usr/local/Cellar, która przywraca cię do pierwszego problemu wymienionego powyżej.

/usr/local/opt rozwiązuje ten problem. Zapewnia miejsce dla obecnej wersji wszystkich formuł do dowiązania symbolicznego, niezależnie od tego, czy są one tylko keg-czy nie. Teraz, gdy chcesz skompilować swój program, możesz użyć -L/usr/local/opt/libfoo/lib -lfoo, a twój program połączy się z najnowszą wersją libfoo, nawet jeśli ją zaktualizujesz, a nawet jeśli jest to tylko keg-only.

Answer 2

Tylko w celu uzupełnienia odpowiedzi Mipadi.

Z artykułu o wdzięcznej nazwie „/usr/local/opt”

przechowywania plików w spójnych miejsc jest ważnym elementem utrzymania system czystej i w utrzymaniu. W większości systemów Linux większość oprogramowania jest instalowana przy użyciu menedżera pakietów. Menedżer pakietów śledzi zainstalowane pliki, dzięki czemu może aktualizować i usuwać oprogramowanie o minimalnych efektach ubocznych.

Są jednak chwile, kiedy oprogramowanie, które nie jest dostępne przez , musi zostać zainstalowany menedżer pakietów.Aby zminimalizować skutki uboczne w systemie plików, takie oprogramowanie jest instalowane w katalogu/usr/local . Instalacja oprogramowania w systemie UNIX umieszcza pliki w bin, lib, share, itp. Podkatalogach pod lokalnym katalogiem głównym, ale jest bardzo często instalowana w katalogach specyficznych dla danego pakietu i zamiast nich dodajemy lokalne linki zamiast lokalnych miękkich katalogów. . Pozwala to na łatwe usunięcie oprogramowania - wystarczy usunąć katalog specyficzny dla pakietu , a także wszelkie linki do niego wskazujące.

Niektóre oprogramowanie udostępnia instrukcje lokalnej instalacji, które promują tworzenie katalogu specyficznego dla pakietu bezpośrednio w/usr/local. Ten numer nie promuje dobrej organizacji, ponieważ łączy katalogi z katalogiem UNIX z katalogami specyficznymi dla pakietu. Instalacja oprogramowania w katalogach specyficznych dla tego pakietu jest już zrobiona w innym miejscu, w katalogu/opt, dlatego też należy postępować zgodnie z konwencjami i umieścić lokalnie zainstalowane specyficzne dla pakietu katalogi w katalogu/usr/local/opt informator.

Włączenie numeru wersji w nazwie katalogu nie jest wymagane, ale jest dobrą praktyką w przypadku oprogramowania instalowanego lokalnie, ponieważ pozwala na jednoczesną instalację i testowanie wielu wersji wielu wersji. Aby uruchomić konkretną wersję oprogramowania , należy uruchomić plik wykonywalny bezpośrednio w katalogu o nazwie pakiet . Dowolną wersją można ustawić jako domyślną, kontrolując , z którym plik wykonywalny jest połączony z/usr/local/bin. Na przykład nową wersję oprogramowania można zainstalować i przetestować bez usuwania starej wersji . Gdy nowa wersja jest gotowa, link w/usr/local/bin może zostać zaktualizowany tak, aby wskazywał na to. Starą wersję oprogramowania można następnie usunąć, gdy nie jest już potrzebna.

Źródło: Copyright © 2014 Extellisys