토론이 게시물Debian과 Arch 패키지 관리의 차이점이 궁금했습니다. 또한 사람들은 아치가 매우 가볍다고 말하는 경향이 있는데 이것이 패키지 관리와 어떤 관련이 있는지 궁금합니다. 아마도 데비안이 처리하기 때문일 것입니다.추천하다기본적으로 하드 종속성으로 사용됩니까?
또한 두 패키지 관리자 간의 유연성/기능에 대해 언급할 수 있습니까? 둘 중 어느 것이 더 많은 작업을 수행할 수 있습니까?
Arch에는 하나의 제품군이 있고 Debian에는 여러 제품군(예: APT 고정 및 고급 종속성 처리)이 있기 때문에 Debian 패키지 관리 시스템에서 사용할 수 있는 일부 기능이 Arch 시스템과 관련이 없다는 것을 알고 있으므로 다음 기능을 비교하십시오. 두 시스템 모두에 적용 가능 (즉, 데비안을 가정하면 저는 그냥불안정한).
답변1
저는 몇 주 전부터 정기적으로 Arch를 사용하고 있으며 해당 주제에 대한 전문가는 아니므로 이 답변은 결코 완전한 것이 아니며 "유연성/기능성"에 대해 제가 알아차린 몇 가지 사항에 불과합니다.
이것은 단지 인상일 뿐이지만 팩맨의 디자인/아키텍처가 더 현대적이고 단순해 보입니다. 적어도 처리할 도구는 훨씬 적습니다. 적절한 소스 코드는 모르지만 우연히 libalpm 코드(팩맨의 기본 라이브러리)를 보고 깨끗하고 이해하기 쉬운 매우 간단한 패치를 만들었습니다.
또한 매우 빠릅니다(최적화로 인해 아마도 몇 가지 사항을 고려한 덕분일 것입니다(아래 참조)). 마지막 버전(며칠 전 pacman 3.5)은 관련된 데이터베이스 파일 수를 줄여 성능을 향상시키려고 했습니다.
아치는 바이너리 패키지 작업에 맞춰져 있지만 BSD(ABS) 포트와 유사한 빌드 시스템을 사용하여 소스 코드에서 패키지를 빌드할 때도 이점이 있습니다.
패키지를 만드는 것은 빠르고 쉽습니다. PKGBUILD 파일에 몇 줄만 추가하면 됩니다. 제어/규칙/저작권/변경 로그/데비안 패키지와 같은 것을 다룰 필요가 없습니다. 웹 UI를 몇 번만 클릭하면 패키지가 AUR(Arch User Repository)의 모든 사람과 공유됩니다.
아치가 아닌 데비안에서 얻는 것:
트리거/후크(패키저에게 아무 것도 요구하지 않고 패키지 설치 파일이 어디에 있는지 확인하기 위해 아이콘 캐시, mandb 등을 적절하게 업데이트하는 것)(계획이를 달성하기 위해).
debconf(그건 그렇고, 나에게 수동으로 작업을 하도록 강요하면 정확히 무엇이 수행되고 있는지 알 수 있게 됩니다.) 그리고 새 구성 파일을 올바르게 처리합니다(적어도 팩맨이 새 구성 파일에 구성 파일이 언제 있는지 알 수 있기를 바랍니다). 패키지가 설치된 것과 동일한 버전입니다. 새 버전에서 변경되었거나 로컬에서 수정했기 때문에 버전이 다릅니다.)
패키지 서명(아마도~에 종사하다).
아치를 사용하는 유일한 진짜 이유는 기본적으로 매우 적은 수의 패키지를 설치하고 필요한 패키지를 추가하도록 권장하기 때문입니다. 따라서 기본적으로 선택적 종속성을 설치하지 않으면 사용자가 부풀어오르는 것을 피하기 위해 설치하도록 강요할 수 있습니다.
답변2
저는 Ubuntu lucid로 Linux 여행을 시작했고 현재는 Arch를 사용하고 있습니다. 나는 몇 가지 Arch 패키지를 작성했는데 데비안 패키지를 작성하는 것보다 훨씬 쉽다고 말하고 싶습니다. 다만, 제가 지적하고 싶은 점은@gentlemandevilArch에는 install file.
기본적으로 이것이 바로 ${pkgname}.install설치 전/설치 후/제거/업그레이드를 위한 일부 기능이 포함되어 있습니다. 글꼴 캐시 업데이트를 여기에 넣으면 데비안 후크와 거의 동일하게 작동합니다.
/etc/pacman.conf또한, Debian 패키지 관리 도구를 사용하여 응용 프로그램을 "고정"한다고 언급하신 것을 보았습니다. Arch의 팩맨에는 을 포함한 많은 설정을 허용하는 내장 기능이 있습니다. IgnorePkg =이렇게 하면 등호(공백으로 구분) 뒤에 나열된 모든 소프트웨어에 대한 업그레이드가 방지됩니다. ) 가방
답변3
너무 멀리 가기 전에 좀 조사해 보세요Linux 타임라인 다이어그램
패키지 관리자의 차이점을 이해하려면 위 이미지와 같이 운영체제의 원리를 이해해야 합니다.
세 부모
- Redhat(현재 Fedora) - 패키지 관리자 - RPM, Redhat Package Manager의 약어, 명령줄
rpm - Slackware - 패키지 관리자 - tgz, 일반 압축 파일. 이는 단지 압축된 파일이지만 Slackware에 의해 업스트림으로 구축되어 때로는 포트라고 불리는 저장소에 배치됩니다.
- 데비안(Debian) - DEB, Debian의 줄임말, 명령줄 도구는 다음과 같습니다.
Aptitude or Apt
이 부모는 오늘날 우리가 알고 있는 대부분의 배포판의 부모입니다. 패키지 관리 시스템의 아이디어/개념은 어떤 형태나 방식으로 파생되거나 공유됩니다. 그럼에도 불구하고 이러한 상위 요소는 모두 바이너리 배포자입니다. 즉, 프로그램은 제3자에 의해 패키징되고 결정된 다음 저장소에 저장되고 사용자 기반에 의해 사용되거나 설치됩니다.
미성년 부모 3명
- Linux From Scratch - 소스 코드를 기반으로 하며 패키지 관리자가 없습니다.
- 젠투 - 파생됨처음부터 리눅스. 이 배포판은 기본적으로 Linux from Scratch와 Portage/emerge라는 패키지 관리자가 포함되어 있습니다.
- SourceMage - 매직 패키지 관리자
이러한 상위 항목은 사용자 기반이 속도와 설치 용이성을 위해 성능과 구성 용이성을 교환하기 때문에 부차적입니다. 각 패키지는 변수와 구성 파일을 사용하여 처음부터 다운로드되고 컴파일됩니다.
다리
Arch는 바이너리 배포판(예: 3개의 주요 상위 배포판 중 하나)과 소스 기반 배포판(3개의 보조 상위 배포판 중 하나) 사이를 연결하는 역할을 하기 위해 만들어졌습니다. 따라서 이 기능을 제공하는 다른 상위 항목이 없기 때문에 타임라인에서 상위 항목으로 상태를 받습니다. Pacman은 사용자가 공식 리포지토리에서 바이너리 패키지를 설치하거나 Arch 빌드 시스템을 사용하여 맞춤형 패키지를 설치할 수 있는 유연성을 갖추고 있습니다. 이 개념은 부 상위가 제공하는 성능과 기본 상위가 제공하는 설치 용이성 간의 균형을 제공합니다.
제 생각에는 시스템의 힘을 보여주는 것은 패키지 관리자가 아닙니다. 왜냐하면 모든 패키지 관리자는 건강한 시스템을 관리하고 유지하는 동일한 작업을 수행하기 때문입니다. 따라서 사용하는 시스템은 다음 사항에 따라 결정되어야 합니다.
- 사용자 수준: Linux를 처음 접하는 사용자는 기본 부모부터 시작해야 하며, 기술적으로 능숙한 사용자는 균형을 찾을 것입니다.
- 시스템으로 수행하려는 작업: 추가 사용자와 함께 LAMP 서버를 실행하는 것은 웹 검색 및 이메일 읽기에 사용되는 데스크톱 PC를 실행하는 것과 완전히 다릅니다.
- 편안함 수준: 사용자 수준에 관계없이 기술적으로 능숙하지만 시스템을 컴파일하는 데 주말을 보내고 싶지 않은 경우 아는 모든 사람이 다른 것을 선택하는지 여부에 관계없이 하나의 기본 부모를 선택합니다.
답변4
이것은 결코 완전하거나 철저한 답변이 아닙니다. 제 앞에 있는 포스터는 이미 매우 좋은 점을 제시했으며 저는 단지 2센트만 추가하고 싶습니다. 또 다른 점은 저는 apt/dpkg에 전혀 익숙해지지 않았다는 것입니다. 나에게는 항상 너무 복잡해 보였습니다. 저는 yum/rpm이 가장 만족스럽습니다.
pacman은 사용하기 매우 쉽습니다. 장점이자 단점입니다. 오후에 사용법을 배울 수 있습니다(패키지 구축 제외). 대부분 직관적이고 완전한 패키지 관리 기능을 사용하지만, 이것은 큰 문제입니다. 그것은 매우 융통성이 없습니다.
디자이너가 기능을 미리 생각하지 않으면 망할 것입니다.
몇 가지 예: 팩맨에는 기본 버전 제어 기능이 없습니다. 패키지 버전을 다운그레이드하려면 특정 패키지 버전을 다운로드하고 -U(업그레이드) 옵션을 사용하여 파일에서 설치해야 합니다. 시스템에서 항상 가장 발전된 소프트웨어 패키지를 사용하는 데 적합합니다.
실제 내부 캐시 정리/전체 재구축이 없습니다. -Syu 도중과 같이 패키지 다운로드가 손상된 경우(예: 네트워크 문제로 인해) 오류 메시지는 정확하지만 그다지 유용하지 않습니다. "전체" 세부 정보 및 디버깅이 켜져 있어도 손상된 패키지를 정확히 찾아내지 못합니다. , 그리고 상관없이 -Syyc의 양은 실제로 캐시를 정리하고 패키지를 다시 다운로드하지 않습니다. 좋은 소식은 -Sc가 다운로드한 패키지의 위치를 알려주므로 문제가 되는 패키지(어떤 패키지인지 알아낼 수 있는 경우) 또는 모두 삭제하고 -Syu를 다시 시작할 수 있다는 것입니다.
pacman과 dkms의 통합에도 몇 가지 문제가 있습니다. 새 커널을 설치할 때 dkms에서 계속 오류가 발생합니다. dkms build && dkms install을 사용하면 새 커널에 대해 잘 작동하지만 pacman은 커널 업그레이드 중에 dkms가 실패한 이유에 대한 정보를 제공하지 않습니다(새 커널에 대한 올바른 경로를 전달하지 않았으며 dkms가 기본값을 사용하도록 허용함) 경로) (현재 커널을 실행 중이지만 잘못된 버전).
유연성 부족에 대한 또 다른 일화는 언급했듯이 rpm/yum에 익숙합니다. 내 시스템에 파일이 있고 어떤 패키지가 이를 소유하고 있는지 알고 싶다면 yum Provide /path/to/file을 실행하여 해당 파일을 거기에 넣을 수 있는 모든 패키지를 가져올 수 있습니다. 해당 패키지가 설치되어 있지 않더라도 마찬가지입니다. 파일이 수동으로 배치되었고 이제 패키지를 설치하려는 경우 새 패키지의 이름이 바뀌고(확장자 .rpmnew 추가) 사용할 패키지를 선택할 수 있습니다.
팩맨은 파일이 이미 존재한다고 잘못 설명하지만 완전히 관련 없는 오류 메시지와 함께 파일의 "실제" 소유자와 현재 설치된 "파일 시스템" 패키지 사이의 충돌에 대해 불평합니다. 마치 동일한 파일의 소유자이기도 한 것처럼 말이죠. 같은. 또한 이는 주로 로컬에 설치된 정보에 맞춰져 있습니다. 아직 설치되지 않은 패키지에 대한 정보(예: 파일 목록 및 소유권)를 얻으려는 시도는 덜 직관적입니다.
간단히 말해서, yum만큼 성숙하지도 않고 아마도 dpkg만큼 성숙하지도 않을 것입니다. 이는 사용 용이성과 상대적 유연성에도 기여합니다.