rpm과 debian 패키지를 모두 지원할 수있는 Linux 배포판을 이론적으로 구축 할 수 있는지 궁금합니다.

둘 다를 지원하는 배포판이 있습니까?

그리고 가능하지 않은 경우에도 가능합니까?

베드락 리눅스가 이것을한다. 내가 이것을했다거나 좋은 생각이라고 말하지는 않지만,되고 있습니다.

나는 기본적으로 두 가지를 모두 지원하는 배포판이 있다고 생각하지 않았지만 Bedrock Linux ( 정보에 대한 iMalinowski 덕분 에) 개발 중 하나가 있음이 밝혀졌습니다 . 다른 배포판에서는 변환 도구를 사용 하여 한 형식에서 다른 형식 으로 변환 할 수 있습니다 . 충분한 시간과 에너지가 주어지면 소프트웨어 기반의 모든 것이 가능하므로 그러한 배포판을 구축하는 것이 가능할 것입니다 (그러나 패키지 의 기능 과 패키지 의 차이점은 상당히 어렵습니다).alien.deb.rpm

당신이 다음 (잘 어디서나 제공 어디에서 패키지를 설치할 수 있기 때문에이 모든 아마, 두 패키지 포맷을 지원하는 생활 간단하게 할 것이라는 생각에서 비롯된 .deb또는 .rpm). 철학적으로는 결함이 있습니다. 배포판은 일관된 패키지 세트입니다. 해당 배포를위한 소프트웨어를 제공하려면 패키지 형식 (및 더 중요한 메타 데이터) 사용을 포함하여 구체적으로 대상을 지정해야합니다. 기본적으로 여러 패키지 형식을 지원할 필요는 없습니다.

(데비안 세계에서는 패키지 명명법이 균질하고 대부분의 배포판이 상속 트리에 적합하기 때문에 패키지는 주요 대상이 아닌 변형에서 작동 할 수 있습니다. RPM 세계에서는 그렇지 않습니다. 일치하는 것은 나쁜 생각입니다.)

배포판을 다른 배포판과 혼합하지 않고 배포판의 규칙과 생태계를 고수하면서 원하는 시스템을 구축 할 수있는 기반으로 고려해야합니다. 믹싱 및 매칭을 지원하려면 (또는 여러 배포 환경을 제공하기 위해) Steam 런타임, Flatpak 등과 같은 고급 추상화가 필요합니다.

아니요, 그런 괴물을 지어서는 안됩니다. 예를 들어, 운영 체제에서 응용 프로그램을 실행하는 데 필요한 모든 것을 포함하는 MacOS 응용 프로그램 번들과 달리 RPM 및 .deb 패키지는 거의 항상 공유 라이브러리와 같은 다른 패키지에 의존합니다. Linux 패키지는 존재해야하는 다른 패키지를 나열하며 패키지 관리자는 이러한 요구 사항을 시행하는 데 도움이됩니다. 또한 Linux 배포판은 작업 수행 방식이 다릅니다 (예 : /etc/network/interfaces.dvs. /etc/sysconfig/network-scripts).

동일한 패키지 형식 제품군 내에서 임의의 리포지토리의 패키지를 혼합해서는 안됩니다. 즉, CentOS 시스템에 SuSE 패키지를 설치하는 데 둘 다 RPM을 사용하더라도 문제가 발생합니다. 내가 무엇을하고 있는지 정확히 알지 못하면 동일한 OS의 다른 버전 (예 : 16.04 시스템의 Ubuntu 14.04 패키지) 용 패키지도 설치하지 않을 것입니다.

따라서 동일한 시스템에서 RPM과 .deb를 모두 지원하는 것은 의문의 여지가 없습니다. 절박한 상황에서는을 사용하여 특정 패키지를 변환 할 수 alien있지만 이러한 해킹으로 인해 발생할 수있는 문제를 해결하기 위해 많은 노력을 기울여야합니다.

