라이브러리 업그레이드를위한 spec 파일의 올바른 정의

Question

배포를 담당하는 라이브러리 패키지가 있습니다. 얼마 전에, 빌드 시스템은 가정에서 구운 Makefile에서 GNU Autotools로 전환되었습니다. 따라서 libtool을 사용하여 여러 설치된 버전의 라이브러리를 쉽게 관리 할 수 ​​있습니다. 배포를 위해 RPM으로 전환 한 후, 업그레이드 할 때 이전 버전을 완전히 제거하지 않도록 spec 파일을 "의사 (doctor)"할 수있는 방법을 알고 싶습니다. 물론

[afalanga@afalanga4 libtest]$ ls /usr/lib64/libaby* 
/usr/lib64/libabyss.a /usr/lib64/libabyss.so /usr/lib64/libabyss.so.0.0.1 
/usr/lib64/libabyss.la /usr/lib64/libabyss.so.0 

하는 libtool- 같이

예를 들어, 더미 라이브러리 프로젝트의 버전 1.0.0을 설치 한 후 나는 sudo yum localupdate .... 후 나는 다음이, 그리고

[afalanga@afalanga4 libtest]$ ls /usr/lib64/libaby* 
/usr/lib64/libabyss.a /usr/lib64/libabyss.so /usr/lib64/libabyss.so.0.0.0 
/usr/lib64/libabyss.la /usr/lib64/libabyss.so.0 

이 제작 된 라이브러리의 유일한 "실제"파일은 libabyss.a, libabyss.la and libabyss.so.0.0.1입니다. libabyss.so.0.0.1이 설치된 후 libabyss.so.0.0.0이 유지되도록하려면 spec 파일에서 수행해야하는 작업은 무엇입니까? 심볼릭 링크가 이에 따라 처리됩니다.

Answer 1

라이브러리를로드하는 데 사용되는 심볼릭 링크가 ldconfig에 의해 관리되고 라이브러리의 SONAME을 기반으로하기 때문에 수행하려는 작업을 실제로 수행 할 방법이 없습니다 (my post on the topic 참조). .so.0.0.1 아무 것도 사용하지 않을 것입니다.

다른 ABI 일 수 있기 때문에 호환성을 원하면 versioning is done correctly을 확인해야하지만 읽을 수있는 것은 아닙니다.

그 외에도 RPM에 이러한 경우 여러 라이브러리 버전을 유지하는 특별한 경우가 있는지 잘 모르겠다. uld는 실제로 그러한 일이 발생할 필요가 없습니다.

Answer 2

음, 실제로 작동하지 않습니다. 라이브러리 버전 관리에 대한 일반적인 GNU 빌드 시스템 가정은 -version-info에 대해 설정 한 값인 computing에 described here 스키마를 사용하는 것입니다. 디에고 (Diego)가 말했듯이 RPM을 사용하여 오래된 lib 디렉토리를 남겨 두도록 설득했다하더라도 (IIRC, 나는 rpm이 실행될 때 그렇게 할 수 있다고 생각합니다.), 이전 버전은 이전과 동일한 SONAME을 공유합니다 (예 : libabyss.so.0). 라이브러리 설치/업그레이드에서 ldconfig을 실행하면 고아가됩니다.

보통 사람들은 libtool -release 플래그를 사용하거나 libabyss0, libabyss1 등과 같은 RPM 패키지의 이름을 바꾸어 SONAME 버전 번호를 미리 지정합니다.