소프트웨어 패키지 및 배포


Red Hat Enterprise Linux 10

RPM 패키지 관리 시스템을 사용하여 소프트웨어 패키징

Red Hat Customer Content Services

초록

RPM 패키지 관리자를 사용하여 소프트웨어를 RPM 패키지로 패키징합니다. 패키징, 패키지 소프트웨어, Python 프로젝트 패키징 또는 RubyGems 패키지를 RPM 패키지로 확인하는 등 고급 패키징 시나리오를 위한 소스 코드를 준비합니다.

Red Hat 문서에 관한 피드백 제공

문서 개선을 위한 의견에 감사드립니다. 어떻게 개선할 수 있는지 알려주십시오.

Jira를 통해 피드백 제출 (계정 필요)

  1. Jira 웹 사이트에 로그인합니다.
  2. 상단 탐색 바에서 생성을 클릭합니다.
  3. 요약 필드에 설명 제목을 입력합니다.
  4. 설명 필드에 개선을 위한 제안을 입력합니다. 문서의 관련 부분에 대한 링크를 포함합니다.
  5. 대화 상자 하단에서 생성 을 클릭합니다.

1장. RPM 소개

RPM(RPM)은 RHEL(Red Hat Enterprise Linux), CentOS 및 Fedora에서 실행되는 패키지 관리 시스템입니다. RPM을 사용하여 이러한 운영 체제에 대해 생성하는 소프트웨어를 배포, 관리 및 업데이트할 수 있습니다.

RPM 패키지 관리 시스템은 기존 아카이브 파일에 소프트웨어를 배포하는 것보다 다음과 같은 이점이 있습니다.

  • RPM은 서로 독립적으로 설치, 업데이트 또는 제거할 수 있는 패키지 형태로 소프트웨어를 관리하므로 운영 체제를 보다 쉽게 유지 관리할 수 있습니다.
  • RPM 패키지는 압축된 아카이브와 유사하게 독립 실행형 바이너리 파일이므로 RPM을 단순화합니다. 이러한 패키지는 특정 운영 체제 및 하드웨어 아키텍처를 위해 빌드됩니다. RPM에는 패키지가 설치될 때 파일 시스템의 적절한 경로에 배치되는 컴파일된 실행 파일 및 라이브러리와 같은 파일이 포함되어 있습니다.

RPM을 사용하면 다음 작업을 수행할 수 있습니다.

  • 패키지 소프트웨어를 설치, 업그레이드 및 제거합니다.
  • 패키지 소프트웨어에 대한 자세한 정보를 쿼리합니다.
  • 패키지 소프트웨어의 무결성을 확인합니다.
  • 소프트웨어 소스에서 자체 패키지를 빌드하고 빌드 지침을 완료합니다.
  • GPG(GNU Privacy Guard) 유틸리티를 사용하여 패키지에 디지털 서명합니다.
  • DNF 리포지토리에 패키지를 게시합니다.

Red Hat Enterprise Linux에서 RPM은 DNF 또는 PackageKit과 같은 고급 패키지 관리 소프트웨어에 완전히 통합되어 있습니다. RPM은 자체 명령줄 인터페이스를 제공하지만 대부분의 사용자는 이 소프트웨어를 통해서만 RPM과 상호 작용해야 합니다. 그러나 RPM 패키지를 빌드할 때는 rpmbuild(8) 와 같은 RPM 유틸리티를 사용해야 합니다.

1.1. RPM 패키지

RPM 패키지는 이러한 파일을 설치 및 삭제하는 데 사용되는 파일 및 메타데이터의 아카이브로 구성됩니다. 특히 RPM 패키지에는 다음 부분이 포함되어 있습니다.

  • GPG 서명

    GPG 서명은 패키지의 무결성을 확인하는 데 사용됩니다.

  • 헤더(패키지 메타데이터)

    RPM 패키지 관리자는 이 메타데이터를 사용하여 패키지 종속성, 파일 설치 위치 및 기타 정보를 확인합니다.

  • 페이로드

    페이로드는 시스템에 설치할 파일이 포함된 cpio 아카이브입니다.

RPM 패키지에는 다음 두 가지 유형이 있습니다. 두 유형 모두 파일 형식과 툴링을 공유하지만 콘텐츠가 다르며 다른 용도로 사용됩니다.

  • 소스 RPM(SRPM)

    SRPM에는 소스 코드와 사양 파일이 포함되어 있으며, 바이너리 RPM에 소스 코드를 빌드하는 방법을 설명합니다. 선택적으로 SRPM은 소스 코드에 대한 패치를 포함할 수 있습니다.

  • 바이너리 RPM

    바이너리 RPM에는 소스 및 패치에서 빌드된 바이너리가 포함되어 있습니다.

1.2. RPM 패키징 유틸리티 나열

RPM은 패키지 빌드를 위한 rpmbuild(8) 프로그램 외에도 다른 유틸리티를 제공하여 패키지 생성 프로세스를 보다 쉽게 수행할 수 있도록 합니다. 이러한 프로그램은 rpmdevtools 패키지에서 찾을 수 있습니다.

사전 요구 사항

  • rpmdevtools 패키지가 설치되었습니다.

    # dnf install rpmdevtools
    Copy to Clipboard Toggle word wrap

프로세스

  • 다음 방법 중 하나를 사용하여 RPM 패키징 유틸리티를 나열합니다.

    • rpmdevtools 패키지에서 제공하는 특정 유틸리티와 짧은 설명을 나열하려면 다음을 입력합니다.

      $ rpm -qi rpmdevtools
      Copy to Clipboard Toggle word wrap
    • 모든 유틸리티를 나열하려면 다음을 입력합니다.

      $ rpm -ql rpmdevtools | grep ^/usr/bin
      Copy to Clipboard Toggle word wrap

2장. RPM 패키징 소프트웨어 생성

RPM 패키징용 소프트웨어를 준비하려면 소스 코드가 무엇이며 소프트웨어 생성 방법을 이해해야 합니다.

2.1. 소스 코드란

소스 코드는 계산을 수행하는 방법을 설명하는 컴퓨터에 대해 사람이 읽을 수 있는 명령입니다. 소스 코드는 프로그래밍 언어를 사용하여 표현됩니다.

세 가지 프로그래밍 언어로 작성된 Hello World 프로그램의 다음 버전은 주요 RPM 패키지 관리자 사용 사례를 다룹니다.

  • bash로 작성된 hello world

    bello 프로젝트는 Bash에서 Hello World 를 구현합니다. 구현에는 bello 쉘 스크립트만 포함됩니다. 이 프로그램의 목적은 명령줄에서 Hello World 를 출력하는 것입니다.

    벨로 파일에는 다음 내용이 있습니다.

    #!/bin/bash
    
    printf "Hello World\n"
    Copy to Clipboard Toggle word wrap
  • Hello World 는 Python으로 작성됩니다.

    pello 프로젝트는 Python에서 Hello World 를 구현합니다. 구현에는 pello.py 프로그램만 포함됩니다. 프로그램의 목적은 명령줄에서 Hello World 를 출력하는 것입니다.

    pello.py 파일에는 다음과 같은 내용이 있습니다.

    #!/usr/bin/python3
    
    print("Hello World")
    Copy to Clipboard Toggle word wrap
  • Hello World 에서 C로 작성됩니다.

    cello 프로젝트는 Hello World in C를 구현합니다. 구현에는 cello.cMakefile 파일만 포함됩니다. 따라서 생성된 tar.gz 아카이브에는 LICENSE 파일 외에 두 개의 파일이 있습니다. 프로그램의 목적은 명령줄에서 Hello World 를 출력하는 것입니다.

    cello.c 파일에는 다음과 같은 내용이 있습니다.

    #include <stdio.h>
    
    int main(void) {
        printf("Hello World\n");
        return 0;
    }
    Copy to Clipboard Toggle word wrap
참고

패키징 프로세스는 Hello World 프로그램의 각 버전에 따라 다릅니다.

2.2. 소프트웨어 생성 방법

다음 방법 중 하나를 사용하여 사람이 읽을 수 있는 소스 코드를 머신 코드로 변환할 수 있습니다.

  • 기본적으로 소프트웨어를 컴파일합니다.
  • 언어 인터프리터 또는 언어 가상 머신을 사용하여 소프트웨어를 해석합니다. raw-interpret 또는 byte-compile 소프트웨어 중 하나를 사용할 수 있습니다.

2.2.1. 기본적으로 컴파일된 소프트웨어

고유하게 컴파일된 소프트웨어는 결과 바이너리 실행 파일을 사용하여 머신 코드로 컴파일되는 프로그래밍 언어로 작성된 소프트웨어입니다. 기본적으로 컴파일된 소프트웨어는 독립 실행형 소프트웨어입니다.

참고

기본적으로 컴파일된 RPM 패키지는 아키텍처에 따라 다릅니다.

64비트(x86_64) AMD 또는 Intel 프로세서를 사용하는 컴퓨터에서 이러한 소프트웨어를 컴파일하면 32비트(x86) AMD 또는 Intel 프로세서에서 실행되지 않습니다. 결과 패키지에는 이름에 지정된 아키텍처가 있습니다.

2.2.2. 해석된 소프트웨어

Bash 또는 Python과 같은 일부 프로그래밍 언어는 머신 코드로 컴파일되지 않습니다. 대신 언어 인터프리터 또는 언어 가상 머신은 사전 변환 없이 프로그램의 소스 코드를 단계별로 실행합니다.

참고

완전히 해석된 프로그래밍 언어로 작성된 소프트웨어는 아키텍처에 한정되지 않습니다. 따라서 결과 RPM 패키지에는 이름에 noarch 문자열이 있습니다.

해석된 언어로 작성된 raw-interpret 또는 byte-compile 소프트웨어 중 하나를 사용할 수 있습니다.

  • 원시 중단 소프트웨어

    이러한 유형의 소프트웨어를 컴파일할 필요는 없습니다. 원시 해석 소프트웨어는 인터프리터에 의해 직접 실행됩니다.

  • 바이트로 컴파일된 소프트웨어

    먼저 이 유형의 소프트웨어를 바이트 코드로 컴파일해야 하며, 그런 다음 언어 가상 머신에서 실행해야 합니다.

    참고

    일부 바이트로 컴파일된 언어는 원시 해석 또는 바이트 컴파일될 수 있습니다.

RPM을 사용하여 소프트웨어를 빌드하고 패키지하는 방법은 두 가지 소프트웨어 유형에 따라 다릅니다.

2.3. 소스에서 소프트웨어 빌드

소프트웨어 빌드 프로세스 중에 소스 코드는 RPM을 사용하여 패키징할 수 있는 소프트웨어 아티팩트로 변환됩니다.

2.3.1. 기본적으로 컴파일된 코드에서 소프트웨어 빌드

다음 방법 중 하나를 사용하여 컴파일된 언어로 작성된 소프트웨어를 실행 파일로 빌드할 수 있습니다.

  • 수동 빌드
  • 자동화된 빌드
2.3.1.1. 수동으로 샘플 C 프로그램 빌드

수동 빌드를 사용하여 컴파일된 언어로 작성된 소프트웨어를 빌드할 수 있습니다.

