저는 일부 rpm 패키지를 구축하고 rpmlint. 우리 패키지에는 사내 소프트웨어, 리포지토리에 있는 소프트웨어 패치 버전, 공식 리포지토리에서 사용할 수 없는 소프트웨어를 포함한 다양한 소프트웨어가 포함되어 있습니다. 우리는 /usr/local여러 가지 이유로 로컬 패키지를 설치합니다 .
- 공식 패키지와의 이름 충돌 방지
yum update로컬 패키지의 손상 방지- 로컬 패키지가 별도의 파티션이나 디스크에 상주하거나 NFS를 통해 공유되도록 허용하여 호스트 간에 패키지와 구성을 공유할 수 있습니다.
bin표준 설치 경로( ,lib, 등)include를 따르지 않는 공식 저장소 이외의 소스에서 설치된 패키지를 더 효과적으로 제어할 수 있습니다.share
그러나 예를 들어 GNU Hello World의 사용자 정의 빌드에서는 다음과 같이 rpmlint말해야 합니다./usr/localrpmlint -i
hello.x86_64: E: dir-or-file-in-usr-local /usr/local/hello-2.8/bin/hello
A file in the package is located in /usr/local. It's not permitted for
packages to install files in this directory.
알아요파일 시스템 계층 표준, 이에 따르면:
"/usr/local"의 원래 아이디어는 "/usr" 외에 각 시스템에 별도의 ("로컬") "/usr" 디렉터리를 두는 것이었습니다. 이 디렉터리는 다른 곳에서 설치하는 경우 읽기 전용일 수 있습니다. "/usr"의 구조를 복사합니다. 오늘날 "/usr/local"은 자체 컴파일된 프로그램이나 타사 프로그램을 보관하기에 좋은 장소로 널리 간주됩니다. /usr/local 계층 구조는 소프트웨어를 로컬로 설치할 때 시스템 관리자가 사용합니다. 시스템 소프트웨어가 업데이트되면 덮어쓰지 않도록 해야 합니다. 호스트 그룹 간에 공유할 수 있지만 /usr에는 없는 프로그램 및 데이터에 사용할 수 있습니다. 로컬로 설치된 소프트웨어는 /usr의 소프트웨어를 교체하거나 업그레이드하기 위해 설치하지 않는 한 /usr이 아닌 /usr/local에 있어야 합니다.
사실 /usr/local이러한 이유로 우리는 이러한 표준을 따르고 로컬 소프트웨어를 설치하므로 패키지 관리자를 사용하여 /usr/local. . 로컬 패키지 간의 일관성 외에도. 그러면 rpmlint파일에 오류가 발생하는 이유는 무엇입니까 /usr/local? 이건 포장업체에서 결정하면 안되는 것 아닌가요? 이 오류를 무시하거나 적어도 rpmlint경고를 인쇄할 수 있습니까?
답변1
rpmlint특정 패키징 전략에 따라 RPM을 확인하는 도구입니다. 해당 구성은 일반적으로 배포판별로 다르며 패키지는 특정 배포 정책에 대해 확인됩니다. 당신이 원하는 것이면 자신의 가방을 확인하십시오.
정책이 배포 정책과 다른 경우 rpmlint그에 따라 구성하거나 사용을 피하거나 특정 오류를 무시해야 합니다.
/etc/rpmlint/config또는 (테스트되지 않음)에 추가되면 ~/.config/rpmlint다음이 트릭을 수행해야 합니다.
addFilter("E: dir-or-file-in-usr-local")
원천:
답변2
당신은 표준을 따르지 않습니다. /usr/local로컬로 컴파일된 파일, 즉 로컬 컴퓨터에 빌드된 파일을 포함하도록 의도되었습니다.
패키지를 만들 때 목표는 패키지를 다른 컴퓨터에 배포하는 것입니다.
한 시스템에 패키지를 설치한 다음 동일한 시스템의 소스에서 동일한 소프트웨어를 빌드하는 경우 두 대상이 모두 충돌하는 것을 피하려고 합니다 /usr/local.rpmlint
귀하의 경우에는 /opt/hello2.8.