후속 조치Ubuntu LTS 바이너리는 Debian과 호환됩니까?
나는 Ubuntu와 Debian 바이너리 패키지가 종종 호환되지 않는다는 것을 알고 있습니다. 나는 다른 소스의 패키지를 혼합하는 것이 일반적으로 나쁜 생각이라는 것을 알고 있으며 사람들은 항상 그렇게 하는 것에 대해 경고를 받습니다. 그럼 순수한 기술적인 논의로 넘어가겠습니다.
물론 종속성이 문제가 아닌데, 서로 다른 소스의 패키지에 대한 비호환성은 정확히 어떻게 발생합니까?
------ 분리, 자세한 내용은 아래 ------
좋다그 말:
바이너리 호환성에 대해 (https://wiki.ubuntu.com/MarkShuttleworth#What_about_binary_compatibility_between_distributions.3F): 데비안 패키지는 다양한 툴체인 버전으로 구축되었을 가능성이 높으므로 문제가 발생할 수 있습니다.
다른 툴체인 버전이 문제를 일으키는 이유는 무엇입니까? 좋다
- 나는 Debian sid에서 Debian stable로 최소 패키지 세트를 가져오는 방법을 알고 있으며 항상 그렇게 해왔습니다.
- 나는 이전 버전의 Ubuntu/Debian에서 최신 버전으로 패키지를 가지고 다니곤 했습니다.
- Ubuntu/Debian의 단일 실행 파일을 RedHat 또는 FreeBSD 등 다른 배포판으로 복사합니다.
그리고절대전에 문제가 있었어요. 그렇다면 사람들이 말하는 문제의 원인은 정확히 무엇입니까?
gcc인가요 아니면 커널 버전인가요? 해당 릴리스를 사용하는 동안 계속 업그레이드되기 때문에 나에게는 가능성이 낮습니다.
그럼 glibc 버전인가요? 하지만 일반적으로 이전 버전과 호환될 것이며 아마도 가장 그럴 것입니다. 그렇죠?
내 첫 번째 링크의 답변을 인용하면 다음과 같습니다.
실제로 상호 호환성을 보장하거나 암시하는 것은 없습니다. 문제가 발생하더라도 데비안이나 우분투 커뮤니티에서 많은 동정을 받을 것이라고 기대하지 마십시오. 그 경우 당신은 대부분 혼자입니다. 괜찮다면 자유롭게 시도해 보세요.
따라서 기본적으로 나는 모든 곳에서 이러한 관행에 대한 경고를 보았지만 아무도 더 이상의 기술적인 설명을 제공하지 않았습니다. 누구든지 그렇게 할 때 발생할 수 있는 위험, 잠재적인 기술적 문제를 나열할 수 있습니까?
이 대답은 데비안이나 우분투와 같은 다른 소스의 패키지를 혼합하거나 동일한 배포판이지만 다른 릴리스에서 패키지를 혼합하고 싶거나 필요한 경우(종속성이 문제가 아닌 경우) 가장 안전한 접근 방식을 선택하는 데 도움이 될 것입니다. 내가 확실히 알고 있는 PPA는 결코 데비안, 내가 현재 사용하고 있는 데비안 불스아이에 들어가지 않을 것입니다.
답변1
바이너리와 패키지 비호환성은 다르며 별도로 설명할 가치가 있습니다.
바이너리 비호환성
이것은 일반적으로 사람들이 툴체인 차이점 등에 대해 이야기할 때 언급되는 것입니다.툴체인비호환성 자체는 특이한데, 툴체인은 커널과 함께 개발자가 이전 버전과의 호환성을 유지하는 데 가장 주의를 기울이는 영역 중 하나이기 때문입니다. 결과적으로 과거에 빌드된 바이너리는 계속 실행되어야 합니다.바이너리종속성을 계속 사용할 수 있습니다. 이는 필요한 라이브러리를 유지하는 것으로 요약됩니다.
문제가 발생하는 부분은 상위 버전과의 호환성입니다. "미래에" 빌드된 바이너리의 실행이 보장될 수 없습니다. 이는 일반적으로 C 라이브러리에서 누락된 기호로 표시됩니다(C 라이브러리 개발자가 호환성을 유지하기 위해 세심한 주의를 기울이기 때문에 정확하게 감지됩니다). C 라이브러리는 많이 변경되지 않는다고 생각할 수 있으므로 다른 C 라이브러리를 사용하여 프로그램을 빌드하면 필요한 기호가 변경되어서는 안 되며 호환성을 유지해야 합니다. 그렇지 않으며 기능은 이전 버전과 호환되지 않는 방식으로 정기적으로 변경됩니다. C 라이브러리는 보존합니다뒤로적절한 버전 기호를 사용하여 이전 인터페이스와 호환되는 기능 버전을 계속 제공함으로써 호환성을 보장합니다. 예를 들어, GNU C 라이브러리 버전 2.33에는 패밀리 stat( fstat/ lstat/ stat등)와 같은 일반적인 기능에 대해 호환되지 않는 변경 사항이 있습니다. 2.33의 기본 설정으로 구축된 프로그램을 실행하려면 C 라이브러리 버전 2.33이 필요합니다.
툴체인 관련 라이브러리 및 C 라이브러리는 이러한 비호환성이 라이브러리 기호 변경 또는 soname 변경으로 표시되어 패키지 종속성(패키지 소프트웨어의 경우)으로 인코딩되거나 동적 링커에 의해 포착되는 방식으로 유지됩니다. (별도의 바이너리의 경우)
C 라이브러리만큼 세심하게 관리되지 않는 라이브러리에서는 이러한 비호환성은 즉시 나타나지 않고 잘못된 조합이 테스트된 경우에만 나타납니다(심지어 특정 상황에서만). 배포 개발자는 일반적으로 개발 중인 릴리스의 맥락에서만 패키지를 테스트하므로 Ubuntu 20.04용으로 구축한 패키지가 Debian 10에 올바르게 설치되지만 6월 CEST 기준 오전 1시에서 오전 2시 사이에 사용하면 애완 다람쥐가 죽는다는 사실을 알지 못합니다. 21.
이것은 좋은 결과로 이어집니다 ...
패키지 비호환성
이것이 의식적으로 이루어지든 아니든, 패키지는 진공 상태에서 구축되는 경우가 거의 없으며 배포 릴리스의 일부입니다. 이는 패키지 소스(더 일반적으로는 프로젝트 소스) 자체에서 시작됩니다. 프로젝트와 패키지는 개발자의 시스템에 구축되며 많은 노력을 기울이지 않으면 종속성을 정확하게 인코딩하지 못할 수 있습니다.
이는 바이너리 패키지 종속성 및 문서에 설명된 종속성으로 흘러갑니다. 프로젝트 관리자는 systemd 버전 239가 특정 방식으로 시스템 설정을 시작했기 때문에 현재 구성의 프로젝트만 작동한다는 사실을 인식하지 못할 수도 있습니다. 패키지 관리자는 자신이 작업 중인 배포판에 이미 systemd 버전 239가 있는 경우 이를 인식하지 못할 수도 있습니다(배포판 관리자는 일반적으로 미래에 살고 있다는 점을 명심하십시오.즉다음 릴리스에서 개발됩니다.)
이 모든 것~할 수 있었다테스트에 걸릴 수 있지만 일단 다양한 배포판과 릴리스의 바이너리를 혼합하고 일치시키기 시작하면 패키지와 바이너리 버전의 정확한 조합을 테스트하는 최초의 사람이 될 가능성이 높습니다. 그리고저것이것이 권장되지 않는 이유입니다. 대부분의 사용자는 시스템을 테스트하기보다는 사용하기를 원합니다.
물론 이는 귀하의 경험에 부합하며 많은 경우 모든 것이 제대로 작동합니다. 이것은 또한 여러분이 인식하는 편견에 기여합니다. 사람들은 Z 시스템에 distro Y에서 패키지 X를 설치한 방법을 설명하는 게시물(또는 Stack Exchange 컨텍스트에서 질문)을 작성하지 않는 경향이 있으며 제대로 작동했습니다. 따라서 이 도메인에서 볼 수 있는 대부분의 콘텐츠는 다음과 같은 시나리오입니다.하지 않았다작업을 수행하거나 설정이 복잡해졌거나 다른 것을 망가뜨렸습니다. 그리고 사람들은 명시적으로 권장된 일을 함으로써 스스로 초래한 일회성 문제를 누군가가 해결하도록 돕는데 시간을 들이는 것을 당연히 꺼립니다.~에 맞서.