C (cello.c)로 작성된 샘플 Hello World 프로그램에는 다음과 같은 내용이 있습니다.

#include <stdio.h>

int main(void) {
    printf("Hello World\n");
    return 0;
}
Copy to Clipboard Toggle word wrap

프로세스

  1. GNU Compiler Collection에서 C 컴파일러를 호출하여 소스 코드를 바이너리로 컴파일합니다.

    $ gcc -g -o cello cello.c
    Copy to Clipboard Toggle word wrap
  2. 결과 바이너리 셀로를 실행합니다.

    $ ./cello
    Hello World
    Copy to Clipboard Toggle word wrap
2.3.1.2. 샘플 C 프로그램에 대한 자동화된 빌드 설정

대규모 소프트웨어는 일반적으로 자동화된 빌드를 사용합니다. Makefile 파일을 만든 다음 GNU make 유틸리티를 실행하여 자동화된 빌드를 설정할 수 있습니다.

프로세스

  1. cello.c 와 동일한 디렉토리에 다음 콘텐츠를 사용하여 Makefile 파일을 만듭니다.

    cello:
    	gcc -g -o cello cello.c
    clean:
    	rm cello
    Copy to Clipboard Toggle word wrap

    cello:clean 아래의 줄은 탭 문자(tab)로 시작해야 합니다.

  2. 소프트웨어를 빌드합니다.

    $ make
    make: 'cello' is up to date.
    Copy to Clipboard Toggle word wrap
  3. 빌드는 현재 디렉터리에서 이미 사용할 수 있으므로 make clean 명령을 입력한 다음 make 명령을 다시 입력합니다.

    $ make clean
    rm cello
    
    $ make
    gcc -g -o cello cello.c
    Copy to Clipboard Toggle word wrap

    이 시점에서 프로그램을 다시 빌드하려는 경우 GNU make 시스템이 기존 바이너리를 감지하므로 영향을 미치지 않습니다.

    $ make
    make: 'cello' is up to date.
    Copy to Clipboard Toggle word wrap
  4. 프로그램을 실행합니다.

    $ ./cello
    Hello World
    Copy to Clipboard Toggle word wrap

2.3.2. 소스 코드 해석

해석된 프로그래밍 언어로 작성된 소스 코드를 다음 방법 중 하나를 사용하여 머신 코드로 변환할 수 있습니다.

  • 바이트 컴파일

    바이트 컴파일 소프트웨어의 절차는 다음 요인에 따라 다릅니다.

    • 프로그래밍 언어
    • 언어의 가상 머신
    • 해당 언어와 함께 사용되는 툴 및 프로세스

      참고

      예를 들어 Python에서 작성된 소프트웨어를 바이트화할 수 있습니다. 배포를 위해 설계된 Python 소프트웨어는 종종 바이트로 컴파일되지만 이 문서에서 설명하는 방식에는 포함되지 않습니다. 설명된 절차는 커뮤니티 표준을 준수하는 것이 아니라 간단하게 하는 것을 목표로 합니다. 실제 Python 지침의 경우 소프트웨어 패키징 및 배포를 참조하십시오.

    또한 원시 해석 Python 소스 코드도 사용할 수 있습니다. 그러나 바이트로 컴파일된 버전이 더 빠릅니다. 따라서 RPM 패키지는 최종 사용자에게 배포하기 위해 바이트로 컴파일된 버전을 패키징하는 것을 선호합니다.

  • Raw-interpreting

    Bash와 같은 쉘 스크립팅 언어로 작성된 소프트웨어는 항상 원시 해석에 의해 실행됩니다.

2.3.2.1. 샘플 Python 프로그램 바이트 컴파일

Python 소스 코드의 원시 해석을 통해 바이트 컴파일을 선택하면 더 빠른 소프트웨어를 만들 수 있습니다.

Python 프로그래밍 언어(pello.py)로 작성된 샘플 Hello World 프로그램에는 다음과 같은 내용이 있습니다.

print("Hello World")
Copy to Clipboard Toggle word wrap

프로세스

  1. pello.py 파일을 byte-compile합니다.

    $ python -m compileall pello.py
    Copy to Clipboard Toggle word wrap
  2. 바이트로 컴파일된 파일 버전이 생성되었는지 확인합니다.

    $ ls __pycache__
    pello.cpython-311.pyc
    Copy to Clipboard Toggle word wrap

    출력의 패키지 버전은 설치된 Python 버전에 따라 다를 수 있습니다.

  3. pello.py 에서 프로그램을 실행합니다.

    $ python pello.py
    Hello World
    Copy to Clipboard Toggle word wrap
2.3.2.2. 샘플 Bash 프로그램 원시 해석

Bash 쉘로 내장된 언어(llo)로 작성된 샘플 Hello World 프로그램에는 다음과 같은 내용이 있습니다.

#!/bin/bash

printf "Hello World\n"
Copy to Clipboard Toggle word wrap
참고

