왜 pbuilder를 통해 sbuild를 사용합니까?

깨끗하고 재현 가능한 환경에서 데비안 패키지를 빌드하는 방법은 여러 가지가 있습니다. 가장 자주 사용되는 것은 pbuilder와 sbuild입니다. 개인적으로 저는 항상 pbuilder를 사용했습니다. pbuilder를 사용하고 유지 관리하는 것이 훨씬 쉽습니다. 두 가지를 나란히 비교할 수 없었습니다. 내가 무엇을 놓치고 있습니까?

pbuilder보다 sbuild를 사용하면 어떤 이점이 있습니까?

sbuild와 pbuilder는 수년에 걸쳐 거의 동일한 기능을 갖도록 개발되었으며, 기능이 추가 될 때 다른 기능에 의해 빠르게 채택되는 경향이 있습니다.

데비안 패키징은 정책 중심의 형식이므로, 주어진 빌드 문제가 빌더 구현의 버그인지 또는 빌드 시스템의 여러 구현을 갖도록 패키지가 빌드 된 문제인지를 결정하는 데 도움이됩니다. 이를 유지하기 위해서는 최고의 빌드 시스템이 정책을 가장 정확하게 구현할 수 있도록 협업 경쟁의 정신으로이를 지원하는 강력한 파트너가 있어야합니다.

sbuild와 pbuilder의 내부 메카니즘은 상당히 다르므로 빌드 의존성을 충족시키기 위해 어떤 패키지를 가져 오거나 가져 오는 방법, 데비안 / 규칙의 다양한 대상을 호출하는 정확한 메커니즘 등이 약간 씩 달라질 수 있습니다. 특정 패키지에 대한 매우 특정한 경우의 동작 차이. 대부분의 경우 이는 하나 또는 다른 구현의 버그를 나타내며 때로는 패키징 정책의 명확성이 부족함을 반영합니다. 어쨌든 동작 변경이 해결되어야합니다.

데비안과 우분투의 공식 빌드는 sbuild (아카이브에서 사용 가능한 sbuild는 아니지만)를 사용합니다.이 빌드는 빌드 할 때 패키지가 노출 될 구성과 일치 할 것이라는 확신이 있기 때문에 일부 개발자는 이점으로 간주합니다. 모든 사람이이 작업을 수행하더라도 정책의 버그와 sbuild의 버그를 구별하는 기능을 잃게됩니다.

역사적으로, pbuilder 개발은 초기에는 최종 사용자 및 sbuild 개발이 빌드 및 아카이브 관리자의 요구에 초점을 두었 기 때문에 처음에는 개발자의 요구에 중점을 두었습니다. 사람들이 pbuilder를 기반으로 아카이브 관리 시스템을 구축하고 sbuild를 사용하여 더 유용한 개발자 도구를 구축함에 따라 최근 이러한 초점이 바뀌 었습니다.

두 툴 (또는 일반적으로 사용 가능한 close 파생 상품)은 시스템에 압축을 푼 타르볼로 chroot를 별도의 볼륨 (특별한 마운트를위한 사용 가능한 후크 포함 : LVM 스냅 샷), 오버레이 파일 시스템 사용, COW (Copy-On-Write) 시맨틱 사용 등을 지원합니다. 두 도구는 일반적인 사례를 간소화하는 간단한 명령 줄 도구 (패키지 테스트 빌드)와 복잡한 사례 (대규모 아카이브)를 지원하는 풍부한 후크 의미를 제공합니다. 둘 다 chroot에서 테스트 환경을 작성하는 수단을 제공합니다. 요컨대, 두 도구 모두 패키지 작성 도구에서 원하는 것으로 생각되는 모든 것을 제공합니다 (그리고 둘 다 버그와 패치를 받아들이는 활성 업스트림이 있습니다).

요약하면 pbuilder에 만족하면 계속 사용하십시오. 당신이 sbuild를 가지고 놀고 싶다면, 자유롭게 느끼십시오. 가장 좋은 도구는 당신이하는 일에 익숙한 도구입니다.

Emmet에 동의하지 않는 것은 항상 위험하므로, 그의 대답이 더 정확하다는 것을 인정하여 시작하겠습니다. 그러나 개인적으로 pbuilder는 사용자 친화적이고 성능이 뛰어납니다.

Ubuntu 12.10 이상을 사용하는 경우 원시 pbuilder 주위 에 매우 친숙한 래퍼 세트 인 우수한 pbuilder 스크립트를 설치하십시오 .

Ubuntu 12.04를 사용하는 경우 백 포트 저장소에서 pbuilder-scripts를 설치할 수 있습니다.

이제 동등한 작업의 사용자 친 화성을 비교하고 대조합시다. 이 예제에서는 x86에서 호스팅되는 ARM chroot를 사용하여 살펴 보지만 x86에서 호스팅되는 x86 chroot에도 개념이 적용됩니다. pbuilder-scripts 래퍼를 사용하고 있습니다.