글쎄, alien( man page )가 있으며 rpm, deb등을 변환 할 수는 있지만 실제 문제는 종속성 (소프트웨어의 다른 패키지 이름)과 구성 파일의 위치를 ​​처리하는 것으로 가정합니다.

물론 두 가지 유형의 패키지가 배포판 자체에서 나올 수 있음을 의미한다면 해결 될 수는 있지만 누구나 그렇게 할 수있는 이유는 무엇입니까? (그리고 여전히 모든 것을 하나 또는 다른 것으로 변환해야합니다 , 나는 dpkg데이터베이스를 읽는 방법을 모른다고 생각하기 때문에 rpm그 반대도 마찬가지입니다.)

예, 가능하지만 배포판을 망칩니다.

패키지는 단순한 형식이 아니라 한 형식에서 다른 형식으로 쉽게 이식 할 수 있습니다.

참고 : 패키지 설치 도구는 모든 패키지, 버전, 종속성, 구성 파일, 사전 및 사후 설치 스크립트 (한 패키지를 다른 패키지에서 다른 패키지로 교체하는 경우)의 중앙 목록을 갖기를 원하므로 이식해야합니다. 설치 제거 스크립트 (이전 형식)는 새 패키지 시스템에서 실행됩니다.

그러나 배포 및 패키지는 패키지 형식 그 이상입니다. 예 : 데비안 : 파일을 올바른 위치에 배치하고, 매뉴얼 페이지를 제공하고, 일반적인 데몬 (deamonizing) 스크립트를 원하며, 프로그램이 많은 아키텍처, 다양한 그래픽 환경에서 실행되어 사용자가 찾을 수 있기를 원합니다. 새로운 패키지와 패키지에 대해서도 잘 알고 있습니다.

데비안에서는 소스를 통해 사용자가 패키지를 쉽게 빌드 할 수 있기 때문에 중요한 패키지를 사용자 정의 할 수 있습니다. 이를 위해서는 대부분의 업스트림 작성자가 제공 할 수없는 많은 인프라가 필요합니다 (다양한 아키텍처에 대한 자동 빌드 및 테스트, 때때로 수행). 또한 데비안 고유의 라이센스 요구 사항이므로 모든 패키지를 확인하지 않고도 패키지 또는 배포를보다 쉽게 ​​포크 할 수 있습니다.

결국, 배포는 패키지뿐만 아니라 일관성있는 패키지에 의해 이루어집니다.

예. 대부분의 .deb 기반 배포판은 이미 그렇게하지만 ...

데비안과 관련 제품군에는 최소한 alienRPM 패키지를 설치할 수있는 소프트웨어가 있습니다.

형식에 관계없이 외부 패키지를 설치할 때 배포판과 함께 작동하도록 설계되지 않은 패키지를 혼합 할 때 동일한 문제가 발생합니다. DEB 기반 시스템에 RPM을 설치하는 경우 RPM이 시스템과 호환되어야합니다. RPM 기반 시스템에 RPM 패키지를 설치하는 것처럼 보이지만 그렇지 않습니다. 당신은 그것을 할 수 있지만 아마 원하지 않을 것입니다.

예, 아니오 deb와 rpm은 형식입니다. 두 형식을 모두 지원할 수 있지만 의미는 없습니다. 패키지는 일반적으로 배포판, 특히 서로 기반이 아닌 배포판 사이에서 비교할 수 없습니다.

모든 배포에 동일한 버전 요구 사항이있는 경우 모든 배포는 패키지 선택입니다. 패키지를 나열하여 모든 배포를 설치할 수 있습니다.

그러나 배포판은 지원할 수있는 소프트웨어를 제공해야합니다. 응용 프로그램이 작동하는 라이브러리를 유지 관리하지 않고 다른 것으로 대체 된 라이브러리가 필요한 경우이 충돌을 어떻게 해결합니까? 패키지 관리자가 코드를 이식 할 수 없습니다. 다른 배포판에 의해 선택된 여러 후속 작업이있을 수 있습니다.