주요 패키지 관리자는 (특별한 순서 없이) apt, yum 및 pacman인 것 같습니다. 하지만 결국 차이점은 무엇입니까? 내 이해는 각 배포판이 다른 배포판보다 선호되는 것처럼 보이지만 모든 배포판에서 이들 중 하나를 사용할 수 있다는 것입니다.
그래서 제 질문은: 주요 패키지 관리자 간의 핵심 차이점은 무엇입니까? 왜 둘 중 하나를 고려해야 합니까?
답변1
글쎄요, 기본적으로 처리하는 패킷 유형(apt - deb; yum - rpm; pacman - tar.gz)에 관한 것인데, 이러한 패키징 시스템 자체는 약간 다릅니다... 그리고 종속성을 처리하는 방법은 어떻습니까(매우 중요)... 물론 - 그들이 제공하는 옵션과 설치되는 패키지에 대한 데이터를 표시하는 방법... 이것이 주요 차이점 중 일부라고 말하고 싶습니다...
답변2
당신이 참조하는 패키지 관리자는 실제로 기본 패키징 시스템의 프런트 엔드에 대한 옵션일 뿐입니다. 예를 들어 yum은 RPM의 프런트엔드이지만 다른 프런트엔드(smart, zypper, apt4rpm 등)도 존재합니다. 마찬가지로 DPKG 기반 시스템에는 기본적으로 2~3개의 패키지 관리자(Synaptic, Aptitude, apt-get, dselect 등)가 있습니다. 나는 거기에 논평할 만큼 Pacman에 대해 충분히 알지 못합니다.
프런트 엔드는 실제로 그다지 흥미롭지 않습니다. 특정 수준의 종속성 해결을 처리해야 하지만 패키지 관리의 정말 "어려운" 부분은 기본 패키지 형식에서 비롯됩니다.
다시 말하지만, Pacman에 대해서는 언급할 수 없지만 RPM과 DPKG 사이에서는 RPM이 더 어려운 작업을 수행합니다. RPM 패키지에서 매우 복잡한 관계를 정의할 수 있으며 파서는 이러한 관계를 어떻게든 처리해야 하며 패키지 정의에서는 다음과 같은 문제가 발생할 수 있습니다. 통증. 종속성 정보에 관한 한 DPKG는 패키지 이름과 버전이라는 두 가지 항목만 정의할 수 있으므로 더 간단한 형식인 반면, RPM을 사용하면 종속성의 기호 버전 관리와 같은 복잡한 작업을 수행할 수 있습니다.
따라서 귀하의 질문에 대답하자면 단일 형식의 관리자 선택은 개인 취향에 달려 있습니다 (저는 주로 능력을 사용합니다). 형식 사이의 선택은 컨트롤을 얼마나 세부적으로 만들고 싶은지에 따라 달라집니다(그리고 아이러니하게도 컨트롤이 패키징에 도입하려는 복잡성의 정도).
답변3
패키지 관리자는 두 가지 주요 범주로 나눌 수 있습니다.
바이너리 패키지 관리자: 소프트웨어는 일부 원격 시스템에 구축되어 있으며 컴파일된 결과만 얻을 수 있습니다. 가장 널리 사용되는(유일한?) 형식은 deb(apt) 및 rpm(yum)입니다.
소스 패키지 관리자: 소프트웨어 코드 소스 코드를 직접 얻어 로컬에서 컴파일합니다. 일부 소스 패키지 관리자는 BSD, Mac Ports, Homebrew, pip(Python), gem(Ruby) 등의 이머지, pacman, yaourt, slackpkg입니다.
바이너리 패키지의 주요 장점은 다음과 같습니다.설치 시간이 대폭 단축됩니다.인터넷 대역폭이 충분히 높은 경우.재현성도 좋아졌습니다패키지 버전은 항상 하나의 바이너리에만 해당합니다.
약점은패키지 크기(소스 코드보다 몇 배 더 큼)시스템 강성: Windows와 달리 Linux의 바이너리는 하드 코딩된 경로로 포함되는 경우가 많으며 재배치 가능한 바이너리(이동 가능한 바이너리)를 생성하기가 어렵습니다. 즉, 바이너리 패키지 관리는 일반적으로 /usr에서만 작동합니다.
소스코드와 바이너리의 차이점을 알려드리자면,데비안 아카이브현재 소스는 1Tb를 약간 넘지만 72Gb에 불과합니다! amd64와 같은 한 아키텍처는 약 95+92=187Gb(2.5 (1) 더 큼)입니다.
바이너리 패키지의 또 다른 문제는고정된 컴파일 플래그: 일부 옵션 기능은 시스템 패키지에서 비활성화될 수 있으며 일부 최신 CPU 확장은 호환성 이유로 비활성화될 수 있습니다.
논쟁의 여지가 있는 점 중 하나는 바이너리 패키지 관리자가 다음을 제공하는 경향이 있다는 것입니다.구 버전. 실제로 각 릴리스 직후 각 패키지에 대한 최신 업데이트를 제공하는 것은 대부분 소스 코드 패키지 관리자입니다. 그러나 바이너리 패키지는 저장소에 도달하기 전에 광범위한 테스트를 거치는 경향이 있습니다.가지다모든 아키텍처에 대해 성공적으로 컴파일됩니다! ).
선택을 돕기 위해 일반적인 패턴은 구성 프로세스에 많은 시간을 소비하고 싶지 않은 서버 및 상자에 바이너리 패키지 관리자를 사용하는 것입니다. 소스 패키지 관리자는 "고급 사용자"가 사용하는 개발 시스템과 최첨단 라이브러리가 필요한 곳에 더 자주 사용되는 경향이 있습니다.
(1) 95Gb+92Gb는 amd64 패키지와 아키텍처 독립적인 파일(멀티미디어 리소스, 글꼴, 문서 등)인 "모든" 패키지의 합계입니다.