벨로 파일의 상단에 있는 shebang (#!)기호는 프로그래밍 언어 소스 코드의 일부가 아닙니다.

shebang 을 사용하여 텍스트 파일을 실행 파일로 전환합니다. 시스템 프로그램 로더는 shebang 이 포함된 행을 구문 분석하여 바이너리 실행 파일의 경로를 가져온 다음 프로그래밍 언어 인터프리터로 사용됩니다.

프로세스

  1. 소스 코드로 파일을 실행 가능하게 만듭니다.

    $ chmod +x bello
    Copy to Clipboard Toggle word wrap
  2. 생성된 파일을 실행합니다.

    $ ./bello
    Hello World
    Copy to Clipboard Toggle word wrap

3장. RPM 패키지용 소프트웨어 준비

RPM을 사용하여 패키징할 소프트웨어를 준비하려면 먼저 소프트웨어를 패치하고 LICENSE 파일을 만들고 tarball로 보관하면 됩니다.

3.1. 소프트웨어 패치

소프트웨어를 패키징할 때는 버그 수정 또는 구성 파일 변경과 같은 원래 소스 코드를 변경해야 할 수 있습니다. RPM 패키징에서는 원래 소스 코드를 그대로 두고 패치를 적용할 수 있습니다.

패치는 소스 코드 파일을 업데이트하는 텍스트입니다. 패치는 두 버전의 텍스트의 차이를 나타내기 때문에 diff 형식이 있습니다. diff 유틸리티를 사용하여 패치를 생성한 다음 patch 유틸리티를 사용하여 소스 코드에 패치를 적용할 수 있습니다.

참고

소프트웨어 개발자는 종종 Git과 같은 버전 제어 시스템을 사용하여 코드 기반을 관리합니다. 이러한 도구는 diffs 또는 Patch 소프트웨어를 만드는 자체 방법을 제공합니다.

3.1.1. 샘플 C 프로그램에 대한 패치 파일 생성

diff 유틸리티를 사용하여 원래 소스 코드에서 패치를 생성할 수 있습니다. 예를 들어 C (cello.c)로 작성된 Hello world 프로그램을 패치하려면 다음 단계를 완료합니다.

사전 요구 사항

  • 시스템에 diff 유틸리티를 설치했습니다.

    # dnf install diffutils
    Copy to Clipboard Toggle word wrap

프로세스

  1. 원래 소스 코드를 백업합니다.

    $ cp -p cello.c cello.c.orig
    Copy to Clipboard Toggle word wrap

    p 옵션은 모드, 소유권 및 타임스탬프를 유지합니다.

  2. 필요에 따라 cello.c 를 수정합니다.

    #include <stdio.h>
    
    int main(void) {
        printf("Hello World from my very first patch!\n");
        return 0;
    }
    Copy to Clipboard Toggle word wrap
  3. 패치를 생성합니다.

    $ diff -Naur cello.c.orig cello.c
    --- cello.c.orig        2016-05-26 17:21:30.478523360 -0500
    + cello.c     2016-05-27 14:53:20.668588245 -0500
    @@ -1,6 +1,6 @@
     #include<stdio.h>
    
     int main(void){
    -    printf("Hello World!\n");
    +    printf("Hello World from my very first patch!\n");
         return 0;
     }
    \ No newline at end of file
    Copy to Clipboard Toggle word wrap

    + 로 시작하는 줄은 - 로 시작하는 행을 바꿉니다.

    참고

    대부분의 사용 사례에 적합하므로 diff 명령과 함께 n ur 옵션을 사용하는 것이 좋습니다.

    • - n (--new-file)

      N 옵션은 없는 파일을 빈 파일로 처리합니다.

    • -a (--text)

      a 옵션은 모든 파일을 텍스트로 처리합니다. 결과적으로 diff 유틸리티는 바이너리로 분류된 파일을 무시하지 않습니다.

    • -u (-U NUM 또는 --unified[=NUM])

      -u 옵션은 통합 컨텍스트의 출력 NUM(기본값 3) 줄로 출력을 반환합니다. 이는 패치 파일에서 일반적으로 사용되는 컴팩트하고 쉽게 읽을 수 있는 형식입니다.

    • -r (--recursive)

      r 옵션은 diff 유틸리티에서 발견된 하위 디렉토리를 재귀적으로 비교합니다.

    그러나 이 특별한 경우에는 -u 옵션만 필요합니다.

  4. 패치를 파일에 저장합니다.

    $ diff -Naur cello.c.orig cello.c > cello.patch
    Copy to Clipboard Toggle word wrap
  5. 원래 cello.c 를 복원하십시오.

    $ mv cello.c.orig cello.c
    Copy to Clipboard Toggle word wrap
    중요

    RPM 패키지를 빌드할 때 RPM 패키지 관리자가 수정된 파일이 아닌 원본 파일을 사용하므로 원래 cello.c 를 유지해야 합니다. 자세한 내용은 사양 파일 작업을 참조하십시오.

3.1.2. 샘플 C 프로그램 패치

소프트웨어에 코드 패치를 적용하려면 patch 유틸리티를 사용할 수 있습니다.

사전 요구 사항

  • 시스템에 패치 유틸리티를 설치했습니다.

    # dnf install patch
    Copy to Clipboard Toggle word wrap
  • 원본 소스 코드에서 패치를 생성했습니다. 자세한 내용은 샘플 C 프로그램에 대한 패치 파일 생성을 참조하십시오.

프로세스

다음 단계는 cello.c 파일에 이전에 생성된 cello.patch 파일을 적용합니다.

  1. 패치 파일을 패치 명령으로 리디렉션합니다.

    $ patch < cello.patch
    patching file cello.c
    Copy to Clipboard Toggle word wrap
  2. cello.c 의 내용이 이제 원하는 변경 사항을 반영하는지 확인합니다.

    $ cat cello.c
    #include<stdio.h>
    
    int main(void){
        printf("Hello World from my very first patch!\n");
        return 1;
    }
    Copy to Clipboard Toggle word wrap

검증

  1. 패치된 cello.c 프로그램을 빌드합니다.

    $ make
    gcc -g -o cello cello.c
    Copy to Clipboard Toggle word wrap
  2. 빌드된 cello.c 프로그램을 실행합니다.

    $ ./cello
    Hello World from my very first patch!
    Copy to Clipboard Toggle word wrap

3.2. LICENSE 파일 만들기

소프트웨어 라이센스와 함께 소프트웨어를 배포하는 것이 좋습니다.

소프트웨어 라이센스 파일은 사용자에게 소스 코드로 수행할 수 있는 작업을 사용자에게 알립니다. 소스 코드에 대한 라이센스가 없으면 이 코드에 대한 모든 권한을 보유하고 소스 코드에서 파생 작업을 재현, 배포 또는 생성할 수 없습니다.

프로세스

  • 필요한 라이센스 문을 사용하여 LICENSE 파일을 생성합니다.

    $ vim LICENSE
    Copy to Clipboard Toggle word wrap

    예 3.1. GPLv3 LICENSE 파일 텍스트 예

    $ cat /tmp/LICENSE
    This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.
    
    This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
    
    You should have received a copy of the GNU General Public License along with this program. If not, see http://www.gnu.org/licenses/.
    Copy to Clipboard Toggle word wrap

3.3. 배포를 위한 소스 코드 아카이브 생성

아카이브 파일은 .tar.gz 또는 .tgz 접미사가 있는 파일입니다. 소스 코드를 아카이브에 배치하는 것은 나중에 배포를 위해 패키징할 소프트웨어를 릴리스하는 일반적인 방법입니다.

3.3.1. 샘플 Bash 프로그램의 소스 코드 아카이브 생성

벨로 프로젝트는 Bash의 Hello World 파일입니다.

다음 예제에는 bello 쉘 스크립트만 포함되어 있습니다. 따라서 생성된 tar.gz 아카이브에는 LICENSE 파일 외에 하나의 파일만 있습니다.

참고

패치 파일은 프로그램과 함께 아카이브에 배포되지 않습니다. RPM 패키지 관리자는 RPM을 빌드할 때 패치를 적용합니다. 패치는 tar.gz 아카이브와 함께 ~/rpmbuild/SOURCES/ 디렉터리에 배치됩니다.

사전 요구 사항

  • bello 프로그램의 0.1 버전이 사용된다고 가정합니다.
  • LICENSE 파일을 생성하셨습니다. 자세한 내용은 LICENSE 파일 만들기를 참조하십시오.

프로세스

  1. 필요한 모든 파일을 단일 디렉터리로 이동합니다.

    $ mkdir bello-0.1
    
    $ mv ~/bello bello-0.1/
    
    $ mv LICENSE bello-0.1/
    Copy to Clipboard Toggle word wrap
  2. 배포를 위한 아카이브를 생성합니다.

    $ tar -cvzf bello-0.1.tar.gz bello-0.1
    bello-0.1/
    bello-0.1/LICENSE
    bello-0.1/bello
    Copy to Clipboard Toggle word wrap
  3. 생성된 아카이브를 ~/rpmbuild/SOURCES/ 디렉터리로 이동합니다. 이 디렉터리는 rpmbuild 명령이 패키지 빌드용 파일을 저장하는 기본 디렉터리입니다.

    $ mv bello-0.1.tar.gz ~/rpmbuild/SOURCES/
    Copy to Clipboard Toggle word wrap

3.3.2. 샘플 Python 프로그램에 대한 소스 코드 아카이브 생성

pello 프로젝트는 Python의 Hello World 파일입니다.

다음 예제는 pello.py 프로그램만 포함합니다. 따라서 생성된 tar.gz 아카이브에는 LICENSE 파일 외에 하나의 파일만 있습니다.

참고

패치 파일은 프로그램과 함께 아카이브에 배포되지 않습니다. RPM 패키지 관리자는 RPM을 빌드할 때 패치를 적용합니다. 패치는 tar.gz 아카이브와 함께 ~/rpmbuild/SOURCES/ 디렉터리에 배치됩니다.

사전 요구 사항

  • pello 프로그램의 0.1.1 버전이 사용되었다고 가정합니다.
  • LICENSE 파일을 생성하셨습니다. 자세한 내용은 LICENSE 파일 만들기를 참조하십시오.

프로세스

  1. 필요한 모든 파일을 단일 디렉터리로 이동합니다.

    $ mkdir pello-0.1.1
    
    $ mv pello.py pello-0.1.1/
    
    $ mv LICENSE pello-0.1.1/
    Copy to Clipboard Toggle word wrap
  2. 배포를 위한 아카이브를 생성합니다.

    $ tar -cvzf pello-0.1.1.tar.gz pello-0.1.1
    pello-0.1.1/
    pello-0.1.1/LICENSE
    pello-0.1.1/pello.py
    Copy to Clipboard Toggle word wrap
  3. 생성된 아카이브를 ~/rpmbuild/SOURCES/ 디렉터리로 이동합니다. 이 디렉터리는 rpmbuild 명령이 패키지 빌드용 파일을 저장하는 기본 디렉터리입니다.

    $ mv pello-0.1.1.tar.gz ~/rpmbuild/SOURCES/
    Copy to Clipboard Toggle word wrap

3.3.3. 샘플 C 프로그램에 대한 소스 코드 아카이브 생성

cello 프로젝트는 C의 Hello World 파일입니다.

다음 예제에는 cello.cMakefile 파일만 포함되어 있습니다. 따라서 생성된 tar.gz 아카이브에는 LICENSE 파일 외에도 두 개의 파일이 있습니다.

참고

패치 파일은 프로그램과 함께 아카이브에 배포되지 않습니다. RPM 패키지 관리자는 RPM을 빌드할 때 패치를 적용합니다. 패치는 tar.gz 아카이브와 함께 ~/rpmbuild/SOURCES/ 디렉터리에 배치됩니다.

사전 요구 사항

  • cello 프로그램의 1.0 버전이 사용되었다고 가정합니다.
  • LICENSE 파일을 생성하셨습니다. 자세한 내용은 LICENSE 파일 만들기를 참조하십시오.

프로세스

  1. 필요한 모든 파일을 단일 디렉터리로 이동합니다.

    $ mkdir cello-1.0
    
    $ mv cello.c cello-1.0/
    
    $ mv Makefile cello-1.0/
    
    $ mv LICENSE cello-1.0/
    Copy to Clipboard Toggle word wrap
  2. 배포를 위한 아카이브를 생성합니다.

    $ tar -cvzf cello-1.0.tar.gz cello-1.0
    cello-1.0/
    cello-1.0/Makefile
    cello-1.0/cello.c
    cello-1.0/LICENSE
    Copy to Clipboard Toggle word wrap
  3. 생성된 아카이브를 ~/rpmbuild/SOURCES/ 디렉터리로 이동합니다. 이 디렉터리는 rpmbuild 명령이 패키지 빌드용 파일을 저장하는 기본 디렉터리입니다.

    $ mv cello-1.0.tar.gz ~/rpmbuild/SOURCES/
    Copy to Clipboard Toggle word wrap

4장. 소프트웨어 패키지

다음 섹션에서는 RPM 패키지 관리자를 사용하여 패키징 프로세스의 기본 사항을 알아봅니다.

4.1. RPM 패키지 작업 공간 설정

RPM 패키지를 빌드하려면 먼저 다른 패키징 목적으로 사용되는 디렉터리로 구성된 특수 작업 공간을 생성해야 합니다.

4.1.1. RPM 패키지 작업 공간 구성

RPM 패키징 작업 공간을 구성하려면 rpmdev-setuptree 유틸리티를 사용하여 디렉터리 레이아웃을 설정할 수 있습니다.

사전 요구 사항

  • RPM 패키징 유틸리티를 제공하는 rpmdevtools 패키지가 설치되어 있습니다.

    # dnf install rpmdevtools
    Copy to Clipboard Toggle word wrap

프로세스

  • rpmdev-setuptree 유틸리티를 실행합니다.

    $ rpmdev-setuptree
    
    $ tree ~/rpmbuild/
    /home/user/rpmbuild/
    |-- BUILD
    |-- RPMS
    |-- SOURCES
    |-- SPECS
    `-- SRPMS
    
    5 directories, 0 files
    Copy to Clipboard Toggle word wrap

4.1.2. RPM 패키징 작업 공간 디렉터리

다음은 rpmdev-setuptree 유틸리티를 사용하여 생성된 RPM 패키징 작업 공간 디렉터리입니다.

Expand
표 4.1. RPM 패키징 작업 공간 디렉터리
디렉터리목적

BUILD

SOURCES 디렉터리의 소스 파일에서 컴파일된 빌드 아티팩트를 포함합니다.

RPMS

바이너리 RPM은 다양한 아키텍처의 하위 디렉토리에 있는 RPMS 디렉토리 아래에 생성됩니다. 예를 들어 x86_64 또는 noarch 하위 디렉터리에서.

소스

압축된 소스 코드 아카이브 및 패치를 포함합니다. 그런 다음 rpmbuild 명령은 이 디렉토리에서 이러한 아카이브 및 패치를 검색합니다.

SPECS

패키지 관리자에서 생성한 사양 파일을 포함합니다. 그런 다음 이러한 파일은 패키지를 빌드하는 데 사용됩니다.

SRPMS

rpmbuild 명령을 사용하여 바이너리 RPM 대신 SRPM을 빌드하면 결과 SRPM이 이 디렉터리에 생성됩니다.

4.2. 사양 파일 정보

사양 파일은 rpmbuild 유틸리티에서 RPM 패키지를 빌드하는 데 사용하는 지침이 포함된 파일입니다. 이 파일은 일련의 섹션에 지침을 정의하여 빌드 시스템에 필요한 정보를 제공합니다. 이러한 섹션은 Preamblespec 파일의 Body 부분에 정의되어 있습니다.

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

4.2.1. Preamble 항목

다음은 RPM 사양 파일의 Preamble 섹션에서 사용할 수 있는 몇 가지 지시문입니다.

Expand
표 4.2. 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 지시문을 추가하면 이 패키지를 이름 이외의 종속성에서 참조할 수 있습니다.

이름,버전릴리스 (NVR) 지시문은 name-version-release 형식으로 RPM 패키지의 파일 이름을 구성합니다.

rpm 명령을 사용하여 RPM 데이터베이스를 쿼리하여 특정 패키지에 대한 NVR 정보를 표시할 수 있습니다. 예를 들면 다음과 같습니다.

# rpm -q bash
bash-4.4.19-7.el8.x86_64
Copy to Clipboard Toggle word wrap

여기에서 bash 는 패키지 이름이고 4.4.19 는 버전이며 7.el8 은 릴리스입니다. x86_64 마커는 패키지 아키텍처입니다. NVR 과 달리 아키텍처 마커는 RPM 패키지러를 직접 제어하지 않지만 rpmbuild 빌드 환경에 의해 정의됩니다. 이에 대한 예외는 아키텍처 독립적인 noarch 패키지입니다.

4.2.2. 본문 항목

다음은 RPM 사양 파일의 Body 섹션에 사용된 항목입니다.

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

%Description

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

%Prep

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

%build

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

%install

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

%install 디렉터리는 최종 사용자의 루트 디렉터리와 유사한 빈 chroot 기본 디렉터리입니다. 여기에서 설치된 파일을 포함할 모든 디렉터리를 생성할 수 있습니다. 이러한 디렉터리를 만들려면 경로를 하드 코딩하지 않고도 RPM 매크로를 사용할 수 있습니다.

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

%check

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

%files

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

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

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

%changelog

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

4.2.3. 고급 항목

사양 파일은 Scriptlets 또는 Trigger와 같은 고급 항목을 포함할 수 있습니다. 스크립트릿 및 트리거는 빌드 프로세스가 아닌 최종 사용자의 시스템에서 설치 프로세스 중에 다른 지점에서 적용됩니다.

4.3. BuildRoots

RPM 패키징 컨텍스트에서 buildrootchroot 환경입니다. 빌드 아티팩트는 최종 사용자 시스템에서 향후 계층 구조와 동일한 파일 시스템 계층 구조를 사용하고 buildroot 는 루트 디렉터리 역할을 합니다. 빌드 아티팩트 배치는 최종 사용자 시스템의 파일 시스템 계층 구조 표준을 준수해야 합니다.

buildroot 의 파일은 나중에 RPM의 주요 부분이 되는 cpio 아카이브에 배치됩니다. RPM이 최종 사용자의 시스템에 설치되면 이러한 파일이 루트 디렉터리에 추출되어 올바른 계층 구조를 유지합니다.

참고

rpmbuild 프로그램에는 자체 기본값이 있습니다. 이러한 기본값을 재정의하면 특정 문제가 발생할 수 있습니다. 따라서 buildroot 매크로의 고유한 값을 정의하지 마십시오. 대신 기본 %{buildroot} 매크로를 사용합니다.

4.4. RPM 매크로

rpm 매크로 는 특정 기본 제공 기능이 사용될 때 문의 선택적 평가를 기반으로 조건부로 할당할 수 있는 간단한 텍스트 대체입니다. 따라서 RPM은 텍스트 대체를 수행할 수 있습니다.

예를 들어 패키지된 소프트웨어 버전은 %{version} 매크로에서 한 번만 정의하고 사양 파일 전체에서 이 매크로를 사용할 수 있습니다. 모든 발생은 매크로에서 정의한 Version 으로 자동 대체됩니다.

참고

익숙하지 않은 매크로가 표시되면 다음 명령으로 평가할 수 있습니다.

$ rpm --eval %{MACRO}
Copy to Clipboard Toggle word wrap

예를 들어 %{_bindir}%{_libexecdir} 매크로를 평가하려면 다음을 입력합니다.

$ rpm --eval %{_bindir}
/usr/bin

$ rpm --eval %{_libexecdir}
/usr/libexec
Copy to Clipboard Toggle word wrap

4.5. 사양 파일 작업

새 소프트웨어를 패키징하려면 사양 파일을 생성해야 합니다. 다음 방법 중 하나를 사양 파일을 생성할 수 있습니다.

  • 사양 파일을 처음부터 수동으로 작성합니다.
  • rpmdev-newspec 유틸리티를 사용합니다. 이 유틸리티는 필요한 지시문 및 필드를 채우는 채워지지 않은 사양 파일을 생성합니다.
참고

일부 자격증에 중점을 둔 텍스트 편집기는 자체 사양 템플릿으로 새 사양 파일을 미리 채웁니다. rpmdev-newspec 유틸리티는 편집기와 무관한 방법을 제공합니다.

4.5.1. 샘플 Bash, Python 및 C 프로그램에 대한 새 사양 파일 생성

rpmdev-new spec 유틸리티를 사용하여 Hello World! 프로그램의 세 가지 구현 각각에 대해 사양 파일을 생성할 수 있습니다.

사전 요구 사항

프로세스

  1. ~/rpmbuild/SPECS 디렉터리로 이동합니다.

    $ cd ~/rpmbuild/SPECS
    Copy to Clipboard Toggle word wrap
  2. Hello World! 프로그램의 세 가지 구현 각각에 대한 사양 파일을 생성합니다.

    $ rpmdev-newspec bello
    bello.spec created; type minimal, rpm version >= 4.11.
    
    $ rpmdev-newspec cello
    cello.spec created; type minimal, rpm version >= 4.11.
    
    $ rpmdev-newspec pello
    pello.spec created; type minimal, rpm version >= 4.11.
    Copy to Clipboard Toggle word wrap

    ~/rpmbuild/SPECS/ 디렉터리에는 이제 bello. spec ,cello.spec, pello.spec 이라는 세 개의 사양 파일이 포함되어 있습니다.

  3. 생성된 파일을 검사합니다.

    파일의 지시문은 사양 파일 정보를 나타냅니다. 다음 섹션에서는 rpmdev-newspec 의 출력 파일에 특정 섹션을 채웁니다.

4.5.2. 원래 사양 파일 수정

rpmdev-new spec 유틸리티로 생성된 원본 출력 사양 파일은 rpmbuild 유틸리티에 필요한 지침을 제공하기 위해 수정해야 하는 템플릿을 나타냅니다. 그런 다음 rpmbuild 는 이러한 지침을 사용하여 RPM 패키지를 빌드합니다.

사전 요구 사항

프로세스

  1. rpmdev-newspec 유틸리티에서 제공하는 ~/rpmbuild/SPECS/<name>.spec 파일을 엽니다.
  2. spec 파일 Preamble 섹션의 다음 지시문을 채웁니다.

    이름
    name 이 이미 rpmdev-newspec 에 인수로 지정되었습니다.
    버전
    소스 코드의 업스트림 릴리스 버전과 일치하도록 Version 을 설정합니다.
    릴리스
    릴리스 는 자동으로 1%{?dist} 로 설정되며 처음 1 입니다.
    요약
    패키지에 대한 한 줄 설명을 입력합니다.
    라이센스
    소스 코드와 관련된 소프트웨어 라이센스를 입력합니다.
    URL
    업스트림 소프트웨어 웹 사이트의 URL을 입력합니다. 일관성을 위해 %{name} RPM 매크로 변수를 사용하고 https://example.com/%{name} 형식을 사용합니다.
    소스

    업스트림 소프트웨어 소스 코드에 대한 URL을 입력합니다. 패키지되는 소프트웨어 버전에 직접 연결합니다.

    참고

    이 문서의 예제 URL에는 향후 변경될 수 있는 하드 코드된 값이 포함되어 있습니다. 마찬가지로 릴리스 버전도 변경될 수 있습니다. 이러한 잠재적인 변경 사항을 단순화하려면 %{name}%{version} 매크로를 사용합니다. 이러한 매크로를 사용하면 사양 파일에서 하나의 필드만 업데이트해야 합니다.

    BuildRequires
    패키지에 대한 빌드 시간 종속 항목을 지정합니다.
    필요
    패키지에 대한 런타임 종속 항목을 지정합니다.
    BuildArch
    소프트웨어 아키텍처를 지정합니다.
  3. spec 파일 Body 섹션의 다음 지시문을 채웁니다. 이러한 지시문은 여러 줄, 다중 설명 또는 스크립팅된 작업을 정의할 수 있으므로 이러한 지시문을 섹션 제목으로 간주할 수 있습니다.

    %Description
    소프트웨어에 대한 전체 설명을 입력합니다.
    %Prep
    빌드용 소프트웨어를 준비하려면 명령 또는 일련의 명령을 입력합니다.
    %build
    소프트웨어 빌드를 위한 명령 또는 일련의 명령을 입력합니다.
    %install
    rpmbuild 명령에 소프트웨어를 BUILDROOT 디렉터리에 설치하는 방법에 대한 명령 또는 일련의 명령을 입력합니다.
    %files
    RPM 패키지에서 제공하는 파일 목록을 시스템에 설치합니다.
    %changelog

    패키지의 각 Version-Release 에 대한 datestamped 항목 목록을 입력합니다.

    별표(*) 문자 뒤에 Day -of-Week Day Name Surname <email> - Version-Release 를 사용하여 %changelog 섹션의 첫 번째 행을 시작합니다.

    실제 변경 항목은 다음 규칙을 따릅니다.

    • 각 변경 항목에는 각 변경 사항에 대해 하나씩 여러 항목이 포함될 수 있습니다.
    • 각 항목은 새 줄에서 시작됩니다.
    • 각 항목은 하이픈(-) 문자로 시작합니다.

이제 필요한 프로그램에 대한 전체 사양 파일을 작성했습니다.

4.5.3. 샘플 Bash 프로그램의 사양 파일 예

참조를 위해 bash 작성된 벨로 프로그램에 다음 예제 사양 파일을 사용할 수 있습니다.

bash로 작성된 bello 프로그램의 사양 파일 예

Name:           bello
Version:        0.1
Release:        1%{?dist}
Summary:        Hello World example implemented in bash script

License:        GPLv3+
URL:            https://www.example.com/%{name}
Source0:        https://www.example.com/%{name}/releases/%{name}-%{version}.tar.gz

Requires:       bash

BuildArch:      noarch

%description
The long-tail description for our Hello World Example implemented in
bash script.

%prep
%setup -q

%build

%install

mkdir -p %{buildroot}/%{_bindir}

install -m 0755 %{name} %{buildroot}/%{_bindir}/%{name}

%files
%license LICENSE
%{_bindir}/%{name}

%changelog
* Tue May 31 2016 Adam Miller <maxamillion@fedoraproject.org> - 0.1-1
- First bello package
- Example second item in the changelog for version-release 0.1-1
Copy to Clipboard Toggle word wrap

  • llo 에 대한 빌드 시간 종속 항목을 지정하는 BuildRequires 지시문이 삭제되었습니다. Bash는 원시 해석 프로그래밍 언어이며 파일은 시스템의 위치에 설치됩니다.
  • 패키지에 대한 런타임 종속성을 지정하는 Requires 지시문에는 bello 스크립트를 실행하기 위해 bash 쉘 환경만 필요하므로 bash 만 포함됩니다.
  • bash 스크립트를 빌드할 필요가 없기 때문에 소프트웨어 빌드 방법을 지정하는 %build 섹션은 비어 있습니다.
참고

벨로를 설치하려면 대상 디렉터리를 생성하고 실행 가능한 bash 스크립트 파일을 설치해야 합니다. 따라서 %install 섹션에서 install 명령을 사용할 수 있습니다. RPM 매크로를 사용하여 하드 코딩 경로 없이 이 작업을 수행할 수 있습니다.

4.5.4. 샘플 Python 프로그램에 대한 사양 파일의 예

참조용으로 Python 프로그래밍 언어로 작성된 pello 프로그램에 다음 예제 사양 파일을 사용할 수 있습니다.

Python으로 작성된 pello 프로그램의 사양 파일 예

Name:           pello
Version:        0.1.1
Release:        1%{?dist}
Summary:        Hello World example implemented in Python

License:        GPLv3+
URL:            https://www.example.com/%{name}
Source0:        https://www.example.com/%{name}/releases/%{name}-%{version}.tar.gz

BuildRequires:  python
Requires:       python
Requires:       bash

BuildArch:      noarch

%description
The long-tail description for our Hello World Example implemented in Python.

%prep
%setup -q

%build

python -m compileall %{name}.py

%install

mkdir -p %{buildroot}/%{_bindir}
mkdir -p %{buildroot}/usr/lib/%{name}

cat > %{buildroot}/%{_bindir}/%{name} <<EOF
#!/bin/bash
/usr/bin/python /usr/lib/%{name}/%{name}.pyc
EOF

chmod 0755 %{buildroot}/%{_bindir}/%{name}

install -m 0644 %{name}.py* %{buildroot}/usr/lib/%{name}/

%files
%license LICENSE
%dir /usr/lib/%{name}/
%{_bindir}/%{name}
/usr/lib/%{name}/%{name}.py*

%changelog
* Tue May 31 2016 Adam Miller <maxamillion@fedoraproject.org> - 0.1.1-1
  - First pello package
Copy to Clipboard Toggle word wrap

  • 패키지에 대한 런타임 종속성을 지정하는 Requires 지시문에는 다음 두 가지 패키지가 포함됩니다.

    • python 패키지는 런타임 시 바이트로 컴파일된 코드를 실행하는 데 필요합니다.
    • small entry-point 스크립트를 실행하는 데 필요한 bash 패키지입니다.
  • 패키지의 build-time 종속 항목을 지정하는 BuildRequires 지시문에는 python 패키지만 포함됩니다. pello 프로그램을 사용하려면 python 이 바이트 컴파일 빌드 프로세스를 수행해야 합니다.
  • 소프트웨어를 빌드하는 방법을 지정하는 %build 섹션은 바이트로 컴파일된 버전의 스크립트를 생성합니다. 실제 패키지에서는 일반적으로 사용되는 배포에 따라 자동으로 수행됩니다.
  • %install 섹션은 바이트로 컴파일된 파일을 시스템의 라이브러리 디렉터리에 설치해야 하므로 액세스할 수 있습니다.

spec 파일에 래퍼 스크립트를 인라인으로 생성하는 예에서는 사양 파일 자체를 스크립팅할 수 있음을 보여줍니다. 이 래퍼 스크립트는 여기 문서를 사용하여 Python 바이트로 컴파일된 코드를 실행합니다.

4.5.5. 샘플 C 프로그램에 대한 사양 파일 예

참조용으로 C 프로그래밍 언어로 작성된 cello 프로그램에 다음 예제 사양 파일을 사용할 수 있습니다.

C로 작성된 셀오 프로그램에 대한 사양 파일의 예

Name:           cello
Version:        1.0
Release:        1%{?dist}
Summary:        Hello World example implemented in C

License:        GPLv3+
URL:            https://www.example.com/%{name}
Source0:        https://www.example.com/%{name}/releases/%{name}-%{version}.tar.gz

Patch0:         cello-output-first-patch.patch

BuildRequires:  gcc
BuildRequires:  make

%description
The long-tail description for our Hello World Example implemented in
C.

%prep
%setup -q

%patch0

%build
make %{?_smp_mflags}

%install
%make_install

%files
%license LICENSE
%{_bindir}/%{name}

%changelog
* Tue May 31 2016 Adam Miller <maxamillion@fedoraproject.org> - 1.0-1
- First cello package
Copy to Clipboard Toggle word wrap

  • 패키지에 대한 빌드 시간 종속성을 지정하는 BuildRequires 지시문에는 컴파일 빌드 프로세스를 수행하는 데 필요한 다음 패키지가 포함됩니다.

    • gcc
    • make
  • 이 예제에서는 패키지에 대한 런타임 종속 항목을 지정하는 Requires 지시문을 생략합니다. 모든 런타임 요구 사항은 rpmbuild 에서 처리하며, cello 프로그램에는 코어 C 표준 라이브러리 이외의 항목이 필요하지 않습니다.
  • %build 섹션은 이 예에서 cello 프로그램의 Makefile 파일이 작성되었다는 사실을 반영합니다. 따라서 GNU make 명령을 사용할 수 있습니다. 그러나 구성 스크립트를 제공하지 않았기 때문에 %configure 에 대한 호출을 제거해야 합니다.

%make_install 매크로를 사용하여 cello 프로그램을 설치할 수 있습니다. 이는 cello 프로그램에 대한 Makefile 파일을 사용할 수 있기 때문에 가능합니다.

4.6. RPM 빌드

rpmbuild 명령을 사용하여 RPM 패키지를 빌드할 수 있습니다. 이 명령을 사용하는 경우 rpmdev-setuptree 유틸리티에서 설정한 구조와 동일한 특정 디렉터리 및 파일 구조가 예상됩니다.

다양한 사용 사례와 원하는 결과에는 rpmbuild 명령에 서로 다른 인수 조합이 필요합니다. 다음은 주요 사용 사례입니다.

  • 소스 RPM 빌드.
  • 바이너리 RPM 빌드:

    • 소스 RPM에서 바이너리 RPM 다시 빌드.
    • 사양 파일에서 바이너리 RPM 빌드.

4.6.1. 소스 RPM 빌드

SRPM(Source RPM)을 구축하면 다음과 같은 이점이 있습니다.

  • 환경에 배포된 RPM 파일의 특정 Name-Version-Release 의 정확한 소스를 유지할 수 있습니다. 여기에는 정확한 사양 파일, 소스 코드 및 모든 관련 패치가 포함됩니다. 이는 추적 및 디버깅 목적에 유용합니다.
  • 다른 하드웨어 플랫폼 또는 아키텍처에 바이너리 RPM을 빌드할 수 있습니다.

사전 요구 사항

  • 시스템에 rpmbuild 유틸리티를 설치했습니다.

    # dnf install rpm-build
    Copy to Clipboard Toggle word wrap
  • 다음 Hello World! 구현은 ~/rpmbuild/SOURCES/ 디렉터리에 배치되었습니다.

  • 패키징하려는 프로그램의 사양 파일이 있습니다.

프로세스

  1. 생성된 사양 파일이 포함된 ~/rpmbuild/SPECS/ 지시문으로 이동합니다.

    $ cd ~/rpmbuild/SPECS/
    Copy to Clipboard Toggle word wrap
  2. 지정된 사양 파일을 사용하여 rpmbuild 명령을 입력하여 source RPM을 빌드합니다.

    $ rpmbuild -bs <specfile>
    Copy to Clipboard Toggle word wrap

    -bs 옵션은 빌드 소스 를 나타냅니다.

    예를 들어 벨로 ,pellocello 프로그램에 대한 소스 RPM을 빌드하려면 다음을 입력합니다.

    $ rpmbuild -bs bello.spec
    Wrote: /home/admiller/rpmbuild/SRPMS/bello-0.1-1.el8.src.rpm
    
    $ rpmbuild -bs pello.spec
    Wrote: /home/admiller/rpmbuild/SRPMS/pello-0.1.2-1.el8.src.rpm
    
    $ rpmbuild -bs cello.spec
    Wrote: /home/admiller/rpmbuild/SRPMS/cello-1.0-1.el8.src.rpm
    Copy to Clipboard Toggle word wrap

검증

  • rpmbuild/SRPMS 디렉터리에 결과 소스 RPM이 포함되어 있는지 확인합니다. 디렉터리는 rpmbuild 에서 예상되는 구조의 일부입니다.

4.6.2. 소스 RPM에서 바이너리 RPM 다시 빌드

소스 RPM(SRPM)에서 바이너리 RPM을 다시 빌드하려면 --rebuild 옵션과 함께 rpmbuild 명령을 사용합니다.

바이너리 RPM을 생성할 때 생성되는 출력은 상세화되어 디버깅에 유용합니다. 출력은 다양한 예에 따라 다르며 사양 파일에 해당합니다.

생성된 바이너리 RPM은 다음 디렉토리 중 하나에 있습니다.

  • ~/rpmbuild/RPMS/YOURARCH. 여기서ARCH 는 아키텍처입니다.
  • 패키지가 아키텍처에 한정되지 않은 경우 ~/rpmbuild/RPMS/noarch/.

사전 요구 사항

  • 시스템에 rpmbuild 유틸리티를 설치했습니다.

    # dnf install rpm-build
    Copy to Clipboard Toggle word wrap

프로세스

  1. SRPM이 포함된 ~/rpmbuild/SRPMS/ 지시문으로 이동합니다.

    $ cd ~/rpmbuild/SRPMS/
    Copy to Clipboard Toggle word wrap
  2. SRPM에서 바이너리 RPM을 다시 빌드합니다.

    $ rpmbuild --rebuild <srpm>
    Copy to Clipboard Toggle word wrap

    예를 들어 SRPM에서 p ello,pello, cello 를 다시 빌드하려면 다음을 입력합니다.

    $ rpmbuild --rebuild bello-0.1-1.el8.src.rpm
    [output truncated]
    
    $ rpmbuild --rebuild pello-0.1.2-1.el8.src.rpm
    [output truncated]
    
    $ rpmbuild --rebuild cello-1.0-1.el8.src.rpm
    [output truncated]
    Copy to Clipboard Toggle word wrap
참고

rpmbuild --rebuild 를 호출하려면 다음 프로세스가 포함됩니다.

  • SRPM의 콘텐츠( spec 파일 및 소스 코드)를 ~/rpmbuild/ 디렉터리에 설치합니다.
  • 설치된 콘텐츠를 사용하여 RPM 빌드.
  • 사양 파일 및 소스 코드 제거

다음 방법 중 하나를 빌드한 후 사양 파일 및 소스 코드를 유지할 수 있습니다.

  • RPM을 빌드할 때 --rebuild 옵션 대신 --recompile 옵션과 함께 rpmbuild 명령을 사용합니다.
  • 벨로 ,pello , 셀오 용 SRPM 설치:

    $ rpm -Uvh ~/rpmbuild/SRPMS/bello-0.1-1.el8.src.rpm
    Updating / installing…​
       1:bello-0.1-1.el8               [100%]
    
    $ rpm -Uvh ~/rpmbuild/SRPMS/pello-0.1.2-1.el8.src.rpm
    Updating / installing…​
    …​1:pello-0.1.2-1.el8              [100%]
    
    $ rpm -Uvh ~/rpmbuild/SRPMS/cello-1.0-1.el8.src.rpm
    Updating / installing…​
    …​1:cello-1.0-1.el8            [100%]
    Copy to Clipboard Toggle word wrap

4.6.3. 사양 파일에서 바이너리 RPM 빌드

사양 파일에서 바이너리 RPM을 빌드하려면 rpmbuild 명령을 -bb 옵션과 함께 사용합니다.

사전 요구 사항

  • 시스템에 rpmbuild 유틸리티를 설치했습니다.

    # dnf install rpm-build
    Copy to Clipboard Toggle word wrap

프로세스

  1. 사양 파일이 포함된 ~/rpmbuild/SPECS/ 지시문으로 이동합니다.

    $ cd ~/rpmbuild/SPECS/
    Copy to Clipboard Toggle word wrap
  2. 사양에서 바이너리 RPM을 빌드합니다.

    $ rpmbuild -bb <spec_file>
    Copy to Clipboard Toggle word wrap

    예를 들어 사양 파일에서 벨로,pellocello 바이너리 RPM을 빌드하려면 다음을 입력합니다.

    $ rpmbuild -bb bello.spec
    
    $ rpmbuild -bb pello.spec
    
    $ rpmbuild -bb cello.spec
    Copy to Clipboard Toggle word wrap

4.7. syslog에 RPM 활동 로깅

syslog(System Logging Protocol)를 사용하여 RPM 활동 또는 트랜잭션을 기록할 수 있습니다.

사전 요구 사항

  • syslog 플러그인은 시스템에 설치됩니다.

    # dnf install rpm-plugin-syslog
    Copy to Clipboard Toggle word wrap
    참고

    syslog 메시지의 기본 위치는 /var/log/messages 파일입니다. 그러나 다른 위치를 사용하여 메시지를 저장하도록 syslog 를 구성할 수 있습니다.

프로세스

  1. syslog 메시지를 저장하도록 구성한 파일을 엽니다.

    또는 기본 syslog 구성을 사용하는 경우 /var/log/messages 파일을 엽니다.

  2. [RPM] 문자열을 포함하여 새 행을 검색합니다.

4.8. RPM 콘텐츠 추출

예를 들어 RPM에 필요한 패키지가 손상된 경우 패키지의 내용을 추출해야 할 수 있습니다. 이러한 경우 RPM 설치가 손상에도 불구하고 여전히 작동하는 경우 rpm2archive 유틸리티를 사용하여 .rpm 파일을 tar 아카이브로 변환하여 패키지 내용을 사용할 수 있습니다.

참고

RPM 설치가 심각한 경우 rpm2cpio 유틸리티를 사용하여 RPM 패키지 파일을 cpio 아카이브로 변환할 수 있습니다.

프로세스

  • RPM 파일을 tar 아카이브로 변환합니다.

    $ rpm2archive <filename>.rpm
    Copy to Clipboard Toggle word wrap

    결과 파일에는 .tgz 접미사가 있습니다. 예를 들어 bash 패키지에서 아카이브를 생성하려면 다음을 입력합니다.

    $ rpm2archive bash-4.4.19-6.el8.x86_64.rpm
    $ ls bash-4.4.19-6.el8.x86_64.rpm.tgz
    bash-4.4.19-6.el8.x86_64.rpm.tgz
    Copy to Clipboard Toggle word wrap

4.9. RPM 패키지에 서명

다음 소프트웨어 중 하나를 사용하여 타사에서 콘텐츠를 변경할 수 없도록 RPM 패키지에 서명할 수 있습니다.

  • Sequoia PGP는 OpenPGP 표준을 지원합니다. RPM은 Sequoia PGP를 사용하여 소프트웨어 서명을 확인합니다.
  • GNU Privacy Guard(GnuPG)는 이전 OpenPGP 표준 버전을 지원하므로 GnuPG가 RHEL 9 및 이전 버전과 보다 호환됩니다.
주의

새로운 알고리즘과 서명이 이전 RHEL 버전과 호환되지 않을 수 있습니다.

4.9.1. GnuPG를 사용하여 RPM 패키지에 서명

GNU Privacy Guard(GnuPG) 소프트웨어를 사용하여 RPM 패키지에 서명할 수 있습니다.

4.9.1.1. GnuPG를 사용하여 패키지에 서명하기 위한 OpenPGP 키 생성

GNU Privacy Guard(GnuPG) 소프트웨어를 사용하여 RPM 패키지에 서명하려면 먼저 OpenPGP 키를 생성해야 합니다.

사전 요구 사항

  • rpm-signpinentry 패키지가 시스템에 설치되어 있습니다.

프로세스

  1. OpenPGP 키 쌍을 생성합니다.

    $ gpg --gen-key
    Copy to Clipboard Toggle word wrap
  2. 생성된 키 쌍을 확인합니다.

    $ gpg --list-keys
    Copy to Clipboard Toggle word wrap
  3. 공개 키를 내보냅니다.

    $ gpg --export -a '<public_key_name>' > RPM-GPG-KEY-pmanager
    Copy to Clipboard Toggle word wrap
4.9.1.2. GnuPG로 패키지에 서명하도록 RPM 구성

GNU Privacy Guard(GnuPG) 소프트웨어를 사용하여 RPM 패키지에 서명하려면 %_gpg_name RPM 매크로를 지정하여 RPM을 구성해야 합니다.

사전 요구 사항

프로세스

  • $HOME/.rpmmacros 디렉토리에 %_gpg_name 매크로를 정의합니다.

    %_gpg_name <key-ID>
    Copy to Clipboard Toggle word wrap

    GnuPG의 유효한 키 ID 값은 키를 생성할 때 제공한 키 지문, 전체 이름 또는 이메일 주소일 수 있습니다.

4.9.1.3. RPM 패키지에 서명 추가

패키지는 일반적으로 서명 없이 빌드됩니다. 패키지가 릴리스되기 전에 서명을 추가할 수 있습니다.

사전 요구 사항

프로세스

  • 패키지에 서명을 추가합니다.

    $ rpmsign --addsign <package-name>.rpm
    Copy to Clipboard Toggle word wrap

검증

  1. 내보낸 OpenPGP 공개 키를 RPM 인증 키로 가져옵니다.

    # rpmkeys --import RPM-GPG-KEY-pmanager
    Copy to Clipboard Toggle word wrap
  2. GnuPG를 사용하여 키 ID를 표시합니다.

    $ gpg --list-keys
    [...]
    pub   rsa3072 2025-05-13 [SC] [expires: 2028-05-12]
          A8AF1C39AC67A1501450734F6DE8FC866DE0394D
    [...]
    Copy to Clipboard Toggle word wrap

    키 ID는 명령 출력의 40자 문자열입니다(예: A8AF1C39AC67A1501450734F6DE8FC866DE0394D ).

  3. RPM 파일에 해당 서명이 있는지 확인합니다.

    $ rpm -Kv <package_name>.rpm
    <package_name>.rpm:
        Header V4 RSA/SHA256 Signature, key ID 6de0394d: OK
        Header SHA256 digest: OK
        Header SHA1 digest: OK
        Payload SHA256 digest: OK
        MD5 digest: OK
    Copy to Clipboard Toggle word wrap

    서명 키 ID는 OpenPGP 키 ID의 마지막 부분과 일치합니다.

4.9.2. Sequoia PGP를 사용하여 RPM 패키지에 서명

Sequoia PGP를 사용하여 RPM 패키지에 서명하고 타사가 콘텐츠를 변경할 수 없도록 할 수 있습니다.

4.9.2.1. Sequoia PGP를 사용하여 패키지에 서명하기 위한 OpenPGP 키 생성

Sequoia PGP 소프트웨어를 사용하여 패키지에 서명하려면 먼저 OpenPGP 키를 생성해야 합니다.

프로세스

  1. Sequoia PGP 도구를 설치합니다.

    # dnf install sequoia-sq
    Copy to Clipboard Toggle word wrap
  2. OpenPGP 키 쌍을 생성합니다.

    $ sq key generate --own-key --userid <key_name>
    Copy to Clipboard Toggle word wrap
  3. 생성된 키 쌍을 확인합니다.

    $ sq key list
    Copy to Clipboard Toggle word wrap
  4. 공개 키를 내보냅니다.

    $ sq cert export --cert-userid '<key_name>' > RPM-PGP-KEY-pmanager
    Copy to Clipboard Toggle word wrap
4.9.2.2. Sequoia PGP로 패키지에 서명하도록 RPM 구성

Sequoia PGP 소프트웨어를 사용하여 RPM 패키지에 서명하려면 Sequoia PGP를 사용하고 %_gpg_name 매크로를 지정하도록 RPM을 구성해야 합니다.

사전 요구 사항

  • rpm-sign 패키지가 시스템에 설치되어 있습니다.

프로세스

  1. macros.rpmsign-sequoia 파일을 /etc/rpm 디렉터리에 복사합니다.

    # cp /usr/share/doc/rpm/macros.rpmsign-sequoia /etc/rpm/
    Copy to Clipboard Toggle word wrap
  2. 키 목록 출력에서 유효한 OpenPGP 키 지문 값을 가져옵니다.

    $ sq cert list --cert-userid '<key_name>'
     - 7E4B52101EB3DB08967A1E5EB595D12FDA65BA50
       - created 2025-05-13 10:33:29 UTC
       - will expire 2028-05-13T03:59:50Z
    
       - [    ✓    ] <key_name>
    Copy to Clipboard Toggle word wrap

    키 지문은 출력의 첫 번째 줄에 있는 40자 문자열입니다(예: 7E4B52101EB3DB08967A1E595D12FDA65BA50 ).

  3. 다음과 같이 $HOME/.rpmmacros 파일에 %_gpg_name 매크로를 정의합니다.

    %_gpg_name <key_fingerprint>
    Copy to Clipboard Toggle word wrap

    지문 대신 전체 키 ID를 사용할 수도 있습니다.

    참고

    GnuPG와 달리 Sequoia PGP는 전체 키 ID 또는 지문만 허용합니다.

4.9.2.3. RPM 패키지에 서명 추가

패키지는 일반적으로 서명 없이 빌드됩니다. 패키지가 릴리스되기 전에 서명을 추가할 수 있습니다.

사전 요구 사항

프로세스

  • 패키지에 서명을 추가합니다.

    $ rpmsign --addsign <package-name>.rpm
    Copy to Clipboard Toggle word wrap

검증

  1. 내보낸 OpenPGP 공개 키를 RPM 인증 키로 가져옵니다.

    # rpmkeys --import RPM-PGP-KEY-pmanager
    Copy to Clipboard Toggle word wrap
  2. 서명 키의 키 지문을 표시합니다.

    $ sq key list --cert-userid <key_name>
     - 7E4B52101EB3DB08967A1E5EB595D12FDA65BA50
       - user ID: <key_name> (authenticated)
       - created 2025-05-13 10:33:29 UTC
       - will expire 2028-05-13T03:59:50Z
       - usable for signing
       - @softkeys/7E4B52101EB3DB08967A1E5EB595D12FDA65BA50: available, unlocked
    
       - 78E56DD2E12E02CFEEA27F8B9FE57972D6BCEA6F
         - created 2025-05-13 10:33:29 UTC
         - will expire 2028-05-13T03:59:50Z
         - usable for decryption
         - @softkeys/7E4B52101EB3DB08967A1E5EB595D12FDA65BA50: available, unlocked
       - C06E45F8ABC3E59F44A9E811578DDDB66422E345
         - created 2025-05-13 10:33:29 UTC
         - will expire 2028-05-13T03:59:50Z
         - usable for signing
         - @softkeys/7E4B52101EB3DB08967A1E5EB595D12FDA65BA50: available, unlocked
       - E0BD231AB350AD6802D44C0A270E79FFC39C3B25
         - created 2025-05-13 10:33:29 UTC
         - will expire 2028-05-13T03:59:50Z
         - usable for signing
         - @softkeys/7E4B52101EB3DB08967A1E5EB595D12FDA65BA50: available, unlocked
    Copy to Clipboard Toggle word wrap

    키 지문은 일반적으로 sq 키 목록 --cert-userid < key_name > 명령 출력의 서명 하위 키입니다(예: E0BD231AB350AD6802D44C0A270E79FFC3B25 ).

  3. RPM 파일에 해당 서명이 있는지 확인합니다. 예를 들면 다음과 같습니다.

    $ rpm -Kv <package_name>.rpm
    <package_name>.rpm:
        Header V4 EdDSA/SHA512 Signature, key ID c39c3b25: OK
        Header SHA256 digest: OK
        Header SHA1 digest: OK
        Payload SHA256 digest: OK
        MD5 digest: OK
    Copy to Clipboard Toggle word wrap

    서명 키 ID는 키 지문의 마지막 부분과 일치합니다.

5장. Python 3 RPM 패키징

DNF 패키지 관리자를 사용하여 시스템에 Python 패키지를 설치할 수 있습니다. DNF 는 소프트웨어에 대한 다운스트림 제어를 제공하는 RPM 패키지 형식을 사용합니다.

Python 프로젝트를 RPM 패키지로 패키징하면 기본 Python 패키지와 비교하여 다음과 같은 이점이 있습니다.

  • Python 및 Python이 아닌 패키지에 대한 종속성은 DNF 패키지 관리자에 의해 엄격하게 적용됩니다.
  • 패키지에 암호화 방식으로 서명할 수 있습니다. 암호화 서명을 사용하면 RPM 패키지의 내용을 다른 운영 체제와 검증, 통합 및 테스트할 수 있습니다.
  • 빌드 프로세스 중에 테스트를 실행할 수 있습니다.

네이티브 Python 패키지의 패키징 형식은 PyPA(Python Packaging Authority) 사양으로 정의됩니다. 지금까지 대부분의 Python 프로젝트는 setup.py 파일에서 패키지 정보를 패키징하고 정의하는 데 distutils 또는 setuptools 유틸리티를 사용했습니다. 그러나 기본 Python 패키지를 생성할 가능성은 시간이 지남에 따라 진화했습니다.

  • setup.py 파일을 사용하는 Python 소프트웨어를 패키징하려면 이 문서를 따르십시오.
  • pyproject.toml 파일로 최신 패키지를 패키징하려면 pyproject-rpm-macrosREADME 파일을 참조하십시오. pyproject-rpm-macros 는 지원되지 않는 패키지가 포함된 CRB(CodeReady Linux Builder) 리포지토리에 포함되어 있으며 시간이 지남에 따라 최신 Python 패키징 표준을 지원할 수 있습니다.

5.1. 예제 Python 패키지에 대한 사양 파일 설명

Python 프로젝트의 RPM 사양 파일에는 Python이 아닌 RPM 사양 파일과 비교하여 몇 가지 특정 사항이 있습니다.

python3- 접두사를 포함하려면 Python 라이브러리의 모든 RPM 패키지 이름에 사용하는 것이 좋습니다.

python3-pello 패키지의 다음 예제에서 Python RPM 사양 파일 관련 노트를 참조하십시오.

Python으로 작성된 pello 프로그램의 SPEC 파일의 예

%global python3_pkgversion 3                                          
1


Name:           python-pello                                          
2

Version:        1.0.2
Release:        1%{?dist}
Summary:        Example Python library

License:        MIT
URL:            https://github.com/fedora-python/Pello
Source:         %{url}/archive/v%{version}/Pello-%{version}.tar.gz

BuildArch:      noarch
BuildRequires:  python%{python3_pkgversion}-devel                     
3


# Build dependencies need to be specified manually
BuildRequires:  python%{python3_pkgversion}-setuptools

# Test dependencies need to be specified manually
# Runtime dependencies need to be BuildRequired manually to run tests during build
BuildRequires:  python%{python3_pkgversion}-pytest >= 3


%global _description %{expand:
Pello is an example package with an executable that prints Hello World! on the command line.}

%description %_description

%package -n python%{python3_pkgversion}-pello                         
4

Summary:        %{summary}

%description -n python%{python3_pkgversion}-pello %_description


%prep
%autosetup -p1 -n Pello-%{version}


%build
# The macro only supports projects with setup.py
%py3_build                                                            
5



%install
# The macro only supports projects with setup.py
%py3_install


%check                                                                
6

%pytest


# Note that there is no %%files section for python-pello
%files -n python%{python3_pkgversion}-pello
%doc README.md
%license LICENSE.txt
%{_bindir}/pello_greeting

# The library files needed to be listed manually
%{python3_sitelib}/pello/

# The metadata files needed to be listed manually
%{python3_sitelib}/Pello-*.egg-info/
Copy to Clipboard Toggle word wrap

1
python3_pkgversion 매크로를 정의하면 이 패키지가 빌드될 Python 버전을 설정합니다. 기본 Python 버전 3.12 에 대해 빌드하려면 행을 제거합니다.
2
Python 프로젝트를 RPM에 패키징할 때 항상 python- 접두사를 프로젝트의 원래 이름에 추가합니다. 여기에 프로젝트 이름은 Pello 이며, 따라서 소스 RPM(SRPM)의 이름은 python-pello 입니다.
3
BuildRequires 는 이 패키지를 빌드하고 테스트하는 데 필요한 패키지를 지정합니다. BuildRequires 에서 항상 Python 패키지를 빌드하는 데 필요한 도구를 제공하는 항목을 포함합니다. python3-devel 과 사용자가 패키징하는 특정 소프트웨어에 필요한 관련 프로젝트(예: python3-setuptools 또는 %check 섹션에서 테스트를 실행하는 데 필요한 런타임 및 테스트 종속 항목)를 포함합니다.
4
바이너리 RPM의 이름(사용자가 설치할 수 있는 패키지)을 선택할 때 버전이 지정된 Python 접두사를 추가합니다. 기본 Python 3.12에 python3- 접두사를 사용합니다. 예를 들어 이후 버전의 Python을 사용할 수 있는 경우와 같이 기본 Python 버전 3.12 의 경우 3 으로 평가되는 %{python3_pkgversion} 매크로를 사용할 수 있습니다.
5
%py3_build%py3_install 매크로는 설치 위치, 사용할 인터프리터 및 기타 세부 정보를 지정하는 추가 인수와 함께 setup.py buildsetup.py install 명령을 각각 실행합니다.
참고

setuptools 패키지의 setup.py buildsetup.py install 명령을 사용하는 것은 더 이상 사용되지 않으며 향후 주요 RHEL 릴리스에서 제거됩니다. 대신 pyproject-rpm-macros 를 사용할 수 있습니다.

6
%check 섹션은 패키지된 프로젝트의 테스트를 실행합니다. 정확한 명령은 프로젝트 자체에 따라 다르지만 %pytest 매크로를 사용하여 RPM 친화적인 방식으로 pytest 명령을 실행할 수 있습니다.

5.2. Python 3 RPM의 일반적인 매크로

Python RPM 사양 파일에서는 항상 값을 하드 코딩하지 않고 Python 3 RPM용 매크로를 사용합니다.

사양 파일 상단에 python3_pkgversion 매크로를 정의하여 이러한 매크로에서 사용되는 Python 3 버전이 무엇입니까. 자세한 내용은 예제 Python 패키지에 대한 사양 파일 설명을 참조하십시오. python3_pkgversion 매크로를 정의하면 다음 표에 설명된 매크로 값이 지정된 Python 3 버전을 반영합니다.

Expand
표 5.1. Python 3 RPM용 매크로
macro일반 정의설명

%{python3_pkgversion}

3

다른 모든 매크로에서 사용하는 Python 버전입니다. 추가될 모든 Python 버전에 대해 다시 정의할 수 있습니다.

%{python3}

/usr/bin/python3

Python 3 인터프리터

%{python3_version}

3.12

Python 3 인터프리터의 major.minor 버전입니다.

%{python3_sitelib}

/usr/lib/python3.12/site-packages

pure-Python 모듈이 설치된 위치입니다.

%{python3_sitearch}

/usr/lib64/python3.12/site-packages

아키텍처별 확장 모듈을 포함하는 모듈이 설치된 위치입니다.

%py3_build

 

RPM 패키지에 적합한 인수를 사용하여 setup.py build 명령으로 확장합니다.

%py3_install

 

RPM 패키지에 적합한 인수를 사용하여 setup.py install 명령으로 확장합니다.

%{py3_shebang_flags}

sP

Python 인터프리터 지시문 매크로의 기본 플래그 세트인 %py3_shebang_fix.

%py3_shebang_fix

 

Python 인터프리터 지시문을 #! %{python3} 로 변경하고 기존 플래그(있는 경우)를 유지하고 %{py3_shebang_flags} 매크로에 정의된 플래그를 추가합니다.

5.3. Python RPM에 자동으로 생성된 종속 항목 사용

업스트림 제공 메타데이터를 사용하여 Python RPM에 대한 종속성을 자동으로 생성할 수 있습니다.

사전 요구 사항

프로세스

  1. 결과 RPM에 다음 디렉토리 중 하나를 포함합니다.

    • .dist-info
    • .egg-info

      RPM 빌드 프로세스는 이러한 디렉터리에서 제공하는 가상 pythonX.Ydist 를 자동으로 생성합니다. 예를 들면 다음과 같습니다.

      python3.12dist(pello)
      Copy to Clipboard Toggle word wrap

      그런 다음 Python 종속성 생성기는 업스트림 메타데이터를 읽고 생성된 pythonX.Ydist 가상 제공 기능을 사용하여 각 RPM 패키지에 대한 런타임 요구 사항을 생성합니다. 생성된 요구 사항 태그의 예:

      Requires: python3.12dist(requests)
      Copy to Clipboard Toggle word wrap
  2. 생성된 요구 사항을 검사합니다.
  3. 생성된 일부 요구 사항을 제거하려면 사양 파일의 %prep 섹션에서 업스트림 제공 메타데이터를 수정합니다.
  4. 자동 요구 사항 생성기를 비활성화하려면 기본 패키지의 %description 선언 위에 %{?python_disable_dependency_generator} 매크로를 포함합니다.

6장. Python 스크립트에서 인터프리터 지시문 수정

Red Hat Enterprise Linux 10에서 실행 가능한 Python 스크립트는 주요 Python 버전을 명시적으로 지정하는 hashbangs 또는 shebangs라고도 하는 인터프리터 지시문을 사용할 것으로 예상됩니다. 예를 들면 다음과 같습니다.

#!/usr/bin/python3
#!/usr/bin/python3.12
Copy to Clipboard Toggle word wrap

RPM 패키지를 빌드할 때 /usr/lib/rpm/redhat/brp-mangle-shebangs BRP(Buildroot 정책) 스크립트가 자동으로 실행되며 모든 실행 파일에서 인터프리터 지시문을 수정하려고 합니다. BRP 스크립트는 모호한 인터프리터 지시문과 함께 Python 스크립트가 발생할 때 오류를 생성합니다(예: #!/usr/bin/python 또는 #!/usr/bin/env python ).

RPM 빌드 시 빌드 오류가 발생하지 않도록 Python 스크립트의 인터프리터 지시문을 수정할 수 있습니다.

사전 요구 사항

  • Python 스크립트의 일부 인터프리터 지시문으로 인해 빌드 오류가 발생합니다.

프로세스

  • 시나리오에 따라 다음 단계 중 하나를 수행하여 인터프리터 지시문을 수정합니다.

    • 사양 파일의 %prep 섹션에서 다음 매크로를 사용합니다.

      %py3_shebang_fix <SCRIPTNAME> …​
      Copy to Clipboard Toggle word wrap

      SCRIPTNAME 은 파일, 디렉토리 또는 파일 및 디렉터리 목록일 수 있습니다.

      결과적으로 나열된 디렉터리에 있는 모든 나열된 파일과 .py 파일에는 %{python3} 을 가리키도록 인터프리터 지시문이 수정되었습니다. 원래 인터프리터 지시문의 기존 플래그는 보존되며 %{py3_shebang_flags} 매크로에 정의된 추가 플래그가 추가됩니다. 사양 파일에서 %{py3_shebang_flags} 매크로를 추가하여 추가할 플래그를 변경할 수 있습니다.

    • 패키지 Python 스크립트가 예상 형식을 준수하도록 수정합니다.

7장. Ruby gems 패키징

Ruby는 동적이고 해석되고, 반영적이며, 개체 지향적이며 범용 프로그래밍 언어입니다.

Ruby로 작성된 프로그램은 일반적으로 특정 Ruby 패키징 형식을 제공하는 RubyGems 소프트웨어를 사용하여 패키징됩니다.

RubyGems에서 생성한 패키지를 gems라고 하며 RPM 패키지로 다시 패키징할 수 있습니다.

참고

이 문서는 gem 접두사와 함께 RubyGems 개념과 관련된 용어를 나타냅니다. 예를 들어 .gemspecgem 사양에 사용되며 RPM과 관련된 용어는 정규화되지 않습니다.

7.1. RubyGems가 RPM과 관련된 방법

RubyGems는 Ruby의 자체 패키징 형식을 나타냅니다. 그러나 RubyGems에는 RPM에 필요한 메타데이터와 유사한 메타데이터가 포함되어 있습니다. 이 메타데이터는 패키징 gem을 RPM으로 간소화합니다. RPM은 나머지 배포에 적합한 gems에서 다시 패키징됩니다. 최종 사용자는 적절한 RPM 패키지 gem 및 기타 시스템 라이브러리를 설치하여 gem의 종속성을 충족할 수도 있습니다.

RubyGems는 사양 파일, 패키지 이름, 종속성 및 기타 항목과 같은 RPM 패키지와 유사한 용어를 사용합니다.

나머지 RHEL RPM 배포를 준수하기 위해 RubyGems에서 생성한 패키지는 다음 규칙을 준수해야 합니다.

  • 패키지 이름을 지정할 때 rubygem-%{gem_name} 패턴을 따릅니다.
  • #!/usr/bin/ruby 문자열을 인터프리터 지시문으로 사용합니다.

7.2. RubyGems 사양 파일 규칙

RubyGems 사양 파일은 다음 규칙을 충족해야 합니다.

  • 파일에는 gem의 사양의 이름인 %{gem_name} 의 정의가 포함되어 있습니다.
  • 패키지의 소스는 릴리스된 gem 아카이브의 전체 URL이어야 합니다.
  • 패키지 버전은 gem의 버전이어야 합니다.
  • 파일에는 다음 BuildRequires 지시문이 포함되어 있습니다.

    BuildRequires: rubygems-devel
    Copy to Clipboard Toggle word wrap

    rubygems-devel 패키지에는 빌드에 필요한 매크로가 포함되어 있습니다.

  • 이러한 지시문은 gem 메타데이터에서 자동으로 생성되므로 파일에 추가 rubygem(foo) Requires 또는 Provides 지시문이 포함되어 있지 않습니다.

7.2.1. RubyGems 사양 파일 예

다음은 gem을 빌드하기 위한 예제 사양 파일의 RubyGems 특정 부분입니다. 사양 파일의 나머지 부분은 일반 지침을 따릅니다.

예제 사양 파일의 RubyGems 특정 부분

%prep
%setup -q -n  %{gem_name}-%{version}

# Modify the gemspec if necessary
# Also apply patches to code if necessary
%patch 0 -p1

%build
# Create the gem as gem install only works on a gem file
gem build ../%{gem_name}-%{version}.gemspec

# %%gem_install compiles any C extensions and installs the gem into ./%%gem_dir
# by default, so that we can move it into the buildroot in %%install
%gem_install

%install
mkdir -p %{buildroot}%{gem_dir}
cp -a ./%{gem_dir}/* %{buildroot}%{gem_dir}/

# If there were programs installed:
mkdir -p %{buildroot}%{_bindir}
cp -a ./%{_bindir}/* %{buildroot}%{_bindir}

# If there are C extensions, copy them to the extdir.
mkdir -p %{buildroot}%{gem_extdir_mri}
cp -a .%{gem_extdir_mri}/{gem.build_complete,*.so} %{buildroot}%{gem_extdir_mri}/
Copy to Clipboard Toggle word wrap

7.2.2. RubyGems 사양 파일 지시문

다음은 spec 파일의 RubyGems 특정 부분에 있는 특정 항목의 세부 사항입니다.

Expand
표 7.1. RubyGems의 spec 지시문 특정
지시문RubyGems 세부 사항

%Prep

RPM은 gem 아카이브의 압축을 직접 해제할 수 있습니다. %setup -n %{gem_name}-%{version} 매크로는 gem의 압축을 푼 디렉토리를 제공합니다. 동일한 디렉터리 수준에서 %{gem_name}-%{version}.gemspec 파일이 자동으로 생성됩니다. 이 파일을 사용하여 다음 작업을 수행할 수 있습니다.

  • .gemspec 파일 수정
  • 코드에 패치를 적용합니다.

%build

이 섹션에는 소프트웨어를 머신 코드로 빌드하는 명령이 포함되어 있습니다. %gem_install 매크로는 gem 아카이브에서만 작동합니다. 따라서 gem 빌드 ../%{gem_name}-%{version}.gemspec 명령을 사용하여 아카이브를 먼저 다시 생성해야 합니다. 그런 다음 %gem_install 에서 다시 만든 gem 파일을 사용하여 기본 ./%{gem_dir} 임시 디렉터리에 gem 코드를 빌드하고 설치합니다. 설치하기 전에 빌드된 소스는 자동으로 생성되는 임시 디렉터리에 배치됩니다.

%install

설치는 %{buildroot} 계층 구조로 수행됩니다. 필요한 디렉터리를 생성한 다음 설치된 코드를 임시 디렉터리의 %{buildroot} 계층 구조로 복사할 수 있습니다. gem이 공유 오브젝트를 생성하면 아키텍처별 %{gem_extdir_mri} 경로로 이동합니다.

7.3. RubyGems 매크로

다음은 RubyGems에서 만든 패키지에 유용한 매크로입니다. 이러한 매크로는 rubygems-devel 패키지에서 제공합니다.

Expand
표 7.2. RubyGems의 매크로
매크로 이름확장 경로사용법

%{gem_dir}

/usr/share/gems

gem 구조의 최상위 디렉터리입니다.

%{gem_instdir}

%{gem_dir}/gems/%{gem_name}-%{version}

gem의 실제 콘텐츠가 있는 디렉터리입니다.

%{gem_libdir}

%{gem_instdir}/lib

gem의 라이브러리 디렉터리입니다.

%{gem_cache}

%{gem_dir}/cache/%{gem_name}-%{version}.gem

캐시된 gem입니다.

%{gem_spec}

%{gem_dir}/specifications/%{gem_name}-%{version}.gemspec

gem 사양 파일입니다.

%{gem_docdir}

%{gem_dir}/doc/%{gem_name}-%{version}

gem에 대한 RDoc 문서입니다.

%{gem_extdir_mri}

%{_libdir}/gems/ruby/%{gem_name}-%{version}

gem 확장을 위한 디렉터리입니다.

7.4. gem2rpm을 사용하여 사양 파일을 생성

gem2rpm 유틸리티를 사용하여 RPM 사양 파일을 만들 수 있습니다.

7.4.1. Ruby gem에 대한 RPM 사양 파일 생성

gem2rpm 유틸리티를 사용하여 RubyGems 패키지에 대한 RPM 사양 파일을 생성할 수 있습니다.

사전 요구 사항

  • gem2rpm 유틸리티가 시스템에 설치되어 있습니다.

    $ gem install gem2rpm
    Copy to Clipboard Toggle word wrap

프로세스

  1. 최신 버전에서 gem을 다운로드하고 이 gem에 대한 RPM 사양 파일을 생성합니다.

    $ gem2rpm --fetch <gem_name> > <gem_name>.spec
    Copy to Clipboard Toggle word wrap
  2. 생성된 사양 파일을 편집하여 라이센스 및 변경 로그와 같은 누락된 정보를 추가합니다.

7.4.2. 사용자 지정 gem2rpm 템플릿을 사용하여 사양 파일을 생성

gem2rpm 템플릿은 RPM 사양 파일을 생성할 수 있는 표준 ERP (ERB) 파일입니다. 생성된 사양 파일을 편집하는 대신 RPM 사양 파일이 생성되는 템플릿을 편집할 수 있습니다.

사전 요구 사항

  • gem2rpm 유틸리티가 시스템에 설치되어 있습니다.

    $ gem install gem2rpm
    Copy to Clipboard Toggle word wrap

프로세스

  1. 모든 gem2rpm 기본 제공 템플릿을 표시합니다.

    $ gem2rpm --templates
    Copy to Clipboard Toggle word wrap
  2. 기본 제공 템플릿 중 하나를 선택하여 사용자 지정 템플릿으로 저장합니다.

    $ gem2rpm -t <template> -T > rubygem-<gem_name>.spec.template
    Copy to Clipboard Toggle word wrap

    RHEL 10 베타에서는 fedora-27-rawhide 템플릿이 권장됩니다.

  3. 필요에 따라 템플릿을 편집합니다. 자세한 내용은 gem2rpm 템플릿 변수를 참조하십시오.
  4. 편집된 템플릿을 사용하여 사양 파일을 생성합니다.

    $ gem2rpm -t rubygem-<gem_name>.spec.template <gem_name>-<latest_version>.gem > <gem_name>-GEM.spec
    Copy to Clipboard Toggle word wrap

7.4.3. gem2rpm 템플릿 변수

다음은 RPM 사양 파일 생성용 gem2rpm 템플릿에 포함된 변수입니다.

Expand
표 7.3. gem2rpm 템플릿의 변수
Variable설명

패키지

gem에 대한 Gem::Package 변수입니다.

spec

gem에 대한 Gem::Specification 변수( format.spec)입니다.

config

spec 템플릿 도우미에 사용되는 기본 매크로 또는 규칙을 지정할 수 있는 Gem2Rpm::Configuration 변수입니다.

runtime_dependencies

패키지 런타임 종속 항목 목록을 제공하는 Gem2Rpm::RpmDependencyList 변수

development_dependencies

패키지 개발 종속 항목 목록을 제공하는 Gem2Rpm::RpmDependencyList 변수

테스트

실행을 허용하는 테스트 프레임워크 목록을 제공하는 Gem2Rpm::TestSuite 변수입니다.

파일

패키지에 필터링되지 않은 파일 목록을 제공하는 Gem2Rpm::RpmFileList 변수.

main_files

기본 패키지에 적합한 파일 목록을 제공하는 Gem2Rpm::RpmFileList 변수

doc_files

-doc 하위 패키지에 적합한 파일 목록을 제공하는 Gem2Rpm::RpmFileList 변수.

법적 공지

Copyright © 2025 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

Theme

© 2026 Red Hat
맨 위로 이동