Ach tak, jest to bardzo mylące, jeśli zajmujesz się Uniksami przez dłuższy czas. Istnieje standard, który większość uniksów „próbuje” przestrzegać, zwany FHS - Standard systemu plików .
Biorąc pod uwagę, że używam głównie dystrybucji opartych na systemie Red Hat, jestem najbardziej zaznajomiony z ich podejściem do FHS dla dystrybucji Fedora, CentOS i RHEL Linux. Ale użyłem również dystrybucji opartych na Debianie i BSD i nie różnią się one tak bardzo pod względem miejsca przechowywania, pod względem systemu plików.
Teraz na twoje pytania. Rzuciłbym okiem na dokument FHS , który luźno reguluje te struktury katalogów. Ogólnie:
Katalog - /lib
Zawiera niezbędne współdzielone biblioteki i moduły jądra.
Cel: katalog / lib zawiera obrazy biblioteki współdzielonej potrzebne do uruchomienia systemu i uruchomienia poleceń w głównym systemie plików, tj. przez pliki binarne w / bin i / sbin.
Uwaga 1: Biblioteki współdzielone, które są niezbędne tylko dla plików binarnych w / usr (takich jak dowolne pliki binarne X Window), nie mogą znajdować się w / lib. Mogą być tu tylko biblioteki współużytkowane wymagane do uruchamiania plików binarnych w / bin i / sbin.
Uwaga 2: Biorąc pod uwagę, że głównym celem / lib jest przechowywanie bibliotek narzędzi rozmieszczonych w katalogach / bin i / sbin, biblioteki w / lib mogą być 32-bitowe lub 64-bitowe.
Na przykład (system 64-bitowy Fedora 14)
$ uname -a
Linux grinchy 2.6.35.14-106.fc14.x86_64 #1 SMP Wed Nov 23 13:07:52 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
Oto próbka plików z mojego / lib
./libpam.so.0.82.2: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped
./libplc4.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped
./libidn.so.11.6.1: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped
./upstart/telinit: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, stripped
./upstart/runlevel: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, stripped
./upstart/shutdown: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, stripped
./upstart/reboot: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, stripped
./libdb-4.8.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped
./firmware/mixart/miXart8.elf: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (SYSV), statically linked, not stripped
./libtinfo.so.5.7: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped
Katalog - /lib<qual>
Niezbędne biblioteki współdzielone w innym formacie (opcjonalnie). Byłyby to katalogi / lib32, / lib64 itp.
Cel: Może istnieć jeden lub więcej wariantów katalogu / lib w systemach, które obsługują więcej niż jeden format binarny wymagający osobnych bibliotek. Jest to powszechnie używane do obsługi 64-bitowej lub 32-bitowej w systemach obsługujących wiele formatów binarnych, ale wymagających bibliotek o tej samej nazwie.
Uwaga: W tym przypadku / lib32 i / lib64 mogą być katalogami bibliotek, a / lib dowiązaniem symbolicznym do jednego z nich.
Katalog - /usr/lib
Biblioteki do programowania i pakietów.
Cel: / usr / lib obejmuje 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.
Uwaga 1: Różne pliki statyczne i podkatalogi, niezależne od architektury, muszą być umieszczone w / usr / share.
Aplikacje mogą korzystać z jednego podkatalogu w katalogu / usr / lib. Jeśli aplikacja korzysta z podkatalogu, wszystkie dane zależne od architektury wykorzystywane wyłącznie przez aplikację muszą zostać umieszczone w tym podkatalogu.
Uwaga 2: Na przykład podkatalog perl5 dla modułów i bibliotek Perl 5.
Katalog - /usr/lib<qual>
Biblioteki formatu alternatywnego (opcjonalnie).
Cel: /usr/lib<qual> spełnia tę samą funkcję jak / usr / lib na alternatywnym formacie binarnym, oprócz tego, że dowiązania symboliczne /usr/lib<qual>/sendmaili /usr/lib<qual>/X11nie są wymagane.
Uwaga: Przypadek, w którym / usr / lib i /usr/lib<qual>są takie same (jeden jest dowiązaniem symbolicznym do drugiego), te pliki i podkatalogi dla poszczególnych aplikacji będą istnieć.
TLDR;
Ogólnie:
Jeśli istnieją biblioteki wymagane przez plik wykonywalny w katalogach / bin lub / sbin, biblioteki te powinny znajdować się w katalogach / lib *.
Jeśli istnieją biblioteki programów użytkowych i pakietów, znajdują się w katalogu / usr / lib / *. Jeśli istnieją pliki wykonywalne, które są potrzebne konkretnej bibliotece, ale te pliki wykonywalne nie powinny być wywoływane przez użytkowników bezpośrednio lub przez root, przechodzą do katalogu / usr / libexec.