Jaka jest różnica między / opt a / usr / local?

Zgodnie ze standardem hierarchii systemów plików , /optsłuży do „instalacji dodatkowych pakietów aplikacji”. /usr/localjest „do użytku przez administratora systemu podczas lokalnej instalacji oprogramowania”. Te przypadki użycia wydają się dość podobne. Oprogramowanie nie dołączone do dystrybucji zwykle jest domyślnie skonfigurowane do instalacji w jednym /usr/locallub /optbez określonego wiersza lub powodu, dla którego wybrali.

Czy brakuje mi jakiejś różnicy, czy oba robią to samo, ale istnieją z powodów historycznych?

Oba są zaprojektowane tak, aby zawierały pliki nienależące do systemu operacyjnego, /opti /usr/localnie mają zawierać tego samego zestawu plików.

/usr/localto miejsce do instalowania plików zbudowanych przez administratora, zwykle za pomocą makepolecenia (np ./configure; make; make install.). Chodzi o to, aby uniknąć kolizji z plikami, które są częścią systemu operacyjnego, które w przeciwnym razie zostałyby zastąpione lub zastąpiłyby pliki lokalne (np. /usr/bin/fooJest częścią systemu operacyjnego, podczas gdy /usr/local/bin/foojest lokalną alternatywą).

Wszystkie pliki poniżej /usrmożna udostępniać między instancjami systemu operacyjnego, chociaż rzadko dzieje się tak w przypadku systemu Linux. Jest to część, w której FHS jest nieco wewnętrznie sprzeczny, ponieważ /usrjest zdefiniowany jako tylko do odczytu, ale /usr/local/binmusi być do odczytu i zapisu, aby lokalna instalacja oprogramowania zakończyła się pomyślnie. Standard systemu plików SVR4, który był głównym źródłem inspiracji FHS, zaleca unikanie tego problemu /usr/locali używanie go /opt/localzamiast tego.

/usr/localjest dziedzictwem oryginalnej BSD. W tym czasie kod źródłowy /usr/binkomend OS były /usr/src/bini /usr/src/usr.bin, podczas gdy źródło lokalnie opracowanych poleceń było /usr/local/src, a ich binaria /usr/local/bin. Nie było pojęcia opakowania (poza kulkami).

Z drugiej strony /optjest katalogiem do instalowania wydzielonych pakietów (tj. Pakietów nie stanowiących części dystrybucji systemu operacyjnego, ale dostarczonych przez niezależne źródło), każdy w swoim własnym podkatalogu. Są już zbudowane całe pakiety dostarczone przez niezależnego zewnętrznego dystrybutora oprogramowania. W przeciwieństwie do /usr/localrzeczy, te pakiety są zgodne z konwencjami katalogowymi (a przynajmniej powinny). Na przykład someappzostałby zainstalowany w /opt/someapp, z jednym poleceniem /opt/someapp/bin/foo, jego plikiem konfiguracyjnym byłby /etc/opt/someapp/foo.conf, a pliki dziennika w /var/opt/someapp/logs/foo.access.

Podstawowa różnica polega na tym, że /usr/localoprogramowanie nie jest zarządzane przez program pakujący system, ale nadal przestrzega standardowych zasad wdrażania unix.

Dlatego trzeba /usr/local/bin, /usr/local/sbin /usr/local/includeetc ...

/optz drugiej strony dotyczy oprogramowania, które nie przestrzega tego i jest wdrażane w sposób monolityczny. Zwykle obejmuje to oprogramowanie komercyjne i / lub wieloplatformowe, które jest spakowane w stylu „Windows”.

Są bardzo podobne, a użycie jednego lub drugiego jest bardziej kwestią opinii. Czasopismo Linux miał ten punkt / kontrapunkt dyskusję o dokładnym ten temat tutaj .

Dla mnie osobiście tak powiedział Bill w linku @ philfr:

W systemie deweloperskim lub w piaskownicy posiadanie katalogu / opt, w którym możesz po prostu wrzucić rzeczy i sprawdzić, czy działają, ma sens. Wiem, że nie zamierzam samodzielnie pakować rzeczy, aby je wypróbować. Jeśli aplikacja nie działa, możesz po prostu uruchomić katalog / opt / mytestapp, a ta aplikacja jest historią. Pakowanie może mieć sens, gdy prowadzisz duże wdrożenie (są chwile, kiedy robię aplikacje), ale wiele razy miło jest wrzucić / opt.

Niestety, większość make installskryptów wpycha pliki /usr/localzamiast tworzyć tam tylko dowiązanie symboliczne: - /

Po pierwsze, nie sądzę, że istnieje ścisła odpowiedź; różni administratorzy będą mieli różne opinie, w zależności od ich pochodzenia. Historycznie /usr/localbyło pierwsze; była to konwencja w Berkley, IIRC. W pewnym momencie rozwoju Systemu V, jeśli się nie mylę (to było dawno temu, a ja nie robiłem notatek), pojawiła się decyzja lub chęć zamontowania /usrtylko do odczytu, co oznaczało, że nie można dodać do niego nowego oprogramowania; być może dlatego /opt został wynaleziony. Tak się składa, że ​​istniało tak wiele istniejących programów, które napisały, /usrże ten pomysł nigdy tak naprawdę się nie zaczął.

Osobiście preferuję /optoddzielny podkatalog dla każdego produktu; powoduje to, że usunięcie produktu jest prostym przypadkiem rm -fr. Ale jeśli całe twoje oprogramowanie jest zainstalowane za pomocą dobrego menedżera pakietów, nie ma to znaczenia, a jeśli instalowane oprogramowanie nie przestrzega ściśle tych konwencji i zapisuje konfiguracje /usritp., To nie ma znaczenia, chociaż z przeciwnych powodów.

Mam nieco inne podejście do tej kwestii.
Choć wszystko w jlliagre „s odpowiedź jest poprawna, praktyczne zastosowanie dla mnie, podczas wdrażania oprogramowania w klastrze, sprowadza się do domyślnych zmiennych środowiskowych i domyślnej ponownego wykorzystania bibliotekami.

Mówiąc najprościej - /usr/locala wszystkie jego potomne katalogi znajdują się w odpowiednich zmiennych env, takich jak PATHi MANPATH, i /usr/local/lib{,64}są w ldconfig's ( /etc/ld.so.conf.d/).

/opt/OTOH nie jest - co jest zarówno korzystne, gdy wymaga współistnienia wielu wersji lub sprzecznych pakietów w systemie, ale wymaga pewnego rodzaju zarządzania środowiskiem (np. Modułów środowiska lub kolekcji oprogramowania ), i jest niekorzystne, ponieważ potencjalnie „zmarnowałoby” „miejsce do przechowywania poprzez kopiowanie bibliotek współdzielonych, ponieważ każda instalacja /optmoże być całkowicie samodzielna.

Dla wspólnego charakteru /usr/localpracy zakłada się, że np. Pliki binarne są instalowane bezpośrednio na /usr/local/bin(i stronach man odpowiednio /usr/local/share/man/...) zamiast /usr/local/app/{bin,share/man,...}itp.