Debian과 Arch의 패키지 관리 차이

몇 주 동안 정기적으로 아치를 사용합니다. 주제에 대한 전문가가 아니므로이 답변은 결코 완전하지 않습니다. “유연성 / 파워”에 대해 제가 언급 한 몇 가지 사항입니다.

• 이것은 인상 일 뿐이지 만 팩맨은 디자인 / 아키텍처에서보다 현대적이고 단순 해 보입니다. 적어도 다룰 도구는 훨씬 적습니다. 적절한 소스 코드는 모르지만 libalpm 코드 (pacman의 기본 라이브러리)를보고 매우 간단한 패치를 만들었습니다. 깔끔하고 이해하기 쉬운 것 같습니다.

• 또한 매우 빠릅니다 (최적화로 인해 그리고 아마도 몇 가지 사항에 신경을 써서 (아래 참조)). 마지막 릴리스 (몇 일 전 팩맨 3.5)에서는 수를 줄여 성능을 향상 시키려고했습니다. 관련 데이터베이스 파일.

• arch가 바이너리 패키지 사용을 지향하고 있지만 BSD의 포트와 유사한 빌드 시스템을 사용하여 소스에서 패키지를 빌드 할 때도 이점이 있습니다. ABS).

• 패키지를 만드는 것은 매우 쉽고 빠릅니다. PKGBUILD 파일에 몇 줄만 있으면 완료됩니다. 제어 / 규칙 / 저작권을 다룰 필요가 없습니다. / changelog / whatever like with Debian packages. 그리고 웹 UI를 몇 번만 클릭하면 패키지가 AUR (Arch User Repository)의 모든 사용자와 공유됩니다.

내가 얻는 것 아치가 아닌 데비안에서 :

• Triggers / h ooks (패키지가 아무것도 할 필요없이 패키지 설치 파일의 위치를 확인하여 아이콘 캐시, mandb 또는 무엇이든 업데이트하는 것) ( 계획 ).

• debconf (별도의 일이 아니며 수동으로 작업을 수행하도록 강제함으로써 정확히 수행 된 작업을 알도록 강요합니다.) 새 구성 파일의 적절한 처리 (새 패키지 버전의 구성 파일이 새 버전에서 변경되었거나 로컬로 수정했기 때문에 설치된 것과 다른 경우 pacman이 알고 싶습니다)

• 패키지 서명 ( 작업 으로 간주)

아치가 가볍기 때문에 유일한 실제 이유는 기본적으로 설치된 패키지가 거의 없기 때문이며 “필요한 것을 추가하는 것이 좋습니다. 따라서 기본적으로 선택적 종속성을 설치하지 않는 것은 사용자가 부 풀리지 않도록 설치하도록 유도하는 것입니다. .

댓글

• 이것을 파싱 할 수는 없습니다 ‘ : 이 없이도 할 수 있으며 더 나은 것을 알 수 있습니다 . 마지막 문장에도 오타가 있습니다.
• 팩맨 패키지 관리자는 어떤 언어로 작성됩니까? dpkg / apt와 유사한 저수준 및 고수준 패키지 관리 기능이 있습니까? 그렇다면 그 이름은 무엇입니까?
• @Tshepang : 죄송합니다. 영어가 모국어가 아닙니다. 저는 “이 기능 (debconf)이없는 것이 큰 문제가 아니며 수동으로 작업을 강제함으로써 정확히 무엇을했는지 알도록 강요합니다. “.
• @Faheem Mitha : Pacman은 C로 작성되었으며 libalpm의 프런트 엔드로 ” high를 모두 처리합니다. -level ” 및 ” 낮은 수준 ” 패키지 관리
• @zanko : 나도 ‘ 원어민이 아닙니다. 내가 원했던 것은 댓글이 아니라 게시물 자체에서 문장을 더 명확하게 만드는 것입니다. BTW, 제가 언급 한 오타는 선택적 입니다. 게시물을 직접 수정할 수는 있지만 설명 부분과 함께 수정하는 것이 좋습니다.

저는 Ubuntu lucid로 Linux 여행을 시작했으며 현재 Arch를 사용하고 있습니다.저는 소수의 Arch 패키지를 작성했으며 데비안 패키지를 작성하는 것보다 훨씬 쉽다고 말할 것입니다. 하지만 @gentledevil 에게 Arch는 install file.

기본적으로 이름은 ${pkgname}.install이며 사전 / 사후 설치 / 제거 / 업그레이드를위한 몇 가지 기능을 포함합니다. 글꼴 캐시 업데이트를 배치하기 만하면됩니다. 데비안 후크와 거의 동일하게 작동합니다.

또한 데비안 패키지 관리 도구를 사용하여 애플리케이션을 “고정”한다고 언급 한 것을 보았습니다. Arch “s pacman에는 이러한 기능이 내장되어 있습니다. 또한 /etc/pacman.conf는 IgnorePkg =를 포함한 여러 설정을 허용합니다.이 설정은 등호 (공백으로 구분) 뒤에 나열된 패키지로의 업그레이드를 방지합니다. )

댓글

