deb 대 rpm의 장단점은 무엇입니까?

많은 사람들이 소프트웨어 설치를 apt-get와 rpm -i와 비교하므로 DEB가 더 좋습니다. 그러나 이것은 DEB 파일 형식과 관련이 없습니다. 실제 비교는 dpkg vs rpm 및 aptitude/apt-* vs zypper/yum입니다.

사용자 관점에서 보면 이러한 도구에는 큰 차이가 없습니다. RPM 및 DEB 형식은 모두 아카이브 파일이며 일부 메타 데이터가 첨부되어 있습니다. 둘 다 똑같이 신비 롭고 하드 코딩 된 설치 경로 (yuck!)가 있으며 미묘한 세부 사항 만 다릅니다. dpkg -i와 rpm -i 모두 명령 줄에 지정되어있는 경우를 제외하고는 종속성을 설치하는 방법을 알아낼 방법이 없습니다.

이러한 도구 외에도 apt-... 또는 zypper/yum 형식의 리포지토리 관리가 있습니다. 이 도구는 리포지토리를 다운로드하고 모든 메타 데이터를 추적하며 종속성 다운로드를 자동화합니다. 각 단일 패키지의 최종 설치는 하위 수준 도구로 전달됩니다.

오랫동안 apt-get는 엄청난 양의 메타 데이터를 실제로 빠르게 처리하는 데 탁월했지만 yum은 (는) 시간이 오래 걸립니다. RPM은 또한 다른 배포판에 대해 10 개 이상의 호환되지 않는 패키지를 찾을 수있는 rpmfind와 같은 사이트에서 어려움을 겪었습니다. Apt 모든 패키지가 동일한 소스에서 설치 되었기 때문에 DEB 패키지에 대해이 문제를 완전히 숨겼습니다.

제 생각에는, zypper은 (는) apt와 (과)의 격차를 좁히고 있으며 요즘 RPM 기반 배포판을 사용하는 것을 부끄러워 할 이유가 없습니다. 거대한 호환 가능한 패키지 인덱스를 위해 openSUSE 빌드 서비스와 함께 사용하기가 쉽지 않더라도 좋습니다.

시스템 관리자의 관점에서 나는 주로 패키지 형식이 아닌 dpkg/rpm 도구 세트에서 몇 가지 사소한 차이점을 발견했습니다.

• dpkg-divert를 사용하면 자신의 파일을 패키지에서 가져온 파일로 대체 할 수 있습니다. /usr 또는 /lib에서 파일을 찾고 응답을 위해 /usr/local를 사용하지 않는 프로그램이있는 경우 생명의 은인이 될 수 있습니다. 아이디어가 제안되었지만 rpm으로 채택 할 수없는 한 rpm

• Rpm 기반 시스템을 마지막으로 관리했을 때 (수년 전에는 상황이 개선되었을 수도 있음) rpm은 항상 수정 된 구성 파일을 덮어 쓰고 사용자 지정 내용을 *.rpmsave (IIRC)로 옮깁니다. 이로 인해 시스템을 한 번 이상 부팅 할 수 없습니다. Dpkg는 사용자 지정 내용을 기본값으로 유지하면서 수행 할 작업을 묻습니다.

• Rpm 이진 패키지는 패키지가 아닌 파일에 대한 종속성을 선언 할 수 있으므로 deb 패키지보다 세밀한 제어가 가능합니다.

• Rpm 도구의 버전 N-1이있는 시스템에는 버전 N rpm 패키지를 설치할 수 없습니다. 형식이 자주 변경되지 않는 것을 제외하고는 dpkg에도 적용될 수 있습니다.

• Dpkg 데이터베이스는 텍스트 파일로 구성됩니다. rpm 데이터베이스는 이진입니다. 따라서 dpkg 데이터베이스를 쉽게 조사하고 복구 할 수 있습니다. 반면에 아무 문제가 없으면 rpm이 훨씬 빨라질 수 있습니다 (deb를 설치하려면 수천 개의 작은 파일을 읽어야합니다).

• Deb 패키지는 표준 형식 (ar, tar, gzip)을 사용하여 deb 패키지를 쉽게 검사하고 조정할 수 있습니다. Rpm 패키지는 그다지 친숙하지 않습니다.

RPM :

• '표준화'(deb 사양이 없음)
• 여러 다른 배포판에서 사용하지만 하나의 패키지는 다른 패키지에서 작동하지 않을 수도 있습니다.
• IIRC는 패키지뿐만 아니라 파일에 대한 종속성을 허용합니다

뎁 :

• 인기 증가
• 권장 사항 및 제안 허용 (최신 RPM도 가능)

아마도 가장 중요한 질문은 패키지 형식이 아닌 패키지 관리자 (dpkg 대 yum 대 적성 등)입니다 (둘 다 비교 가능).

여러 응답자가 말했듯이 특정 패키지 형식 이 분명히 우수하지는 않습니다. 기술적으로는 다소 비슷할 수 있습니다. 내 관점에서 많은 차이점과 사람들이 서로 선호하는 이유는 다음과 관련이 있습니다.

