Dlaczego oprogramowanie instaluje się w / usr / lib?

Używam serwerów Linuksa od lat i wciąż jestem zdezorientowany standardem Hierarchii Systemów Plików. Zwykle mogę żyć z zamieszaniem. Ale teraz, gdy tworzę własne oprogramowanie dla Linuksa, muszę zrozumieć, gdzie powinien je zainstalować menedżer pakietów.

Byłem całkiem przekonany, że / opt to idealna lokalizacja dla mojej aplikacji. Ale po sprawdzeniu mojego systemu plików Debiana nie jestem już pewien: wiele programów jest faktycznie zainstalowanych w / usr / lib! Aby wymienić tylko kilka: MySQL, MySQLWorkbench, Nautilus, Rythmbox ...

Według FHS, / usr / lib powinien zawierać „Biblioteki do programowania i pakietów” oraz „zawiera pliki obiektowe, biblioteki i wewnętrzne pliki binarne, które nie są przeznaczone do bezpośredniego uruchamiania przez użytkowników lub skrypty powłoki” ( patrz tutaj ).

Wiele programów znajdujących się w / usr / lib mojego serwera Debiana nie jest bibliotekami ani wewnętrznymi plikami binarnymi, ale pełnowartościowym oprogramowaniem wykonywalnym użytkownika!

Nadal jestem na dobrej drodze do zainstalowania mojej aplikacji w / opt. Ale naprawdę chciałbym zrozumieć, czy to prawda, a przede wszystkim dlaczego .

Z góry dziękuję za miłe porady,

Eric

Prawdziwym kluczem do zrozumienia standardu Heirarchy System plików jest wiedza, że ​​został on zaprojektowany z myślą o sieciowych systemach plików.

Dla każdej maszyny z tym samym systemem operacyjnym, wydaniem i architekturą możesz udostępnić / usr przez NFS i zamontować go.
/ usr jest (ponownie) montowany po zainicjowaniu stosu sieciowego.

/var <-- local, r/w optimized
/usr <-- can be mounted over network, possibly even read-only!
/opt <-- local, read mostly
/etc <-- local, read mostly
/srv <-- local, r/w optimized

/home <-- either/or

Różnica polega na tym, /usrże pakiety mają być instalowane jako część systemu . Pakiety, które otrzymujesz z repozytoriów Debian / Ubuntu, PPA itp., Przejdź tutaj. Chociaż /optjest przeznaczony do uwolnionych aplikacji innych firm, które nie są dystrybuowane w procesie dystrybucji pakietów dystrybucji.

Jeśli dystrybuujesz pakiety .deb lub .rpm, z myślą o ewentualnym włączeniu oprogramowania do oficjalnych repozytoriów, powinieneś zainstalować /usr. W przeciwnym razie zainstaluj /opt. W obu przypadkach twoja aplikacja powinna mieć możliwość kompilacji do działania w dowolnym dowolnym miejscu (np. Przy pomocy autotools GNU).

Instalujesz biblioteki w <prefix>/lib, pliki binarne w <prefix>/bin, pliki nagłówka w <prefix>/include, strony man w prefix/[share/]man, pliki pkgconfig w <prefix>/lib/pkgconfiglub <prefix/share/pkgconfig, twoje pliki cmake .m4 w<prefix>/share/aclocal

Następnie pozwól menedżerowi pakietu zdecydować o prefiksie. Jeśli sam dystrybuujesz rpm / deb, /usrto dobry wybór na prefiks.

./configure --prefix=~/.local/ Powinien nadal działać, więc proszę, nie nigdzie nie wpisuj swojej ścieżki na stałe!

Niektóre biblioteki są zapakowane w inne narzędzie, które sprawia, że ​​są one również uruchamialne i użyteczne jako biblioteka, ale nadal są bibliotekami, a nie w $ PATH, więc myślę, że można je umieścić w / lib.

Sugeruję, aby unikać instalowania aplikacji w / opt. Powód 1: Niektóre dystrybucje domyślnie nie mają opcji / opt Powód 2: / usr / lib to standardowa ścieżka do bibliotek {Jeśli inne aplikacje muszą korzystać z biblioteki, musisz ręcznie dodać ścieżkę biblioteki do / etc / ldconfig} / opt jest wygodniejszy, gdy masz samodzielne aplikacje, które instalujesz ręcznie i chcesz wiedzieć, gdzie się znajdują

Jednym z powodów, dla których w pełni rozwinięte pliki wykonywalne znajdują się w katalogu / usr / lib, może być to, że są one używane z innych skryptów. {Na przykład skrypty bash nie mogą bezpośrednio korzystać z interfejsu API. z tego powodu powszechną sztuczką jest budowanie „otoki” wokół tego interfejsu API i wypychanie parametrów jako argumentów skryptu}

Zainstaluj go w / opt.

Zbyt wiele aplikacji Linuksa sprawia, że ​​programiści Windowsa robili to samo w latach 90-tych.

Zainstalujmy nasze rzeczy w C: \ windows, aby było to łatwe i łatwe do znalezienia (i nieco szybciej). Potem przyszło 15 lat piekła DLL, ponieważ różne pakiety oprogramowania wymagały różnych wersji tych samych bibliotek (które w systemie Windows nie miały wersji bibliotek).

O ile nie piszesz rzeczywistego oprogramowania systemowego, włącz / opt, aby ludzie mogli lepiej śledzić, kto co zainstalował.