• 또한 리포지토리 패키지는 아니지만 powerpill 래퍼를 사용할 수 있습니다. pacman이 여러 패키지를 병렬로 다운로드 할 수 있도록하기 위해 pacman -S libfoo libbar libbaz 대신 각 패키지를 차례로 다운로드합니다. r 대신 세 가지 모두를 동시에 다운로드하여 더 나은 연결을 위해 업그레이드 속도를 크게 높였습니다.

이전 너무 멀리 가서 그림 Linux 타임 라인

패키지 관리자의 차이점을 이해하려면 OS의 철학을 이해해야합니다. ” 위 그림에 표시된 es

Three Major Parents

1. Redhat, Now Fedora-Package Manger-RPM, Redhat Package Manager의 약자, 명령 줄 rpm
2. Slackware-패키지 관리자-tgz, 일반 압축 파일. 이 파일은 압축 파일 일 뿐이지 만 Slackware 업스트림에 의해 빌드되어 저장소에 저장됩니다. 때로는 포트라고도합니다.
3. Debian-DEB, Debian의 약자입니다. 명령 줄 도구는

이 부모들은 오늘날 우리가 알고있는 대부분의 배포판에 대한 어머니와 아버지입니다. 패키지 관리 시스템의 아이디어 / 개념은 일부에서 파생되거나 공유되었습니다. 형식이나 형식에 관계없이 이러한 모든 부모는 바이너리 배포자입니다. 즉, 프로그램이 제 3 자에 의해 패키징되고 결정된 다음 저장소에 저장되고 사용자 기반이 사용하거나 설치합니다.

3 마이너 부모

1. Linux From Scratch-소스 기반, 패키지 관리자 없음
2. Gentoo- Linux from Scratch .이 배포판은 기본적으로 Scratch의 Linux와 Portage / emerge라고하는 패키지 관리자입니다.
3. SourceMage-Package Manager Sorcery

이러한 부모는 사용자 기반이속도와 설치 용이성을 강력하고 쉽게 구성 할 수 있습니다. 각 패키지는 변수와 구성 파일을 사용하여 처음부터 다운로드 및 컴파일됩니다.

The Bridge

Arch는 3 개의 주요 상위 항목 중 하나와 같이 바이너리 배포 사이의 브리지로 생성되었습니다. 그리고 3 Minor Parents 중 하나와 같은 소스 기반 배포판. 따라서 다른 부모가이 기능을 제공하지 않았기 때문에 타임 라인에서 부모로 상태를받습니다. Pacman은 사용자가 공식 저장소에서 바이너리 패키지를 설치하거나 아치 빌드 시스템을 사용하여 사용자 정의 빌드 패키지를 설치할 수있는 유연성을 가지고 있습니다. 이 개념은 미성년 부모가 제공하는 권한과 주요 부모가 제공하는 설치 용이성 사이의 균형을 제공합니다.

제 생각에는 패키지 관리자가 모든 패키지 관리자가 동일한 작업을 수행하므로 정상적인 시스템을 관리하고 유지합니다. 따라서 사용하는 시스템은 다음과 같은 요소에 의해 결정되어야합니다.

• 사용자 수준 : 누군가 Linux를 처음 접하는 사람은 Major Parent부터 시작해야하지만 기술적으로 능숙한 사람은 균형을 찾을 수 있습니다.
• 시스템으로 수행 할 작업 : 연결된 사용자로 LAMP 서버를 실행하는 것은 데스크톱 PC를 실행하는 것과 완전히 다릅니다. 웹 브라우징 및 이메일 읽기 용.
• 편안함 수준 : 사용자 수준은 문제가되지 않습니다. 기술적으로 능숙하지만 시스템을 컴파일하는 데 주말을 보내고 싶지 않은 경우 주요 부모를 선택합니다. 아는 모든 사람이 다른 것을 선택했는지 여부에 관계없이.

댓글

• 더 중요합니다. pacman과 Debian ‘의 패키지 관리 도구를 비교하는 것이 아니라 배포판의 계보를 사용했습니다 …
• @jasonwryan That ‘ 모든 패키지 관리자가 동일한 작업을 수행하므로 emerge packagename는 sudo apt-get install packagename와 동일합니다.
• 그 수준에서는 그렇습니다. 그러나 그것은 질문의 요점을 완전히 놓친 것입니다. 그 외에는 차이가 없습니다. 유일한 차이점은 의미 론적, 즉 하나의 명령과 다른 명령입니다.OP가 의미 적 차이를 찾고 있다면 그에 대한 매뉴얼이 있습니다.

이것은 아니오는 완전하거나 철저한 답변을 의미합니다. 이전의 포스터는 이미 몇 가지 좋은 점을주었습니다. 저는 2 센트를 더하고 싶습니다. 또 한 가지-저는 apt / dpkg에 익숙해지지 않았습니다. 항상 너무 복잡해 보였습니다. 저, 저는 yum / rpm에 가장 익숙합니다.

팩맨은 사용하기 매우 쉽습니다. 이것은 찬반 양론입니다. 오후에 그것을 사용하는 법을 배울 수 있습니다. -대부분 직관적이고 완전한 패키지 관리 기능을 사용하지만-이것은 크지 만 매우 유연하지 않습니다.