• 독창적 인 패키지 디자인의 철학과 대상 독자
• 커뮤니티 규모 및 확장에 따라 리포지토리의 품질과 풍부 성

철학 :

Ubuntu/Debian/Mint/... 세계에서 사용자는 설치된 패키지가 일단 설치되면 "작동"할 것으로 기대합니다. 즉, 설치하는 동안 패키지는 패키지를 실제로 실행하는 데 필요한 모든 것을 처리해야합니다.

• 필수 또는 선택적 크론 작업 설정
• 대안/별칭 설정
• 시작/종료 스크립트 설정
• 필요한 모든 구성 파일을 기본값으로 포함
• 이전 버전의 라이브러리 유지 및 이전 버전과의 호환성을 위해 올바른 버전의 심볼릭 링크를 라이브러리 (.so)에 추가
• 동일한 머신 등에서 다중 아키텍처 (32 및 64 비트) 바이너리를 깨끗하게 지원합니다.

Rpm 세계에서-몇 년 전의 상황이지만, 그 이후 개선되었을 수도 있습니다. 실제로 패키지를 실제로 작동시키기 위해 추가 단계 (예 : chkconfig, cron 작업 활성화)를 실행해야한다는 것을 알았습니다. 이것은 시스템 관리자 나 유닉스에 대해 잘 알고있는 사람들에게는 문제가되지 않지만 초보자 경험을 어렵게 만듭니다. RPM 패키지 형식 자체가이를 방지하는 것이 아니라, 많은 패키지가 사실상 "완전히 완료되지 않은"라는 점에 유의하십시오. 초보자의 관점.

커뮤니티 규모, 참여 및 풍부한 저장소 :

우분투/데비안/민트/... 커뮤니티가 더 넓기 때문에 더 많은 사람들이 소프트웨어 패키징 및 테스트에 참여하고 있습니다. 리포지토리의 풍부함과 품질이 우수하다는 것을 알았습니다. 우분투에서는 소스를 다운로드하여 빌드 할 필요가 거의 없습니다. 집에서 Red Hat에서 Ubuntu로 전환했을 때 일반적인 RHEL 리포지토리에는 ~ 3000 개의 패키지가 있고, 동시에 모든 정식 미러에서 직접 사용할 수있는 ubuntu + universe + multiverse는 ~ 30,000 개의 패키지 (약 10x)가있었습니다. RPM 형식으로 찾은 대부분의 패키지는 패키지 관리자에서 간단한 검색 및 클릭을 통해 쉽게 액세스 할 수 없었습니다. 대체 저장소로 전환하고 rpmfind 서비스 웹 사이트 등을 검색해야했습니다. 대부분의 경우 문제를 해결하기보다는 종속성을 올바르게 업그레이드하거나 업그레이드 할 수없는 항목을 제한하지 않아 설치가 중단되었습니다. Shawn J. Goff가 위에서 설명한 것처럼 "종속성 지옥"현상에 부딪 쳤습니다.

우분투/데비안에서 나는 소스에서 빌드 할 필요가 거의 없다는 것을 알았습니다. 또한 다음으로 인해 :

• 우분투 빠른 (6 개월) 릴리스주기
• 즉시 사용할 수있는 완전히 호환되는 PPA의 존재
• 단일 소스 리포지토리 (모두 Canonical에서 호스팅)는 대체/보완 리포지토리를 검색 할 필요가 없습니다.
• 클릭에서 실행까지 완벽한 사용자 경험

공식 (정식) 개발자가 유지 관리하지 않더라도 이전 버전의 패키지를 타협 할 필요가 없었습니다. 키워드로 편리한 검색을 수행하고 원하는 패키지를 찾아 설치하기 위해 내가 좋아하는 GUI 패키지 관리자를 떠나지 않아도됩니다. 또한 우분투에 데비안 (비정규) 패키지를 몇 번 설치했는데 공식적으로 보장되지는 않았지만 정상적으로 작동했습니다.

이것은 화염 전쟁을 시작하기위한 것이 아니라 단지 몇 년 동안 (일과 집) 두 세계를 동시에 사용한 경험을 공유하는 것입니다.

편견은 패키지 형식이 아니라 RedHat의 저장소에 존재했던 불일치 때문이라고 생각합니다.

RedHat이 배포판 (RHEL, Fedora 및 Fedora Core 이전)으로 돌아 왔을 때 사람들은 때때로 "RPM 지옥"또는 "종속성 지옥"에서 자신을 발견했습니다. 이것은 리포지토리가 상호 배타적 인 종속성 (일반적으로 여러 계층 깊이)이있는 패키지로 끝날 때 발생했습니다. 또는 두 개의 서로 다른 패키지에 두 개의 상호 배타적 인 종속성이있을 때 발생합니다. 이것은 패키지 형식이 아니라 저장소의 상태에 문제가있었습니다. "RPM 지옥"은이 문제로 불타 버린 일부 Linux 사용자 집단에서 RPM 시스템에 열광을 남겼습니다.

