설명하자면, 저는 우리 회사의 일부 제품을 32비트에서 64비트로 업데이트하는 업무를 담당하고 있습니다.
결국 우리는 64비트 커널 + 32비트 애플리케이션 + 일부 64비트 애플리케이션을 갖게 됩니다. 이 경우 우리는 주로 종속성인 일부 rpm의 32비트 및 64비트 버전이 필요하다고 추론했지만 종속성을 사용하기 시작한 후에는 상황이 약간 나빠졌습니다.
64비트인 Program1이라는 프로그램 하나만 있고 시스템의 나머지 부분은 32비트라고 가정해 보겠습니다. 이 프로그램 1에는 libgcc가 필요합니다. 시스템에서 작업을 수행하기 전에 실제 libgcc 버전을 쿼리합니다.
$>rpm -qa --queryformat '%{NAME}.%{ARCH}\n' | grep libgcc
응답은 다음과 같습니다.
$>libgcc.i386
나는 64비트 libgcc rpm을 설치하러 갔다:
$>rpm -ivh --force --ignorearch libgcc-4.3.2-7.x86_64
하지만 지금은 쿼리 한 후에
$>rpm -qa --queryformat '%{NAME}.%{ARCH}\n' | grep libgcc
2개도 아니고 1개만 받았어요
$>libgcc.x86_64
파일을 확인하면 라이브러리와 프로그램이 예상대로 실행되므로 두 버전 모두에서 공통 인프라를 업데이트하기 전까지는 문제가 없을 것입니다.
이제 commonlibraries.i386.rpm 및 commonlibraries.x86_64.rpm과 같은 새로운 공통 패키지가 있다고 상상해 보십시오.
commonlibraries.i386을 업그레이드하려면 libgcc.i386이 필요하며 x86_64를 업데이트한 후 볼 수 있듯이 아키텍처가 하나만 보고되므로 업그레이드 프로세스가 실패합니다.
흥미롭게도 내 워크스테이션에서는 두 버전을 모두 얻을 수 있습니다.
$ rpm -qa --queryformat '%{NAME}.%{ARCH}\n' | grep libgcc
libgcc.x86_64
libgcc.i686
그러나 우리 제품에서는 여러 아키텍처에 동일한 패키지를 사용하는 것이 불가능해 보입니다(이는 libgcc와 같은 일부 패키지에서는 발생하지만 kerberos5-libraries와 같은 다른 패키지에서는 발생하지 않습니다). 과거에 이 문제를 겪은 마스터가 있었습니까?
나는 이것을 읽었다https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=380441rpm -e --justbd --nodeps PackageName을 실행하고 나중에 rpm을 설치하지만... 작동하지 않습니다.
답변1
결국 우리는 64비트로 전환했습니다. 이 문제는 실제 32~64비트 문제라기보다는 이전 배포판의 패키징 문제처럼 보입니다.
libgcc를 강제하지 않고 설치하려고 하면 post_libgcc_upgrade와 같은 %post 매크로 섹션의 일부 바이너리와 충돌합니다. 따라서 32-64비트 충돌 rpm 패키지마다 32비트 패키지가 "손실"됩니다.
결국 나는 rpm 패키지와 해당 스크립트 세트에서 전체 종속성을 가져와 충돌하는 파일에 대해 다른 이름을 가진 자체 rpm 패키지를 만들고 이에 따라 스크립트를 수정했습니다. 모든 정보를 수집하고 제대로 테스트하는 데 며칠이 걸렸지만 그만한 가치가 있었습니다.
어쨌든, 이것이 누군가에게 도움이 될 수 있기 때문에 제가 채택한 솔루션을 게시하게 되었습니다.