6장. 소프트웨어 패키지
RPM 패키지 관리자를 사용한 패키징 프로세스의 기본 사항을 알아보십시오.
6.1. 사양 파일 정보 링크 복사링크가 클립보드에 복사되었습니다!
사양 파일은 rpmbuild 유틸리티에서 RPM 패키지를 빌드하는 데 사용하는 지침이 포함된 파일입니다.
사양 파일은 일련의 섹션에 지침을 정의하여 빌드 시스템에 필요한 정보를 제공합니다. 이러한 섹션은 Preamble 및 spec 파일의 Body 부분에 정의되어 있습니다.
- Preamble 섹션에는 본문 섹션에서 사용되는 일련의 메타데이터 항목이 포함되어 있습니다.
- Body 섹션은 지침의 주요 부분을 나타냅니다.
6.1.1. 사양 파일의 Preamble 항목 링크 복사링크가 클립보드에 복사되었습니다!
RPM 사양 파일의 Preamble 섹션에서 다음 지시문을 사용합니다.
| 지시문 | 정의 |
|---|---|
|
|
|
|
| 소프트웨어의 업스트림 버전 번호입니다. |
|
| 패키지 버전이 릴리스된 횟수입니다.
초기 값을 |
|
| 패키지에 대한 간단한 한 줄 요약입니다. |
|
| 패키지되는 소프트웨어의 라이센스입니다.
|
|
| 소프트웨어에 대한 자세한 내용은 전체 URL(예: 패키징 중인 소프트웨어에 대한 업스트림 프로젝트 웹 사이트)입니다. |
|
| 패치되지 않은 업스트림 소스 코드의 압축된 아카이브의 경로 또는 URL입니다. 이 링크는 아카이브의 액세스 가능하고 안정적인 스토리지(예: 패키지 관리자의 로컬 스토리지)가 아닌 업스트림 페이지(예: 업스트림 페이지)를 가리켜야 합니다.
지시문 이름 끝에 숫자 또는 숫자 없이 |
|
| 필요한 경우 소스 코드에 적용할 첫 번째 패치의 이름입니다.
지시문 이름 끝에 숫자 또는 숫자 없이
|
|
| 소프트웨어가 빌드될 아키텍처입니다.
예를 들어 소프트웨어를 해석된 프로그래밍 언어로 완전히 작성한 경우 해당 값을 |
|
|
컴파일된 언어로 작성된 프로그램을 빌드하는 데 필요한 쉼표 또는 공백으로 구분된 패키지 목록입니다. |
|
|
설치된 소프트웨어를 실행하는 데 필요한 쉼표 또는 공백으로 구분된 패키지 목록입니다. |
|
|
특정 프로세서 아키텍처에서 소프트웨어를 작동할 수 없는 경우 |
|
|
설치된 경우 소프트웨어가 제대로 작동하려면 시스템에 설치해서는 안 되는 쉼표 또는 공백으로 구분된 패키지 목록입니다. |
|
|
|
|
|
패키지에 |
6.1.2. 사양 파일의 본문 항목 링크 복사링크가 클립보드에 복사되었습니다!
RPM 사양 파일의 Body 섹션에서 다음 지시문을 사용합니다.
| 지시문 | 정의 |
|---|---|
|
| RPM에 패키지된 소프트웨어에 대한 전체 설명입니다. 이 설명은 여러 줄에 걸쳐 있을 수 있으며 단락으로 나눌 수 있습니다. |
|
|
빌드하기 위해 소프트웨어를 준비하는 명령 또는 일련의 명령(예: |
|
| 빌드하기 위한 소프트웨어를 구성하는 명령 또는 일련의 명령입니다. |
|
| 소프트웨어를 머신 코드(컴파일된 언어의 경우) 또는 바이트 코드(일부 해석 언어의 경우)로 빌드하는 명령 또는 일련의 명령입니다. |
|
|
소프트웨어를 빌드한 후
|
|
| 소프트웨어를 테스트하는 명령 또는 일련의 명령(예: 단위 테스트)입니다. |
|
| RPM 패키지에서 제공하는 파일 목록(사용자 시스템 및 시스템의 전체 경로 위치)을 설치합니다.
빌드 중에
|
|
|
다른 |
6.1.3. 고급 사양 파일 항목 링크 복사링크가 클립보드에 복사되었습니다!
사양 파일에는 Scriptlets, File 트리거 및 Trigger와 같은 고급 항목이 포함될 수 있습니다. 이러한 지시문은 사양 파일뿐만 아니라 RPM의 정보로 시스템을 업데이트하여 결과 RPM이 설치된 대상 운영 체제에도 영향을 미칩니다.
스크립트릿, 파일 트리거 및 트리거는 빌드 프로세스가 아닌 대상 시스템에 설치 프로세스 중 다른 지점에서 적용됩니다.
- 스크립트릿은 패키지 설치 또는 삭제 전후에 무조건 실행됩니다.
- 트리거는 지정된 트리거 조건이 설치된 시스템 또는 트랜잭션의 다른 패키지와 일치할 때 조건부로 실행됩니다.
- 파일 트리거는 지정된 경로 접두사가 설치된 시스템 또는 트랜잭션의 다른 파일과 일치하면 조건부로 실행됩니다.
6.1.3.1. scriptlets 지시문 링크 복사링크가 클립보드에 복사되었습니다!
스크립트릿은 패키지 설치 또는 삭제 전이나 후에 패키지 수명과 관련된 사전 결정된 슬롯에서 실행되는 임의의 프로그램입니다. 스크립트릿은 빌드 시 또는 시작 스크립트에서 수행할 수 없는 작업에만 사용합니다.
기본적으로 스크립트릿은 사양 파일의 다양한 %pre 또는 %post 지시문에서 선언한 짧은 쉘 스크립트입니다.
일반적인 스크립트릿 지시문은 spec 파일 섹션 헤더(예: %build 또는 %install )와 유사합니다. 코드의 여러 줄 세그먼트로 정의되며 종종 표준 POSIX 쉘 스크립트로 작성됩니다. 그러나 RPM이 대상 시스템의 배포를 위해 허용하는 다른 프로그래밍 언어로 작성할 수도 있습니다.
6.1.3.2. 스크립트릿 지시문 실행 순서 링크 복사링크가 클립보드에 복사되었습니다!
패키지 업그레이드 중에 스크립트릿이 실행되는 순서를 검토합니다.
| 지시문 | 설명 |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
6.1.3.3. 스크립트릿 실행 해제 링크 복사링크가 클립보드에 복사되었습니다!
스크립트릿 이름과 함께 --no 옵션을 사용하여 모든 스크립트릿 실행을 끕니다.
다음 스크립트릿의 실행을 끄는 것과 동일한 --noscripts 옵션을 사용할 수도 있습니다.
-
--nopre -
--nopost -
--nopreun -
--nopostun -
--nopretrans -
--noposttrans -
--nopreuntrans -
--nopostuntrans
자세한 내용은 시스템의 rpm 도움말 페이지를 참조하십시오.
프로세스
scriptlet 실행을 끕니다.
# rpm --no<scriptlet_name>예를 들어
%pretransscriptlet의 실행을 끄려면 다음을 입력합니다.# rpm --nopretrans
6.1.3.4. 스크립트릿의 매크로 예 링크 복사링크가 클립보드에 복사되었습니다!
다음은 사양 파일에서 스크립트릿에 사용할 수 있는 매크로의 예입니다. 이러한 매크로는 systemd-rpm-macros 패키지에서 제공하는 실제 매크로입니다. systemd관련 항목을 패키징하는 데 이러한 매크로를 사용할 수 있습니다. 다른 패키지에도 유사한 원칙을 적용할 수 있습니다.
systemd 장치 파일이 포함된 패키지는 scriptlets를 사용하여 systemd 서비스를 올바르게 처리해야 합니다. systemd 패키지는 systemd 스크립트릿 작업을 처리하는 일련의 매크로를 제공합니다. 예를 들면 다음과 같습니다.
%post
%systemd_post httpd.service
%preun
%systemd_preun httpd.service
이러한 매크로는 패키지에서 다음으로 확장됩니다.
$ rpm --eval "%systemd_preun httpd.service"
if [ $1 -eq 0 ] && [ -x "/usr/lib/systemd/systemd-update-helper" ]; then
# Package removal, not upgrade
/usr/lib/systemd/systemd-update-helper remove-system-units httpd.service || :
fi
매크로가 작동하는 방식은 변경될 수 있습니다. 예를 들어, 매크로의 동작은 패키지 개발을 통해 변경될 수 있습니다.
6.1.4. Epoch 지시문 링크 복사링크가 클립보드에 복사되었습니다!
Version spec file 지시문을 설정하는 것만으로는 패키지 버전 비교에 충분하지 않은 경우 Epoch 지시문을 사용할 수 있습니다. 예를 들어 Epoch 를 사용하여 호환되지 않는 방식으로 버전 번호 지정 체계의 업스트림 변경으로 인해 발생한 업그레이드 경로 문제를 해결할 수 있습니다.
epoch 는 숫자 필드입니다. Epoch 에 값을 할당하면 RPM에서 패키지 버전을 비교할 때 사용하는 한정자가 추가됩니다. spec 파일에 Epoch 지시문이 나열되지 않음은 Epoch 가 설정되지 않았음을 의미합니다. 이는 Epoch 를 설정하지 않는 일반적인 신념과는 대조적입니다. 0 의 Epoch 가 발생합니다. 그러나 처리를 위해 Epoch 를 설정하지 않는 경우 RPM은 Epoch 가 0 으로 설정된 것처럼 취급하며 그 반대의 경우도 마찬가지입니다.
사양 파일에서 를 사용하는 것은 대부분의 경우 패키지 버전을 비교할 때 예상되는 RPM 동작을 왜곡하기 때문에 일반적으로 생략됩니다. 따라서 Epoch Epoch 를 마지막 수단으로 사용하는 것이 좋습니다.
예를 들어 Epoch: 1 및 Version: 1.0 을 사용하여 foobar 패키지를 설치했습니다. 다른 패키지러는 Version: 2.0 이 있지만 Epoch 지시문이 없는 foobar 를 패키징합니다. 결과적으로 Epoch 버전이 RPM 패키지에 대한 버전 관리를 나타내는 기존 Name-Version-Release 마커보다 우선하므로 새 버전은 업데이트로 간주되지 않습니다.
6.1.5. 패키지 버전 관리 필수 링크 복사링크가 클립보드에 복사되었습니다!
패키지 설명의 필수 부분은NVR( Name,Version ) spec 파일 지시문에 정의된 정보입니다. RPM은 이 정보를 사용하여 패키지 버전을 비교하고 패키지 종속성을 추적합니다.
RPM으로 작업할 때 EVR (epoch-version-release), NEVR (name-epoch-version-release) 및 NEVRA (name-epoch-version-release-architecture)를 참조할 수도 있습니다. EVR 은 RPM이 비교할 때 항상 사용하는 패키지의 전체 버전 정보입니다. RPM은 첫 번째 구성 요소에서 시작하여 한 번에 하나의 구성 요소를 비교합니다. RPM은 구성 요소에서 차이를 찾을 때 비교를 중지합니다. 예를 들어 Epoch 가 다른 경우 RPM은 나머지 EVR 구성 요소를 비교하지 않습니다.
RPM 데이터베이스를 쿼리하여 특정 패키지에 대한 NVR 정보를 표시할 수 있습니다. 예를 들면 다음과 같습니다.
# rpm -q bash
bash-4.4.19-7.el8.x86_64
여기에서 bash 는 패키지 이름이고 4.4.19 는 버전이며 7.el8 은 릴리스입니다. x86_64 마커는 패키지 아키텍처입니다. NVR 과 달리 아키텍처 마커는 RPM 패키지러를 직접 제어하지 않지만 rpmbuild 빌드 환경에 의해 정의됩니다. 이에 대한 예외는 아키텍처 독립적인 noarch 패키지입니다.
rpm -q 명령은 기본적으로 NEVRA 형식으로 패키지 정보를 표시합니다.