루트가 아닌 사용자로 소스에서 여러(>10) 패키지를 빌드하고 이를 설치하려고 합니다(이 문제를 해결하려면 값을 선택하십시오 --prefix=). 두 가지 확실한 선택은 다음과 같습니다.
- 내 홈 디렉토리 사용
etc/즉 , ,usr/및 이와 유사한 하위 디렉터리가 있고var/각 하위 디렉터리에는 서로 다른 패키지에 대한 파일이 포함됩니다. 그러나 대부분의 패키지는 상호 작용하지 않으므로 해당 파일을 동일한 하위 디렉터리에 두는 것은 의미가 없으며, 이로 인해 제거가 어려울 것이라고 생각합니다. - 각 패키지마다 별도의 디렉터리를 사용하세요., 예를 들어 등
--prefix=$HOME/myfooapp.--prefix=$HOME/mybarlib이렇게 하면 모든 것이 분리되어 유지되지만 이제 내 홈 디렉터리는 내가 보고 싶지 않은 여러 하위 디렉터리로 채워지게 됩니다. 패키지도 있어요하다대화형이므로 같은 장소에 함께 있어도 괜찮습니다(PATH를 매우 길게 만들 필요가 없습니다).
제가 놓친 다른 옵션이 있나요? 내 말은, 난 할 수 있어
- 옵션 2와 유사하지만 내 홈 디렉터리의 하위 디렉터리에 있음,예를 들어
--prefix=$HOME/opt/myfooapp,--prefix=$HOME/opt/mybarlib
이것이 내가 할 수 있는 최선인가?
답변1
나는 이것이 일반적으로 웹 사이트 규칙이라고 생각합니다. 장기간 실행되는 설치의 경우 $HOME 트리에 의존하기를 꺼리고 /opt를 사용하는 것을 선호합니다. 이는 적절한 권한으로 /opt//를 설정하고 데이터 등의 표준 위치로 사용할 관련 디렉토리를 설정하는 것을 의미하더라도 /opt를 사용하는 것을 선호합니다. . 당신이 지적할 수 있는 것에 대한 합리적인 설명과 일치합니다.https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
나에게는 관례를 직접적으로 위반하지 않으려는 노력 외에도 구조 사용에 가장 큰 영향을 미치는 것은 서버 사용입니다. 서버 이미지를 다른 환경이나 소프트웨어/데이터로 교체할 계획이신가요? 공유 파일 시스템을 사용합니까, 아니면 소프트웨어를 최적화하기 위해 특정 파티션이 필요합니까? 이 디렉토리를 백업 등에 포함시키시겠습니까? 실행 권한이나 데이터를 다른 사용자 계정과 공유하시겠습니까? 기본 경로와 공통 빌드 플래그를 확장하기 위해 공유 셸 프로필 로그인에서 일부 환경 변수를 설정하는 것을 고려할 수도 있습니다.
이것이 생각할 거리를 주기를 바랍니다. 물론, 로컬 컴퓨터에 있다면 옳다고 생각되는 모든 작업을 수행하세요. 하지만 무시되는 디렉터리 트리이므로 /opt 사용을 배제하지 마세요. ^)
답변2
마침내 나는 결정했다 $HOME/opt/myfooapp. 왜냐하면:
- 옵션 2와 3을 사용하면 서로 다른 패키지의 파일 계층을 분리할 수 있습니다. /를 루트로 사용할 때 도움을 줄 수 있는 패키지 관리자가 있으므로 이는 문제가 되지 않습니다. 나는 아니에요...
- 옵션 3만이 내 홈 디렉토리가 패키지 설치와 관련된 여러 디렉토리로 복잡해지는 것을 방지합니다.
답변3
--prefix=$HOME덜 복잡 PATH하고 다른 유사한 정보 파일 위치도 사용하며 MANPATH잘 작성된 패키지는 어쨌든 각 발가락을 밟지 않습니다.