(Linux 배포판에서는 비교적 새로운 버전입니다)
Redhat/CentOS에 .deb 패키지(apt 또는 dpkg 사용)를 설치하지 못하게 하는 이유는 무엇입니까? 아니면 Debian/Ubuntu의 .rpm 패키지인가요?
내가 이해한 바로는 Debian/Ubuntu 기반 시스템은 패키지 관리자로 apt 및 dpkg(.deb 파일)를 사용하는 반면 RedHat 기반 시스템은 .rpm을 사용합니다. 그러나 이것은 단지 관례/선호에 불과합니까, 아니면 차이점이 더 심오합니까?
RedHat/CentOs에 .deb 패키지를 설치하는 방법을 설명하는 인터넷의 모든 페이지에서는전환하다먼저 .rpm 파일로 이동합니다.
그러나 근본적으로 누군가가 RedHat/CentOS에 dpkg 또는 apt를 설치한 다음 이를 사용하여 .deb 파일을 직접 설치하는 것을 금지하는 것은 무엇입니까?
내 이해는.deb와 .rpm은 정말 아름다운 타르볼입니다!기본 바이너리는 RedHat/CentOs 및 Debian에서 실행될 수 있어야 합니다. 그렇죠? 내 말은, 두 배포판 모두에서 동일한 실행 파일을 수동으로 갖고 있다면 두 배포판 모두에서 실행되어야 한다는 뜻입니까? (그렇지 않다면 .rpm과 .deb 사이의 비호환성을 확실히 이해하겠습니다)
추가 질문: 누군가가 Linux 세계에 바이너리를 배포하려는 경우 바이너리를 지원하고 패키징해야 하는 시스템 수는 몇 개입니까? (물론 그는 원하는 만큼 가져갈 수 있지만 무슨 말인지 아시겠죠)
이전에 아무도 이 질문을 한 적이 없는 것 같아서 이것이 의심스럽고 약간 실망스럽습니다. 나는 아마도 이것에 비교적 새로운 기본적인 것을 놓치고있을 것입니다.
이 문제에 대한 모든 문서도 환영합니다.
답변1
일반적으로 동일한 시스템에서 서로 다른 패키지 관리자를 혼합하는 것을 금지하는 것은 없습니다(배포판에서는 외부 패키지를 설치할 수 없도록 패키지된 외부 패키지 관리자를 수정하는 경우가 많지만). 일반적으로 수행 중인 작업을 실제로 알지 않는 한 그렇지 않으면 수행할 작업 이것은 매우 불쾌할 것입니다. 이것이 아마도 매우 나쁜 생각인 대부분의 이유는 다음과 같습니다.
- 패키지 관리자는 파일 시스템의 개념을 관리하고 자체 데이터베이스에서 이를 추적하는 일을 담당합니다. 서로 다른 패키지 관리자를 혼합한다는 것은 각 패키지 관리자가 다른 패키지 관리자를 알지 못한 채 경로 이름을 추적하므로 f.ex를 기꺼이 무시한다는 의미입니다. 버전이 지정된 종속성 요구 사항과 파일이 충돌하여 다른 패키지 관리자의 경로 이름을 덮어쓰게 되어 예상치 못한 숨겨진 버전 종속성이 충족되지 않게 됩니다.
- 패킷 형식은 일반적으로 어느 정도 기능적 패리티를 가져야 하지만 여전히 의미론적으로 상당한 차이가 있을 수 있습니다. 그것들은 단순한 컨테이너가 아닙니다.파일 시스템 로드, 종속성 정보, 관리자 스크립트 또는 설정, 복구 또는 정리 작업을 수행하고 작업을 자동으로 트리거하는 스크립틀릿을 포함한 패키지 메타데이터도 포함됩니다.
- 또한 배포판 간의 큰 차이(동일한 패키지 관리자를 사용하는 동일한 제품군 내에서도)는 전략과 사물이 함께 통합되는 방식(예: 파일 시스템 등록 콘텐츠에 항목이 배치되는 위치, 위치 및 방법 등)에서 비롯됩니다. 많은 경우 배포별 또는 패키지 관리자별 인터페이스(예
dpkg-divert:), 기본 빌드 플래그, 패키징 세분성(업스트림 프로젝트가 배포 패키지로 분할되는 방법 및 위치), 활성화할 업스트림 기능, 활성화 방법 및 차이 정도를 사용합니다. from upstream(있는 경우)이 활성화됩니다. 예를 들어 일부 배포판에는 0 발산 정책이 있는 반면 다른 배포판에서는 업스트림이 ABI를 위반하는 경우 공유 라이브러리 SONAME을 사용하지만 이에 대한 수정 사항은 릴리스되지 않습니다. - 릴리스 A의 이름이 릴리스 B의 업스트림 프로젝트와 동일하다는 보장은 없으며 네임스페이스는 버전 공간이 아니라 독립적입니다. 보편적으로 쉽게 표현할 수 없는 상충되는 네임스페이스 충돌 업스트림이 많이 있었고 지금도 있어 왔습니다. 따라서 릴리스 경계를 넘을 때는 종속성 메타데이터를 사용하는 것조차 의미가 없을 수 있습니다. 버전 공간과 관련하여 배포판은 다른 시점이나 다른 이유로 버전 시대(개념이 있는 경우)와 같은 기능을 사용하거나
1.0really2.0회피 와 같은 버전 복구 트릭을 사용합니다.불필요한 에포크 사용. - 위의 점 및 배포판 불일치와 관련하여 일부 배포판은 업스트림 패치를 하기 때문에 프로그램이나 공유 라이브러리 또는 기타 인터페이스가 다른 기본 빌드 플래그와 같은 것은 말할 것도 없고 API 또는 ABI와 호환된다는 보장이 없습니다.
요약하자면, 동일한 시스템에서 패키지 관리자를 혼합하여 사용할 수 있습니까? 확실하다면 f.ex. 완전히 독립적인 파일 시스템 계층 구조를 관리한 다음가능한자신의 chroot나 f.ex를 통해 작업합니다. 관리자/및 기타/옵션. 그렇지 않은 경우 가장 좋은 방법은 패키지 형식을 변환하고(예제에서 언급한 대로 alien) 이를 사용하여 이러한 외부 패키지를 기본 패키지 시스템으로 가져오는 것입니다. 그러나 이 방법도 성공할 것이라고 보장할 수는 없습니다. 하지만 그 외에는 강력히 반대합니다. 나는 Ubuntu 패키지를 Debian 시스템에 설치하지 않는 것을 권장합니다(전자는 후자의 파생물입니다). 왜냐하면 dpkg저는 Ubuntu 패키지를 거부하고 예를 들어 이와 유사한 새로운 강제 옵션이 필요하기를 원하기 때문입니다 --force-vendor.
업스트림이 이러한 다양성을 어떻게 처리해야 하는지에 대한 질문에 대해 내가 선호하고 권장하는 솔루션은 프로젝트가 다양한 배포판으로 쉽게 패키징될 수 있도록 업스트림 모범 사례를 따르는 것입니다(f.ex.https://wiki.debian.org/UpstreamGuide) 그런 다음 참여하거나 배포 패키저가 이러한 문제를 처리하도록 하세요. "범용"으로 간주되는 다양한 컨테이너 형식 중 하나를 사용하는 것이 더 나은 경우가 아니라면 물론 이미 여러 가지 경쟁 형식(예: snap, flatpak, appimage등)이 있으므로 다시 결정해야 합니다. 내 생각에 업스트림은 일반적으로 패키징을 처리하지 않거나 패키징에만 집중하기 위해 몇 가지 주류 형식을 선택합니다(예: .deb및 .rpm).