한 가지 주목할 점은 pbuilder-scripts가 Ruby on Rails가 사용자를 대신하여 빠르게 결정을 내릴 수있는 방식과 유사한 약간의 규칙을 구현한다는 것입니다. 나는 우리가 갈 때 이것들을 지적하려고 노력할 것이다.

chroot 만들기

mk-sbuild --arch=armhf quantal

vs

# in addition to the chroot, creates a new, empty directory named ~/Projects/quantal-armhf
pcreate -a armhf -d quantal quantal-armhf

평결 : tie , 두 명령 줄은 매우 간단하며 필요한 경우 더 멋진 사용 사례를 위해 추가 옵션을 사용할 수 있습니다. 그러나 pcreate로 작성된 추가 새 디렉토리에 유의하십시오.

소스 패키지 다운로드

# standard debian/ubuntu method, works in any directory
apt-get source casper

vs.

# 'quantal-armhf' is the name of the chroot created earlier
# results in downloading package to: ~/Projects/quantal-armhf/casper/
pget quantal-armhf casper

평결 : 표준 데비안 / 우분투 모범 사례를 사용하고 있기 때문에 sbuild 에 대한 약간의 우위 . pget이 사용하는 규칙은 처음에는 이상하게 보일지 모르지만 Ubuntu의 여러 릴리스에서 여러 패키지로 작업하기 때문에 부과하는 조직이 마음에 듭니다. apt-get source는 명령을 실행할 때마다 소스를 추출하여 * .orig.tar.gz, * .debian.tar.gz, * .dsc 및 확장 디렉토리를 남겨 둡니다. 지저분 해 나는 조직의 아름다움이 곧 올 것이라고 약속한다.

chroot 임시 버전을 입력하십시오.

schroot -c quantal-armhf

vs.

ptest quantal-armhf

평결 : pbuild의 가장자리 가 적고 입력 할 문자 수가 적습니다. 이 chroot 입력 버전에서 chroot를 종료하면 여기에서 변경 한 내용이 모두 손실됩니다. 또한 schroot에서는 일반 사용자로 유지되지만 ptest를 사용하면 chroot에 루트 사용자로있게됩니다.

chroot를 입력하고 변경 사항을 저장하십시오.

sudo schroot -c quantal-armhf-source -u root

vs.

ptest quantal-armhf --save

평결 : 내 의견으로 는 pbuild의 약간의 가장자리 , 적은 문자 및보다 직관적 인 명령 줄 인수. chroot에 들어가는이 버전에서는 변경 사항이 저장되어 향후 호출을 위해 저장됩니다.

chroot 내에 패키지를 빌드하십시오

debuild -S -sa -I -i
sbuild -A --arch armhf -d quantal-armhf /path/to/casper-1.315.dsc

vs.

# must be invoked when pwd is ~/Projects/quantal-armhf/casper/casper-1.315
pbuild

평결 : pbuild , 이제 pbuild의 규칙을 사용할 때 첫 번째 중요한 승리를 볼 수 있습니다. 이것은 아키텍처, chroot의 이름을 지정하고 sbuild에 필요한 * .dsc 파일의 경로를 요구하는 것과 달리 기억할 것이없는 간단한 간단한 명령입니다. 또한 sbuild를 사용하여 새 * .dsc 파일을 생성해야하지만 pbuild가 자동으로 수행합니다.

chroot에서 두 번째로 동일한 패키지를 빌드하십시오.

위 예제에서 sbuild와 pbuild는 각각의 chroot에 build-deps를 다운로드하여 설치합니다. 그러나 pbuild 는 다운로드 한 .deb 파일을 / var에 저장하므로 pbuild를 두 번 호출하면 모든 빌드 -deps를 다시 다운로드 할 필요는 없습니다 (여전히 chroot에 설치되어 있어야 함). sbuild는 .deb 파일을 캐시하지 않으므로 (적어도 기본적으로는 아님) chroot에 설치 될 때까지 기다리는 것 외에도 모든 빌드 -deps를 다시 다운로드해야합니다.

평결 : 긴 샷으로 pbuild . build-deps 캐싱은 훌륭한 기본 설정이며 pbuild는 아카이브에 최신 버전의 build-dep가 있는지 감지 할 수있을 정도로 똑똑하며 필요한 경우 새 버전을 풀다운합니다. 빌드 딥이 많은 복잡한 패키지의 경우이 간단한 설정으로 수명을 단축 할 수 있습니다.

개요

기본적으로 pbuilder-scripts는 sbuild에 비해 훨씬 친숙하고 빠릅니다. 물론 pbuilder를 더 빠르게 만드는 방법이 있습니다 (tmpfs로 빌드하고 일부 chroot 훅을 비활성화하십시오) .sbuild에도 동일한 트릭이있을 수는 있지만 알지 못합니다.

이것이 도움이되기를 바랍니다.