"표준"이란 무엇입니까? 애플리케이션(바이너리뿐 아니라 전체 배포판)을 /usr/local 또는 /usr/local/share에 배치해야 합니까?
예를 들어 scala 또는 weka에는 예제, 바이너리, 라이브러리 등이 포함되어 있습니다. 그렇게 될 것이다
/usr/local/scala-2.9.1
또는
/usr/local/share/scala-2.9.1
나는 유일한 관리자이기 때문에 이것은 나에게 큰 문제는 아니지만 내 자신의 사용자 정의보다는 널리 사용 가능한 것을 사용하는 것을 선호합니다.
중요한:애플리케이션을 /usr/local/bin, /usr/local/lib 등으로 분할해야 하는 상황에 대해 묻는 것이 아닙니다. 대신, 전체 애플리케이션에 대해 하나의 홈 디렉터리를 유지해야 하는 상황에 대해 묻고 있습니다.
답변1
이 경우에는 /opt가 더 표준적이라고 생각합니다.파일 시스템 계층 표준의 관련 부분아래 인용문.
Distros는 /opt에 소프트웨어를 설치할 수 있지만 로컬 시스템 관리자의 허가 없이 로컬 시스템 관리자가 설치한 소프트웨어를 수정하거나 제거할 수는 없습니다.
Ÿ 이론적 근거 추가 기능 소프트웨어와 함께 /opt를 사용하는 것은 UNIX 커뮤니티에서 잘 확립된 관행입니다. System V 응용 프로그램 바이너리 인터페이스[AT&T 1990]는 System V 인터페이스 정의(3판)를 기반으로 하며 여기에 정의된 것과 매우 유사한 /opt 구조를 제공합니다.
iBCS2(Intel Binary Compatibility Standard v.2)도 /opt에 대해 유사한 구조를 제공합니다.
일반적으로 /etc/opt/ 및 /var/opt/에 복사할 파일과 /opt에 있는 디렉터리를 포함하여 시스템에서 패키지를 지원하는 데 필요한 모든 데이터는 /opt/에 있어야 합니다.
배포판에 설치된 소프트웨어와 로컬에 설치된 소프트웨어 사이에 충돌이 발생할 수 있으므로 /opt를 사용하는 배포판에는 약간의 제한이 필요합니다. 특히 일부 바이너리 소프트웨어에 고정된 경로 이름이 있는 경우 더욱 그렇습니다.
/opt/ 아래의 디렉토리 구조는 소프트웨어 패키지 프로그램에 의해 결정되지만, 패키지를 /opt//에 설치하고 /opt/package 지침과 유사한 구조를 따르는 것이 좋습니다. 이 구조에서 벗어나는 유효한 이유 중 하나는 패키지를 지원하는 파일이 /opt//lib 또는 /opt//bin에 설치될 수 있다는 것입니다.
답변2
/usr/local/share특정 아키텍처/OS 버전과 관련이 없는 파일 만 사용해야 합니다 .
그런 다음 의 기존 하위 디렉터리 간에 파일을 배포할지 /usr/local아니면 에서 새 전용 디렉터리를 생성할지 결정할 수 있습니다 /usr/local(그러나 후자는 실행 파일 또는 에 아직 존재하지 PATH않습니다 LD_LIBRARY_PATH) MANPATH.
보세요FHS
답변3
/opt일반적인 장소는 그것이 일반화 되기 전이었습니다 /usr/local/lib/<package>.
답변4
로컬 애플리케이션을 설치할 때 액세스 및 업데이트 방법에 따라 여러 옵션이 있습니다. 또한 일부 방법은 이미 보유하고 있는 시스템과 더 비슷해 보이지만 다른 방법은 좀 더 임시적일 수도 있다는 점에 유의해야 합니다. 나는 "최고의" 솔루션은 일을 보다 관리하기 쉽게 만드는 솔루션이라고 제안하고 싶습니다.
사용자 정의 설치하려는 패키지 수에 따라 이 답변을 분할했습니다. Split은 내 경험을 바탕으로 작성되었습니다. 이러한 경험은 패키지를 관리하는 데 필요한 시간과 무언가를 망칠 위험을 비교합니다. 보편적인 표준을 이해한다는 뜻은 아니지만, 결정을 내릴 때 이를 기준으로 삼는다는 뜻입니다.
일부 패키지에만 사용 가능, 나는 추가 기능 패키지를 /opt다른 모든 것의 방해가 되지 않는 어딘가에 배치하여 아무것도 패키지를 망치거나 다른 것을 망치지 않도록 할 것입니다. 이것이 제가 NAS에서 사용하는 방법입니다. 그러나 이 방법은 바이너리를 PATH 외부에 유지하므로 수동으로 추가해야 합니다. 설치해야 할 패키지가 몇 개뿐인 경우에는 잘 작동하지만, 너무 많으면 혼란스러울 수 있습니다.
여기에서 업데이트하는 것은 디렉터리를 덮어쓰는 것만큼 간단합니다.
이점:
- 단순한
- 빠른 설치
- 시스템의 다른 부분에 영향을 미칠 가능성이 없습니다.
- 제거는 설치만큼 쉽습니다
결점:
- 설치할 패키지 수가 많으면 꽤 지루해질 수 있습니다.
PATH사람을 지저분하게 보이게 만들어
여러 패키지의 경우/usr/local/<your package>, 실행 파일을 사용하고 심볼릭 링크하는 것이 좋습니다 . /usr/local/bin또는 /usr/local/sbin루트 액세스가 필요한지 여부에 따라 다릅니다. 이렇게 하면 새로운 것을 추가할 때마다 PATH를 변경할 필요가 없으므로 PATH를 깨끗하게 유지할 수 있습니다. 이것은 팩맨이 아닌 모든 패키지와 AUR 패키지에 대해 내 Arch 노트북에서 사용하는 방법입니다.
업데이트는 패키지 디렉터리를 덮어쓰고 심볼릭 링크가 여전히 유효한지 확인하고 그렇지 않은 경우 수정하여 수행됩니다.
이점
PATH엉망으로 만들지 않을 거야- 기본 시스템에 영향을 주지 않습니다.
- 모든 추가 기능을 제거하고 깨끗한 기본 시스템으로 돌아가는 것은 여전히 매우 간단합니다.
결점:
- 설정해야 할 작업이 더 남아 있습니다.
- 하나의 패키지만 제거하려면 약간의 검색이 필요합니다.
많은 패키지의 경우. 원하시는 상황이 아니므로 간략하게 말씀드리겠습니다. 패키지를 bin, lib, share등으로 분할하여 설치하는 것이 좋습니다 /usr/local. 이는 구조를 깨끗하게 유지하기 위함입니다. 누가 어디에 쓸 수 있는지 등을 지정할 수도 있습니다. 예를 들어 루트 이외의 다른 사람이 실행 파일을 수정하는 것을 원하지 않습니다.
여기의 업데이트는 여러 디렉터리에 써야 하기 때문에 약간 까다롭습니다. 모든 것을 포장하고 패키지 관리자가 나머지를 처리하도록 하는 것이 좋습니다.
주식
Faheem에 설명된 대로 디렉토리 share자체는 아키텍처 독립적인 파일에 사용됩니다.협회아키텍처 관련 파일은 , lib등 으로 이동해야 합니다.lib32lib64