3장. 패키지 소프트웨어
3.1. RPM 패키지
이 섹션에서는 RPM 패키지 형식의 기본 사항에 대해 설명합니다.
3.1.1. RPM이란 무엇입니까?
RPM 패키지는 다른 파일 및 메타데이터(시스템에 필요한 파일에 대한)를 포함하는 파일입니다.
특히 RPM 패키지는 cpio
아카이브로 구성됩니다.
cpio
아카이브에는 다음이 포함됩니다.
- Files
RPM 헤더(패키지 메타데이터)
rpm
패키지 관리자는 이 메타데이터를 사용하여 종속성, 파일 설치 위치 및 기타 정보를 결정합니다.
RPM 패키지 유형
RPM 패키지에는 두 가지 유형이 있습니다. 두 유형 모두 파일 형식과 툴링을 공유하지만 내용이 다르고 용도가 다릅니다.
소스 RPM(SRPM)
SRPM에는 소스 코드와 SPEC 파일이 포함되어 있으며, 바이너리 RPM에 소스 코드를 빌드하는 방법을 설명합니다. 선택적으로 소스 코드에 대한 패치도 포함됩니다.
바이너리 RPM
바이너리 RPM에는 소스 및 패치에서 빌드된 바이너리가 포함되어 있습니다.
3.1.2. RPM 패키징 툴의 유틸리티 나열
다음 절차에서는 rpmdevtools
패키지에서 제공하는 유틸리티를 나열하는 방법을 보여줍니다.
사전 요구 사항
RPM 패키지 툴을 사용하려면 RPM 패키징을 위한 여러 유틸리티를 제공하는 rpmdevtools
패키지를 설치해야 합니다.
# yum install rpmdevtools
절차
RPM 패키지 도구의 유틸리티를 나열합니다.
$ rpm -ql rpmdevtools | grep bin
추가 정보
- 위의 유틸리티에 대한 자세한 내용은 도움말 페이지 또는 도움말 대화 상자를 참조하십시오.
3.1.3. RPM 패키징 작업 공간 설정
이 섹션에서는 rpmdev-setuptree
유틸리티를 사용하여 RPM 패키징 작업 공간인 디렉터리 레이아웃을 설정하는 방법을 설명합니다.
사전 요구 사항
rpmdevtools
패키지가 시스템에 설치되어 있어야 합니다.
# yum install rpmdevtools
절차
-
rpmdev-setuptree
유틸리티를 실행합니다.
$ rpmdev-setuptree $ tree ~/rpmbuild/ /home/<username>/rpmbuild/ |-- BUILD |-- RPMS |-- SOURCES |-- SPECS `-- SRPMS 5 directories, 0 files
생성된 디렉터리는 다음 목적을 제공합니다.
디렉터리 | 목적 |
빌드 |
패키지가 빌드되면 다양한 |
RPMS |
여기에서 바이너리 RPM은 다른 아키텍처를 위한 하위 디렉터리(예: 하위 디렉터리 |
소스 |
여기에서 packager는 압축 소스 코드 아카이브와 패치를 배치합니다. |
SPECS | 패키지러는 SPEC 파일을 여기에 배치합니다. |
SRPMS |
바이너리 RPM 대신 |
3.1.4. SPEC 파일은 무엇입니까?
SPEC 파일을 rpmbuild
유틸리티에서 RPM을 빌드하는 데 사용하는 레시피로 이해할 수 있습니다. SPEC 파일은 일련의 섹션에서 명령을 정의하여 빌드 시스템에 필요한 정보를 제공합니다. 섹션은 Preamble 및 DestinationRule 부분에 정의되어 있습니다. Preamble 부분에는 DestinationRule 부분에서 사용되는 일련의 메타데이터 항목이 포함되어 있습니다. DestinationRule 부분은 지침의 주요 부분을 나타냅니다.
3.1.4.1. Preamble 항목
아래 표는 RPM SPEC 파일의 Preamble 섹션에서 자주 사용되는 몇 가지 지시문입니다.
SPECECDHE | 정의 |
---|---|
| SPEC 파일 이름과 일치해야 하는 패키지의 기본 이름입니다. |
| 소프트웨어의 업스트림 버전 번호입니다. |
|
이 버전의 소프트웨어가 릴리스된 횟수입니다. 일반적으로 초기 값을 1%{?dist}로 설정하고 새 패키지 릴리스마다 늘립니다. 소프트웨어의 새 버전이 빌드된 경우 1로 재설정합니다. |
| 패키지에 대한 한 줄 요약입니다. |
| 소프트웨어 라이센스가 패키지됩니다. |
| 프로그램에 대한 자세한 내용은 전체 URL을 참조하십시오. 대부분의 경우 이것은 패키지화되는 소프트웨어의 업스트림 프로젝트 웹 사이트입니다. |
| 업스트림 소스 코드의 압축 아카이브에 대한 경로 또는 URL(패치되지 않은 패치는 다른 위치에서 처리됨). 이는 아카이브의 로컬 스토리지가 아니라 액세스 가능하고 안정적인 아카이브(예: 업스트림 페이지)를 가리켜야 합니다. 필요하면 Source1, Source2, Source3 등과 같이 때마다 더 많은 SourceX 지시문을 추가할 수 있습니다. |
| 필요한 경우 소스 코드에 적용할 첫 번째 패치의 이름입니다. 이 지시문을 Patch 끝에 숫자와 함께 사용하거나 사용하지 않는 두 가지 방법으로 적용할 수 있습니다. 번호가 지정되지 않으면 내부적으로 항목이 할당됩니다. Patch0, Patch1, Patch2, Patch3 등을 사용하여 명시적으로 번호를 지정할 수도 있습니다. 이러한 패치는 %patch0, %patch1, %patch2 매크로 등을 사용하여 하나씩 적용할 수 있습니다. 매크로는 RPM SPEC 파일의 DestinationRule 섹션에 있는 %prep 지시문에 적용됩니다. 또는 %autopatch 매크로를 사용하여 SPEC 파일에서 제공되는 모든 패치를 자동으로 적용할 수 있습니다. |
|
패키지가 아키텍처 종속적이지 않은 경우 예를 들어 해석된 프로그래밍 언어로 완전히 작성된 경우 이 패키지를 |
|
컴파일된 언어로 작성된 프로그램을 빌드하는 데 필요한 패키지의 쉼표 또는 공백으로 구분된 목록입니다. |
|
설치된 한 번 실행하는 데 필요한 패키지의 쉼표 또는 공백으로 구분된 목록입니다. |
| 특정 프로세서 아키텍처에서 소프트웨어를 작동할 수 없는 경우 여기에서 해당 아키텍처를 제외할 수 있습니다. |
|
|
|
이 지시문에서는 |
|
If |
Name
,Version
, Release
지시문에는 RPM 패키지의 파일 이름이 포함됩니다. RPM 패키지 유지 관리자 및 시스템 관리자는 RPM 패키지 파일 이름에 NAME-VERSION-RELEASE
형식이 있기 때문에 이러한 세 가지 지시문인 N-V-R 또는 NVR 을 호출하는 경우가 많습니다.
다음 예제에서는 rpm
명령을 쿼리하여 특정 패키지에 대한 NVR 정보를 가져오는 방법을 보여줍니다.
예 3.1. bash 패키지에 대한 NVR 정보를 제공하도록 rpm 쿼리
$ rpm -q bash bash-4.2.46-34.el7.x86_64
여기에서 bash
는 패키지 이름이고 4.2.46
은 버전이며 34.el7
은 릴리스입니다. 최종 마커는 x86_64
로 아키텍처 신호를 보냅니다. NVR 과 달리 아키텍처 마커는 RPM 패키지 관리자를 직접 제어하지 않지만 rpmbuild
빌드 환경에서 정의합니다. 이에 대한 예외는 아키텍처 독립적인 noarch
패키지입니다.
3.1.4.2. 본문 항목
RPM SPEC 파일 의 DestinationRule 섹션에
사용된 항목은 아래 표에 나열되어 있습니다.
SPECECDHE | 정의 |
---|---|
| RPM에 패키지된 소프트웨어에 대한 전체 설명입니다. 이 설명은 여러 줄에 걸쳐 있을 수 있으며 단락으로 나눌 수 있습니다. |
|
소프트웨어를 빌드할 명령 또는 일련의 명령(예: |
| 소프트웨어를 머신 코드(컴파일 언어용) 또는 바이트 코드(일부 해석된 언어의 경우)로 빌드하기 위한 명령 또는 일련의 명령 |
|
|
| 소프트웨어를 테스트하기 위한 명령 또는 일련의 명령 여기에는 일반적으로 단위 테스트와 같은 사항이 포함됩니다. |
| 최종 사용자의 시스템에 설치될 파일 목록입니다. |
|
다양한 |
3.1.4.3. 고급 항목
SPEC 파일에는 또한 Scriptlets 또는 Triggers 와 같은 고급 항목을 포함할 수 있습니다. 빌드 프로세스가 아닌 최종 사용자 시스템의 설치 프로세스 중에 다른 시점에서 적용됩니다.
3.1.5. BuildRoots
RPM 패키징 컨텍스트에서 buildroot
는 chroot 환경입니다. 즉, 빌드 아티팩트는 최종 사용자의 시스템에서 향후 계층 구조와 동일한 파일 시스템 계층을 사용하여 여기에 배치되며 buildroot
가 루트 디렉터리로 작동합니다. 빌드 아티팩트 배치는 최종 사용자 시스템의 파일 시스템 계층 표준을 준수해야 합니다.
나중에 buildroot
의 파일은 RPM의 주요 부분이 되는 cpio
아카이브에 배치됩니다. RPM이 최종 사용자 시스템에 설치되면 이러한 파일이 루트
디렉터리에 추출되어 올바른 계층을 유지합니다.
6부터 rpmbuild
프로그램에는 자체 기본값이 있습니다. 이러한 기본값을 재정의하면 여러 문제가 발생합니다. 따라서 {RH}는 이 매크로의 고유 값을 정의하지 않는 것이 좋습니다. rpmbuild
디렉터리의 기본값과 함께 %{buildroot}
매크로를 사용할 수 있습니다.
3.1.6. RPM 매크로
rpm 매크로 는 특정 기본 제공 기능이 사용될 때 문의 선택적 평가를 기반으로 조건부로 할당할 수 있는 간단한 텍스트 대체입니다. 따라서 RPM은 텍스트 대체를 수행할 수 있습니다.
예제 사용은 패키지 소프트웨어 버전을 SPEC 파일에서 여러 번 참조하는 것입니다. %{version}
매크로에서 한 번만 Version 을 정의하고 SPEC 파일 전체에서 이 매크로를 사용합니다. 모든 이벤트는 이전에 정의한 버전으로 자동으로 대체됩니다.
예기치 않은 매크로가 표시되면 다음 명령을 사용하여 평가할 수 있습니다.
$ rpm --eval %{_MACRO}
%{_bindir} 및 %{_libexecdir} 매크로 평가
$ rpm --eval %{_bindir} /usr/bin $ rpm --eval %{_libexecdir} /usr/libexec
일반적으로 사용되는 매크로는 %{?dist}
매크로로, 빌드에 사용되는 배포(distribution 태그)를 나타냅니다.
# On a RHEL 8.x machine $ rpm --eval %{?dist} .el8