어떤 이유로든 저는 항상 RPM 기반 배포판(Fedora, Centos 및 현재 openSUSE)을 사용해 왔습니다. 나는 종종 사람들이 deb가 rpm보다 낫다고 말하는 것을 듣습니다. 그러나 이유를 물었을 때 결코 일관된 대답을 얻지 못합니다(보통 열정적인 호언장담과 많은 침을 뱉습니다).
몇 가지 역사적인 이유가 있을 수 있다는 것을 알고 있지만, 두 가지 다른 패키징 방법을 사용하는 현대 배포판의 경우 둘 중 하나와 다른 것의 기술적(또는 기타) 이점을 알려줄 수 있는 사람이 있습니까?
답변1
많은 사람들 이 소프트웨어 설치를 DEB와 apt-get비교하여 rpm -iDEB가 더 좋다고 말합니다. 그러나 이는 DEB 파일 형식과는 아무런 관련이 없습니다. 실제 비교는 dpkgvs rpm및 aptitude/ apt-*vs zypper/ 입니다 yum.
사용자 관점에서 볼 때 이러한 도구 간에는 큰 차이가 없습니다. RPM과 DEB 형식은 모두 일부 메타데이터가 첨부된 아카이브 파일입니다. 둘 다 똑같이 모호하고 설치 경로가 하드 코딩되어 있으며(으악!) 사소한 세부 사항만 다릅니다. dpkg -i둘 다 rpm -i명령줄에 지정되지 않는 한 종속성을 설치하는 방법을 알 수 없습니다.
apt-...이러한 도구 외에도 zypper. yum이러한 도구는 저장소를 다운로드하고 모든 메타데이터를 추적하며 자동으로 종속성을 다운로드합니다. 각 개별 패키지의 최종 설치는 하위 수준 도구에 맡겨집니다.
이는 완료하는 데 오랜 시간이 걸리는 apt-get대량의 메타데이터를 신속하게 처리하는 데 오랫동안 탁월했습니다. yumRPM은 또한 rpmfind와 같은 사이트의 영향을 받습니다. 이 사이트에서는 10개가 넘는 배포판에 대해 호환되지 않는 패키지를 찾을 수 있습니다. AptDEB 패키지의 이 문제는 모든 패키지가 동일한 소스에서 설치되므로 완전히 숨겨져 있습니다.
제 생각에는 이것이 zypper실제로 격차를 줄여주고 apt이제 RPM 기반 배포판을 사용하는 것을 부끄러워할 이유가 없습니다. OpenSUSE 빌드 서비스를 사용하여 호환 가능한 패키지의 거대한 색인을 얻는 것도 쉽지는 않지만 좋습니다.
답변2
패키지 관리자(데비안 용어로는 "개발자"라고 생각합니다)의 주요 차이점은 패키지 메타데이터와 그에 수반되는 스크립트가 함께 제공되는 방식입니다.
RPM 세계에서 모든 패키지(유지 관리 하는 RPM ) 는 ~/rpmbuild. 이제 관련 없는 콘텐츠입니다.SPECSOURCESRPMSSRPMS
모든 것RPM 생성 방법과 관련된 내용은 사양 파일에 있습니다. 적용할 패치, 가능한 사전 및 사후 스크립트, 메타데이터, 변경 로그 등이 있습니다. 모든 소스 타르볼 및 모든 패치모든 패키지소스에서.
이제 개인적으로 나는 모든 것이 사양 파일에 들어가고 사양 파일이 소스 타르볼과 별도의 엔터티라는 사실을 좋아하지만모두소스 내의 소스. IMHO, 소스는 빠르게 혼란스러워질 수 있으며 그 내용을 잊어버리는 경향이 있습니다. 그러나 의견은 다릅니다.
RPM의 경우정밀한업스트림 프로젝트에서 릴리스한 압축 패키지와 동일하며 타임스탬프까지 동일합니다. 일반적으로 이 규칙에는 예외가 없습니다. 데비안 패키지에는 업스트림과 동일한 타르볼이 필요하지만 데비안 정책에서는 일부 타르볼을 다시 패키징해야 합니다(고마워요, Umang).
데비안 패키지는 다른 접근 방식을 취합니다. (여기에 오류가 있으면 죄송합니다. 저는 RPM보다 deb에 대한 경험이 훨씬 적습니다.) 데비안 패키지의 개발 파일은 패키지당 디렉터리에 포함되어 있습니다.
내가 이 접근 방식을 좋아하는 이유는 모든 것이 하나의 디렉토리에 포함되어 있기 때문입니다.
데비안 세계에서는 (아직) 업스트림이 아닌 패키지에 패치를 포함하는 것이 더 허용됩니다. RPM 세계에서는(적어도 Red Hat 파생 제품 중에서) 이는 인기가 없습니다. 바라보다"Fedora 프로젝트: 업스트림 프로젝트와 긴밀한 연결 유지".
게다가 데비안에는 패키지 생성 작업의 상당 부분을 자동화하는 스크립트가 많이 있습니다. 예를 들어 setuptool로 처리되는 Python 프로그램의 간단한 패키지를 만드는 것은 몇 개의 메타데이터 파일을 만들고 debuild. 이제는 많은 것들이 자동화되었습니다.
답변3
시스템 관리자의 관점에서 볼 때 주로 패키지 형식이 아닌 dpkg/rpm 도구 세트에서 몇 가지 미묘한 차이점을 발견했습니다.
dpkg-divert패키지의 파일을 사용자 고유의 파일로 바꿀 수 있습니다. 답변을 찾거나 찾지 않고/usr파일을 찾는 프로그램이 있을 때 생명의 은인이 될 수 있습니다 ./lib/usr/local이 아이디어는 제안되었지만 내가 아는 한 rpm 단위로 채택되지 않았습니다.내가 마지막으로 rpm 기반 시스템을 관리했을 때(물론 몇 년 전이지만 상황이 개선되었을 수도 있음) rpm은 항상 수정된 구성 파일을 덮어쓰고 내 사용자 정의를
*.rpmsaveIIRC로 옮겼습니다. 이로 인해 시스템이 한 번 이상 부팅할 수 없게 되었습니다. Dpkg는 나에게 무엇을 해야 할지 물었고 내 사용자 정의 설정을 기본값으로 두었습니다.RPM 바이너리 패키지는 패키지가 아닌 파일에 대한 종속성을 선언할 수 있으므로 deb 패키지보다 더 강력한 제어가 가능합니다.
버전 N-1 rpm 도구가 있는 시스템에는 버전 N rpm 패키지를 설치할 수 없습니다. 형식이 자주 변경되지 않는다는 점을 제외하면 dpkg에서도 작동할 수 있습니다.
dpkg 데이터베이스는 텍스트 파일로 구성됩니다. rpm 데이터베이스는 바이너리입니다. 이렇게 하면 dpkg 데이터베이스를 쉽게 조사하고 복구할 수 있습니다. 반면에 문제가 없다면 rpm은 훨씬 더 빠를 수 있습니다(deb를 설치하려면 수천 개의 작은 파일을 읽어야 합니다).
deb 패키지는 표준 형식(
ar,tar,gzip)을 사용하므로 deb 패키지를 쉽게 검사하고 필요한 경우 조정할 수 있습니다. RPM 패키지는 그다지 친숙하지 않습니다.
답변4
여러 응답자들이 말했듯이 패키지라고 말하는 것보다체재분명히 우월합니다. 기술적으로는 다소 비슷할 수 있습니다. 내 관점에서 볼 때 많은 차이점과 사람들이 다른 것을 선호하는 이유는 다음 요소와 관련이 있습니다.
- 독창적인 포장 디자인 컨셉과 대상 고객
- 커뮤니티 규모, 저장소의 품질과 풍부함
철학:
Ubuntu/Debian/Mint/... 세계에서 사용자는 설치된 패키지가 일단 설치되면 "제대로 작동"할 것으로 기대합니다. 이는 설치 중에 패키지가 다음을 포함하되 이에 국한되지 않고 실제로 제대로 실행되는 데 필요한 모든 것을 처리해야 함을 의미합니다.
- 필수 또는 선택적 크론 작업 설정
- 대체/별칭 설정
- 시작/종료 스크립트 설정
- 의미 있는 기본값과 함께 모든 필수 구성 파일을 포함합니다.
- 이전 버전의 라이브러리를 유지하고 이전 버전과의 호환성을 위해 올바른 버전의 심볼릭 링크를 라이브러리(.so)에 추가하세요.
- 동일한 시스템에서 다중 아키텍처(32비트 및 64비트) 바이너리 등을 완벽하게 지원합니다.
rpm 세계에서는 - 확실히 이것은 몇 년 전의 일이고 그 이후로 약간 개선되었을 수 있습니다. - 패키지가 실제로 작동하도록 하려면 추가 단계(예: chkconfig, cron 작업 활성화)를 실행해야 한다는 것을 알게 되었습니다. 이는 시스템 관리자나 Unix를 아는 사람들에게는 괜찮을 수 있지만 초보자에게는 어려움을 겪을 수 있습니다. 이 문제가 발생하는 것을 방지하는 것은 RPM 패키지 형식 자체가 아니라 많은 패키지가 실제로 이러한 현상을 방지하지 않는다는 점에 유의하십시오."완전히 완료되었습니다"초보자의 관점에서.
커뮤니티 규모, 참여 및 저장소의 풍부함:
ubuntu/debian/mint/... 커뮤니티의 규모가 더 크기 때문에 소프트웨어 패키징 및 테스트에 참여하는 사람들이 더 많습니다. 나는 저장소의 풍부함과 품질이 탁월하다는 것을 알았습니다. 우분투에서는 소스 코드를 다운로드하여 빌드할 필요가 거의 없습니다. 집에서 Red Hat에서 Ubuntu로 전환했을 때 일반 RHEL 저장소에는 약 3000개의 패키지가 있었고 동시에 Canonical 미러에서 직접 사용할 수 있는 ubuntu+universe+multiverse에는 약 30,000개의 패키지가 있었습니다(약 10번). ). 내가 찾고 있는 RPM 형식의 패키지 대부분은 패키지 관리자에서 간단한 검색과 클릭만으로는 쉽게 접근할 수 없습니다. 대체 저장소로 전환하고 rpmfind 서비스 웹사이트를 검색해야 합니다. 대부분의 경우 문제가 해결되지는 않지만 올바르게 업그레이드할 수 있거나 업그레이드할 수 없는 종속성을 제한할 수 없어 설치가 중단됩니다. Shawn J. Goff의 답변에 설명된 대로 "의존성 지옥" 현상이 발생했습니다.
대조적으로, Ubuntu/Debian에서는 소스에서 빌드할 필요가 거의 없다는 것을 알았습니다. 또한 다음과 같은 이유 때문에:
- Ubuntu 빠른(6개월) 릴리스 주기
- 존재감완벽하게 호환됨즉시 사용 가능한 PPA
- 단일 소스 저장소(모두 Canonical에서 호스팅) 대체/보완 저장소를 검색할 필요가 없습니다.
- 클릭부터 실행까지 원활한 사용자 경험
나는 내가 관심을 갖고 있는 이전 버전의 패키지를 공식(정규) 개발자가 유지 관리하지 않더라도 타협할 필요가 없었습니다. 내가 원하는 패키지를 찾고 설치하기 위해 키워드로 편리한 검색을 수행하기 위해 내가 가장 좋아하는 친숙한 GUI 패키지 관리자를 떠날 필요가 없습니다. 또한 우분투에 데비안(비표준) 패키지를 몇 번 설치했는데, 비록 이 호환성이 공식적으로 보장되지는 않지만 잘 작동합니다.
이것은 격렬한 전쟁을 시작하려는 의도가 아니라 단순히 수년에 걸쳐 두 세계(직장과 가정)를 오가며 경험한 내용을 공유하는 것입니다.