왜 소프트웨어가 / usr / lib에 설치됩니까?


11

나는 수년 동안 Linux 서버를 사용해 왔으며 Filesystem Hierarchy Standard에 의해 계속 혼란스러워하고 있습니다. 보통, 나는 혼란과 함께 살 수 있습니다. 그러나 이제는 Linux 용으로 자체 소프트웨어를 개발하고 있으므로 패키지 관리자가 설치해야하는 위치를 이해해야합니다.

나는 / opt가 내 응용 프로그램의 완벽한 위치라는 것을 확신했습니다. 그러나 데비안 파일 시스템을 조사한 후에는 더 이상 확실하지 않습니다. 많은 소프트웨어가 실제로 / usr / lib에 설치되어 있습니다! 몇 가지 예를 들면 : MySQL, MySQLWorkbench, Nautilus, Rythmbox ...

FHS에 따르면 / usr / lib는 "프로그래밍 및 패키지 용 라이브러리"를 포함하고 "사용자 또는 쉘 스크립트가 직접 실행하지 않는 객체 파일, 라이브러리 및 내부 바이너리를 포함합니다"( 여기 참조 ).

내 데비안 서버의 / usr / lib에있는 많은 소프트웨어는 라이브러리 나 내부 바이너리가 아니라 본격적인 사용자 실행 가능 소프트웨어입니다!

/ opt에 내 응용 프로그램을 설치하려고 여전히 진행 중입니다. 그러나 이것이 이것이 올바른지, 무엇보다도 왜인지 이해하고 싶습니다 .

친절한 조언에 미리 감사드립니다.

에릭


2
MySQL Workbench는 / usr / lib 아래에 라이브러리 만 설치한다는 점에서 스팟 검사. / usr / lib에 "본격적인 사용자 실행 가능 소프트웨어"가 있다고 생각하는 것은 무엇입니까?
Mark Wagner

올바르게 기억하면 응용 프로그램 메뉴에있는 실제 바로 가기는 / usr / lib에있는 바이너리를 가리 킵니다.
Eric MORAND

나열된 소프트웨어가 설치된 위치가 혼란스러워 보입니다. 다음은 MySQL 및 Nautilus 용 파일 인 경우 목록에 대한 링크입니다. FHS가 말한 것처럼 파일이 / etc, / usr / bin, / usr / lib 등으로 분할됩니다. packages.debian.org/wheezy/i386/mysql-server-5.5/filelist packages.debian.org/wheezy/i386/nautilus/filelist
sciurus

답변:


6

파일 시스템 계층 표준을 이해하기위한 진정한 열쇠는 네트워크 파일 시스템을 염두에두고 설계된 것입니다.

동일한 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

지역 / 원격 및 r-r / w 표준에 대한 링크를 제공 하시겠습니까?
기린 선장

이것은 네트워크의 모든 Linux 서버 또는 워크 스테이션에 대해 단일 / usr "저장소"를 가질 수 있다는 것을 의미합니까?
Eric MORAND

1
약간의 작업이 필요하지만 가능합니다. 값 비싼 하드 드라이브가 큰 롤아웃의 표준이었던 경우로 되돌아갑니다.
Dan Garthwaite

@ eric-morand FHS에서 : "/ usr은 파일 시스템의 두 번째 주요 섹션입니다. / usr은 공유 가능한 읽기 전용 데이터입니다. 즉, / usr은 다양한 FHS 호환 호스트간에 공유 가능해야하며 "호스트에 따라 다르거 나 시간에 따라 다른 정보는 다른 곳에 저장됩니다." pathname.com/fhs/pub/fhs-2.3.html#THEUSRHIERARCHY
Dan Garthwaite

으악. 위의 의견은 @CaptainGiraffe 위해이었다
댄 Garthwaite

12

차이점은 시스템의 일부로/usr 설치된 패키지를 보유한다는 의미 입니다. 데비안 / 우분투 리포지토리, PPA 등에서 얻은 패키지는 여기로 이동하십시오. 동안은 번들위한 것입니다 타사 배포의 패키지 배포 프로세스를 통해 배포되지 않은 응용 프로그램./opt

.deb 또는 .rpm 패키지를 배포하고 결국 공식 리포지토리에 소프트웨어를 포함시키려는 경우에는에 설치해야합니다 /usr. 그렇지 않으면에 설치하십시오 /opt. 어느 경우이든 응용 프로그램은 임의의 위치에서 실행되도록 컴파일 할 수 있어야합니다 (예 : GNU autotools의 도움으로).


감사. 지금은 공식 저장소에 앱을 포함시킬 계획이 없습니다.
Eric MORAND

그렇다면 / usr / local은 어떻습니까? 아니면 별개
Aaron Copley

@AaronCopley /usr/local는이 질문의 범위에 포함되지 않았습니다. 그러나 로컬 관리자가 컴파일하고 설치하는 타사 소프트웨어를위한 것입니다.
Michael Hampton

그래서 나는 그것이 별개의 것으로 간주되는지 물었습니다.
Aaron Copley

2

라이브러리 <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에 넣는 것이 좋습니다.


1

/ opt 아래에 앱을 설치하지 않는 것이 좋습니다. 이유 1 : 일부 배포판에는 기본적으로 / opt가 없습니다 이유 2 : / usr / lib는 라이브러리의 표준 경로입니다. {다른 응용 프로그램이 라이브러리를 사용해야하는 경우 라이브러리 경로를 수동으로 / etc / ldconfig} / opt에 추가해야합니다. 수동으로 설치하는 독립형 앱이 있고 해당 앱의 위치를 ​​알고 싶은 경우 더 편리합니다

본격적인 실행 파일이 / usr / lib 아래에있는 이유 중 하나는 다른 스크립트에서 사용하기 때문일 수 있습니다. {예를 들어 bash 스크립트는 API를 직접 사용할 수 없습니다. 이러한 이유로 일반적인 API는이 API 주위에 "래퍼"를 작성하고 스크립트의 인수로 매개 변수를 푸시하는 것입니다}


2
동의하지 않습니다. / opt에 설치하려면 패키지 관리자가 디렉토리를 작성하므로 문제가되지 않습니다. 또한 / usr / lib에 설치된 바이너리는 나쁜 생각입니다.
Walter

감사합니다 @Nikolaidis Fotis. 그러나 제 경우에는 내 응용 프로그램에 공용 라이브러리가 포함되어 있지 않으며 다른 응용 프로그램에서 사용되지 않습니다.
Eric MORAND

0

/ opt에 설치하십시오.

너무 많은 Linux 응용 프로그램이 Windows 개발자가 90 년대에 만든 것과 똑같은 방식으로 만듭니다.

C : \ windows에 물건을 설치하여 간단하고 쉽게 찾을 수 있습니다 (약간 더 빠름). 다른 소프트웨어 패키지는 동일한 라이브러리의 다른 버전이 필요했기 때문에 15 년 동안의 DLL 지옥이 생겼습니다 (Windows에는 라이브러리의 버전이 없었습니다).

실제 시스템 소프트웨어를 작성하지 않는 한 사람들이 누가 무엇을 설치했는지 더 잘 추적 할 수 있도록 / opt에 넣으십시오.


4
이것은 Windows가 아닙니다. 우리는 작동 하는 패키지 관리자를 가지고 있으며 이것은 실제로 큰 문제가 아닙니다.
Michael Hampton

모든 것이 동일한 트리에있는 것이 걱정된다면 Nix 패키지 관리자를 확인하십시오 . 당신이 저에게 묻는다면 두 세계의 최고.
TheSola10
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.