6장. 소프트웨어 패키지


RPM 패키지 관리자를 사용한 패키징 프로세스의 기본 사항을 알아보십시오.

6.1. 사양 파일 정보

사양 파일은 rpmbuild 유틸리티에서 RPM 패키지를 빌드하는 데 사용하는 지침이 포함된 파일입니다.

사양 파일은 일련의 섹션에 지침을 정의하여 빌드 시스템에 필요한 정보를 제공합니다. 이러한 섹션은 Preamblespec 파일의 Body 부분에 정의되어 있습니다.

  • Preamble 섹션에는 본문 섹션에서 사용되는 일련의 메타데이터 항목이 포함되어 있습니다.
  • Body 섹션은 지침의 주요 부분을 나타냅니다.

6.1.1. 사양 파일의 Preamble 항목

RPM 사양 파일의 Preamble 섹션에서 다음 지시문을 사용합니다.

Expand
표 6.1. Preamble 섹션 지시문
지시문정의

이름

사양 파일 이름과 일치해야 하는 패키지의 기본 이름입니다.

버전

소프트웨어의 업스트림 버전 번호입니다.

릴리스

패키지 버전이 릴리스된 횟수입니다.

초기 값을 1%{?dist} 로 설정하고 패키지의 새 릴리스마다 늘립니다. 새 버전의 소프트웨어가 빌드되면 1 로 재설정합니다.

요약

패키지에 대한 간단한 한 줄 요약입니다.

라이센스

패키지되는 소프트웨어의 라이센스입니다.

사양 파일의 라이센스 레이블을 지정하는 방법에 대한 정확한 형식은 다음 RPM 기반 Linux 배포 지침(예: GPLv3 이상)에 따라 달라집니다.

URL

소프트웨어에 대한 자세한 내용은 전체 URL(예: 패키징 중인 소프트웨어에 대한 업스트림 프로젝트 웹 사이트)입니다.

소스

패치되지 않은 업스트림 소스 코드의 압축된 아카이브의 경로 또는 URL입니다. 이 링크는 아카이브의 액세스 가능하고 안정적인 스토리지(예: 패키지 관리자의 로컬 스토리지)가 아닌 업스트림 페이지(예: 업스트림 페이지)를 가리켜야 합니다.

지시문 이름 끝에 숫자 또는 숫자 없이 Source 지시문을 적용할 수 있습니다. 번호가 지정되지 않은 경우 번호가 내부적으로 항목에 할당됩니다. 값을 명시적으로 지정할 수도 있습니다(예: Source0,Source1,Source2,Source3 등).

패치

필요한 경우 소스 코드에 적용할 첫 번째 패치의 이름입니다.

지시문 이름 끝에 숫자 또는 숫자 없이 Patch 지시문을 적용할 수 있습니다. 번호가 지정되지 않은 경우 번호가 내부적으로 항목에 할당됩니다. 또한 Patch0,Patch1,Patch2,Patch3 등과 같은 번호를 명시적으로 지정할 수도 있습니다.

%patch0,%patch1,%patch2 매크로 등을 사용하여 패치를 개별적으로 적용할 수 있습니다. 매크로는 RPM 사양 파일의 Body 섹션에 있는 %prep 지시문 내에 적용됩니다. 또는 모든 패치를 사양 파일에서 제공되는 순서대로 자동으로 적용하는 %autopatch 매크로를 사용할 수 있습니다.

BuildArch

소프트웨어가 빌드될 아키텍처입니다.

예를 들어 소프트웨어를 해석된 프로그래밍 언어로 완전히 작성한 경우 해당 값을 BuildArch: noarch 로 설정합니다. 이 값을 설정하지 않으면 소프트웨어가 빌드된 시스템의 아키텍처(예: x86_64 )를 자동으로 상속합니다.

BuildRequires

컴파일된 언어로 작성된 프로그램을 빌드하는 데 필요한 쉼표 또는 공백으로 구분된 패키지 목록입니다. BuildRequires 의 여러 항목이 있을 수 있으며 각각 SPEC 파일의 자체 행에 있습니다.

필요

설치된 소프트웨어를 실행하는 데 필요한 쉼표 또는 공백으로 구분된 패키지 목록입니다. Requires 의 여러 항목이 있을 수 있으며 각각 사양 파일의 자체 행에 있을 수 있습니다.

ExcludeArch

특정 프로세서 아키텍처에서 소프트웨어를 작동할 수 없는 경우 ExcludeArch 지시문에서 이 아키텍처를 제외할 수 있습니다.