디자이너가 미리 기능을 생각하지 않았다면 당신은 엉망입니다.

p>

몇 가지 예 : pacman에는 기본 버전 관리가 없습니다. 패키지 버전을 다운 그레이드하려면 특정 패키지 버전을 다운로드하고 -U (업그레이드) 옵션을 사용하여 파일에서 설치해야합니다. Alwa에 매우 적합합니다. 시스템에서 최첨단 패키지를 사용합니다.

실제 내부 캐시 정리 / 완전 재 구축이 없습니다. (네트워크 문제로 인해) 패키지 다운로드가 손상된 경우 (예 : -Syu 동안) 오류 메시지는 정확하지만 그다지 유용하지 않습니다. “전체”상세도 및 디버그가 켜져 있어도 손상된 패키지를 찾아 내지 못합니다. , -Syyc의 양은 실제로 캐시를 정리하고 패키지를 다시 다운로드하지 않습니다. 좋은 소식은 -Sc가 다운로드 한 패키지의 위치를 알려주기 때문에 문제가되는 패키지를 제거하거나 (어떤 패키지인지 알아낼 수 있다면) 모두 제거하고 -Syu를 다시 시작할 수 있다는 것입니다.

팩맨과 dkms의 통합도 다소 문제가 있습니다. 새 커널을 설치하는 동안 dkms에서 오류가 계속 발생했습니다. dkms 빌드 & & dkms 설치를 사용하여 새 커널에 대해 문제없이 작동했지만 팩맨은 dkms가 실패한 이유에 대한 정보를 제공하지 않습니다. 커널 업그레이드 (새 커널의 올바른 경로를 통과 한 적이 없다고 생각하고 dkms가 기본 (현재 실행중인) 커널을 잘못된 버전으로 사용하도록합니다.)

그것에 대한 또 다른 일화 “의 비 유연성-as “나는 rpm / yum에 익숙합니다. 시스템에 파일이 있고 어떤 패키지가 파일을 소유하고 있는지 알고 싶다면 yum이 / path / to / file을 제공하고 파일을 설치할 수있는 모든 패키지를 가져올 수 있습니다. 파일이 수동으로 배치되었는데 이제 패키지를 설치하고 싶습니다. 새 패키지의 이름을 바꾸고 (확장자 .rpmnew 추가) 사용할 항목을 선택하겠습니다.

팩맨은 단순히 파일이 이미 있다고 오류를 표시합니다. 존재하지만 완전히 관련이없는 오류 메시지가 표시됩니다. 파일 “true”소유자와 현재 설치된 “filesystems”패키지 간의 충돌에 대해 마치 동일한 파일의 소유자 인 것처럼 불평합니다. 또한 대부분 로컬에 설치된 정보에 맞춰져 있습니다. 아직 설치되지 않은 패키지의 정보 (예 : 파일 목록 및 소유권)를 얻으려는 시도는 덜 직관적입니다.

간단히 말하면 yum만큼 성숙하지 않습니다. 그리고 아마도 dpkg는 “사용 편의성도 함께 제공하는 상대적인 비 유연성입니다.

댓글

• 포괄적 인 비 답변의 부족, 팩맨에 대해 익숙하지 않은 결과물 인 포인트가 많이 있습니다. 예를 들어 pacman -Qo $file는 $ file을 소유 한 패키지를 알려줍니다. 또한 OP가 Arch와 Debian 의 차이점을 명시 적으로 요청했기 때문에 전체 답변은 짚맨입니다. yum는 그것과 아무 관련이 없습니다 …
• 그래서 대답의 시작 부분에 그 사실을 명시 적으로 공개했습니다. -Qo $ file-아직 설치되지 않은 패키지에 대해 시도해 본 적이 있습니까?
• 설치되지 않은 패키지에 대해 시도해 볼 필요가 없습니다. 이를위한 다른 도구가 있습니다. 그리고 공개는 ‘ 당신이 질문에 대답하지 않았다는 사실을 완화하지 않습니다. ‘ : a ” 비교 “는 Debian ‘과 Arch의 차이점과 같지 않습니다 . ‘의 패키지 관리자
• @jasonwryan 물론 요점이 있습니다. 파일이 아직 설치되지 않았더라도 ‘ 어떤 패키지가 파일을 소유 할 수 있는지 파악할 필요가 없다고 ‘ ‘ 이러한 요구가 존재하지 않음을 의미하지는 않습니다. ‘ 그게 요점이었습니다. 다른 도구의 경우-알아야 할 필요가 있습니까? pacman은 패키지 관리자입니다. 요점과 관련하여-질문을 완전히 잘못 읽었을 수도 있지만 가벼운 PM 대 더 복잡한 PM에 관한 것이라고 가정했습니다. 나는 apt / dpkg가 적어도 yum / rpm만큼 복잡하다고 가정합니다. 기능면 에서요.
• 내 요점은 사과와 배에 대한 제한된 이해를 비교하여 사과와 오렌지를 비교하는 질문에 답하고 있다는 것입니다. 그리고 네, 질문을 완전히 잘못 읽었습니다 …