후속 조치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 버전인가요? 하지만 일반적으로 이전 버전과 호환되며 이는 상당히 가능합니다. 그렇죠?
내 첫 번째 링크의 답변을 인용하면 다음과 같습니다.
상호 호환성은 실제로 보장되거나 암시되지 않습니다. 문제가 발생하면 데비안이나 우분투 커뮤니티로부터 많은 동정을 기대하지 마세요. 이 경우 기본적으로 당신은 스스로입니다. 당신이 그것에 대해 편안함을 느끼는 한, 자유롭게 시도해 보십시오.
그래서 기본적으로 나는 이 관행에 대한 경고를 어디에서나 볼 수 있지만 아무도 더 이상의 기술적인 설명을 제공하지 않습니다. 누구든지 이 작업의 위험, 잠재적인 기술 문제를 나열할 수 있습니까?
다른 소스(예: Debian 또는 Ubuntu)의 패키지를 혼합하거나 동일한 배포판이지만 다른 버전의 패키지를 혼합하고 싶거나 필요한 경우(종속성이 문제가 아닌 경우) 이 답변은 가장 안전한 접근 방식을 선택하는 데 도움이 될 것입니다. PPA 나는 데비안, 즉 내가 현재 사용하고 있는 데비안 Bullseye에 결코 나타나지 않을 것이라고 확신합니다.
답변1
바이너리와 패키지 비호환성은 서로 다르므로 별도로 설명해야 합니다.
바이너리 비호환성
이는 일반적으로 사람들이 툴체인 차이점 등에 관해 이야기할 때 언급됩니다.도구 체인커널과 마찬가지로 툴체인은 개발자가 이전 버전과의 호환성을 유지하는 데 가장 주의해야 하는 영역 중 하나이기 때문에 비호환성 자체가 특이한 것입니다. 따라서 과거에 빌드된 바이너리는 해당 바이너리가 실행되는 한 계속 실행되어야 합니다.바이너리종속성은 계속해서 사용 가능하며 이는 필요한 라이브러리를 유지하는 데 달려 있습니다.
문제는 상위 호환성에 있습니다. "미래" 빌드 바이너리는 실행이 보장되지 않습니다. 이는 일반적으로 C 라이브러리에서 누락된 기호로 표시됩니다(이는 C 라이브러리 개발자가 호환성을 유지하기 위해 세심한 주의를 기울였기 때문에 감지된 것입니다). C 라이브러리는 많이 변경되지 않는다고 생각할 수 있으므로 다른 C 라이브러리를 사용하여 프로그램을 빌드하면 필요한 기호가 변경되어서는 안 되며 호환성을 유지해야 합니다. 그렇지 않습니다. 함수는 C 라이브러리가 유지하는 이전 버전과 호환되지 않는 방식으로 주기적으로 변경됩니다.뒤로호환성은 적절한 버전 기호와 함께 이전 인터페이스와 호환되는 기능 버전을 계속 제공함으로써 달성됩니다. 예를 들어, GNU C 라이브러리 버전 2.33에서는 패밀리 stat( fstat// lstat등 ) stat와 같이 일반적으로 사용되는 기능을 호환되지 않게 변경했습니다 . 이러한 기능에 대한 2.33 기본 설정으로 빌드된 프로그램을 실행하려면 C 라이브러리 버전 2.33이 필요합니다.
툴체인 관련 라이브러리 및 C 라이브러리는 이러한 비호환성이 라이브러리 기호 변경 또는 이름 변경으로 나타나 결국 패키지 종속성(패키지 소프트웨어의 경우)으로 인코딩되거나 동적 링커(개별 바이너리 파일의 경우)에 포착되는 방식으로 유지됩니다. ).
C 라이브러리만큼 세심하게 관리되지 않는 라이브러리에서는 이러한 비호환성이 즉시 나타나지 않고 잘못된 조합을 테스트할 때만 나타납니다(그리고 심지어 그런 경우에도 일부 경우에만 나타납니다). Distro 개발자는 일반적으로 자신이 개발 중인 배포판의 컨텍스트에서만 패키지를 테스트하므로 Ubuntu 20.04용으로 빌드한 패키지가 Debian 10에 올바르게 설치되는지 알 수 없지만 6월 오전 1시(CEST)에 설치하면 알 수 없습니다. 2에서 21 사이에 사용하면 애완용 다람쥐가 죽을 것입니다.
이것은 좋은 결과로 이어집니다 ...
패키지 비호환성
의식적이든 아니든 패키지는 진공 상태에서 구축되는 경우가 거의 없으며 배포판의 일부입니다. 이는 패키지 소스(더 일반적으로는 프로젝트 소스) 자체부터 시작됩니다. 프로젝트와 패키지는 개발자의 시스템에 구축되며 큰 노력 없이는 해당 종속성이 정확하게 코딩되지 않을 수 있습니다.
이는 문서에 설명된 종속성뿐만 아니라 바이너리 패키지 종속성에도 영향을 미칩니다. 프로젝트 유지관리자는 자신의 프로젝트가 현재 구성에서만 작동한다는 사실을 깨닫지 못할 수도 있습니다. 예를 들어 systemd 버전 239가 시스템을 특정 방식으로 설정하기 시작했기 때문입니다. 패키지 관리자는 자신이 작업 중인 배포판에 이미 시스템화된 239 버전이 있는 경우 이를 인식하지 못할 수도 있습니다(배포판 관리자는 일반적으로 미래에 거주하며,즉다음 버전에서 개발될 예정입니다.)
이들 모두할 수 있다테스트에 걸렸지만 일단 다양한 배포판과 버전의 바이너리를 혼합하고 일치시키기 시작하면 패키지와 바이너리 버전의 정확한 조합을 가장 먼저 테스트할 수 있습니다. 그리고저것이것이 권장되지 않는 이유입니다. 대부분의 사용자는 시스템을 테스트하기보다는 사용하기를 원합니다.
물론 이것은 귀하의 경험과 일치하며 대부분의 경우 모든 것이 잘 작동합니다. 이는 또한 편견에 대한 인식에 기여합니다. 사람들은 시스템 Z의 distro Y에서 패키지 X를 설치하는 방법을 설명하는 게시물(또는 Stack Exchange 환경의 질문)을 작성하지 않는 경향이 있지만 작동합니다. 그래서 이 공간에서 보는 대부분은 장면이에요.아니요작업을 수행하거나 설정이 복잡해지거나 다른 것을 깨뜨릴 수도 있습니다. 사람들이 명시적으로 권장하는 작업을 수행하여 발생한 일회성 문제를 해결하는 데 시간을 들이고 싶지 않다는 것은 이해할 수 있습니다.반대하다.