데비안 패키지에서 질문을 할 수 있고 설치 프로세스를 차단할 수있는 "철학적"차이점도 있습니다. 이것의 나쁜 점은 응답 할 때까지 일부 패키지가 업그레이드를 차단한다는 것입니다. 이것의 좋은면은 또한 데비안 기반 시스템에서 철학적으로 다른 점으로, 패키지가 설치 될 때 패키지가 구성되고 (항상 원하는대로는 아님) 실행되는 것입니다. 기본/템플릿 구성 파일을/usr/share/doc/*에서 작성/복사해야하는 Redhat 기반 시스템에는 없습니다.

RPM에 대해 좋아하는 것 중 하나는 델타 RPM을 추가 한 것입니다. 이를 통해 업데이트가 쉬워지고 필요한 대역폭이 줄어 듭니다.

DEB는 표준 ar 파일 (더 많은 표준 아카이브가 있음)이고 RPM은 "독점"이진 파일입니다. 나는 개인적으로 전자가 더 편리하다고 생각합니다.

내 머리 꼭대기에서 생각할 수있는 것은 두 가지뿐입니다. 둘 다 매우 비슷합니다. 둘 다 우수한 패키징 도구가 있습니다. 나는 다른 하나 이상의 장점이 있다고 생각하지 않습니다.

데비안 패키지에는 installed size 가 포함될 수 있지만 RPM에 동등한 필드가 있다고 생각하지 않습니다. 패키지에 포함 된 파일을 기반으로 계산할 수 있지만 설치 전/후 스크립트에서 수행 할 수있는 작업 때문에 신뢰할 수 없습니다.

다음은 각 특정 패키징 형식에 사용할 수있는 일부 특정 기능을 비교하기위한 참고 자료입니다. http://debian-br.sourceforge.net/txt/alien.htm (웹에 따르면 서버에서 해당 문서는 상당히 오래되었습니다 : 마지막 수정 : 2000 년 10 월 15 일 일요일 이 문서가 가장 적합하지 않을 수 있습니다.)

OpenSUSE 빌드 서비스 (OBS)와 zypper는 패키지 및 사용자 관점에서 RPM보다 deb를 선호하는 두 가지 이유입니다. Zypper는 먼 길을 왔으며 꽤 빠릅니다. OBS는 뎁을 처리 할 수 ​​있지만 openSUSE, SLE, RHEL, centos, Fedora, mandriva 등과 같은 다양한 플랫폼의 rpm을 패키징 할 때 정말 좋습니다.

다른 어떤 답변도 다음 세 가지 기본 차이점이 실제 결과에 어떤 영향을 미치는지에 대해서는 다루지 않습니다.

1. deb 파일은 기본적으로 두 개의 압축 된 타르볼을 포함하는 ar 아카이브입니다.
2. deb 패키지와 dpkg 시스템은 관리자 스크립트를 별도의 파일로 저장합니다
3. dpkg 및 rpm는 업그레이드하는 동안 관리자 스크립트를 다른 순서로 실행합니다.

이러한 차이점으로 인해 잘못된 패키지로 인한 문제를 해결하고 deb 기반 시스템에서 rpm 기반 시스템에서 패키지가 필요한 방식으로 작동하도록 훨씬 쉬워졌습니다 [$ var] _ 기반 시스템, 둘 다 시스템 관리자 및 패키지 관리자.

# 1 때문에 deb 파일을 변경해야 할 경우, 파일을 열어서 원하는대로 변경하고 다시 패키지 할 수 있습니다. 대부분의 시스템에 존재하는 표준 도구 사용 .

여기에는 종속성이나 패키지 파일 또는 관리자 스크립트를 변경/추가/제거하거나 패키지 버전 또는 이름을 변경하는 것이 포함됩니다.

# 2 때문에 패키지 이미 설치되어 있음_에 의해 설치된 "제거"스크립트에 문제가있는 경우, 사소하게 모든 시스템에 존재하는 표준 도구 사용.

# 3으로 인해 업그레이드 중에 dpkg에서 새 버전의 패키지 before 이전 버전의 "제거 후"스크립트.

이것은 "복구 가능성 원칙"을 위반하는 표면적이 deb 패키지에서 더 작다는 것을 의미합니다. 이전 버전의 패키지에서 더 많은 실수는 새로운 버전으로 복구 할 수 있습니다.

그리고 패키지를 수정하는 것이 매우 쉬워서 (실제로 패키지 별 자료 및 지식 오버 헤드가 작음) deb 파일을 사용하면 더 많은 사람들이 액세스 할 수 있고 시간과 노력이 덜 걸립니다.

데비안 패키지에는 대규모 도우미 스크립트, 일관된 정책 매뉴얼 및 거의 모든 것을 수행하는 최소한의 방법이 있습니다. 종속성은 매우 잘 처리되며 매우 세부적으로 정의 할 수 있습니다. 데비안 패키지로 패키지를 다시 빌드하는 것은 매우 쉬우 며 사용 가능한 도구로 잘 지원됩니다.

Google 검색으로 이동

1. rpm 중복 패키지
2. dpkg 복제 패키지

돌아 오는 페이지를 읽으십시오. dpkg에서는 그러한 경우가 발생하지 않지만 중복 패키지가있는 엉망인 RPM 데이터베이스를 가질 수 있다고 매우 말하고 있습니다.