데비안과 아치의 패키지 관리의 차이점


9

이 글 에서 토론 한 결과, 데비안과 아치 패키지 관리의 차이점이 궁금합니다. 또한 사람들은 아치가 매우 가볍다 고 말하는 경향이 있으므로 패키지 관리와 관련이 있는지 궁금합니다. 데비안이 권장 사항 을 기본적으로 하드 종속성으로 취급하기 때문일 수 있습니까?

또한 두 패키지 관리자 간의 유연성 / 전력에 대해 언급 할 수 있습니까?

Arch에는 단일 Suite가 있고 Debian에는 여러 가지가 있으므로 (예 : APT 고정 및 고급 종속성 처리를 염두에두고) 데비안 패키지 관리 시스템에서 사용 가능한 일부 기능은 Arch 시스템과 관련이 없다는 것을 알고 있습니다. 두 시스템 모두에 적용 가능합니다 (즉, 데비안에서는 unstable 만 사용한다고 가정 ).


참고 : 데비안 패키지 관리에서는 APT, aptitude 및 dpkg를 말합니다. 아치 도구에 익숙하지 않으므로 팩맨 이외의 것이 있는지 모르겠습니다.
tshepang

답변:


7

나는 몇 주 이후로 정기적으로 아치를 사용하고 주제에 대해 전문가가 아니기 때문에이 대답은 결코 철저하지 않으며 "유연성 / 힘"에 대해 언급 한 몇 가지 사항입니다.

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

  • 또한 최적화로 인해 매우 빠르며 아마도 몇 가지 사항을 신경 쓰면됩니다 (아래 참조). 마지막 릴리스 (pacman 3.5, 며칠 전)는 관련된 데이터베이스 파일 수를 줄여서 성능을 개선하려고했습니다.

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

  • PKGBUILD 파일에 몇 줄만 있으면 패키지를 쉽고 빠르게 만들 수 있으며, 데비안 패키지와 같이 control / rules / copyright / changelog /를 처리 할 필요가 없습니다. 그리고 웹 UI를 몇 번만 클릭하면 패키지가 AUR (Arch User Repository)의 모든 사용자와 공유됩니다.

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

  • 트리거 / 후크 (패키저가 아무것도 할 필요없이 패키지 설치 파일의 위치를보고 아이콘 캐시, mandb 또는 기타를 업데이트하는 이유) ( 이를 구현할 계획 이있는 것으로 보입니다 ).

  • debconf (대부분의 일이 아니며 수동으로 작업을 강제로 수행하여 정확하게 수행 된 것을 알도록 강요) 및 새로운 구성 파일의 적절한 처리 (적어도 pacman이 새 패키지의 구성 파일이 언제인지 알기를 원합니다. 버전이 새 버전에서 변경되었거나 로컬에서 수정했기 때문에 설치된 버전과 다릅니다.

  • (것 같다가되고있어 서명 패키지 에 근무 ).

아치가 가벼우면 유일한 기본 이유는 기본적으로 설치된 패키지가 거의 없으며 필요한 것을 추가하는 것이 좋습니다. 따라서 기본적으로 선택적 종속성을 설치하지 않으면 사용자가 부풀어 오르지 않도록 설득 할 수 있습니다.


나는이를 구문 분석 할 수 없습니다 : 하지만 난 그것없이 할 수 있고, 그런데 내가 더 잘 알고 . 마지막 문장에도 오타가 있습니다.
tshepang

팩맨 패키지 매니저는 어떤 언어로 작성됩니까? dpkg / apt와 비슷한 저수준 및 고수준 패키지 관리 기능이 있습니까? 그렇다면 그 기능을 무엇입니까?
Faheem Mitha

@Tshepang : 죄송합니다. 영어가 모국어가 아닙니다. 나는 "이 기능 (debconf)을 갖지 않는 것은 큰 문제가되지 않으며, 수동으로 일을하도록 강요함으로써 정확히 무엇을해야하는지 알게되었다"는 것을 의미했다.
gentledevil

@Faheem Mitha : Pacman은 C로 작성되었으며 libalpm의 프론트 엔드이며 "고수준"및 "저수준"패키지 관리를 모두 처리합니다.
gentledevil

@zanko : 나도 원어민이 아닙니다. 내가 원했던 것은 문장이 아닌 의견이 아니라 게시물 자체를 명확하게하는 것입니다. BTW, 내가 언급 한 오타는 선택 사항 입니다. 게시물을 직접 편집 할 수는 있지만 설명 부분과 함께 게시물을 수정하는 것도 가능하다고 생각했습니다.
tshepang

6

Ubuntu lucid로 Linux 여행을 시작했으며 현재 Arch를 사용하고 있습니다. 소수의 아치 패키지를 작성했으며 데비안 패키지를 작성하는 것보다 훨씬 쉽다고 말할 것입니다. 그러나 @gentledevil 에게 Arch에는 패키지로 불리는 후크 시스템이 있다고 지적하고 싶습니다 install file.

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

또한 데비안 패키지 관리 도구를 사용하여 응용 프로그램을 '고정'이라고 언급 한 것을 알았습니다. 아치의 팩맨이 내장 된 것을 물론이 /etc/pacman.conf포함 설정의 수, 수용 IgnorePkg =등호 후 나열된 모든 패키지에 대한 업그레이드를 방지 할 수 있습니다 (공백으로 구분)


1
또한 repo 패키지는 아니지만 powerpillpacman 의 래퍼를 사용하여 여러 패키지를 병렬로 다운로드 할 수 있으므로 pacman -S libfoo libbar libbaz각 패키지를 하나씩 다운로드하는 대신 세 개를 동시에 다운로드하여보다 나은 연결을 위해 업그레이드 속도를 크게 향상시킵니다.
hanetzer

-1

너무 멀리 가기 전에 그림 리눅스 타임 라인을 공부하십시오

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


3 대 부모

  1. Redhat, Now Fedora-패키지 관리자-RPM, Redhat Package Manager의 줄임말 rpm
  2. 슬랙웨어-패키지 관리자-tgz, 일반 압축 파일. 이 파일은 압축 된 파일이지만 Slackware 업스트림에서 빌드되어 저장소에 배치되며 포트라고도합니다.
  3. 데비안-DEB, 데비안의 줄임말로 명령 행 도구는 Aptitude or Apt

이 부모는 오늘날 우리가 알고있는 대부분의 배포판에서 어머니와 아버지입니다. 패키지 관리 시스템의 아이디어 / 개념은 어떤 형태 나 방식으로 도출되거나 공유되었습니다. 어쨌든 이러한 모든 부모는 이진 배포자이므로 프로그램은 타사에서 패키지화하여 결정한 다음 리포지토리에 저장하고 사용자 기반에서 사용하거나 설치합니다.

미성년자 3 명

  1. Scratch에서 Linux-소스 기반, 패키지 관리자 없음
  2. 젠투- 스크래치 에서 리눅스에서 파생되었습니다 . 이 배포판은 기본적으로 Scratch의 Linux와 Portage / emerge라는 패키지 관리자입니다.
  3. SourceMage-패키지 관리자 마법사

이 부모는 사용자 기반이 강력하고 쉬운 구성으로 속도와 설치 용이성을 교환하기 때문에 미미합니다. 각 패키지는 변수 및 구성 파일을 사용하여 처음부터 다운로드하여 컴파일됩니다.

다리

아치는 3 개의 주요 부모 중 하나와 같은 이진 배포판과 3 개의 작은 부모 중 하나와 같은 소스 기반 배포판 사이의 다리로 만들어졌습니다. 따라서 다른 부모가이 기능을 제공하지 않았기 때문에 타임 라인에서 부모로 상태를받습니다. Pacman은 사용자가 공식 저장소 또는 바이너리 빌드 시스템을 사용하여 사용자 정의 빌드 패키지에서 바이너리 패키지를 설치할 수있는 유연성을 가지고 있습니다. 이 개념은 미성년 부모가 제공하는 힘과 주요 부모가 제공하는 설치 용이성 사이의 균형을 제공합니다.


제 생각에는 모든 패키지 관리자가 동일한 시스템을 관리하고 유지 관리하는 동일한 작업을 수행하기 때문에 시스템의 힘을 보여주는 것은 패키지 관리자가 아닙니다. 따라서 사용하는 시스템은 다음과 같은 요소에 의해 결정되어야합니다.

  • 사용자 수준 : 리눅스를 처음 접하는 사람은 주요 부모로 시작해야하지만 기술적으로 능숙한 사람은 균형을 찾을 것입니다.
  • 시스템으로 수행하려는 작업 : 사용자가 연결된 LAMP 서버를 실행하는 것은 웹 브라우징 및 전자 메일 읽기를 위해 데스크탑 PC를 실행하는 것과는 완전히 다릅니다.
  • 컴포트 레벨 : 기술 수준이 뛰어나지 만 시스템을 컴파일하는 주말을 보내고 싶지 않은 사용자 수준은 견딜 수 없습니다. 알고있는 모든 사람이 다른 것을 선택하는지 여부에 관계없이 주요 부모를 선택하게됩니다.

이것은 팩맨과 데비안의 패키지 관리 도구를 비교하는 것이 아니라 배포판의
계보에 중점을두고

@jasonwryan 즉, 포인트는 모든 패키지 관리자가 동일한 작업을 수행으로, 즉,의 emerge packagename와 동일합니다 sudo apt-get install packagename.
eyoung100

그 수준에서 그렇습니다. 그러나 그것은 문제의 요점, 즉 팩맨을 {apt, aptitude}와 차별화하는 요소를 완전히 놓친 것입니다.
jasonwryan

@jasonwryan 나는 The Bridge 섹션에서 대답했다. 그 외에는 차이가 없습니다. 유일한 차이점은 의미 론적입니다. 즉 하나의 명령 대 다른 명령입니다. OP가 의미상의 차이점을 찾고 있다면 그에 대한 매뉴얼이 있습니다.
eyoung100

-3

이것은 결코 완전하거나 철저한 대답은 아닙니다. 나 앞의 포스터는 이미 아주 좋은 지적을했으며, 2 센트를 더하고 싶습니다. 또 다른 것은-apt / dpkg에 익숙해지지 않았습니다. 그것은 항상 나에게 너무 복잡해 보였습니다. 나는 yum / rpm에 가장 편안합니다.

pacman은 사용하기 매우 쉽습니다. 프로와 콘-당신은 하루 오후에 그것을 사용하는 것을 배울 수 있습니다 (패키지 건물 제외)-주로 직관적이고 완전한 패키지 관리 기능을 사용하지만-이것은 크지 만- 매우 유연하지 않습니다.

디자이너가 미리 기능을 생각하지 않았다면 문제가 생겼습니다.

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

실제 내부 캐시 정리 / 완전한 재구성은 없습니다. (네트워크 문제로 인해) 패키지 다운로드가 손상된 경우 (예 : -Syu 중) 오류 메시지는 정확하지만 많이 사용되지는 않습니다. "전체"세부 정보 및 디버그가 설정된 경우에도 손상된 패키지를 정확히 찾아 내지 않습니다. -Syyc는 실제로 캐시를 정리하고 패키지를 다시 다운로드하지 않습니다. 좋은 소식은 -Sc가 다운로드 한 패키지의 위치를 ​​알려주므로 문제가있는 패키지 (있는 패키지를 파악할 수있는 경우) 또는 모두 제거하고 -Syu를 다시 시작할 수 있다는 것입니다.

dkms와의 pacman 통합은 다소 문제가 있습니다-새로운 커널을 설치하는 동안 dkms에서 오류가 계속 발생했습니다. dkms build && dkms를 사용하면 새로운 커널에 대한 설치가 장애없이 작동했지만 pacman은 커널 업그레이드 중에 dkms가 실패한 이유에 대해 아무런 정보도 제공하지 않습니다 (새 커널의 올바른 경로를 통과하지 못했고 dkms가 기본값을 사용하도록하십시오) (현재 실행중인) 커널이지만 버전이 잘못되었습니다.

언급 한 바와 같이 유연성이 없다는 또 다른 일화는 rpm / yum에 익숙합니다. 시스템에 파일이 있는데 어떤 패키지를 소유하고 있는지 알고 싶다면 yum provides / path / to / file을 실행하고 패키지가 설치되어 있지 않더라도 모든 패키지를 가져올 수 있습니다. 파일을 수동으로 배치 한 후 패키지를 설치하려면 새 파일 이름을 바꾸고 (확장명 .rpmnew 추가) 사용할 항목을 선택하겠습니다.

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

간단히 말해서-그것은 yum만큼 성숙하지 않으며 아마도 dpkg는 사용하기 쉽고 융통성이 없습니다.


1
포괄적 인 비 응답의 부족으로, 실제로 팩맨에 익숙하지 않은 제품이라는 점이 많이 있습니다. 예를 들어 pacman -Qo $file$ file을 소유 한 패키지를 알려줍니다. 또한, 전체 대답은 명시 적으로 아치 사이의 차이를 묻는 OP로 strawman이다 데비안은 - yum그것과는 아무 ...이 없습니다
jasonwryan

그렇기 때문에 답변을 시작할 때 해당 사실을 명시 적으로 공개했습니다. -Qo $ file과 관련하여-아직 설치되지 않은 패키지에 대해 시도한 적이 있습니까?
Dani_l

설치되지 않은 패키지에는 시도하지 않아도됩니다. 이를위한 다른 도구가 있습니다. 그리고 공개는 당신이 질문에 대답하지 않았다는 사실을 완화시키지 않습니다. yum과 pacman 사이의 "비교" 는 데비안과 아치의 패키지 관리자의 차이점과 동일 하지 않습니다 .
jasonwryan

@jasonwryan 물론 포인트가 있습니다. 아직 설치되어 있지 않은 파일을 소유 한 패키지를 파악할 필요가 없다고해서 그러한 요구가 존재하지 않는다는 의미는 아닙니다. 그게 요점입니다. 다른 도구에 관해서는-그들이 알아야 할 기초가 있습니까? pacman은 패키지 관리자입니다. 요점과 관련하여-질문을 완전히 잘못 읽었을 수도 있지만 가벼운 PM과 복잡한 PM에 관한 것으로 가정했습니다. 나는 apt / dpkg가 최소한 yum / rpm만큼 복잡하다고 가정합니다.
Dani_l

내 요점은 사과와 배에 대한 제한된 이해를 비교하여 사과와 오렌지를 비교하는 것에 대한 질문에 답하고 있다는 것입니다. 그리고 네, 당신은 그 질문을 완전히 잘못 읽었습니다 ...
jasonwryan
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.