개발 패키지가 .so 패키지를 제공하는 이유는 무엇입니까?

배포판 내의 소프트웨어는 일관된 방식으로 기계적으로 연결되어 있으며 발견될 것으로 예상되므로 libavcodec.so.54사전 빌드된 패키지에는 버전이 없는 이름이 필요하지 않습니다.

그러나 소프트웨어를 직접 구축하는 경우 유사한 소프트웨어를 자주 사용하게 되지만 버전이 관리되지 않는다는 -lavcodec사실을 알게 됩니다 . libavcodec.so다시 말하지만, 빌드 스크립트에서는 이러한 이름이 존재할 것으로 예상할 수 있습니다.

릴리스 패키지에는 버전이 지정되지 않은 이름이 필요하지 않으므로 기본적으로 포함되지 않지만, 다른 소프트웨어를 빌드할 때 유용하므로 -devel패키지에 포함됩니다. 다른 배포판에는 설명이 다르며 .so기본 패키지에 링크가 포함되어 있습니다. 둘 다 합리적인 선택입니다.

이를 처리하는 방법은 다양하지만 일반적으로 자동화된 패키지 관리를 사용하지 않는 경우 처리할 필요가 없습니다. 실제로최대자동화된 패키지 관리자가 수행하는 작업 중 하나는 자동화된 패키지 관리로 인해 발생한 문제를 수정하는 것입니다. 이는 패키지 관리자가 가치가 없다는 의미가 아니라, 사실 이후에 필요한 과잉 수정의 추가 가치가 비용이 많이 든다는 의미일 뿐입니다.

패키지 관리 접근 방식을 채택하기로 결정하면 자신이 갇히게 됩니다. rootfs의 제어권을 하나의 모드 또는 다른 모드로 넘겨주고 그 시점부터 그 문제를 받아들여야 합니다. 왜냐하면 그 이후에는 하나의 파일이 다른 파일에 의존할 수 있고 이를 알 수 있는 유일한 방법은 전체 네트워크 열기를 해결하는 것입니다. 바닥이 보일 때까지.

패키지 관리자는 네트워크를 동적 링크 라이브러리 스레드 내부, 스레드 위에 엮습니다. 패키지 관리 솔루션은 동적 연결에 크게 의존하는 경우가 많습니다. 전체 애플리케이션 세트가 동일한 라이브러리를 얻을 수 있으면 패키지 관리자가 버전 제어를 더 쉽게 수행할 수 있습니다. 따라서 패키지 관리자 간의 가장 큰 차이점은 동적 라이브러리 버전 관리를 처리하기 위한 다양한 전략입니다. 특히 다음과 같은 경우에 더욱 그렇습니다.FHS환경은 루트 트리가 실제로 퍼즐의 유일한 다른 주요 변수이기 때문입니다. 당신은 apt다음을 기반으로 이러한 전형적인 것 중 하나를 지적했습니다.개요에스.