it-swarm-ko.tech

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

어떤 이유로 든 항상 RPM 기반 배포판 (Fedora, Centos 및 현재 openSUSE)을 사용했습니다. 나는 종종 deb가 rpm보다 낫다는 말을 들었지만, 왜 물었을 때, 일관된 대답을 얻을 수 없었습니다 (대개 열정적 인 방목과 많은 양의 첨탑을 얻습니다).

역사적인 이유가있을 수 있지만 두 가지 다른 패키징 방법을 사용하는 최신 배포의 경우 누구나 기술적 또는 다른 장점을 다른 사람과 다른 사람에게 줄 수 있습니까?

173
Evan

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

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

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

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

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

97
vdboor

시스템 관리자의 관점에서 나는 주로 패키지 형식이 아닌 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 대 적성 등)입니다 (둘 다 비교 가능).

19
Maciej Piechotka

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

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

철학 :

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 패키지 관리자를 떠나지 않아도됩니다. 또한 우분투에 데비안 (비정규) 패키지를 몇 번 설치했는데 공식적으로 보장되지는 않았지만 정상적으로 작동했습니다.

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

15
arielf

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

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

12
Shawn J. Goff

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

8
Luc Stepniewski

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

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

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

6
johansson

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

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

5
Mike Gray

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

5
decriptor

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

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

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

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

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

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

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

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

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

4
mtraceur

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

4
tex

Google 검색으로 이동

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

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

2
user2472