검색

3장. 패키지 소프트웨어

download PDF

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

생성된 디렉터리는 다음 목적을 제공합니다.

디렉터리

목적

빌드

패키지가 빌드되면 다양한 %buildroot 디렉터리가 생성됩니다. 이는 로그 출력에서 충분한 정보를 제공하지 않는 경우 실패한 빌드를 조사하는 데 유용합니다.

RPMS

여기에서 바이너리 RPM은 다른 아키텍처를 위한 하위 디렉터리(예: 하위 디렉터리 x86_64noarch )에서 생성됩니다.

소스

여기에서 packager는 압축 소스 코드 아카이브와 패치를 배치합니다. rpmbuild 명령은 여기에서 찾습니다.

SPECS

패키지러는 SPEC 파일을 여기에 배치합니다.

SRPMS

바이너리 RPM 대신 rpmbuild 를 사용하여 SRPM을 빌드하면 결과 SRPM이 생성됩니다.

3.1.4. SPEC 파일은 무엇입니까?

SPEC 파일을 rpmbuild 유틸리티에서 RPM을 빌드하는 데 사용하는 레시피로 이해할 수 있습니다. SPEC 파일은 일련의 섹션에서 명령을 정의하여 빌드 시스템에 필요한 정보를 제공합니다. 섹션은 Preamble 및 DestinationRule 부분에 정의되어 있습니다. Preamble 부분에는 DestinationRule 부분에서 사용되는 일련의 메타데이터 항목이 포함되어 있습니다. DestinationRule 부분은 지침의 주요 부분을 나타냅니다.

3.1.4.1. Preamble 항목

아래 표는 RPM SPEC 파일의 Preamble 섹션에서 자주 사용되는 몇 가지 지시문입니다.

표 3.1. RPM SPEC 파일의 Preamble 섹션에서 사용되는 항목
SPECECDHE정의

이름

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

버전

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

릴리스 버전

이 버전의 소프트웨어가 릴리스된 횟수입니다. 일반적으로 초기 값을 1%{?dist}로 설정하고 새 패키지 릴리스마다 늘립니다. 소프트웨어의 새 버전이 빌드된 경우 1로 재설정합니다.

요약

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

라이센스

소프트웨어 라이센스가 패키지됩니다.

URL

프로그램에 대한 자세한 내용은 전체 URL을 참조하십시오. 대부분의 경우 이것은 패키지화되는 소프트웨어의 업스트림 프로젝트 웹 사이트입니다.

Source0

업스트림 소스 코드의 압축 아카이브에 대한 경로 또는 URL(패치되지 않은 패치는 다른 위치에서 처리됨). 이는 아카이브의 로컬 스토리지가 아니라 액세스 가능하고 안정적인 아카이브(예: 업스트림 페이지)를 가리켜야 합니다. 필요하면 Source1, Source2, Source3 등과 같이 때마다 더 많은 SourceX 지시문을 추가할 수 있습니다.

패치

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

이 지시문을 Patch 끝에 숫자와 함께 사용하거나 사용하지 않는 두 가지 방법으로 적용할 수 있습니다.

번호가 지정되지 않으면 내부적으로 항목이 할당됩니다. Patch0, Patch1, Patch2, Patch3 등을 사용하여 명시적으로 번호를 지정할 수도 있습니다.

이러한 패치는 %patch0, %patch1, %patch2 매크로 등을 사용하여 하나씩 적용할 수 있습니다. 매크로는 RPM SPEC 파일의 DestinationRule 섹션에 있는 %prep 지시문에 적용됩니다. 또는 %autopatch 매크로를 사용하여 SPEC 파일에서 제공되는 모든 패치를 자동으로 적용할 수 있습니다.

BuildArch

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

BuildRequires

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

requires

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

ExcludeArch

특정 프로세서 아키텍처에서 소프트웨어를 작동할 수 없는 경우 여기에서 해당 아키텍처를 제외할 수 있습니다.

충돌

충돌Requires 와 다릅니다. 충돌과 일치하는 패키지가 있는 경우 충돌 태그가 이미 설치된 패키지에 있는지 아니면 설치하려는 패키지에 있는지 여부에 대해 패키지를 독립적으로 설치할 수 없습니다.

사용되지 않음

이 지시문에서는 rpm 명령을 명령줄에서 직접 사용하는지 아니면 업데이트 또는 종속성 솔버를 통해 업데이트를 수행하는지 여부에 따라 업데이트되는 방식을 변경합니다. 명령행에서 사용하는 경우 RPM은 설치 중인 패키지의 더 이상 사용되지 않는 것과 일치하는 모든 패키지를 제거합니다. 업데이트 또는 종속성 확인자를 사용하는 경우 일치하는 Obsoletes: 패키지가 업데이트로 추가되고 일치하는 패키지를 교체합니다.

provides

If Provides is added to a package, the package can be referred to by dependencies other than its name.

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 섹션에 사용된 항목은 아래 표에 나열되어 있습니다.

표 3.2. RPM SPEC 파일의 DestinationRule 섹션에서 사용되는 항목
SPECECDHE정의

%description

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

%prep

소프트웨어를 빌드할 명령 또는 일련의 명령(예: Source0 에서 아카이브 압축을 풉니다.) 이 지시문에는 쉘 스크립트가 포함될 수 있습니다.

%build

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

%install

%builddir 에서 원하는 빌드 아티팩트를 복사하기 위한 명령 또는 일련의 명령(빌드이 발생하는 경우)은 패키징할 파일과 함께 디렉터리 구조를 포함하는 %buildroot 디렉토리로 복사합니다. 일반적으로 ~/rpmbuild/BUILD에서 ~/rpmbuild/BUILD ROOT 로 파일을 복사하고 ~/rpmbuild/BUILDROOT 에 필요한 디렉터리를 만드는 것을 의미합니다. 이는 최종 사용자가 패키지를 설치하는 경우가 아니라 패키지를 만들 때만 실행됩니다. 자세한 내용은 3.2절. “SPEC 파일 작업” 을 참조하십시오.

%check

소프트웨어를 테스트하기 위한 명령 또는 일련의 명령 여기에는 일반적으로 단위 테스트와 같은 사항이 포함됩니다.

%files

최종 사용자의 시스템에 설치될 파일 목록입니다.

%changelog

다양한 버전 또는 릴리스 빌드 간 패키지에 발생한 변경 사항 레코드입니다.

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
Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

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

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

Red Hat 소개

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

© 2024 Red Hat, Inc.