it-swarm-ko.tech

/ opt와 / usr / local의 차이점은 무엇입니까?

파일 시스템 계층 표준 , /opt는 "애드온 응용 프로그램 소프트웨어 패키지 설치"를위한 것입니다. /usr/local는 "소프트웨어를 로컬에 설치할 때 시스템 관리자가 사용"입니다. 이 사용 사례는 매우 비슷해 보입니다. 배포판에 포함되지 않은 소프트웨어는 일반적으로 /usr/local 또는 /opt 그들이 선택한 특정 운율이나 이유가 없습니다.

내가 누락 된 차이점이 있습니까, 아니면 둘 다 같은 일을하지만 역사적 이유로 존재합니까?

440
Patches

둘 다 운영 체제에 속하지 않는 파일을 포함하도록 설계되었지만 /opt/usr/local는 동일한 파일 세트를 포함하지 않습니다.

/usr/local는 일반적으로 make 명령 (예 : ./configure; make; make install)을 사용하여 관리자가 작성한 파일을 설치하는 장소입니다. 아이디어는 운영 체제의 일부인 파일과의 충돌을 피하는 것입니다. 운영 체제의 일부는 로컬 파일을 덮어 쓰거나 덮어 씁니다 (예 : /usr/bin/foo는 OS의 일부이고 /usr/local/bin/foo는 지역 대안).

/usr 아래의 모든 파일은 OS 인스턴스간에 공유 할 수 있지만 Linux에서는 거의 수행되지 않습니다. /usr가 읽기 전용으로 정의되어 있지만 소프트웨어의 로컬 설치가 성공하려면 /usr/local/bin가 읽기-쓰기 여야하므로 FHS가 약간 모순되는 부분입니다. FHS의 주요 영감 원인 SVR4 파일 시스템 표준은이 문제를 극복하기 위해 /usr/local를 피하고 /opt/local를 사용하는 것이 좋습니다.

/usr/local는 원래 BSD의 유산입니다. 그 당시 /usr/bin OS 명령의 소스 코드는 /usr/src/bin/usr/src/usr.bin에 있었고 로컬로 개발 된 명령의 소스는 /usr/local/src에있었습니다. /usr/local/bin의 바이너리. 포장에 대한 개념은 없었습니다 (타르볼 외부).

반면, /opt는 번들이없는 패키지 (운영 체제 배포판의 일부가 아니지만 독립적 인 소스에서 제공하는 패키지)를 각각 자체 하위 디렉토리에 설치하기위한 디렉토리입니다. 이들은 독립적 인 타사 소프트웨어 배포자가 제공하는 전체 패키지로 이미 구축되어 있습니다. /usr/local와 달리이 패키지는 디렉토리 규칙을 따릅니다 (또는 최소한 있어야합니다). 예를 들어, someapp/opt/someapp에 설치되며 명령 중 하나는 /opt/someapp/bin/foo이고 구성 파일은 /etc/opt/someapp/foo.conf에 있으며 로그 파일은 /var/opt/someapp/logs/foo.access.

393
jlliagre

기본적인 차이점은 /usr/local는 시스템 패키저가 관리하지 않지만 여전히 표준 유닉스 배포 규칙을 따르는 소프트웨어를위한 것입니다.

그래서 당신은 /usr/local/bin, /usr/local/sbin/usr/local/include 등 ...

/opt 다른 한편으로는 이것을 따르지 않고 모 놀리 식 방식으로 배포되는 소프트웨어를위한 것입니다. 여기에는 일반적으로 "Windows"스타일로 패키지 된 상용 및/또는 크로스 플랫폼 소프트웨어가 포함됩니다.

89
Šimon Tóth

그것들은 실제로 매우 유사하며, 하나 또는 다른 것을 사용하는 것이 더 많은 의견의 문제입니다. 리눅스 저널은이 정확한 주제에 대해이 요점/대책 토론을 가졌다 here .

18
philfr

개인적으로 Bill은 @philfr의 링크에서 다음과 같이 말했습니다.