충돌

설치된 경우 소프트웨어가 제대로 작동하려면 시스템에 설치해서는 안 되는 쉼표 또는 공백으로 구분된 패키지 목록입니다. Conflicts 의 여러 항목이 있을 수 있으며 각각 spec 파일의 자체 행에 있습니다.

사용되지 않음

Obsoletes 지시문은 다음 요인에 따라 업데이트 작동 방식을 변경합니다.

  • 명령행에서 rpm 명령을 직접 사용하는 경우 설치 중인 패키지의 더 이상 사용되지 않는 패키지와 일치하는 모든 패키지를 제거하거나 업데이트 또는 종속성 해결기에 의해 업데이트가 수행됩니다.
  • 업데이트 또는 종속성 확인자(DNF)를 사용하는 경우 일치하는 Obsoletes가 포함된 패키지: 업데이트가 추가되고 일치하는 패키지를 교체합니다.

제공

패키지에 Provides 지시문을 추가하면 이 패키지를 이름 이외의 종속성에서 참조할 수 있습니다.

6.1.2. 사양 파일의 본문 항목

RPM 사양 파일의 Body 섹션에서 다음 지시문을 사용합니다.

Expand
표 6.2. 본문 섹션 항목
지시문정의

%Description

RPM에 패키지된 소프트웨어에 대한 전체 설명입니다. 이 설명은 여러 줄에 걸쳐 있을 수 있으며 단락으로 나눌 수 있습니다.

%Prep

빌드하기 위해 소프트웨어를 준비하는 명령 또는 일련의 명령(예: Source 지시문에서 아카이브 압축을 풀기 위한 명령)입니다. %prep 지시문에는 쉘 스크립트가 포함될 수 있습니다.

%conf

빌드하기 위한 소프트웨어를 구성하는 명령 또는 일련의 명령입니다.

%build

소프트웨어를 머신 코드(컴파일된 언어의 경우) 또는 바이트 코드(일부 해석 언어의 경우)로 빌드하는 명령 또는 일련의 명령입니다.

%install

소프트웨어를 빌드한 후 rpmbuild 유틸리티에서 BUILDROOT 디렉토리에 소프트웨어를 설치하는 데 사용할 명령 또는 일련의 명령입니다. 이러한 명령은 빌드가 수행되는 %_builddir 디렉터리의 원하는 빌드 아티팩트를 패키징할 파일과 디렉터리 구조가 포함된 %buildroot 디렉터리에 복사합니다. 여기에는 ~/rpmbuild/BUILD에서 ~/rpmbuild/BUILD ROOT 로 파일을 복사하고 ~/rpmbuild/BUILDROOT 에 필요한 디렉토리를 만드는 작업이 포함됩니다.

%buildroot 디렉터리는 최종 사용자의 시스템 디렉터리 레이아웃과 유사한 빈 기본 디렉터리입니다. %buildroot 에서는 설치된 파일이 포함된 디렉토리를 생성할 수 있습니다. 이러한 디렉터리를 만들려면 경로를 하드 코딩하지 않고도 RPM 매크로를 사용할 수 있습니다.

%install 은 패키지를 설치할 때가 아니라 패키지를 만들 때만 실행됩니다. 자세한 내용은 사양 파일 작업을 참조하십시오.

%check

소프트웨어를 테스트하는 명령 또는 일련의 명령(예: 단위 테스트)입니다.

%files

RPM 패키지에서 제공하는 파일 목록(사용자 시스템 및 시스템의 전체 경로 위치)을 설치합니다.

빌드 중에 %files 에 나열되지 않은 %buildroot 디렉터리에 파일이 있는 경우 패키징되지 않은 파일에 대한 경고가 표시됩니다.

%files 섹션에서 기본 제공 매크로를 사용하여 다양한 파일의 역할을 나타낼 수 있습니다. rpm 명령을 사용하여 패키지 파일 매니페스트 메타데이터를 쿼리하는 데 유용합니다. 예를 들어 LICENSE 파일이 소프트웨어 라이센스 파일임을 나타내기 위해 %license 매크로를 사용합니다.

%changelog

다른 버전 또는 릴리스 빌드 간에 패키지에 발생한 변경 사항 레코드입니다. 이러한 변경 사항에는 패키지의 각 Version-Release에 대한 날짜-amped 항목 목록이 포함됩니다. 이러한 항목은 소프트웨어 변경이 아닌 패키징 변경 사항을 기록합니다(예: %build 섹션에서 패치 추가 또는 빌드 절차 변경).

