후속 조치로이것질문, 이러한 디버깅 기능에 관심이 없으면 어떻게 해야 합니까? 단순히 이러한 빌드 ID 파일(디버그 정보 패키지?)의 설치를 방지하는 방법은 무엇입니까? 궁극적으로 나는 (적어도 가까운 시일 내에) 클라이언트 측 디버깅 지원에 관심이 없습니다. 반면, 동일한 시스템에 서로 다른 클라이언트 Redhat 제품(패키지)을 설치할 때 알려진 "빌드 ID 폴더 충돌"을 극복해야 합니다. 이것이 어떻게 달성될 수 있습니까?
나읽다rpm을 사용하여 설치할 때 --excludepath=/usr/lib/.build-id/를 사용하는 것이 깔끔한 해결책입니다. 그럴 것 같습니다. "디버깅 기능"을 잃는 것 외에 다른 단점이 있습니까?
--excludepath실제로는 도움이 되지 않습니다. 그러나%define _build_id_links none여기에 제안된 대로 사용했습니다. 간단히 말해서 디버깅 지원에 관심이 없다면 얼마나 큰 문제일까요? 여기에 링크 설명을 입력하세요
답변1
--excludepath=/usr/lib/.build-id예, 깨끗한 솔루션입니다. 내가 아는 한, "디버깅 능력"을 잃어가고 있다예rpm --verify유일한 단점은 이 옵션으로 건너뛴 파일이 실패를 일으키지 않는다는 것입니다 . 그러나 "디버깅 가능성"을 잃으면 유용한 출력을 얻는 능력이 제한되는 것 이상입니다gdb. 예를 들어 오류 보고 도구는 의미 있는 스택 추적을 제공하려는 경우 수동 개입이 필요합니다.%define _build_id_links none패키지를 작성 중이고 패키지와 함께 디버그 정보를 보내고 싶지 않은 경우에도 괜찮습니다.
귀하의 두 가지 질문은 패키지의 다양한 측면을 다루고 있습니다. rpm --excludepath패키지를 포장할 때 발생하는 상황에 영향을 미칩니다.설치됨, 이는 %define _build_id_links패키지가 언제인지에 영향을 미칩니다.세워짐. 패키지를 만드는 데 관심이 있다면 이것이 도움이 되지 않는 rpm --excludepath것이 정상입니다 . 그 시점에서는 관련이 없기 때문입니다.
또한 제안한 대로당신이 링크한 버그 리포트, 빌드 ID 충돌은 패키징 문제를 나타냅니다. 패키지를 빌드하는 경우 패키지의 문제를 수정하는 것이 아니라 문제를 수정해야 합니다.