개발 시스템 또는 샌드 박스에서/opt 디렉토리를 사용하여 사물을 던지고 작동하는지 확인할 수 있습니다. 나는 그것을 시험해보기 위해 스스로 물건을 포장하는 노력을 기울이지 않을 것임을 알고 있습니다. 앱이 작동하지 않으면/opt/mytestapp 디렉토리를 rm으로하면 해당 애플리케이션은 히스토리입니다. 대규모 배포를 실행하는 경우 (패키지 앱을 수행하는 경우가 있음) 패키징이 의미가있을 수 있지만 많은 경우/opt에 물건을 넣는 것이 좋습니다.

불행히도, 대부분의 make install 스크립트는 파일을 /usr/local 심볼릭 링크를 만드는 대신 :-/

13
pepoluan

첫째, 나는 엄격한 대답이 없다고 생각합니다. 배경에 따라 관리자마다 의견이 다릅니다. 역사적으로 /usr/local가 먼저 나타났습니다. IIRC 버클리에서 열린 대회였습니다. System V를 개발하는 동안 어느 시점에서 내가 잘못 생각하지 않으면 (이것은 모두 오래 전이고 메모를하지 않았 음) /usr 읽기 전용이므로 새로운 소프트웨어를 추가 할 수 없습니다. /opt가 발명 된 이유 일 수 있습니다. 그와 같이, /usr에 기록한 기존 소프트웨어가 너무 많아서 그 아이디어는 결코 실현되지 않았습니다.

개인적으로 선호하는 것은 /opt이며 각 제품마다 별도의 하위 디렉토리가 있습니다. 이로 인해 제품을 제거하는 간단한 사례가 rm -fr가됩니다. 그러나 모든 소프트웨어가 적절한 패키지 관리자를 통해 설치 되어도 문제가되지 않으며, 설치 한 소프트웨어가 이러한 규칙을 엄격하게 준수하지 않고 /usr 아래의 구성을 작성하는 경우에는 문제가되지 않습니다. 반대의 이유로도 중요하지 않습니다.

12
James Kanze

이 문제에 약간의 차이가 있습니다.
jlliagre 's answer 의 모든 내용이 정확하지만, 클러스터에 소프트웨어를 배포 할 때 실제 응용 프로그램은 기본 환경 변수 및 기본값으로 변경됩니다. 라이브러리 재사용.

간단히 말해서-/usr/local 그리고 모든 하위 디렉토리는 PATHMANPATH와 같은 적절한 env var에 있고 /usr/local/lib{,64}는 ldconfig의 [/etc/ld.so.conf.d/).

/opt/ OTOH는 — 시스템에 여러 버전이나 충돌 패키지가 공존해야 할 때 유리하지만 일종의 환경 관리가 필요합니다 (예 : environment-modules 또는 software collections )이며, /opt의 각 설치가 완전히 자체 포함될 수 있기 때문에 공유 라이브러리를 복제하여 저장 공간을 "폐기"시킬 수 있다는 단점이 있습니다.

/usr/local의 공유 특성이 작동하려면 다음과 같이 가정합니다. 바이너리는 /usr/local/bin 등이 아닌 /usr/local/share/man/... (및 맨 페이지를 적절한 /usr/local/app/{bin,share/man,...})에 직접 설치됩니다.

10
Dani_l

요약하면, 내 직감은 ...

2.2.6 이후로 FreeBSD에 대한 공정한 지분을 사용하고 버전 9 이후로 Red Hat Linux를 사용했습니다 ...

/usr/local == Old School Conventions
/opt       == New School Conventions

유닉스/리눅스 파일 시스템에서의 배열은 절대 논리보다 관습과 전통과 더 관련이 있습니다.

그렇지 않으면 나는 대부분 다른 사람들과 동의합니다. :-)

규칙에는 항상 예외가 있습니다. 하루가 끝나면 설정에 가장 적합한 것을 결정합니다 (가능한 경우).

0
Anthony Rutledge