Debian build toolchain
debian subdirectory added there by the package maintainer.데비안 빌드 툴체인은 업스트림 소스 타르볼에서 데비안 소스 패키지 (.dsc)와 데비안 바이너리 패키지 (.deb 파일)를 만들기 위해 사용되는 소프트웨어 유틸리티의 모음입니다.
이들 도구는 데비안 프로젝트와 우분투와 같은 데비안-기반 배포판에서도 사용됩니다.
Troubleshootings
- Job 제한
- 큰 프로젝크를 컴파일할 경우에서, CPU 자원을 모든 쓰레드에서 100%를 사용해서, Ubuntu on Ryzen CPU에서 처럼, 쓰레드의 제한을 계획했습니다. 우선, Make (software)에서 GNUMAKEFLAGS로 제한했지만, 패키지 제작에서 컴파일러 옵션으로는 작용되지 않았습니다. 어쨌든, "-j16" 옵션으로 CPU 자원을 제한하는 것처럼 보였지만, 여전히 CPU 100%를 사용하는 경우가 있습니다.
Overview
자유 소프트웨어에 대해 소스 코드는 전형적으로 타르볼이라고 불리는 압축된 타르 아카이브에서 배포됩니다. 데비안은 바이너리-지향 배포판이며, 그것의 deb 패키지는 소프트웨어가 기대하는 파일 시스템 계층 구조로 배열된 사전-컴파일된 바이너리와 데이터 파일을 포함함을 의미합니다. 데비안 빌드 툴체인은 따라서 업스트림 빌드 시스템을 사용하여 올바른 deb 패키지를 빌드하는 방법에 대한 지침이 필요합니다.
이들 지침은 패키지 관리자에 의해 패키징되는 소프트웨어에 대해 소스 트리에 추가되는 debian 하위디렉토리에 저장됩니다. 수정된 소스 트리에서 직접적으로 패키지를 빌드하는 것이 가능하지만, 관리자에 의해 재배포-가능한 형식에서 업스트림 소스로 만들어진 변경 사항을 포함하는 소스 패키지를 만드는 것이 표준 관행입니다.
Source packages
전형적인 데비안 소스 패키지는 다음 세 개의 파일로 구성됩니다:
- 원본 타르볼 (
orig.tar) – 만약 그것이tar형식이고 변경 사항이 필요하지 않으면 업스트림 소스 타르볼의 단순한 복사본이거나 다시-포장된 타르볼입니다. 후자는 타르볼 형식에서 출시된 적이 없는 버전 제어 시스템의 스냅샷을 포함하거나, 관리자가 데비안 자유 소프트웨어 지침과 호환되지 않는 파일을 제거해야 하면 발생할 수 있습니다. debian.tar파일 – 패키지 관리자에 의해 만들어진 업스트림 소스에 대한 변경 사항을 포함하는 파일. 이것은 전체debian디렉토리를 포함합니다. 외부에서 수정된 임의의 파일은 빌드 전에 자동으로 적용되는debian/patches디렉토리 내부에 패치 파일로 집계됩니다.dsc파일 – 소스 패키지를 구성하는 모든 파일의 이름과 그것들의 SHA256 체크섬과 같은 메타데이터를 갖는 텍스트 파일. 그것은 역시 소스 패키지 작성자의 서명을 포함합니다.
예를 들어, 업스트림 버전 1.2.3와 데비안 버전 4를 갖는 foo라는 이름을 갖는 소스 패키지는 다음 파일로 구성될 수 있습니다:
foo_1.2.3.orig.tar.gzfoo_1.2.3-4.debian.tar.gzfoo_1.2.3-4.dsc
소스 패키지는 dpkg-buildpackage 도구 또는 그것의 래퍼 debuild를 사용하여 생성됩니다. 소스 패키지를 생성하기 위해 호출될 때, dpkg-buildpackage는 임의의 중간 파일의 소스 트리를 정리하기 위해 관리자의 규칙을 호출하고, 다양한 온전성 검사를 수행하고, 마지막으로 debsign 유틸리티를 사용하여 패키지 관리자의 키로 dsc 파일에 서명합니다.
역 과정은 – 소스 패키지에서 압축을 푼 소스 트리를 생성합니다 – dpkg-source 유틸리티를 사용하여 수행되며, 이것은 원본 타르볼을 하위디렉토리로 추출하고, 그 안에 debian.tar 타르볼을 추출하고, 존재하는 임의의 퀼트(quilt) 패치를 적용합니다. 이것은 소스 패키지에서 바이너리 패키지를 빌드할 때 빌드 시스템이 수행하는 첫 번째 단계입니다.
오래된 소스 패키지 (소스 형식 1을 사용)는 debian.tar 대신 .diff.gz 파일을 가집니다. 이것은 debian 디렉토리와 패치 시스템에 의해 관리되지 않는 업스트림 소스에 대한 임의의 변경 사항을 포함하는 통합된 diff입니다.
The debian directory
debian 디렉토리는 dpkg-buildpackage에 의해 바이너리와 소스 패키지 둘 다를 생성하기 위해 사용되는 파일을 포함합니니다. 지침에 단일 spec 파일을 사용하는 RPM과 달리, 데비안 도구는 여러 파일을 갖는 전체 하위디렉토리를 사용합니다. 패키지를 올바르게 빌드하기 위해 최소한에서 요구되는 셋의 파일 – changelog, control, 및 rules이 필요합니다. 네 번째 파일, copyright는 데비안 정책에 의해 의무화되어 있지만, 기술적인 것이 아니라 법적 요구사항입니다.
설계에 의해, debian 디렉토리에서 모든 파일은 텍스트 파일이며, 그것의 대부분은 사람이 읽을 수 있고 간단한 텍스트 편집기로 편집될 수 있습니다.
debian/changelog
이것은 패키지가 만들어진 이후의 그것의 모든 버전에 대한 정보를 포함하고 있습니다. 빌드 도구는 오직 패키지 버전, 긴급성 (데비안 자체에만 해당), 및 이번 릴리스에서 수정한 배포판에서 버그를 결정하기 위해 사용되는 최상위 항목만 처리합니다.
예를 들어, foo라는 이름-지은 패키지에 대해, 예제 debian/changelog 엔트리는 다음과 같이 읽을 수 있습니다:
foo (1.2.3-1) unstable; urgency=low
* New upstream release.
* Dropped 02_manpage_hyphens.dpatch, fixed upstream.
* Added 04_edit_button_crash.dpatch: fix a crash after pressing the edit button. (Closes: #654321)
* debian/control: foo should conflict with libbar. (Closes: #987654)
-- John Doe <jdoe@example.com> Fri, 30 Nov 2007 15:29:42 +0100
데비안은 debian/changelog 파일을 조작하기 위한 두 가지 주요 유틸리티를 제공합니다:
dch는changelog에 새 항목을 추가하거나 기존 항목을 수정하기 위해 사용됩니다.dpkg-parsechangelog는 가장 최근 항목을 구문 분석하고debian/control과 유사한Key: value형식에서 그것으로부터 데이터를 추출합니다. 그것은 주로 스크립트에서 사용됩니다.
debian/control
이 파일은 소스 패키지와 그것이 빌드하는 모든 바이너리 패키지에 대한 정보가 포함하고 있습니다 (둘 이상이 있을 수 있습니다; 예를 들어, 소스 패키지 libbar는 단지 공유 라이브러리를 포함하는 바이너리 패키지 libbar0와 바이너리와 헤더 파일의 정적 버전을 포함하는 libbar-dev에 대한 소스 역할을 할 수 있습니다).
그것은 패키지 이름, 관리자, (바이너리 패키지에 대해) 대상 아키텍처, 빌드 종속성 (패키지를 성공적으로 빌드하기 위해 설치해야 하는 패키지), 및 종속성 (설치될 때 제대로 작동하기 위해 패키지에 대해 설치되어야 하는 패키지)과 같은 항목을 나열합니다.
debian/rules
이 파일은 수행할 동작 (clean, build, install, binary)을 지정하는 단일 인수와 함께 dpkg-buildpackage에 의해 호출되는 스크립트입니다. 비록 그것이 기술적으로 임의의 종류의 스크립트가 될 수 있지만, 그것은 항상 makefile로 구현됩니다.
업스트림 빌드 시스템을 호출하는 것 외에도, debian/rules에서 대부분의 지침은 고도로 반복적이고 유비쿼터스이고, 따라서 사실상 모든 debian/rules 파일은 이 기능성을 debhelper 스크립트로 래핑합니다. 예를 들어, 사용된 공유 라이브러리를 기반으로 종속성을 자동으로 결정하는 것은 매우 공통적인 동작이고, 따라서 그것을 수행하기 위해 필요한 코드를 포함하는 대신, debian/rules 파일은 단순히 dh_shlibdeps을 호출합니다. debhelper 스크립트의 다른 예제는 debian/copyright와 같은 스톡 문서 파일을 적절한 위치에 설치하는 dh_installdocs 또는 패키지의 파일에 올바른 액세스 권한이 있는지 확인하는 dh_fixperms를 포함합다 (예를 들어, /usr/bin에서 실행 파일은 " 실행-가능" 비트 설정을 가지지만, 오직 수퍼유저에 의해 쓸 수 있습니다).
debhelper 스크립트의 순서는 자체로 반복적이기 때문에, 일부 패키지는 각 debhelper 명령을 직접 실행하는 대신 dh 또는 CDBS를 사용함으로써 직접 debian/rules 파일을 단순화합니다.
Patch systems
때때로, 관리자는 원본 소스를 수정해야 합니다. 과거에는, 이것은 종종 위치에서 단순히 파일을 편집하고 diff.gz에서 변경 사항을 포함함으로써 행해졌지만, 이것은 모든 변경 사항이 검사되고 필요할 때 병합되어야 하기 때문에 새로운 업스트림 버전이 출시될 때 어려운 유지 관리를 만들 수 있습니다.
최신 소스 형식, 3.0 (퀼트)은 퀼트 패치 시스템을 수정 사항을 논리적으로 분리된 패치의 그룹으로 나뉘는 것을 허용하기 위해 사용하며, 각 패치는 하나의 변경 사항을 처리하고 있는 그대로 업스트림으로 보낼 수 있습니다. 이들 패치는 debian/patches에 있습니다.
dpatch와 같은 다른 패치 시스템을 사용하는 패키지도 있습니다. 그것은 헤더를 갖는 비-표준 통합된 diff 파일인 셸 스크립트를 생성하고 실행하며, 그럼에도 불구하고 표준 diff 유틸리티와 호환됩니다. debian/rules 파일은 바이너리 패키지를 빌드하기 전에 dpatch apply-all을 호출하고 소스 패키지를 빌드하기 전에 (그리고 빌드 부산물을 정리하기 전에) dpatch deapply-all을 호출하도록 수정됩니다. quilt와 특정 기타 패치 시스템은 특수 헤더에 대한 필요성을 제거하고 표준 diff 파일을 사용합니다.
Tracking changes in source packages: debdiff and interdiff
때때로 사용자는 두 소스 패키지 사이의 차이를 보고 싶어할 수 있습니다 – 예를 들어, 배포판의 버그 추적 시스템에 포함하기 위해 현재 저장소에 있는 버전에 대한 제안된 패치를 생성하기 위함입니다. 만약 두 패키지가 같은 업스트림 버전을 사용하면, 이것은 debdiff 도구를 사용하여 수행될 수 있으며, 이 도구는 포함된 패키징 변경 사항을 갖는 두 소스 트리 사이에 차이점을 생성합니다.
만약 두 버전에 대해 업스트림 타르볼이 다르면, 그러한 소박한 비교가 사용될 수 없습니다. 대신에, interdiff 유틸리티는 두 diff 파일 사이 (이 경우에서 두 diff.gz 파일 사이)에 diff를 생성하기 위해 사용될 수 있습니다. 단점은 interdiff 출력은 적용하기 위해 더 많은 노력을 요구하고, 변경 사항을 적용하는 출력은 역시 최신 업스트림 타르볼을 찾고 다운로드해야 한다는 것이며, 이는 전형적으로 debian/rules에서 get-orig-source 규칙을 사용하여 수행됩니다.[1]
Sanity checks with lintian
이 도구는 데비안 정책 위반과 잠재적인 호환성 문제를 포함하여 바이너리와 소스 패키지 둘 다에서 공통적인 패키징 실수에 대해 자동화된 검사를 제공합니다.
관리자는 전형적으로 lintian에 의해 지적된 모든 문제를 수정하는 것을 목표로 하지만, 다른 배포판은 그것들에 관련하여 다른 정책을 가질 수 있습니다. 예를 들어, 우분투는 우분투에서 시작된 모든 패키지를 깨끗하게 되도록 요구하지만, 데비안에서 우분투로 병합된 패키지에 대해, 그러한 요구 사항이 없습니다: 새로운 변경 사항은 단순히 기존 패키지 외에 임의의 경고를 추가하지 않아야 합니다. 이것은 데비안과 우분투 패키지 사이의 차이를 최소화하기 위해 수행됩니다.
다음은 예제 lintian 출력입니다:
W: foo source: source-contains-CVS-dir config/CVS N: N: Package contains a CVS directory. It was most likely included by N: accident, since transient CVS data usually doesn't belong in packages. N: Export from CVS rather than use a checkout. N:
W: libfoo-dev: debian-changelog-line-too-long line 2 N: N: The given line of the latest changelog entry is over 80 columns. Such N: changelog entries may look poor in terminal windows and mail messages N: and be annoying to read. Please wrap changelog entries at 80 columns N: or less where possible. N:
I: foo: arch-dep-package-has-big-usr-share 3399kB 77% N: N: The package has a significant amount of architecture-independent data N: in /usr/share, while it is an architecture-dependent package. This is N: wasteful of mirror space and bandwidth, as we then end up with N: multiple copies of this data, one for each architecture. N: N: If the data in /usr/share is not architecture-independent, it is a N: policy violation, and in this case, you should move that data N: elsewhere. N: N: See also: N: http://www.debian.org/doc/developers-reference/ch-best-pkging-practice N: s#s-bpp-archindepdata
Isolated build environments
소스 패키지는 빌드 종속성이 충족되는 조건 아래에서 대상 배포판 버전의 임의의 설치에서 빌드되도록 의도되어 있습니다. 게다가, 빌드는 시스템에 이미 존재하는 패키지에 의해 영향을 받게 될 수 있습니다.
패키지가 임의의 시스템에서 빌드되는지 확인하고, 임의의 외부 요인을 제외하기 위해, 격리된 빌드 환경을 만드는 도구가 사용됩니다. 이것들은 pbuilder (Personal Builder)와 sbuild입니다.
이들 도구는 chroot에서 최소한의 작업 시스템을 유지하고, debian/control에 나열된 필요한 빌드 종속성만 설치하고, 빌드가 완료될 때 그것들을 제거합니다. 그러므로, pbuilder를 사용하여, 패키지 관리자는 일부 빌드 종속성이 debian/control에 지정되지 않았는지 감지할 수 있습니다. 역시, pbuilder는 관리자가 실행 중인 배포판 이외의 배포판: 예를 들어, 개발 버전에 대해, 실제로 안정적인 버전을 실행하는 동안에 대해 테스트-빌드하는 것을 가능하게 만듭니다.
sbuild는 자동화된 빌드 데몬 (buildd)과의 통합을 위해 설계되었습니다. 그것은 지원되는 모든 각 아키텍처에 대해 바이너리 패키지를 자동으로 빌드하는 데비안 빌드 서버에 의해 사용됩니다. Launchpad 서비스는 공식 배포판과 개인 패키지 아카이브 (PPA) 둘 다에 우분투에 대해 유사한 빌드 데몬을 제공합니다.
See also
References
- ^ "Chapter 4 - Source packages". Debian Policy Manual. Retrieved 1 October 2014.
External links