답변:
패키지 관리자의 주된 차이점은 데비안 링고에서 '개발자'라고 생각합니다. 패키지 메타 데이터와 함께 제공되는 스크립트가 결합되는 방식입니다.
RPM 세계에서 모든 패키지 (유지 관리하는 RPM)는 다음과 같은 곳에 있습니다 ~/rpmbuild. 그 아래에는 SPEC스펙 파일 SOURCES용 디렉토리, 소스 tarball 용 디렉토리 RPMS및 SRPMS새로 작성된 RPM 및 SRPM을 넣을 수있는 디렉토리 및 현재 관련이없는 다른 것들이 있습니다.
RPM 생성 방법과 관련된 모든 것은 스펙 파일에 있습니다. 적용 할 패치, 가능한 사전 및 사후 스크립트, 메타 데이터, 변경 로그 등 모든 것이 있습니다. 모든 소스 타르볼과 모든 패키지 의 모든 패치는 소스에 있습니다.
개인적으로 모든 것이 스펙 파일에 들어가고 스펙 파일이 소스 타르볼과 별개의 엔티티라는 사실을 좋아하지만 SOURCES에 모든 소스를 갖는 것에 지나치게 열중하지는 않습니다 . IMHO, SOURCES는 매우 빠르게 어수선 해져서 거기에 무엇이 있는지 추적하지 못하는 경향이 있습니다. 그러나 의견은 다릅니다.
RPM을 위해 그것을 사용하는 것이 중요합니다 정확한 타임 스탬프까지 것과 같은 업스트림 프로젝트 자료를 같은 타르볼. 일반적으로이 규칙에는 예외가 없습니다. 데비안 패키지에는 업스트림과 동일한 타르볼이 필요하지만 데비안 정책에 따라 일부 타르볼을 다시 패키지해야합니다 (감사, Umang).
데비안 패키지는 다른 접근 방식을 취합니다. (여기서 실수를 저 지르십시오 : RPM과 관련된 deb에 대한 경험이 훨씬 적습니다.) 데비안 패키지의 개발 파일은 패키지 당 디렉토리에 들어 있습니다.
이 접근법에 대해 내가 좋아하는 것은 모든 것이 단일 디렉토리에 포함되어 있다는 사실입니다.
데비안 세계에서는 아직 업스트림이 아닌 패키지로 패치를 전달하는 것이 조금 더 허용됩니다. RPM 세계 (적어도 Red Hat 파생 상품 중)에서 이것은 눈살을 찌푸립니다. "FedoraProject : 업스트림 프로젝트에 가깝게 유지"를 참조하십시오 .
또한 데비안에는 패키지 생성의 많은 부분을 자동화 할 수있는 방대한 양의 스크립트가 있습니다. 예를 들어, setuptool의 Python 프로그램으로 간단한 패키지를 작성하는 것은 몇 개의 메타 데이터 파일을 작성하고 실행하는 것만 큼 간단합니다 debuild. 즉, RPM 형식의 이러한 패키지에 대한 사양 파일은 매우 짧으며 RPM 세계에서도 요즘 자동화되는 많은 것들이 있습니다.
.diff.gz의 .debian.tar.gz파일 또는 파일에 남아 있습니다 debian. BTW : 정책에 재 패키징이 필요하지 않은 경우 타르볼의 MD5는 업스트림 타르볼과 일치해야합니다. 또한 명확히하기 위해 관리자를 업스트림 소스로 만든 패치는 debian 디렉토리 (소스 형식 3.0)와 .diff.gz(형식 1.0)에 저장됩니다.
많은 사람들이와 소프트웨어를 설치 비교할 apt-get에 rpm -i, 따라서 더 나은 DEB를 말한다. 그러나 이것은 DEB 파일 형식과 관련이 없습니다. 실제 비교는 dpkgvs 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 패키지는 그다지 친숙하지 않습니다.
*.rpmnew은 적어도 openSUSE에서 수정 된 파일 을 복제 하는 대신 새 구성 파일을 저장하는 것처럼 보입니다 .
rpm2cpio.sh기울어 진 사람들을위한 것이 있습니다.
deb내가 기억하는 형식을 때 data.tar.gz이되었다 data.tar.xz하는 오래된 지적, dpkg새로운 패키지를 열 수있는 중단했다.
RPM :
뎁 :
아마도 더 중요한 질문은 패키지 형식이 아닌 패키지 관리자 (dpkg 대 yum 대 적성 등)입니다 (둘 다 비교 가능).
여러 응답자가 말했듯이 특정 패키지 형식 이 분명히 우수 하지는 않습니다 . 기술적으로는 다소 비슷할 수 있습니다. 내 관점에서 많은 차이점과 사람들이 서로 선호하는 이유는 다음과 관련이 있습니다.
철학:
Ubuntu / Debian / Mint / ... 세계에서 사용자는 설치된 패키지가 설치되면 "작동"할 것으로 기대합니다. 즉, 설치하는 동안 패키지는 패키지를 실제로 실행하는 데 필요한 모든 것을 처리해야합니다.
rpm 세계에서-이것은 몇 년 전의 상황이며, 그 이후 개선되었을 수도 있습니다. 실제로 패키지를 실제로 작동시키기 위해 추가 단계 (예 : chkconfig, cron 작업 활성화)를 실행해야한다는 것을 알았습니다. 이것은 시스템 관리자 나 유닉스에 대해 잘 알고있는 사람들에게는 문제가되지 않지만 초보자 경험을 어렵게 만듭니다. RPM 패키지 형식 자체가이를 방지하는 것이 아니라, 많은 패키지가 초보자의 관점에서 "완전히 완료 되지 " 않은 것 입니다.
커뮤니티 규모, 참여 및 풍부한 리포지토리 :
우분투 / 데비안 / 민트 / ... 커뮤니티가 더 넓기 때문에 더 많은 사람들이 소프트웨어 패키징 및 테스트에 참여하고 있습니다. 리포지토리의 풍부함과 품질이 우수하다는 것을 알았습니다. 우분투에서는 소스를 다운로드하여 빌드 할 필요가 거의 없습니다. 집에서 Red Hat에서 Ubuntu로 전환했을 때 일반적인 RHEL 리포지토리에는 ~ 3000 개의 패키지가 있고, 동시에 모든 정식 미러에서 직접 사용할 수있는 ubuntu + universe + multiverse는 ~ 30,000 개의 패키지 (약 10x)가있었습니다. RPM 형식으로 찾은 대부분의 패키지는 패키지 관리자에서 간단한 검색 및 클릭을 통해 쉽게 액세스 할 수 없었습니다. 대체 저장소로 전환하고 rpmfind 서비스 웹 사이트 등을 검색해야했습니다. 대부분의 경우 문제를 해결하기보다는 올바르게 업그레이드하거나 업그레이드 할 수없는 종속성을 제한하지 않아 설치가 중단되었습니다. Shawn J. Goff가 위에서 설명한 것처럼 "종속성 지옥"현상에 부딪 쳤습니다.
우분투 / 데비안에서 나는 소스에서 빌드 할 필요가 거의 없다는 것을 알았습니다. 또한 다음으로 인해 :
공식 (정식) 개발자가 유지 관리하지 않더라도 이전 버전의 패키지를 타협 할 필요가 없었습니다. 키워드로 편리한 검색을 수행하고 원하는 패키지를 찾아 설치하기 위해 내가 좋아하는 GUI 패키지 관리자를 떠나지 않아도됩니다. 또한 우분투에 데비안 (비정규) 패키지를 몇 번 설치했는데 공식적으로 보장되지는 않았지만 정상적으로 작동했습니다.
이것은 화염 전쟁을 시작하기위한 것이 아니라 몇 년 동안 (일과 집) 두 세계를 동시에 사용한 경험을 공유하는 것입니다.
편견은 패키지 형식이 아니라 RedHat의 저장소에 존재했던 불일치 때문이라고 생각합니다.
RedHat이 배포판 (RHEL, Fedora 및 Fedora Core 이전)으로 돌아 왔을 때 사람들은 때때로 "RPM 지옥"또는 "종속성 지옥"에 빠져있었습니다. 이것은 리포지토리가 상호 배타적 인 종속성 (일반적으로 여러 계층 깊이)을 가진 패키지로 끝날 때 발생했습니다. 또는 두 개의 서로 다른 패키지에 두 개의 상호 배타적 인 종속성이있을 때 발생합니다. 이것은 패키지 형식이 아닌 리포지토리의 상태에 문제가있었습니다. "RPM 지옥"은이 문제로 불타 버린 일부 Linux 사용자 집단에서 RPM 시스템에 열광을 남겼습니다.
데비안 패키지에서 질문을하고 설치 프로세스를 차단할 수있는 "철학적"차이점도 있습니다. 이것의 나쁜 점은 응답 할 때까지 일부 패키지가 업그레이드를 차단한다는 것입니다. 이것의 좋은 점은 데비안 기반 시스템에서 철학적으로 다른 점으로, 패키지가 설치 될 때 패키지가 구성되어 (항상 원하는 것은 아님) 실행되는 것입니다. / usr / share / doc / *에서 기본 / 템플릿 구성 파일을 작성 / 복사해야하는 Redhat 기반 시스템에는 없습니다.
RPM에 대해 좋아하는 것 중 하나는 델타 RPM을 추가 한 것입니다. 이를 통해 업데이트가 쉬워지고 필요한 대역폭이 줄어 듭니다.
DEB는 표준 ar 파일이며 (더 많은 표준 아카이브가 있음) RPM은 "독점"이진 파일입니다. 나는 개인적으로 전자가 더 편리하다고 생각합니다.
내 머리 꼭대기에서 생각할 수있는 것은 두 가지뿐입니다. 둘 다 매우 비슷합니다. 둘 다 우수한 패키징 도구가 있습니다. 나는 다른 하나 이상의 장점이 있다고 생각하지 않습니다.
rpm2cpio.sh스크립트 를 찾을 수 있습니다.
openSUSE 빌드 서비스 (OBS)와 zypper는 패키지 관리자와 사용자 관점에서 RPM보다 deb를 선호하는 두 가지 이유입니다. Zypper는 먼 길을 왔으며 꽤 빠릅니다. OBS는 뎁을 처리 할 수 있지만 openSUSE, SLE, RHEL, centos, fedora, mandriva 등과 같은 다양한 플랫폼의 rpm을 패키징 할 때 정말 좋습니다.
데비안 패키지에는 설치된 size 가 포함될 수 있지만 RPM에 해당하는 필드가 있다고 생각하지 않습니다. 패키지에 포함 된 파일을 기반으로 계산할 수 있지만 설치 전 / 후 스크립트에서 수행 할 수있는 작업 때문에 신뢰할 수 없습니다.
다음은 각 특정 패키징 형식에 사용할 수있는 특정 기능을 비교하기위한 참고 자료입니다. http://debian-br.sourceforge.net/txt/alien.htm (웹 서버에 따르면 문서는 상당히 오래되었습니다 : 최종 수정일 : Sun, 2000 년 10 월 15 일 이므로 이것이 최선의 참조가 아닐 수도 있습니다.)
데비안 패키지에는 대규모 도우미 스크립트, 일관된 정책 매뉴얼 및 거의 모든 것을 수행하는 최소한의 방법이 있습니다. 종속성은 매우 잘 처리되며 매우 세부적으로 정의 할 수 있습니다. 데비안 패키지로 패키지를 다시 빌드하는 것은 매우 쉬우 며 사용 가능한 도구로 잘 지원됩니다.
다음 세 가지 근본적인 차이점이 실제로 어떤 결과를 가져 오는지에 대한 다른 답변은 없습니다 .
deb파일은 기본적으로 ar압축 된 두 개의 tarball을 포함하는 아카이브입니다.deb패키지와 dpkg시스템은 관리자 스크립트를 별도의 파일로 저장합니다dpkg및 rpm업그레이드 동안 다른 순서로 관리자 스크립트를 실행합니다.함께, 이러한 차이는 만든 훨씬 쉽게 나를 나쁜 패키지로 인한 문제를 해결하고, 패키지에, 내가 그들을 필요로하는 방식으로 작동하게하기 deb보다는 기반 시스템 rpm, 기반 시스템 모두 시스템 관리자 및 패키저로 .
# 1 때문에 deb파일 을 변경해야 할 경우 , 대부분의 시스템에 존재하는 표준 도구를 사용하여 파일을 열어서 원하는대로 변경하고 다시 패키지 할 수 있습니다 .
여기에는 종속성이나 패키지 파일 또는 관리자 스크립트를 변경 / 추가 / 제거하거나 패키지 버전 또는 이름을 변경하는 것이 포함됩니다.
# 2로 인해 이미 설치된 패키지에 의해 설치된 "제거"스크립트에 문제가있는 경우 모든 시스템에 존재하는 표준 도구를 사용하여 사소하게 수정할 수 있습니다 .
# 3 때문에 업그레이드 중에 패키지의 새 버전의 dpkg"사전 설치"스크립트를 "사후 제거"스크립트 전에 실행 하기 때문에 새 버전의 패키지를 릴리스하여 이러한 수정 사항 중 일부를 수행 할 수 있습니다. 이전 버전.
이는 "복구 가능성 원칙"을 위반하는 표면적이 deb패키지 에서 더 작다는 것을 의미 합니다. 이전 버전의 패키지에서 더 많은 실수는 새 버전으로 복구 할 수 있습니다.
또한 패키지 수정이 매우 쉬워 실제 패키지 별 정보 및 지식 오버 헤드가 작기 때문에 더 많은 사람들이 액세스 할 수 있으며 deb파일을 사용 하여 시간과 노력을 덜 소비 합니다.
debian, 디렉토리는 업스트림 소스가 추출 된 디렉토리에 존재하며 데비안은 원시 업스트림 소스 타르볼의 개념을 매우 중요하게 생각합니다. 소스 패키지가 빌드 될 때 소스 패키지라고하는 세 개의 (기본 패키지의 경우 2 개) 파일이 있습니다. 새로운 3.0 형식 (이전 1.0 형식의 diff)과 .dsc