나는 수년 동안 Linux 서버를 사용해 왔으며 Filesystem Hierarchy Standard에 의해 계속 혼란스러워하고 있습니다. 보통, 나는 혼란과 함께 살 수 있습니다. 그러나 이제는 Linux 용으로 자체 소프트웨어를 개발하고 있으므로 패키지 관리자가 설치해야하는 위치를 이해해야합니다.
나는 / opt가 내 응용 프로그램의 완벽한 위치라는 것을 확신했습니다. 그러나 데비안 파일 시스템을 조사한 후에는 더 이상 확실하지 않습니다. 많은 소프트웨어가 실제로 / usr / lib에 설치되어 있습니다! 몇 가지 예를 들면 : MySQL, MySQLWorkbench, Nautilus, Rythmbox …
FHS에 따르면 / usr / lib는 “프로그래밍 및 패키지 용 라이브러리”를 포함하고 “사용자 또는 쉘 스크립트가 직접 실행하지 않는 객체 파일, 라이브러리 및 내부 바이너리를 포함합니다”( 여기 참조 ).
내 데비안 서버의 / usr / lib에있는 많은 소프트웨어는 라이브러리 나 내부 바이너리가 아니라 본격적인 사용자 실행 가능 소프트웨어입니다!
/ opt에 내 응용 프로그램을 설치하려고 여전히 진행 중입니다. 그러나 이것이 이것이 올바른지, 무엇보다도 왜인지 이해하고 싶습니다 .
친절한 조언에 미리 감사드립니다.
에릭
답변
파일 시스템 계층 표준을 이해하기위한 진정한 열쇠는 네트워크 파일 시스템을 염두에두고 설계된 것입니다.
동일한 OS, 릴리스 및 아키텍처의 모든 시스템에 대해 NFS를 통해 / usr을 공유하고 마운트 할 수 있습니다.
/ usr은 네트워크 스택이 초기화 된 후 (다시) 마운트됩니다.
/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
답변
차이점은 시스템의 일부로/usr 설치된 패키지를 보유한다는 의미 입니다. 데비안 / 우분투 리포지토리, PPA 등에서 얻은 패키지는 여기로 이동하십시오. 동안은 번들위한 것입니다 타사 배포의 패키지 배포 프로세스를 통해 배포되지 않은 응용 프로그램./opt
.deb 또는 .rpm 패키지를 배포하고 결국 공식 리포지토리에 소프트웨어를 포함시키려는 경우에는에 설치해야합니다 /usr. 그렇지 않으면에 설치하십시오 /opt. 어느 경우이든 응용 프로그램은 임의의 위치에서 실행되도록 컴파일 할 수 있어야합니다 (예 : GNU autotools의 도움으로).
답변
라이브러리 <prefix>/lib, 바이너리 <prefix>/bin, 헤더 파일 <prefix>/include, 매뉴얼 페이지 prefix/[share/]man, pkgconfig 파일 <prefix>/lib/pkgconfig또는 <prefix/share/pkgconfigcmake .m4 파일을 라이브러리에 설치합니다.<prefix>/share/aclocal
그런 다음 패키지 관리자가 접두사를 결정하게하십시오. rpm / deb를 직접 배포 /usr하는 경우 접두사를 선택하는 것이 좋습니다.
./configure --prefix=~/.local/
여전히 작동해야하므로 경로를 하드 코딩하지 마십시오.
일부 라이브러리는 다른 도구로 래핑되어 실행 가능하고 라이브러리로 사용할 수 있지만 여전히 $ PATH가 아닌 라이브러리이므로 / lib에 넣는 것이 좋습니다.
답변
/ opt 아래에 앱을 설치하지 않는 것이 좋습니다. 이유 1 : 일부 배포판에는 기본적으로 / opt가 없습니다 이유 2 : / usr / lib는 라이브러리의 표준 경로입니다. {다른 응용 프로그램이 라이브러리를 사용해야하는 경우 라이브러리 경로를 수동으로 / etc / ldconfig} / opt에 추가해야합니다. 수동으로 설치하는 독립형 앱이 있고 해당 앱의 위치를 알고 싶은 경우 더 편리합니다
본격적인 실행 파일이 / usr / lib 아래에있는 이유 중 하나는 다른 스크립트에서 사용하기 때문일 수 있습니다. {예를 들어 bash 스크립트는 API를 직접 사용할 수 없습니다. 이러한 이유로 일반적인 API는이 API 주위에 “래퍼”를 작성하고 스크립트의 인수로 매개 변수를 푸시하는 것입니다}
답변
/ opt에 설치하십시오.
너무 많은 Linux 응용 프로그램이 Windows 개발자가 90 년대에 만든 것과 똑같은 방식으로 만듭니다.
C : \ windows에 물건을 설치하여 간단하고 쉽게 찾을 수 있습니다 (약간 더 빠름). 다른 소프트웨어 패키지는 동일한 라이브러리의 다른 버전이 필요했기 때문에 15 년 동안의 DLL 지옥이 생겼습니다 (Windows에는 라이브러리의 버전이 없었습니다).
실제 시스템 소프트웨어를 작성하지 않는 한 사람들이 누가 무엇을 설치했는지 더 잘 추적 할 수 있도록 / opt에 넣으십시오.