6.1.3. 고급 사양 파일 항목

사양 파일에는 Scriptlets, File 트리거 및 Trigger와 같은 고급 항목이 포함될 수 있습니다. 이러한 지시문은 사양 파일뿐만 아니라 RPM의 정보로 시스템을 업데이트하여 결과 RPM이 설치된 대상 운영 체제에도 영향을 미칩니다.

스크립트릿, 파일 트리거 및 트리거는 빌드 프로세스가 아닌 대상 시스템에 설치 프로세스 중 다른 지점에서 적용됩니다.

  • 스크립트릿은 패키지 설치 또는 삭제 전후에 무조건 실행됩니다.
  • 트리거는 지정된 트리거 조건이 설치된 시스템 또는 트랜잭션의 다른 패키지와 일치할 때 조건부로 실행됩니다.
  • 파일 트리거는 지정된 경로 접두사가 설치된 시스템 또는 트랜잭션의 다른 파일과 일치하면 조건부로 실행됩니다.

6.1.3.1. scriptlets 지시문

스크립트릿은 패키지 설치 또는 삭제 전이나 후에 패키지 수명과 관련된 사전 결정된 슬롯에서 실행되는 임의의 프로그램입니다. 스크립트릿은 빌드 시 또는 시작 스크립트에서 수행할 수 없는 작업에만 사용합니다.

기본적으로 스크립트릿은 사양 파일의 다양한 %pre 또는 %post 지시문에서 선언한 짧은 쉘 스크립트입니다.

일반적인 스크립트릿 지시문은 spec 파일 섹션 헤더(예: %build 또는 %install )와 유사합니다. 코드의 여러 줄 세그먼트로 정의되며 종종 표준 POSIX 쉘 스크립트로 작성됩니다. 그러나 RPM이 대상 시스템의 배포를 위해 허용하는 다른 프로그래밍 언어로 작성할 수도 있습니다.

6.1.3.2. 스크립트릿 지시문 실행 순서

패키지 업그레이드 중에 스크립트릿이 실행되는 순서를 검토합니다.

Expand
표 6.3. scriptlets 지시문
지시문설명

%pretrans

%pretrans scriptlet은 패키지를 설치하거나 제거하기 전에 실행됩니다.

%pre

%pre scriptlet은 대상 시스템에 패키지를 설치하기 전에 실행됩니다.

%post

%post 스크립트릿은 대상 시스템에 패키지를 설치한 후 실행됩니다.

%preun

%preun scriptlet은 대상 시스템에서 패키지를 제거하기 전에 실행됩니다.

%postun

%postun scriptlet은 대상 시스템에서 패키지를 제거한 후 실행됩니다.

%posttrans

%posttrans scriptlet은 트랜잭션 종료 시 실행됩니다.

6.1.3.3. 스크립트릿 실행 해제

스크립트릿 이름과 함께 --no 옵션을 사용하여 모든 스크립트릿 실행을 끕니다.

다음 스크립트릿의 실행을 끄는 것과 동일한 --noscripts 옵션을 사용할 수도 있습니다.

  • --nopre
  • --nopost
  • --nopreun
  • --nopostun
  • --nopretrans
  • --noposttrans
  • --nopreuntrans
  • --nopostuntrans

자세한 내용은 시스템의 rpm 도움말 페이지를 참조하십시오.

프로세스

  • scriptlet 실행을 끕니다.

    # rpm --no<scriptlet_name>

    예를 들어 %pretrans scriptlet의 실행을 끄려면 다음을 입력합니다.

    # 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 를 설정하지 않는 일반적인 신념과는 대조적입니다. 0Epoch 가 발생합니다. 그러나 처리를 위해 Epoch 를 설정하지 않는 경우 RPM은 Epoch0 으로 설정된 것처럼 취급하며 그 반대의 경우도 마찬가지입니다.

중요

사양 파일에서 Epoch 를 사용하는 것은 대부분의 경우 패키지 버전을 비교할 때 예상되는 RPM 동작을 왜곡하기 때문에 일반적으로 생략됩니다. 따라서 Epoch 를 마지막 수단으로 사용하는 것이 좋습니다.

예를 들어 Epoch: 1Version: 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 형식으로 패키지 정보를 표시합니다.

Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 문서 정보

Legal Notice

Theme

© 2026 Red Hat
맨 위로 이동