Menu Close
Settings Close

Language and Page Formatting Options

Red Hat Training

A Red Hat training course is available for RHEL 8

소프트웨어 패키징 및 배포

Red Hat Enterprise Linux 8

Red Hat Enterprise Linux 8에서 소프트웨어 패키징 및 배포 가이드

초록

이 문서에서는 소프트웨어를 RPM에 패키징하는 방법을 설명합니다. 또한 패키징을 위해 소스 코드를 준비하는 방법과 Python 프로젝트 패키징 또는 RubyGems와 같은 선택된 고급 패키지 시나리오에 대해 설명합니다.

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

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 용어를 교체하기 위해 최선을 다하고 있습니다. 먼저 마스터(master), 슬레이브(slave), 블랙리스트(blacklist), 화이트리스트(whitelist) 등 네 가지 용어를 교체하고 있습니다. 이러한 변경 작업은 작업 범위가 크므로 향후 여러 릴리스에 걸쳐 점차 구현할 예정입니다. 자세한 내용은 CTO Chris Wright의 메시지를 참조하십시오.

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

문서 개선을 위한 의견을 보내 주십시오. 문서를 개선할 수 있는 방법에 관해 알려주십시오.

  • 특정 문구에 대한 간단한 의견 작성 방법은 다음과 같습니다.

    1. 문서가 Multi-page HTML 형식으로 표시되는지 확인합니다. 또한 문서 오른쪽 상단에 피드백 버튼이 있는지 확인합니다.
    2. 마우스 커서를 사용하여 주석 처리하려는 텍스트 부분을 강조 표시합니다.
    3. 강조 표시된 텍스트 아래에 표시되는 피드백 추가 팝업을 클릭합니다.
    4. 표시된 지침을 따릅니다.
  • Bugzilla를 통해 피드백을 제출하려면 새 티켓을 생성합니다.

    1. Bugzilla 웹 사이트로 이동하십시오.
    2. 구성 요소로 문서를 사용합니다.
    3. 설명 필드에 문서 개선을 위한 제안 사항을 기입하십시오. 관련된 문서의 해당 부분 링크를 알려주십시오.
    4. 버그 제출을 클릭합니다.

1장. RPM 패키지 시작하기

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

RPM 패키지 관리 시스템은 기존 아카이브 파일에서 소프트웨어 배포에 비해 몇 가지 이점을 제공합니다.

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

  • YUM 또는 PackageKit과 같은 표준 패키지 관리 도구를 사용하여 패키지를 설치, 다시 설치, 제거, 업그레이드 및 확인합니다.
  • 설치된 패키지의 데이터베이스를 사용하여 패키지를 쿼리하고 확인합니다.
  • 메타데이터를 사용하여 패키지, 설치 명령 및 기타 패키지 매개 변수를 설명합니다.
  • 패키지 소프트웨어 소스, 패치 및 소스 및 바이너리 패키지에 대한 전체 빌드 명령.
  • YUM 리포지토리에 패키지를 추가합니다.
  • GPG(GG) 서명 키를 사용하여 패키지에 디지털 서명합니다.

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

이 섹션에서는 RPM 패키지 소프트웨어를 준비하는 방법에 대해 설명합니다. 그렇게하기 위해, 코드 방법을 아는 것은 필요하지 않습니다. 그러나 소스 코드의 정의 및 프로그램 수행 방법과 같은 기본 개념을 이해해야 합니다.

2.1. 소스 코드란

이 부분에서는 소스 코드가 무엇인지 설명하고 세 가지 다른 프로그래밍 언어로 작성된 프로그램의 소스 코드 예제를 보여줍니다.

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

이 문서에는 세 가지 다른 프로그래밍 언어로 작성된 Hello World 프로그램의 세 가지 버전이 포함되어 있습니다.

각 버전은 다르게 패키지됩니다.

이러한 버전의 Hello World 프로그램은 RPM 패키지 관리자의 세 가지 주요 사용 사례를 다룹니다.

예 2.1. bash로 작성된 hello World

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

bello 파일에는 다음 구문이 있습니다.

#!/bin/bash

printf "Hello World\n"

예 2.2. Python으로 작성된 hello World

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

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

#!/usr/bin/python3

print("Hello World")

예 2.3. C로 작성된 hello World

cello 프로젝트는 C에서 Hello World 를 구현합니다. 구현에는 cello.cMakefile 파일만 포함되므로 결과 tar.gz 아카이브에는 LICENSE 파일과 별도로 두 개의 파일이 있습니다.

프로그램의 목적은 명령행에 Hello World 를 출력하는 것입니다.

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

#include <stdio.h>

int main(void) {
    printf("Hello World\n");
    return 0;
}

2.2. 프로그램 설정 방법

사람이 읽을 수 있는 소스 코드에서 머신 코드로 변환하는 방법(시스템에서 프로그램을 실행하기 위해 따르는 지침)은 다음과 같습니다.

2.2.1. 기본적으로 컴파일된 코드

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

이러한 방식으로 빌드된 RPM 패키지는 아키텍처에 따라 다릅니다.

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

2.2.2. 해석된 코드

bash 또는 Python 과 같은 일부 프로그래밍 언어는 머신 코드로 컴파일하지 않습니다. 대신, 해당 프로그램의 소스 코드는 사전 변환 없이 언어 Interpreter 또는 Language Virtual Machine에 의해 단계별로 실행됩니다.

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

해석된 언어는 Raw-interpreted 프로그램 또는 Byte- compiled 프로그램 중 하나입니다. 이 두 가지 유형은 프로그램 빌드 프로세스 및 패키징 절차에 따라 다릅니다.

2.2.2.1. 원시 해석 프로그램

원시 해석 언어 프로그램은 컴파일할 필요가 없으며 인터프리터에 의해 직접 실행됩니다.

2.2.2.2. 바이트-게시 컴파일 프로그램

바이트-분명한 언어는 바이트 코드로 컴파일되어야 하며, 그런 다음 언어 가상 머신에서 실행합니다.

참고

일부 언어에서는 선택 사항을 제공합니다. 즉, 원시 해석 또는 바이트로 컴파일할 수 있습니다.

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

컴파일된 언어로 작성된 소프트웨어의 경우 소스 코드는 빌드 프로세스를 통해 진행되므로 머신 코드를 생성합니다. 이 프로세스는 일반적으로 컴파일 또는 변환이라고 하며 다양한 언어에 따라 다릅니다. 생성된 빌드 소프트웨어를 실행할 수 있으므로 컴퓨터가 프로그래머가 지정한 작업을 수행할 수 있습니다.

원시 해석된 언어로 작성된 소프트웨어의 경우 소스 코드는 빌드되지 않고 직접 실행됩니다.

바이트로 컴파일된 해석된 언어로 작성된 소프트웨어의 경우 소스 코드는 바이트 코드로 컴파일되며 언어 가상 머신에서 실행합니다.

다음 하위 시스템은 소스 코드에서 소프트웨어를 빌드하는 방법을 설명합니다.

2.4. 네이티브로 컴파일된 코드에서 소프트웨어 빌드

이 섹션에서는 C 언어로 작성된 cello.c 프로그램을 실행 파일로 빌드하는 방법을 보여줍니다.

cello.c

#include <stdio.h>

int main(void) {
    printf("Hello World\n");
    return 0;
}

2.4.1. 수동 빌딩

cello.c 프로그램을 수동으로 빌드하려면 다음 절차를 사용하십시오.

절차

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

    gcc -g -o cello cello.c
  2. 결과 출력 바이너리 셀o를 실행합니다.

    $ ./cello
    Hello World

2.4.2. 자동화된 빌드

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

자동 빌드를 사용하여 cello.c 프로그램을 빌드하려면 다음 절차를 사용하십시오.

절차

  1. 자동화된 빌드를 설정하려면 cello.c 와 동일한 디렉토리에 다음 콘텐츠를 사용하여 Makefile 파일을 생성합니다.

    Makefile

    cello:
    	gcc -g -o cello cello.c
    clean:
    	rm cello

    cello 아래의 행과 clean: 는 탭 공간으로 시작해야 합니다.

  2. 소프트웨어를 빌드하려면 make 명령을 실행합니다.

    $ make
    make: 'cello' is up to date.
  3. 이미 빌드를 사용할 수 있으므로 make clean 명령을 실행한 후 make 명령을 다시 실행합니다.

    $ make clean
    rm cello
    
    $ make
    gcc -g -o cello cello.c
    참고

    다른 빌드 후에 프로그램을 빌드하려고 하면 효과가 없습니다.

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

    $ ./cello
    Hello World

이제 수동으로 프로그램을 컴파일하고 빌드 도구를 사용합니다.

2.5. 코드 해석

이 섹션에서는 Python 으로 작성된 프로그램을 바이트로 컴파일하고 bash 로 작성된 프로그램을 원시 해석하는 방법을 보여줍니다.

참고

아래 두 예제에서 파일 상단에 있는 #! 행은 he bang 로 알려져 있으며 프로그래밍 언어 소스 코드의 일부가 아닙니다.

he bang 은 텍스트 파일을 실행 파일로 사용할 수 있습니다. 시스템 프로그램 로더는 he bang 이 포함된 행을 구문 분석하여 바이너리 실행 파일에 대한 경로를 가져온 다음 프로그래밍 언어 인터프리터로 사용됩니다. 기능을 사용하려면 텍스트 파일이 실행 파일로 표시되어야 합니다.

2.5.1. 바이트 컴파일 코드

이 섹션에서는 Python으로 작성된 pello.py 프로그램을 바이트 코드로 컴파일하는 방법을 보여줍니다. 이 프로그램은 Python 언어 가상 머신에서 실행합니다.

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

pello.py

#!/usr/bin/python3

print("Hello World")

바이트 컴파일 프로그램에 대한 절차는 다음과 같은 요인에 따라 다릅니다.

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

Python 은 종종 바이트로 컴파일되지만 여기에 설명된 방식이 아닙니다. 다음 절차는 커뮤니티 표준을 따르는 것이 아니라 간단한 절차입니다. 실제 Python 지침은 소프트웨어 패키징 및 배포를 참조하십시오.

pello.py 를 바이트 코드로 컴파일하려면 다음 절차를 사용하십시오.

절차

  1. pello.py 파일을 바이트 압축합니다.

    $ python -m compileall pello.py
    
    $ file pello.pyc
    pello.pyc: python 2.7 byte-compiled
  2. pello.pyc 에서 바이트 코드를 실행합니다.

    $ python pello.pyc
    Hello World

2.5.2. 원시 해석 코드

이 섹션에서는 bash 쉘 내장 언어로 작성된 bello 프로그램을 원시 해석하는 방법을 보여줍니다.

bello

#!/bin/bash

printf "Hello World\n"

bash 와 같이 쉘 스크립팅 언어로 작성된 프로그램은 원시 해석됩니다.

절차

  • 소스 코드를 실행 파일로 파일을 실행하고 실행합니다.

    $ chmod +x bello
    $ ./bello
    Hello World

2.6. 패치 소프트웨어

RPM 패키지에서는 원래 소스 코드를 수정하는 대신 해당 코드를 유지하고 패치를 사용합니다.

패치는 다른 소스 코드를 업데이트하는 소스 코드입니다. 두 버전의 텍스트와 다른 내용을 나타내기 때문에 diff 로 포맷됩니다. diff 유틸리티를 사용하여 빌드되고, 이는 패치 유틸리티를 사용하여 소스 코드에 적용됩니다.

참고

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

이 섹션에서는 소프트웨어를 패치하는 방법을 설명합니다.

다음 예제에서는 diff 를 사용하여 원래 소스 코드에서 패치를 만드는 방법과 패치를 사용하여 패치를 적용하는 방법을 보여줍니다. 패치는 RPM을 만들 때 이후 섹션에서 사용됩니다.

다음 절차에서는 cello.c 에 대한 원래 소스 코드에서 패치를 생성하는 방법을 설명합니다.

절차

  1. 원본 소스 코드를 유지합니다.

    $ cp -p cello.c cello.c.orig

    p 옵션은 모드, 소유권 및 타임스탬프를 유지하는 데 사용됩니다.

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

    #include <stdio.h>
    
    int main(void) {
        printf("Hello World from my very first patch!\n");
        return 0;
    }
  3. diff 유틸리티를 사용하여 패치를 생성합니다.

    $ 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

    - 로 시작하는 행은 원래 소스 코드에서 제거되고 + 로 시작하는 행으로 교체됩니다.

    diff 명령과 함께 Naur 옵션을 사용하는 것이 가장 일반적인 사용 사례에 맞기 때문에 사용하는 것이 좋습니다. 그러나 이 경우 -u 옵션만 필요합니다. 특정 옵션은 다음을 보장합니다.

    • -n (또는 --new-file) - 파일이 비어 있는 것처럼 파일을 처리합니다.
    • -a (또는 --text) - 모든 파일을 텍스트로 처리합니다. 결과적으로 바이너리가 무시되지 않기 때문에 diff 에서 분류하는 파일은 무시되지 않습니다.
    • -u (또는 -U NUM 또는 --unified[=NUM]) - 통합 컨텍스트의 출력 NUM(기본값 3) 라인으로 출력을 반환합니다. 이는 변경된 소스 트리에 패치를 적용할 때 퍼지르는 일치를 허용하는 쉽게 읽을 수 있는 형식입니다.
    • - R(또는 --recursive) - 검색되는 모든 하위 디렉터리를 반복적으로 비교합니다.

      diff 유틸리티의 일반적인 인수에 대한 자세한 내용은 diff 매뉴얼 페이지를 참조하십시오.

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

    $ diff -Naur cello.c.orig cello.c > cello-output-first-patch.patch
  5. 원본 cello.c 를 복원 :

    $ cp cello.c.orig cello.c

    RPM을 빌드할 때 수정된 파일이 사용되지 않으므로 원본 cello.c 를 유지해야 합니다. 자세한 내용은 SPEC 파일 작업을 참조하십시오.

다음 절차에서는 cello-output-first-patch.patch 를 사용하여 cello.c 를 패치하고 패치된 프로그램을 빌드한 후 실행하는 방법을 보여줍니다.

절차

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

    $ patch < cello-output-first-patch.patch
    patching file cello.c
  2. cello.c 의 콘텐츠가 이제 패치를 반영하는지 확인합니다.

    $ cat cello.c
    #include<stdio.h>
    
    int main(void){
        printf("Hello World from my very first patch!\n");
        return 1;
    }
  3. 패치된 cello.c 를 빌드하고 실행합니다.

    $ make clean
    rm cello
    
    $ make
    gcc -g -o cello cello.c
    
    $ ./cello
    Hello World from my very first patch!

2.7. 임의의 아티팩트

UNIX와 같은 시스템은 파일 시스템 계층 구조 표준(Fsandbox)을 사용하여 특정 파일에 적합한 디렉터리를 지정합니다.

RPM 패키지에서 설치된 파일은 Fsandbox에 따라 배치됩니다. 예를 들어 실행 파일은 시스템 $PATH 변수에 있는 디렉터리로 이동해야 합니다.

이 문서의 컨텍스트에서 Arbitrary Artifact 는 RPM에서 시스템에 설치된 모든 항목입니다. RPM 및 시스템의 경우 스크립트의 경우 패키지의 소스 코드, 사전 컴파일된 바이너리 또는 기타 파일에서 컴파일된 바이너리입니다.

다음 섹션에서는 시스템에 Arbitrary Artifacts 를 배치하는 두 가지 일반적인 방법에 대해 설명합니다.

2.8. install 명령을 사용하여 시스템에 임의의 아티팩트 배치

패키지 관리자는 GNU make 와 같은 빌드 자동화 툴링을 구축할 때 설치 명령을 사용하는 경우가 많습니다. 예를 들어 패키지 프로그램에 추가 오버헤드가 필요하지 않은 경우도 있습니다.

install 명령은 coreutils 를 통해 시스템에 제공되며, 이 명령은 지정된 권한 세트를 사용하여 파일 시스템의 지정된 디렉터리에 아티팩트를 배치합니다.

다음 절차에서는 이전에 임의의 아티팩트로 생성된 bello 파일을 이 설치 방법에 따라 사용합니다.

절차

  1. install 명령을 실행하여 실행 스크립트의 일반적인 권한을 사용하여 bello 파일을 /usr/bin 디렉터리에 배치합니다.

    $ sudo install -m 0755 bello /usr/bin/bello

    결과적으로 bello 는 이제 $PATH 변수에 나열된 디렉터리에 있습니다.

  2. 전체 경로를 지정하지 않고 디렉토리에서 bello 를 실행합니다.

    $ cd ~
    
    $ bello
    Hello World

2.9. make install 명령을 사용하여 시스템에 임의의 아티팩트 배치

make install 명령을 사용하는 것은 시스템에 구축된 소프트웨어를 설치하는 자동화된 방법입니다. 이 경우 일반적으로 개발자가 작성한 Makefile 의 시스템에 임의의 아티팩트를 설치하는 방법을 지정해야 합니다.

다음 절차에서는 빌드 아티팩트를 시스템에서 선택한 위치에 설치하는 방법을 설명합니다.

절차

  1. Makefile설치 섹션을 추가합니다.

    Makefile

    cello:
    	gcc -g -o cello cello.c
    
    clean:
    	rm cello
    
    install:
    	mkdir -p $(DESTDIR)/usr/bin
    	install -m 0755 cello $(DESTDIR)/usr/bin/cello

    cello 아래의 행: , clean: , install: must begin with a tab space.

    참고

    $(DESTDIR) 변수는 GNU make built-in이며 일반적으로 root 디렉터리와 다른 디렉토리에 설치를 지정하는 데 사용됩니다.

    이제 Makefile 을 사용하여 소프트웨어를 빌드할 뿐만 아니라 대상 시스템에 설치할 수도 있습니다.

  2. cello.c 프로그램을 빌드하고 설치합니다.

    $ make
    gcc -g -o cello cello.c
    
    $ sudo make install
    install -m 0755 cello /usr/bin/cello

    결과적으로 cello 는 이제 $PATH 변수에 나열된 디렉터리에 있습니다.

  3. 전체 경로를 지정하지 않고 모든 디렉터리에서 cello 를 실행합니다.

    $ cd ~
    
    $ cello
    Hello World

2.10. 패키징을 위한 소스 코드 준비

개발자는 종종 소프트웨어를 소스 코드의 압축 아카이브로 배포한 다음 패키지를 만드는 데 사용됩니다. RPM 패키지 관리자는 준비된 소스 코드 아카이브와 함께 작동합니다.

소프트웨어는 소프트웨어 라이센스와 함께 배포되어야 합니다.

다음 절차에서는 Gradlev3 라이센스 텍스트를 LICENSE 파일의 예제 컨텐츠로 사용합니다.

절차

  1. 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/.

2.11. 소스 코드를 tarball에 배치

이 섹션에서는 " 소스 코드" 에 소개된 세 개의 Hello World 프로그램을 gzip-compressed tarball에 각각 넣는 방법을 설명합니다. 이는 나중에 배포하기 위해 소프트웨어를 릴리스하는 일반적인 방법입니다.

예 2.4. bello 프로젝트를 tarball에 배치

bello 프로젝트는 bash 에서 Hello World 를 구현합니다. 구현에는 bello 쉘 스크립트만 포함되므로 결과 tar.gz 아카이브에는 LICENSE 파일 외에도 하나의 파일만 있습니다.

다음 절차에서는 배포를 위해 벨노 프로젝트를 준비하는 방법을 설명합니다.

사전 요구 사항

이 프로그램의 0.1 버전임을 고려하십시오.

절차

  1. 필요한 모든 파일을 단일 디렉터리에 배치합니다.

    $ mkdir /tmp/bello-0.1
    
    $ mv ~/bello /tmp/bello-0.1/
    
    $ cp /tmp/LICENSE /tmp/bello-0.1/
  2. 배포를 위해 아카이브를 만들고 이를 ~/rpmbuild/SOURCES/ 디렉토리로 이동합니다. 이 디렉터리는 rpmbuild 명령이 패키지 빌드를 위한 파일을 저장하는 기본 디렉터리입니다.

    $ cd /tmp/
    
    $ tar -cvzf bello-0.1.tar.gz bello-0.1
    bello-0.1/
    bello-0.1/LICENSE
    bello-0.1/bello
    
    $ mv /tmp/bello-0.1.tar.gz ~/rpmbuild/SOURCES/

bash로 작성된 예제 소스 코드에 대한 자세한 내용은 bash로 작성된 Hello World 를 참조하십시오.

예 2.5. pello 프로젝트를 tarball에 배치

pello 프로젝트는 Python 에서 Hello World 를 구현합니다. 구현에는 pello.py 프로그램만 포함되어 있으므로 결과 tar.gz 아카이브에는 LICENSE 파일 외에도 하나의 파일만 있습니다.

다음 절차에서는 배포용으로 pello 프로젝트를 준비하는 방법을 설명합니다.

사전 요구 사항

이 프로그램의 버전 0.1.1 을 고려하십시오.

절차

  1. 필요한 모든 파일을 단일 디렉터리에 배치합니다.

    $ mkdir /tmp/pello-0.1.2
    
    $ mv ~/pello.py /tmp/pello-0.1.2/
    
    $ cp /tmp/LICENSE /tmp/pello-0.1.2/
  2. 배포를 위해 아카이브를 만들고 이를 ~/rpmbuild/SOURCES/ 디렉토리로 이동합니다. 이 디렉터리는 rpmbuild 명령이 패키지 빌드를 위한 파일을 저장하는 기본 디렉터리입니다.

    $ cd /tmp/
    
    $ tar -cvzf pello-0.1.2.tar.gz pello-0.1.2
    pello-0.1.2/
    pello-0.1.2/LICENSE
    pello-0.1.2/pello.py
    
    $ mv /tmp/pello-0.1.2.tar.gz ~/rpmbuild/SOURCES/

Python으로 작성된 예제 소스 코드에 대한 자세한 내용은 Python으로 작성된 Hello World 를 참조하십시오.

예 2.6. cello 프로젝트를 tarball에 배치

cello 프로젝트는 C에서 Hello World 를 구현합니다. 구현에는 cello.cMakefile 파일만 포함되므로 결과 tar.gz 아카이브에는 LICENSE 파일과 별도로 두 개의 파일이 있습니다.

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

다음 절차에서는 배포를 위해 cello 프로젝트를 준비하는 방법을 설명합니다.

사전 요구 사항

이 프로그램의 버전 1.0 에 대해 설명합니다.

절차

  1. 필요한 모든 파일을 단일 디렉터리에 배치합니다.

    $ mkdir /tmp/cello-1.0
    
    $ mv ~/cello.c /tmp/cello-1.0/
    
    $ mv ~/Makefile /tmp/cello-1.0/
    
    $ cp /tmp/LICENSE /tmp/cello-1.0/
  2. 배포를 위해 아카이브를 만들고 이를 ~/rpmbuild/SOURCES/ 디렉토리로 이동합니다. 이 디렉터리는 rpmbuild 명령이 패키지 빌드를 위한 파일을 저장하는 기본 디렉터리입니다.

    $ cd /tmp/
    
    $ 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
    
    $ mv /tmp/cello-1.0.tar.gz ~/rpmbuild/SOURCES/
  3. 패치를 추가합니다.

    $ mv ~/cello-output-first-patch.patch ~/rpmbuild/SOURCES/

C로 작성된 예제 소스 코드에 대한 자세한 내용은 C로 작성된 Hello World 를 참조하십시오.

3장. 패키지 소프트웨어

이 섹션에서는 RPM 패키지에 대한 기본 사항을 설명합니다.

3.1. RPM 패키지

RPM 패키지는 다른 파일 및 해당 메타데이터를 포함하는 파일이며(시스템에 필요한 파일 정보)

특히 RPM 패키지는 cpio 아카이브로 구성됩니다.

cpio 아카이브에는 다음이 포함됩니다.

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

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

RPM 패키지 유형

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

  • 소스 RPM(SRPM)

    SRPM에는 소스 코드와 SPEC 파일이 포함되어 있습니다. 이 파일은 소스 코드를 바이너리 RPM에 빌드하는 방법을 설명합니다. 필요한 경우 소스 코드에 대한 패치도 포함되어 있습니다.

  • 바이너리 RPM

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

3.2. RPM 패키징 툴 유틸리티 나열

다음 절차에서는 rpmdevtools 패키지에서 제공하는 유틸리티를 나열하는 방법을 설명합니다.

사전 요구 사항

  • RPM 패키징에 몇 가지 유틸리티를 제공하는 rpmdevtools 패키지를 설치했습니다.

    # yum install rpmdevtools

절차

  • RPM 패키지 도구의 유틸리티를 나열합니다.

    $ rpm -ql rpmdevtools | grep bin

위의 유틸리티에 대한 자세한 내용은 도움말 페이지 또는 도움말 대화 상자를 참조하십시오.

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

이 섹션에서는 rpmdev-setuptree 유틸리티를 사용하여 RPM 패키징 작업 공간인 디렉터리 레이아웃을 설정하는 방법을 설명합니다.

사전 요구 사항

  • RPM 패키징에 몇 가지 유틸리티를 제공하는 rpmdevtools 패키지를 설치했습니다.

    # yum install rpmdevtools

절차

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

    $ rpmdev-setuptree
    
    $ tree ~/rpmbuild/
    /home/user/rpmbuild/
    |-- BUILD
    |-- RPMS
    |-- SOURCES
    |-- SPECS
    `-- SRPMS
    
    5 directories, 0 files

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

디렉터리

목적

BUILD

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

RPMS

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

SOURCES

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

SPECS

패키지 관리자는 SPEC 파일을 여기에 저장합니다.

SRPMS

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

3.4. SPEC 파일이란 무엇입니까?

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

다음 섹션에서는 SPEC 파일의 각 섹션에 대해 설명합니다.

3.4.1. 사전 항목

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

표 3.1. RPM SPEC 파일의 Preamble 섹션에 사용된 항목

SPEC 조건정의

이름

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

버전

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

릴리스 버전

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

요약

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

라이센스

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

URL

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

Source0

업스트림 소스 코드의 압축 아카이브 경로 또는 URL(패치되지 않은 패치는 다른 위치에서 처리됩니다). 이는 아카이브의 액세스 가능하고 안정적인 스토리지(예: 패키지 관리자의 로컬 스토리지가 아닌 업스트림 페이지)를 가리켜야 합니다. 필요한 경우 더 많은 SourceX 지시문을 추가하여 매번 숫자를 늘릴 수 있습니다. 예를 들면 다음과 같습니다. Source1, Source2, Source3 등이 있습니다.

패치

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

지시문은 두 가지 방법으로 적용할 수 있습니다. 패치 종료 시 또는 번호 없이 사용할 수 있습니다.

숫자를 지정하지 않으면 내부적으로 해당 항목에 할당됩니다. Patch0, Patch1, Patch2, Patch3 등을 사용하여 명시적으로 숫자를 지정할 수도 있습니다.

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

BuildArch

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

BuildRequires

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

필수 항목

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

ExcludeArch

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

충돌

conflicts are inverse to Requires. conflicts 와 일치하는 패키지가 있는 경우 Conflict 태그가 이미 설치되어 있거나 설치할 패키지에 있는지 여부에 따라 패키지를 독립적으로 설치할 수 없습니다.

사용되지 않음

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

제공

Provides 가 패키지에 추가되면 해당 이름이 아닌 종속성에서 패키지를 참조할 수 있습니다.If Provides is added to a package, the package can be referred to by dependencies other than its name.

Name,VersionRelease 지시문은 RPM 패키지의 파일 이름을 구성합니다. RPM 패키지 파일 이름에 NAME-VERSION-RELEASE 형식이 있기 때문에 RPM 패키지 관리자 및 시스템 관리자는 이러한 세 개의 지시문 N-V-R 또는 NVR 을 호출하는 경우가 많습니다.

다음 예제에서는 rpm 명령을 쿼리하여 특정 패키지에 대한 NVR 정보를 가져오는 방법을 보여줍니다.

예 3.1. bash 패키지에 대한 NVR 정보를 제공하기 위해 rpm 쿼리

# rpm -q bash
bash-4.4.19-7.el8.x86_64

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

3.4.2. 본문 항목

RPM SPEC 파일의 body 섹션에서 사용된 항목은 아래 표에 나열되어 있습니다.

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

SPEC 조건정의

%Description

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

%Prep

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

%build

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

%install

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

%check

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

%files

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

%changelog

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

3.4.3. 고급 항목

SPEC 파일에는 Scriptlets 또는 Triggers 와 같은 고급 항목이 포함될 수도 있습니다.

이는 빌드 프로세스가 아닌 최종 사용자의 시스템에 설치 프로세스 중 다른 시점에서 적용됩니다.

3.5. BuildRoots

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

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

참고

Red Hat Enterprise Linux 6부터는 rpmbuild 프로그램의 기본값이 있습니다. 이러한 기본값을 재정의하면 몇 가지 문제가 발생할 수 있으므로 Red Hat은 이 매크로의 고유한 값을 정의하는 것을 권장하지 않습니다. rpmbuild 디렉터리의 기본값과 함께 %{buildroot} 매크로를 사용할 수 있습니다.

3.6. RPM 매크로

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

예제 사용은 SPEC 파일에서 패키지 소프트웨어 버전 을 여러 번 참조하는 것입니다. %{version} 매크로에서 한 번만 버전 을 정의하고 SPEC 파일 전체에서 이 매크로를 사용합니다. 모든 이벤트는 이전에 정의한 버전으로 자동 대체됩니다.

참고

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

$ rpm --eval %{_MACRO}

%{_bindir} 및 %{_libexecdir} 매크로 평가

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

$ rpm --eval %{_libexecdir}
/usr/libexec

일반적으로 사용되는 매크로 중 하나는 빌드에 사용되는 배포를 나타내는 %{?dist} 매크로입니다.

# On a RHEL 8.x machine
$ rpm --eval %{?dist}
.el8

3.7. SPEC 파일 작업

새 소프트웨어를 패키징하려면 새 SPEC 파일을 만들어야 합니다.

이 작업을 수행하는 방법에는 두 가지가 있습니다.

  • 새 SPEC 파일을 처음부터 수동으로 작성
  • rpmdev-newspec 유틸리티 사용

    이 유틸리티는 채워지지 않은 SPEC 파일을 생성하고 필요한 지시문과 필드를 작성합니다.

참고

일부 프로그래밍 중심 텍스트 편집기는 새 . spec 파일을 자체 SPEC 템플릿으로 미리 채웁니다. rpmdev-newspec 유틸리티는 편집기와 무관한 방법을 제공합니다.

다음 섹션에서는 소스 코드.에서 설명 된 Hello World! 프로그램의 세 가지 예제 구현을 사용 합니다.

각 프로그램은 또한 아래 표에 완전히 설명되어 있습니다.

소프트웨어 이름

예제 설명

somethingamo

원시 해석된 프로그래밍 언어로 작성된 프로그램입니다. 소스 코드를 빌드할 필요가 없으며 설치할 필요가 있는 경우를 보여줍니다. 사전 컴파일된 바이너리를 패키징해야 하는 경우 바이너리가 파일일 뿐이므로 이 메서드를 사용할 수도 있습니다.

pello

바이트로 컴파일된 해석된 프로그래밍 언어로 작성된 프로그램입니다. 이는 소스 코드를 바이트로 컴파일하고 바이트 코드를 설치하는 것을 보여줍니다. 즉, 그 결과 사전 최적화된 파일이 생성됩니다.

cello

기본적으로 컴파일된 프로그래밍 언어로 작성된 프로그램입니다. 소스 코드를 머신 코드로 컴파일하고 결과 실행 파일을 설치하는 일반적인 프로세스를 보여줍니다.

Hello World 의 구현은 다음과 같습니다.

전제 조건으로 이러한 구현을 ~/rpmbuild/SOURCES 디렉토리에 배치해야 합니다.

3.8. rpmdev-newspec을 사용하여 새 SPEC 파일 만들기

다음 절차에서는 rpmdev-newspec 유틸리티를 사용하여 앞서 언급한 3개의 Hello World! 프로그램 각각에 대해 SPEC 파일을 생성하는 방법을 보여줍니다.

절차

  1. ~/rpmbuild/SPECS 디렉토리로 변경하고 rpmdev-newspec 유틸리티를 사용합니다.

    $ cd ~/rpmbuild/SPECS
    
    $ 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.

    ~/rpmbuild/SPECS/ 디렉터리에는 이제 bello.spec,cello.specpello.spec 이라는 세 개의 SPEC 파일이 있습니다.

  2. 파일을 검사합니다.

    파일의 지시문은 What is a SPEC file.에 설명된 내용을 나타냅니다. 다음 섹션에서는 rpmdev-newspec 의 출력 파일에 특정 섹션을 채웁니다.

참고

rpmdev-newspec 유틸리티는 특정 Linux 배포판과 관련된 지침이나 규칙을 사용하지 않습니다. 그러나 이 문서는 Red Hat Enterprise Linux를 대상으로 하므로 SPEC 파일 전체에서 다른 모든 매크로와 일관성을 유지하기 위해 RPM의 Buildroot를 참조할 때 $RPM_BUILD_ROOT 표기법보다 %{buildroot} 표기법이 선호됩니다.

3.9. RPM을 생성하기 위해 원래 SPEC 파일 수정

다음 절차에서는 RPM을 생성하기 위해 rpmdev-newspec 에서 제공하는 출력 SPEC 파일을 수정하는 방법을 보여줍니다.

사전 요구 사항

  • 특정 프로그램의 소스 코드는 ~/rpmbuild/SOURCES/ 디렉토리에 배치되었습니다.
  • 채워지지 않은 SPEC 파일 ~/rpmbuild/SPECS/<name>.spec 파일은 rpmdev-newspec 유틸리티에 의해 생성되었습니다.

절차

  1. rpmdev-newspec 유틸리티에서 제공하는 ~/rpmbuild/SPECS/<name>.spec 파일의 출력 템플릿을 엽니다.
  2. SPEC 파일의 첫 번째 섹션을 채웁니다.

    첫 번째 섹션에는 rpmdev-newspec 이 함께 그룹화된 지시문이 포함되어 있습니다.

    이름
    Namerpmdev-newspec 에 대한 인수로 이미 지정되었습니다.
    버전
    소스 코드의 업스트림 릴리스 버전과 일치하도록 버전 을 설정합니다.
    릴리스 버전
    릴리스 가 자동으로 1%{?dist} 로 설정되어 있으며 이는 처음 1 입니다. 패치를 포함할 때와 같이 업스트림 릴리스 버전 변경 없이 패키지를 업데이트할 때마다 초기 값을 늘립니다. 새 업스트림 릴리스 가 발생하면 릴리스를 1 로 재설정합니다.
    요약
    요약 은 이 소프트웨어가 무엇인지에 대한 간단한 한 줄 설명입니다.
  3. 라이센스,URLSource0 지시문을 채웁니다.

    라이센스 필드는 업스트림 릴리스의 소스 코드와 관련된 소프트웨어 라이센스입니다. SPEC 파일에서 라이센스에 레이블을 지정하는 방법에 대한 정확한 형식은 다음과 같은 특정 RPM 기반 Linux 배포 지침에 따라 달라집니다.

    예를 들어, RuntimeClassv 3+를 사용할 수 있습니다.

    URL 필드는 업스트림 소프트웨어 웹 사이트에 URL을 제공합니다. 일관성을 위해 %{name} 의 RPM 매크로 변수를 사용하고 https://example.com/%{name} 을 사용합니다.

    Source0 필드는 업스트림 소프트웨어 소스 코드에 URL을 제공합니다. 패키지화된 특정 버전의 소프트웨어에 직접 연결해야 합니다. 이 문서에 제공된 예제 URL에는 향후 변경될 수 있는 하드 코딩된 값이 포함되어 있습니다. 마찬가지로 릴리스 버전도 변경될 수 있습니다. 잠재적인 변경 사항을 단순화하려면 %{name}%{version} 매크로를 사용합니다. 이를 사용하여 SPEC 파일에서 하나의 필드만 업데이트해야 합니다.

  4. BuildRequires,RequiresBuildArch 지시문을 채웁니다.

    BuildRequires 는 패키지에 대한 빌드 타임 종속성을 지정합니다.

    패키지에 대한 런타임 종속 항목을 지정합니다.

    이는 기본적으로 컴파일된 확장 기능 없이 해석된 프로그래밍 언어로 작성된 소프트웨어입니다. 따라서 noarch 값을 사용하여 BuildArch 지시문을 추가합니다. 이는 이 패키지가 빌드된 프로세서 아키텍처에 바인딩되지 않아도 된다고 RPM에 지시합니다.

  5. %description,%prep,%build,%install,%files, % license 지시문을 채웁니다.

    이러한 지시문은 섹션 제목으로 간주될 수 있습니다. 이러한 지시문은 여러 줄, 다중 구조 또는 스크립트된 작업을 정의할 수 있는 지시문이므로 섹션 제목으로 간주할 수 있습니다.

    %description 은 하나 이상의 단락을 포함하는 요약 보다 소프트웨어에 대한 더 길고 완전한 설명입니다.

    %prep 섹션에서는 빌드 환경을 준비하는 방법을 지정합니다. 일반적으로 소스 코드의 압축 아카이브, 패치 적용 및, SPEC 파일의 이후 부분에서 사용하기 위해 소스 코드에 제공된 정보 구문 분석과 관련이 있습니다. 이 섹션에서는 내장 %setup -q 매크로를 사용할 수 있습니다.

    %build 섹션은 소프트웨어를 빌드하는 방법을 지정합니다.

    %install 섹션에는 BUILDROOT 디렉터리에 소프트웨어 설치 방법에 대한 지침이 포함되어 있습니다.

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

    %files 섹션은 이 RPM에서 제공하는 파일 목록과 최종 사용자의 시스템에서 전체 경로 위치를 지정합니다.

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

  6. 마지막 섹션인 %changelog 는 패키지의 각 버전-Release에 대해 오염된 날짜 목록입니다. 소프트웨어 변경 사항이 아닌 패키징 변경 사항을 기록합니다. 패키징 변경의 예: %build 섹션에서 패치 추가, 빌드 절차를 변경합니다.

    첫 번째 줄에 대해 다음 형식을 따릅니다.

    Day-of-Week Month Day Day Name Surname <email> - Version-Release로 시작합니다.

    실제 변경 항목에 대해 다음 형식을 따릅니다.

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

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

3.10. bash로 작성된 프로그램의 SPEC 파일 예제

이 섹션에서는 bash로 작성된 bello 프로그램의 SPEC 파일 예제를 보여줍니다.

bash로 작성된 bello 프로그램의 SPEC 파일 예제

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

패키지에 대한 빌드 시간 종속성을 지정하는 BuildRequires 지시문이 bello 빌드 단계가 없기 때문에 삭제되었습니다. Bash는 원시 해석된 프로그래밍 언어이며 파일은 시스템의 위치에만 설치됩니다.

bello 스크립트에는 bash 쉘 환경만 필요하므로 패키지에 대한 런타임 종속성을 지정하는 Requires 지시문은 bash 만 포함합니다.

소프트웨어 빌드 방법을 지정하는 %build 섹션은 bash 를 빌드할 필요가 없으므로 비어 있습니다.

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

추가 리소스

3.11. Python으로 작성된 프로그램의 SPEC 파일 예제

이 섹션에서는 Python 프로그래밍 언어로 작성된 pello 프로그램의 SPEC 파일 예제를 보여줍니다.

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

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

중요

pello 프로그램은 바이트로 컴파일된 해석된 언어로 작성됩니다. 따라서 결과 파일에 항목이 포함되어 있지 않기 때문에 hebang은 적용되지 않습니다.

Whibang은 적용되지 않기 때문에 다음 방법 중 하나를 적용할 수 있습니다.

  • 실행 파일을 호출할 바이트가 아닌 쉘 스크립트를 만듭니다.
  • 바이트가 아닌 Python 코드의 작은 비트를 프로그램 실행의 진입점으로 제공합니다.

이러한 접근 방식은 특히 코드 수천 개가 있는 대규모 소프트웨어 프로젝트에 유용합니다. 이 경우 사전 바이트로 컴파일된 코드의 성능 증가의 크기를 조정할 수 있습니다.

패키지의 런타임 종속 항목을 지정하는 Requires 지시문에는 다음 두 가지 패키지가 포함되어 있습니다.

  • python 패키지는 런타임 시 바이트- compiled 코드를 실행하는 데 필요합니다.
  • 작은 진입점 스크립트를 실행하려면 bash 패키지가 필요합니다.

패키지의 빌드 시간 종속성을 지정하는 BuildRequires 지시문에는 python 패키지만 포함됩니다. pello 프로그램은 바이트-compile 빌드 프로세스를 수행하기 위해 python 패키지가 필요합니다.

소프트웨어를 빌드하는 방법을 지정하는 %build 섹션은 소프트웨어가 바이트- compiled라는 사실과 일치합니다.

pello 를 설치하려면 shebang이 바이트로 컴파일된 언어로는 적용되지 않기 때문에 래퍼 스크립트를 만들어야 합니다. 이 작업을 수행할 수 있는 옵션은 다음과 같습니다.

  • 별도의 스크립트를 만들고 이를 별도의 SourceX 지시문으로 사용합니다.
  • SPEC 파일에서 해당 파일을 줄로 만듭니다.

이 예제에서는 SPEC 파일 자체를 스크립팅할 수 있음을 증명하기 위해 SPEC 파일에 래퍼 스크립트를 작성하는 방법을 보여줍니다. 이 래퍼 스크립트는 이 문서를 사용하여 Python 바이트로 컴파일된 코드를 실행합니다.

이 예제의 %install 섹션은 액세스할 수 있도록 시스템의 라이브러리 디렉터리에 바이트- compiled 파일을 설치해야 한다는 점에도 해당합니다.

추가 리소스

3.12. C로 작성된 프로그램의 SPEC 파일 예제

이 섹션에서는 C 프로그래밍 언어로 작성된 cello 프로그램의 SPEC 파일 예제를 보여줍니다.

C로 작성된 셀오 프로그램의 SPEC 파일 예제

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

패키지에 대한 빌드 시간 종속성을 지정하는 BuildRequires 지시문에는 컴파일 빌드 프로세스를 수행하는 데 필요한 두 개의 패키지가 포함되어 있습니다.

  • gcc 패키지
  • make 패키지

패키지에 대한 런타임 종속성을 지정하는 Requires 지시문은 이 예에서 생략됩니다. 모든 런타임 요구 사항은 rpmbuild 에 의해 처리되며 cello 프로그램에는 코어 C 표준 라이브러리 외부에 아무것도 필요하지 않습니다.

%build 섹션은 이 예에서 cello 프로그램의 Makefile 이 작성되었음을 반영하므로 rpmdev-newspec 유틸리티에서 제공하는 GNU make 명령을 사용할 수 있습니다. 그러나 구성 스크립트를 제공하지 않았기 때문에 %configure 호출을 제거해야 합니다.

cello 프로그램의 설치는 rpmdev-newspec 명령에서 제공한 %make_install 매크로를 사용하여 수행할 수 있습니다. 이는 셀러 프로그램에 대한 Makefile 이 사용 가능하기 때문에 가능합니다.

추가 리소스

3.13. RPM 빌드

RPM은 rpmbuild 명령을 사용하여 빌드됩니다. 이 명령을 실행하면 특정 디렉터리와 파일 구조가 rpmdev-setuptree 유틸리티로 설정된 구조와 동일합니다.

다른 사용 사례와 원하는 결과에는 rpmbuild 명령에 다양한 인수 조합이 필요합니다. 두 가지 주요 사용 사례는 다음과 같습니다.

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

    • 소스 RPM에서 바이너리 RPM 재빌드
    • SPEC 파일에서 바이너리 RPM 빌드
    • 소스 RPM에서 바이너리 RPM 빌드

다음 섹션에서는 프로그램에 대한 SPEC 파일이 생성된 후 RPM을 빌드하는 방법을 설명합니다.

3.14. 소스 RPM 빌드

다음 절차에서는 소스 RPM을 빌드하는 방법을 설명합니다.

사전 요구 사항

  • 패키지하려는 프로그램에 대한 SPEC 파일이 이미 있어야 합니다.

절차

  • 지정된 SPEC 파일을 사용하여 rpmbuild 명령을 실행합니다.

    $ rpmbuild -bs SPECFILE

    SPECFILE 을 SPECFILE 파일로 대체합니다. b s 옵션은 빌드 소스를 나타냅니다.

다음 예제에서는 bello,pellocello 프로젝트에 대한 소스 RPM을 빌드하는 방법을 보여줍니다.

bello, pello 및 cello를 위한 소스 RPM 구축.

$ cd ~/rpmbuild/SPECS/

8$ 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

검증 단계

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

3.15. 소스 RPM에서 바이너리 RPM 재빌드

다음 절차에서는 소스 RPM(SRPM)에서 바이너리 RPM을 다시 빌드하는 방법을 보여줍니다.

절차

  • SRPMs에서 bello,pello, cello 를 다시 빌드하려면 다음을 실행합니다.

    $ rpmbuild --rebuild ~/rpmbuild/SRPMS/bello-0.1-1.el8.src.rpm
    [output truncated]
    
    $ rpmbuild --rebuild ~/rpmbuild/SRPMS/pello-0.1.2-1.el8.src.rpm
    [output truncated]
    
    $ rpmbuild --rebuild ~/rpmbuild/SRPMS/cello-1.0-1.el8.src.rpm
    [output truncated]
참고

rpmbuild --rebuild 를 호출하면 다음이 포함됩니다.

  • SRPM - SPEC 파일과 소스 코드의 내용을 ~/rpmbuild/ 디렉토리에 설치합니다.
  • 설치된 콘텐츠를 사용하여 빌드합니다.
  • SPEC 파일 및 소스 코드 제거.

빌드 후 SPEC 파일과 소스 코드를 유지하려면 다음을 수행할 수 있습니다.

  • 빌드할 때 --rebuild 옵션 대신 --recompile 옵션과 함께 rpmbuild 명령을 사용합니다.
  • 다음 명령을 사용하여 SRPMs을 설치합니다.

    $ 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%]

바이너리 RPM을 생성할 때 생성된 출력은 자세한 정보이며 디버깅에 유용합니다. 출력은 다양한 예제에 따라 다르며 SPEC 파일에 해당합니다.

생성된 바이너리 RPM은 ~/rpmbuild/RPMS/ YOURARCH 디렉토리에 있습니다. 여기서 KnativeServingARCH는 아키텍처 또는 패키지에 특정되지 않은 경우 ~/rpmbuild/RPMS/noarch/ 디렉터리에 있습니다.

3.16. SPEC 파일에서 바이너리 RPM 빌드

다음 절차에서는 SPEC 파일에서 벨로 ,pellocello 바이너리 RPM을 빌드하는 방법을 보여줍니다.

절차

  • bb 옵션을 사용하여 rpmbuild 명령을 실행합니다.

    $ rpmbuild -bb ~/rpmbuild/SPECS/bello.spec
    
    $ rpmbuild -bb ~/rpmbuild/SPECS/pello.spec
    
    $ rpmbuild -bb ~/rpmbuild/SPECS/cello.spec

3.17. 소스 RPM에서 바이너리 RPM 빌드

소스 RPM에서 모든 종류의 RPM을 빌드할 수도 있습니다. 이를 위해서는 다음 절차를 사용하십시오.

절차

  • 아래 옵션 중 하나와 소스 패키지가 지정된 상태에서 rpmbuild 명령을 실행합니다.

    # rpmbuild {-ra|-rb|-rp|-rc|-ri|-rl|-rs} [rpmbuild-options] SOURCEPACKAGE

추가 리소스

  • rpmbuild(8) 도움말 페이지

3.18. RPM에서 온전성 확인

패키지를 만든 후에는 패키지의 품질을 확인해야 합니다.

패키지 품질을 확인하는 기본 도구는 rpmlint 입니다.

rpmlint 도구는 다음을 수행합니다.

  • RPM 유지 관리 기능 개선
  • RPM의 정적 분석을 수행하여 온전성 검사를 활성화합니다.
  • RPM의 정적 분석을 수행하여 오류 검사를 활성화합니다.

rpmlint 툴은 바이너리 RPM, 소스 RPM(SRPMs) 및 SPEC 파일을 확인할 수 있으므로 다음 섹션에 설명된 것처럼 모든 패키지 단계에 유용합니다.

rpmlint 에는 매우 엄격한 지침이 있으므로 다음 예와 같이 일부 오류 및 경고를 건너뛸 수 있습니다.

참고

다음 섹션에 설명된 예에서 rpmlint 는 검증되지 않은 출력을 생성하는 옵션 없이 실행됩니다. 각 오류 또는 경고에 대한 자세한 설명은 rpmlint -i 를 대신 실행할 수 있습니다.

3.19. Sanity에 대한 벨로오 확인

이 섹션에서는 bello SPEC 파일 예제 및 벨소리 바이너리 RPM에서 RPM 심각도를 확인할 때 발생할 수 있는 경고 및 오류를 보여줍니다.

3.19.1. 벨소 SPEC 파일 확인

예 3.2. bello에 대한 SPEC 파일에서 rpmlint 명령을 실행하는 출력

$ rpmlint bello.spec
bello.spec: W: invalid-url Source0: https://www.example.com/bello/releases/bello-0.1.tar.gz HTTP Error 404: Not Found
0 packages and 1 specfiles checked; 0 errors, 1 warnings.

bello.spec 의 경우 하나의 경고만 있습니다. 이 경고는 Source0 지시문에 나열된 URL에 연결할 수 없음을 나타냅니다. 지정된 example.com URL이 없기 때문에 이 작업이 예상됩니다. 이 URL이 나중에 작동할 것으로 예상한다고 가정하면 이 경고는 무시해도 됩니다.

예 3.3. 벨노용 SRPM에서 rpmlint 명령을 실행하는 출력

$ rpmlint ~/rpmbuild/SRPMS/bello-0.1-1.el8.src.rpm
bello.src: W: invalid-url URL: https://www.example.com/bello HTTP Error 404: Not Found
bello.src: W: invalid-url Source0: https://www.example.com/bello/releases/bello-0.1.tar.gz HTTP Error 404: Not Found
1 packages and 0 specfiles checked; 0 errors, 2 warnings.

bello SRPM의 경우 URL 지시문에 지정된 URL 에 연결할 수 없다는 새로운 경고가 있습니다. 링크는 나중에 작동할 것이라고 가정하면 이 경고를 무시할 수 있습니다.

3.19.2. bello 바이너리 RPM 확인

바이너리 RPM을 확인할 때 rpmlint 은 다음 항목을 확인합니다.

  • 문서
  • 도움말 페이지
  • 파일 시스템 계층 구조 표준을 일관되게 사용

예 3.4. 벨노용 바이너리 RPM에서 rpmlint 명령을 실행하는 출력

$ rpmlint ~/rpmbuild/RPMS/noarch/bello-0.1-1.el8.noarch.rpm
bello.noarch: W: invalid-url URL: https://www.example.com/bello HTTP Error 404: Not Found
bello.noarch: W: no-documentation
bello.noarch: W: no-manual-page-for-binary bello
1 packages and 0 specfiles checked; 0 errors, 3 warnings.

no-documentationno-manual-page-for-binary 경고는 RPM에 문서 또는 도움말 페이지가 없음을 나타냅니다. 위의 경고 외에 RPM은 rpmlint 검사를 통과했습니다.

3.20. 장로에서 장난을 확인

이 섹션에서는 pello SPEC 파일 및 pello 바이너리 RPM 예제에서 RPM 장엄성을 확인할 때 발생할 수 있는 경고 및 오류를 보여줍니다.

3.20.1. Pello SPEC 파일 확인

예 3.5. pello에 대한 SPEC 파일에서 rpmlint 명령을 실행하는 출력

$ rpmlint pello.spec
pello.spec:30: E: hardcoded-library-path in %{buildroot}/usr/lib/%{name}
pello.spec:34: E: hardcoded-library-path in /usr/lib/%{name}/%{name}.pyc
pello.spec:39: E: hardcoded-library-path in %{buildroot}/usr/lib/%{name}/
pello.spec:43: E: hardcoded-library-path in /usr/lib/%{name}/
pello.spec:45: E: hardcoded-library-path in /usr/lib/%{name}/%{name}.py*
pello.spec: W: invalid-url Source0: https://www.example.com/pello/releases/pello-0.1.2.tar.gz HTTP Error 404: Not Found
0 packages and 1 specfiles checked; 5 errors, 1 warnings.

invalid-url Source0 경고에 따르면 Source0 지시문에 나열된 URL에 연결할 수 없습니다. 지정된 example.com URL이 없기 때문에 이 작업이 예상됩니다. 이 URL은 나중에 작동한다고 가정하면 이 경고를 무시할 수 있습니다.

하드코딩-library-path 오류는 라이브러리 경로를 하드 코딩하는 대신 %{_libdir} 매크로를 사용하는 것이 좋습니다. 이 예제에서는 이러한 오류를 무시해도 됩니다. 그러나 프로덕션으로 이동하는 패키지의 경우 모든 오류를 신중하게 확인하십시오.

예 3.6. SRPM for pello에서 rpmlint 명령 실행의 출력

$ rpmlint ~/rpmbuild/SRPMS/pello-0.1.2-1.el8.src.rpm
pello.src: W: invalid-url URL: https://www.example.com/pello HTTP Error 404: Not Found
pello.src:30: E: hardcoded-library-path in %{buildroot}/usr/lib/%{name}
pello.src:34: E: hardcoded-library-path in /usr/lib/%{name}/%{name}.pyc
pello.src:39: E: hardcoded-library-path in %{buildroot}/usr/lib/%{name}/
pello.src:43: E: hardcoded-library-path in /usr/lib/%{name}/
pello.src:45: E: hardcoded-library-path in /usr/lib/%{name}/%{name}.py*
pello.src: W: invalid-url Source0: https://www.example.com/pello/releases/pello-0.1.2.tar.gz HTTP Error 404: Not Found
1 packages and 0 specfiles checked; 5 errors, 2 warnings.

여기에서 새로운 invalid-url URL 오류는 연결할 수 없는 URL 지시문에 관한 것입니다. 나중에 URL이 유효한 것으로 가정하면 이 오류는 무시해도 됩니다.

3.20.2. pello 바이너리 RPM 확인

바이너리 RPM을 확인할 때 rpmlint 은 다음 항목을 확인합니다.

  • 문서
  • 도움말 페이지
  • 파일 시스템 계층 구조 표준을 일관되게 사용

예 3.7. pello 바이너리 RPM에서 rpmlint 명령 실행 출력

$ rpmlint ~/rpmbuild/RPMS/noarch/pello-0.1.2-1.el8.noarch.rpm
pello.noarch: W: invalid-url URL: https://www.example.com/pello HTTP Error 404: Not Found
pello.noarch: W: only-non-binary-in-usr-lib
pello.noarch: W: no-documentation
pello.noarch: E: non-executable-script /usr/lib/pello/pello.py 0644L /usr/bin/env
pello.noarch: W: no-manual-page-for-binary pello
1 packages and 0 specfiles checked; 1 errors, 4 warnings.

no-documentationno-manual-page-for-binary 경고는 제공되지 않기 때문에 RPM에 문서 또는 도움말 페이지가 없음을 나타냅니다.

binary-in-usr-lib 경고는 /usr/lib/ 에 바이너리가 아닌 아티팩트만 제공했다고 합니다. 이 디렉터리는 일반적으로 바이너리 파일인 공유 오브젝트 파일용으로 예약되어 있습니다. 따라서 rpmlint/usr/lib/ 디렉토리에 있는 하나 이상의 파일을 바이너리로 예상합니다.

다음은 Filesystem Hierarchy Standard의 준수를 확인하는 rpmlint 검사의 예입니다. 일반적으로 RPM 매크로를 사용하여 파일의 올바른 배치를 확인합니다. 이 예제에서는 이 경고를 무시해도 됩니다.

실행 불가능한-script 오류는 /usr/lib/pello/pello.py 파일에 실행 권한이 없음을 경고합니다. rpmlint 툴에서는 파일에 hebang이 포함되어 있기 때문에 파일을 실행할 수 있어야 합니다. 이 예제의 목적을 위해 실행 권한 없이 이 파일을 그대로 두고 이 오류를 무시할 수 있습니다.

위의 경고 및 오류 외에도 RPM은 rpmlint 검사를 통과했습니다.

3.21. Sanity에 대한 셀러 확인

이 섹션에서는 cello SPEC 파일 및 pello 바이너리 RPM 예제에서 RPM 심각도를 확인할 때 발생할 수 있는 경고 및 오류를 보여줍니다.

3.21.1. cello SPEC 파일 확인

예 3.8. cello에 대한 SPEC 파일에서 rpmlint 명령을 실행하는 출력

$ rpmlint ~/rpmbuild/SPECS/cello.spec
/home/admiller/rpmbuild/SPECS/cello.spec: W: invalid-url Source0: https://www.example.com/cello/releases/cello-1.0.tar.gz HTTP Error 404: Not Found
0 packages and 1 specfiles checked; 0 errors, 1 warnings.

cello.spec 의 경우 하나의 경고만 있습니다. 이 경고는 Source0 지시문에 나열된 URL에 연결할 수 없음을 나타냅니다. 지정된 example.com URL이 없기 때문에 이 작업이 예상됩니다. 이 URL은 나중에 작동한다고 가정하면 이 경고를 무시할 수 있습니다.

예 3.9. cello에 대해 SRPM에서 rpmlint 명령을 실행하는 출력

$ rpmlint ~/rpmbuild/SRPMS/cello-1.0-1.el8.src.rpm
cello.src: W: invalid-url URL: https://www.example.com/cello HTTP Error 404: Not Found
cello.src: W: invalid-url Source0: https://www.example.com/cello/releases/cello-1.0.tar.gz HTTP Error 404: Not Found
1 packages and 0 specfiles checked; 0 errors, 2 warnings.

cello SRPM의 경우 URL 지시문에 지정된 URL 에 연결할 수 없다는 새로운 경고가 있습니다. 링크는 나중에 작동한다고 가정하면 이 경고를 무시할 수 있습니다.

3.21.2. cello 바이너리 RPM 확인

바이너리 RPM을 확인할 때 rpmlint 은 다음 항목을 확인합니다.

  • 문서
  • 도움말 페이지
  • 파일 시스템 계층 구조 표준을 일관되게 사용

예 3.10. cello에 대한 바이너리 RPM에서 rpmlint 명령을 실행하는 출력

$ rpmlint ~/rpmbuild/RPMS/x86_64/cello-1.0-1.el8.x86_64.rpm
cello.x86_64: W: invalid-url URL: https://www.example.com/cello HTTP Error 404: Not Found
cello.x86_64: W: no-documentation
cello.x86_64: W: no-manual-page-for-binary cello
1 packages and 0 specfiles checked; 0 errors, 3 warnings.

no-documentationno-manual-page-for-binary 경고는 입력하지 않았기 때문에 RPM에 문서 또는 도움말 페이지가 없음을 나타냅니다. 위의 경고 외에 RPM은 rpmlint 검사를 통과했습니다.

3.22. syslog에 RPM 활동 기록

RPM 활동 또는 트랜잭션은 시스템 로깅 프로토콜(syslog)에서 로깅할 수 있습니다.

사전 요구 사항

  • RPM 트랜잭션을 syslog에 로깅할 수 있도록 하려면 syslog 플러그인이 시스템에 설치되어 있는지 확인하십시오.

    # yum install rpm-plugin-syslog
    참고

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

RPM 활동 업데이트를 보려면 설명된 절차를 따르십시오.

절차

  1. syslog 메시지를 저장하도록 구성한 파일을 열거나 기본 syslog 구성을 사용하는 경우 /var/log/message 파일을 엽니다.
  2. [RPM] 문자열을 포함하여 새 행을 검색합니다.

3.23. RPM 콘텐츠 추출

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

참고

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

다음 절차에서는 rpm2archive 유틸리티를 사용하여 rpm 페이로드를 tar 아카이브로 변환하는 방법을 설명합니다.

절차

  • 다음 명령을 실행합니다.

    $ rpm2archive filename.rpm

    파일 이름을 .rpm 파일의 이름으로 바꿉니다.

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

    $ rpm2archive bash-4.4.19-6.el8.x86_64.rpm
    $ bash-4.4.19-6.el8.x86_64.rpm.tgz
    bash-4.4.19-6.el8.x86_64.rpm.tgz

4장. 고급 주제

이 섹션에서는 소개 튜토리얼의 범위를 벗어나지만 실제적인 RPM 패키지에 유용한 주제를 다룹니다.

4.1. 패키지 서명

타사에서 콘텐츠를 변경할 수 없도록 패키지가 서명됩니다. 사용자는 패키지를 다운로드할 때 HTTPS 프로토콜을 사용하여 추가 보안 계층을 추가할 수 있습니다.

패키지에 서명하는 방법은 다음 세 가지가 있습니다.

사전 요구 사항

4.1.1. GPG 키 생성

다음 절차에서는 패키지 서명에 필요한 GPG(GNU 개인 정보 보호 강화) 키를 만드는 방법을 설명합니다.

절차

  1. GPG(GNU 개인 정보 보호 보안) 키 쌍을 생성합니다.

    # gpg --gen-key
  2. 생성된 키를 확인하고 확인합니다.

    # gpg --list-keys
  3. 공개 키를 내보냅니다.

    # gpg --export -a '<Key_name>' > RPM-GPG-KEY-pmanager

    <Key_name>을 선택한 실제 이름으로 바꿉니다.

  4. 내보낸 공개 키를 RPM 데이터베이스로 가져옵니다.

    # rpm --import RPM-GPG-KEY-pmanager

4.1.2. 패키지에 서명하도록 RPM 구성

패키지에 서명하려면 %_gpg_name RPM 매크로를 지정해야 합니다.

다음 절차에서는 패키지에 서명하기 위해 RPM을 구성하는 방법을 설명합니다.

절차

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

    %_gpg_name Key ID

    서명에 사용할 GPG(GG) 키 ID로 키 ID를 바꿉니다. 유효한 GPG 키 ID 값은 키를 생성한 사용자의 전체 이름 또는 이메일 주소입니다.

4.1.3. 기존 패키지에 서명 추가

이 섹션에서는 서명 없이 패키지를 빌드할 때 가장 일반적인 경우를 설명합니다. 서명은 패키지를 릴리스하기 직전에 추가됩니다.

패키지에 서명을 추가하려면 rpm-sign 패키지에서 제공하는 --addsign 옵션을 사용합니다.

서명이 두 개 이상 있으면 패키지 빌더에서 최종 사용자로 패키지의 소유권 경로를 기록할 수 있습니다.

절차

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

    $ rpm --addsign blather-7.9-1.x86_64.rpm
    참고

    서명의 시크릿 키 잠금을 해제하려면 암호를 입력해야 합니다.

4.1.4. 여러 개의 서명이 있는 패키지 서명 확인

다음 절차에서는 여러 서명이 있는 패키지 서명을 확인하는 방법을 설명합니다.

절차

  • 여러 개의 서명이 있는 패키지 서명을 확인하려면 다음을 실행합니다.

    $ rpm --checksig blather-7.9-1.x86_64.rpm
    blather-7.9-1.x86_64.rpm: size pgp pgp md5 OK

    rpm --checksig 명령 출력의 두 pgp 문자열은 패키지가 두 번 서명되었음을 보여줍니다.

4.1.5. 기존 패키지에 서명을 추가하는 실제 예

이 섹션에서는 기존 패키지에 서명을 추가하는 것이 유용할 수 있는 예를 설명합니다.

회사 부서는 패키지를 생성하고 분할 키를 사용하여 서명합니다. 그런 다음 회사의 본부는 패키지의 서명을 확인하고 서명된 패키지가 사실임을 나타내는 회사 서명을 패키지에 추가합니다.

두 개의 서명을 통해 패키지는 리테이커로 이동합니다. 리테이너는 서명을 확인하며 일치하면 서명을 추가합니다.

이제 패키지는 패키지를 배포하려는 회사로 이동합니다. 패키지의 모든 서명을 확인한 후 실제 사본임을 알고 있습니다. 배포 회사의 내부 제어에 따라 고객에게 패키지에 회사 승인을 수신했음을 알리기 위해 자체 서명을 추가하도록 선택할 수 있습니다.

4.1.6. 기존 패키지에서 서명 교체

다음 절차에서는 각 패키지를 다시 빌드할 필요 없이 공개 키를 변경하는 방법을 설명합니다.

절차

  • 공개 키를 변경하려면 다음을 실행합니다.

    $ rpm --resign blather-7.9-1.x86_64.rpm
    참고

    서명의 시크릿 키 잠금을 해제하려면 암호를 입력해야 합니다.

또한 --resign 옵션을 사용하면 다음 절차에 따라 여러 패키지의 공개 키를 변경할 수 있습니다.

절차

  • 여러 패키지의 공개 키를 변경하려면 다음을 실행합니다.

    $ rpm --resign b*.rpm
    참고

    서명의 시크릿 키 잠금을 해제하려면 암호를 입력해야 합니다.

4.1.7. 빌드 시 패키지 서명

다음 절차에서는 빌드 시 패키지에 서명하는 방법을 설명합니다.

절차

  1. rpmbuild 명령을 사용하여 패키지를 빌드합니다.

    $ rpmbuild blather-7.9.spec
  2. --addsign 옵션을 사용하여 rpmsign 명령을 사용하여 패키지에 서명합니다.

    $ rpmsign --addsign blather-7.9-1.x86_64.rpm
  3. 선택적으로 패키지의 서명을 확인합니다.
$ rpm --checksig blather-7.9-1.x86_64.rpm
blather-7.9-1.x86_64.rpm: size pgp md5 OK
참고

여러 패키지를 빌드하고 서명할 때 Pretty good Privacy(PGP) 암호를 여러 번 입력하지 않도록 다음 구문을 사용하십시오.

$ rpmbuild -ba --sign b*.spec

서명의 보안 키를 잠금 해제하기 위해 암호를 입력해야 합니다.

4.2. 매크로에 대한 추가 정보

이 섹션에서는 선택한 내장 RPM 매크로에 대해 설명합니다. 이러한 매크로의 전체 목록은 RPM 설명서 를 참조하십시오.

4.2.1. 자체 매크로 정의

다음 섹션에서는 사용자 지정 매크로를 만드는 방법을 설명합니다.

절차

  • RPM SPEC 파일에 다음 행을 포함합니다.

    %global <name>[(opts)] <body>

<body> 주변의 모든 공백이 제거됩니다. 이름은 영숫자로 구성될 수 있으며 문자 _ 문자는 3자 이상이어야 합니다. (opts) 필드를 포함하는 것은 선택 사항입니다.

  • 간단한 매크로에는 (opts) 필드가 포함되어 있지 않습니다. 이 경우 재귀적 매크로 확장만 수행됩니다.
  • Parametrized 매크로에는 (opts) 필드가 포함되어 있습니다. 괄호 사이에 선택 문자열은 매크로 호출 시작 시 argc/argv 처리를 위해 getopt(3) 에 전달됩니다.
참고

이전 RPM SPEC 파일은 대신 %define <name> <body> 매크로 패턴을 사용합니다. %define%global 매크로의 차이점은 다음과 같습니다.

  • %define 에는 지역 범위가 있습니다. 이는 SPEC 파일의 특정 부분에 적용됩니다. %define 매크로의 본문은 사용 시 확장 됩니다.
  • %global 에는 전역 범위가 있습니다. 이는 전체 SPEC 파일에 적용됩니다. %global 매크로의 본문은 정의 시간에 확장됩니다.
중요

매크로는 주석 처리된 경우에도 평가되거나 매크로의 이름이 SPEC 파일의 %changelog 섹션에 지정됩니다. 매크로를 주석 처리하려면 %% 를 사용합니다. 예: %%global.

추가 리소스

4.2.2. %setup 매크로 사용

이 섹션에서는 %setup 매크로의 다양한 변형을 사용하여 소스 코드 tarball을 사용하여 패키지를 빌드하는 방법을 설명합니다. 매크로 변형을 결합할 수 있습니다. rpmbuild 출력은 %setup 매크로의 표준 동작을 보여줍니다. 각 단계가 시작될 때 매크로는 Executing(%…​)을 출력합니다.) 는 아래 예와 같이 입니다.

예 4.1. %setup 매크로 출력 예

Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.DhddsG

쉘 출력은 set -x enabled로 설정됩니다. /var/tmp/rpm-tmp.DhddsG 의 내용을 보려면 rpmbuild 가 빌드 후 임시 파일을 삭제하므로 --debug 옵션을 사용합니다. 그러면 환경 변수 설정이 표시된 다음 예를 들면 다음과 같습니다.

cd '/builddir/build/BUILD'
rm -rf 'cello-1.0'
/usr/bin/gzip -dc '/builddir/build/SOURCES/cello-1.0.tar.gz' | /usr/bin/tar -xof -
STATUS=$?
if [ $STATUS -ne 0 ]; then
  exit $STATUS
fi
cd 'cello-1.0'
/usr/bin/chmod -Rf a+rX,u+w,g-w,o-w .

%setup 매크로:

  • 올바른 디렉터리에서 작동하는지 확인합니다.
  • 이전 빌드의 남은 부분을 제거합니다.
  • 소스 tarball의 압축을 풉니다.
  • 몇 가지 기본 권한을 설정합니다.

4.2.2.1. %setup -q 매크로 사용

-q 옵션은 %setup 매크로의 상세 수준을 제한합니다. tar -xvvof 대신 tar -xof 만 실행됩니다. 첫 번째 옵션으로 이 옵션을 사용합니다.

4.2.2.2. %setup -n 매크로 사용

n 옵션은 확장된 tarball의 디렉터리 이름을 지정하는 데 사용됩니다.

이는 확장된 tarball의 디렉터리가 예상 것과 다른 이름(%{name}-%{version})과 다른 이름이 있어 %setup 매크로의 오류로 이어질 수 있는 경우에 사용됩니다.

예를 들어 패키지 이름이 cello 이지만 소스 코드가 hello-1.0.tgz 에 보관되고 hello/ 디렉터리가 포함된 경우 SPEC 파일 콘텐츠는 다음과 같아야 합니다.

Name: cello
Source0: https://example.com/%{name}/release/hello-%{version}.tar.gz
…
%prep
%setup -n hello

4.2.2.3. %setup -c 매크로 사용

소스 코드 tarball에 하위 디렉터리가 포함되어 있지 않고 압축을 푼 후 아카이브의 파일이 현재 디렉터리를 채우는 경우 -c 옵션이 사용됩니다.

그런 다음 -c 옵션은 다음과 같이 디렉터리 및 단계를 아카이브 확장에 생성합니다.

/usr/bin/mkdir -p cello-1.0
cd 'cello-1.0'

아카이브 확장 후에는 디렉터리가 변경되지 않습니다.

4.2.2.4. %setup -D 및 %setup -T 매크로 사용

-D 옵션은 소스 코드 디렉터리 삭제를 비활성화하고 %setup 매크로가 여러 번 사용되는 경우 특히 유용합니다. d 옵션을 사용하면 다음 행이 사용되지 않습니다.

rm -rf 'cello-1.0'

-T 옵션은 스크립트에서 다음 행을 제거하여 소스 코드 tarball 확장을 비활성화합니다.

/usr/bin/gzip -dc '/builddir/build/SOURCES/cello-1.0.tar.gz' | /usr/bin/tar -xvvof -

4.2.2.5. %setup -a 및 %setup -b 매크로 사용

a 및 - b 옵션은 특정 소스를 확장합니다.

b 옵션 은 이전을 나타내며 작업 디렉터리를 입력하기 전에 특정 소스를 확장합니다. a 옵션은 를 나타내며, 입력한 후 해당 소스를 확장합니다. 해당 인수는 SPEC 파일의 소스 번호입니다.

다음 예에서 cello-1.0.tar.gz 아카이브에는 빈 예제 디렉터리가 포함되어 있습니다. 예제는 별도의 examples.tar.gz tarball에 포함되어 있으며 동일한 이름의 디렉토리로 확장됩니다. 이 경우 작업 디렉터리를 입력한 후 Source1 을 확장하려면 -a 1 을 사용합니다.

Source0: https://example.com/%{name}/release/%{name}-%{version}.tar.gz
Source1: examples.tar.gz
…
%prep
%setup -a 1

다음 예에서 예제는 cello-1.0/examples 로 확장되는 별도의 cello-1.0-examples.tar.gz tarball에 제공되어 있습니다. 이 경우 작업 디렉터리를 입력하기 전에 -b 1 을 사용하여 Source1 을 확장합니다.

Source0: https://example.com/%{name}/release/%{name}-%{version}.tar.gz
Source1: %{name}-%{version}-examples.tar.gz
…
%prep
%setup -b 1

4.2.3. %files 섹션의 공통 RPM 매크로

다음 표에는 SPEC 파일의 %files 섹션에 필요한 고급 RPM 매크로가 나열되어 있습니다.

표 4.1. %files 섹션의 고급 RPM 매크로

macro정의

% license

매크로는 LICENSE 파일로 나열된 파일을 식별하며 RPM과 같이 설치 및 레이블이 지정됩니다. 예: % license LICENSE

%doc

매크로는 문서로 나열된 파일을 식별하며 RPM과 같이 설치 및 레이블이 지정됩니다. 매크로는 패키지된 소프트웨어에 대한 문서 및 코드 예제 및 다양한 관련 항목에도 사용됩니다. 코드 예제가 포함된 경우 파일에서 실행 모드를 제거하려면 주의해야 합니다. 예: %doc README

%dir

매크로를 사용하면 경로가 이 RPM이 소유한 디렉터리임을 확인할 수 있습니다. RPM 파일 매니페스트에서 설치 제거할 디렉토리를 정확하게 파악할 수 있도록 하는 것이 중요합니다. 예: %dir %{_libdir}/%{name}

%config(noreplace)

매크로를 사용하면 다음 파일이 구성 파일이므로 원래 설치 체크섬에서 파일이 수정된 경우 패키지 설치 또는 업데이트에서 덮어 쓰기(또는 교체)해서는 안 됩니다. 변경이 있는 경우 업그레이드 시 파일 이름 끝에 .rpmnew 를 추가하여 파일이 생성되어 대상 시스템의 기존 또는 수정된 파일이 수정되지 않도록 합니다. 예: %config(noreplace) %{_sysconfdir}/%{name}/%{name}.conf

4.2.4. 내장 매크로 표시

Red Hat Enterprise Linux는 여러 개의 내장 RPM 매크로를 제공합니다.

절차

  1. 기본 제공 RPM 매크로를 모두 표시하려면 다음을 실행합니다.

    rpm --showrc
    참고

    출력은 매우 크기 조정 가능합니다. 결과를 좁히려면 위의 명령을 grep 명령과 함께 사용합니다.

  2. 시스템 RPM 버전의 RPM에 대한 RPM에 대한 정보를 찾으려면 다음을 실행합니다.

    rpm -ql rpm
    참고

    RPM 매크로는 출력 디렉토리 구조에서 매크로 라는 이름의 파일입니다.

4.2.5. RPM 배포 매크로

다른 배포에서는 패키지화된 소프트웨어의 언어 구현 또는 배포의 특정 지침에 따라 다양한 권장 RPM 매크로 세트를 제공합니다.

권장되는 RPM 매크로 세트는 종종 RPM 패키지로 제공되며 yum 패키지 관리자와 함께 설치할 수 있습니다.

설치한 후 매크로 파일은 /usr/lib/rpm/macros.d/ 디렉토리에서 찾을 수 있습니다.

절차

  • 원시 RPM 매크로 정의를 표시하려면 다음을 실행합니다.

    rpm --showrc

위의 출력에는 원시 RPM 매크로 정의가 표시됩니다.

  • 매크로가 수행하는 작업과 RPM을 패키징할 때 도움이 되는 방법을 확인하려면 인수로 사용되는 매크로 이름으로 rpm --eval 명령을 실행합니다.

    rpm --eval %{_MACRO}

추가 리소스

  • RPM 도움말 페이지

4.2.6. 사용자 정의 매크로 생성

사용자 지정 매크로를 사용하여 ~/.rpmmacros 파일에서 배포 매크로를 재정의할 수 있습니다. 변경 사항은 시스템의 모든 빌드에 영향을 미칩니다.

주의

~/.rpmmacros 파일에서 새 매크로를 정의하는 것은 권장되지 않습니다. 이러한 매크로는 다른 시스템에는 존재하지 않으며, 사용자는 패키지를 다시 빌드하려고 할 수 있습니다.

절차

  • 매크로를 재정의하려면 다음을 실행합니다.

    %_topdir /opt/some/working/directory/rpmbuild

rpmdev-setuptree 유틸리티를 통해 모든 하위 디렉터리를 포함하여 위 예제에서 디렉터리를 생성할 수 있습니다. 이 매크로의 값은 기본적으로 ~/rpmbuild 입니다.

%_smp_mflags -l3

위의 매크로는 대부분 Makefile에 전달하는 데 사용됩니다(예: %{?_smp_mflags}, 빌드 단계에서 여러 개의 동시 프로세스 설정). 기본적으로 -jX 로 설정됩니다. 여기서 X 는 여러 코어입니다. 코어 수를 변경하면 패키지 빌드 속도를 높이거나 느려질 수 있습니다.

4.3. epoch, Scriptlets 및 Triggers

이 섹션에서는 RMP SPEC파일의 고급 지시문을 나타내는 스크립트릿, 트리거 및 트리거에 대해 설명합니다.

이러한 모든 지시문은 SPEC 파일뿐만 아니라 결과 RPM이 설치된 최종 시스템에도 영향을 미칩니다.

4.3.1. Epoch 지시문

Epoch 지시문을 사용하면 버전 번호에 따라 가중치 종속 항목을 정의할 수 있습니다.

이 지시문이 RPM SPEC 파일에 나열되지 않으면 Epoch 지시문이 전혀 설정되지 않습니다. 이는 Epoch를 설정하지 않으면 0의 Epoch 가 되는 일반적인 신뢰와 다릅니다. 그러나 yum 유틸리티는 탈락 방지를 위해 0의 Epoch 와 동일하게 설정되지 않은 Epoch 를 처리합니다.

그러나 SPEC 파일에 Epoch 를 나열하는 것은 일반적으로 생략됩니다. 대부분의 경우 패키지 버전을 비교할 때 Epoch 값이 예상되는 RPM 동작을 유발하기 때문입니다.

예 4.2. Epoch 사용

Epoch를 사용하여 foobar 패키지를 설치하는 경우: 1Version: 1.0, 및 다른 사용자가 Version을 사용하여 foobar 를 패키징합니다. 2.0 하지만 Epoch 지시문이 없으면 새 버전이 업데이트되지 않습니다. Epoch 버전이 RPM 패키지에 대한 버전 관리를 나타내는 기존 Name-Version-Release 마커보다 우선하기 때문입니다.

따라서 Epoch 를 사용하는 것은 매우 드물다. 그러나 Epoch 는 일반적으로 업그레이드 순서 문제를 해결하는 데 사용됩니다. 이 문제는 인코딩에 따라 항상 안정적으로 비교할 수 없는 알파벳 문자를 포함하는 소프트웨어 버전 번호 체계 또는 버전의 업스트림 변경의 측면으로 나타날 수 있습니다.

4.3.2. scriptlets 지시문

scriptlets 는 패키지 설치 또는 삭제 전이나 후에 실행되는 일련의 RPM 지시문입니다.

빌드 시 또는 시작 스크립트에서 수행할 수 없는 작업에만 Scriptlets 를 사용합니다.

공통 scriptlet 지시문 세트가 있습니다. SPEC 파일 섹션 헤더(예: %build 또는 %install )와 유사합니다. 이는 종종 표준 POSIX 쉘 스크립트로 작성되는 코드의 여러 줄 세그먼트에 의해 정의됩니다. 그러나 대상 시스템의 배포를 위해 RPM이 허용하는 다른 프로그래밍 언어로도 작성할 수 있습니다. RPM 문서에는 사용 가능한 언어의 전체 목록이 포함되어 있습니다.

다음 표에는 실행 순서에 나열된 Scriptlet 지시문이 포함되어 있습니다. 스크립트가 포함된 패키지가 %pre%post un 지시문 사이에 설치되고 %preun%postun 지시문 사이에 제거됩니다.

표 4.2. Scriptlet 지시문

directive정의

%pretrans

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

%pre

대상 시스템에 패키지를 설치하기 직전에 실행되는 Scriptlet입니다.

%post

대상 시스템에 패키지를 설치한 후에만 실행되는 Scriptlet입니다.

%preun

대상 시스템에서 패키지를 설치 제거하기 직전에 실행되는 Scriptlet입니다.

%postun

대상 시스템에서 패키지를 제거한 후에 실행되는 Scriptlet입니다.

%posttrans

트랜잭션 종료 시 실행되는 Scriptlet입니다.

4.3.3. scriptlet 실행 비활성화

다음 절차에서는 rpm 명령을 --no_scriptlet_name_ 옵션과 함께 사용하여 스크립트 파일의 실행을 끄는 방법을 설명합니다.

절차

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

    # rpm --nopretrans

    다음 모든 항목과 동일한 --noscripts 옵션을 사용할 수도 있습니다.

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

추가 리소스

  • RPM(8) 도움말 페이지.

4.3.4. scriptlets 매크로

Scriptlets 지시문도 RPM 매크로에서 작동합니다.

다음 예제에서는 systemd에 새 장치 파일에 대해 알림을 받는 systemd scriptlet 매크로를 사용하는 방법을 보여줍니다.

$ rpm --showrc | grep systemd
-14: __transaction_systemd_inhibit      %{__plugindir}/systemd_inhibit.so
-14: _journalcatalogdir /usr/lib/systemd/catalog
-14: _presetdir /usr/lib/systemd/system-preset
-14: _unitdir   /usr/lib/systemd/system
-14: _userunitdir       /usr/lib/systemd/user
/usr/lib/systemd/systemd-binfmt %{?*} >/dev/null 2>&1 || :
/usr/lib/systemd/systemd-sysctl %{?*} >/dev/null 2>&1 || :
-14: systemd_post
-14: systemd_postun
-14: systemd_postun_with_restart
-14: systemd_preun
-14: systemd_requires
Requires(post): systemd
Requires(preun): systemd
Requires(postun): systemd
-14: systemd_user_post  %systemd_post --user --global %{?*}
-14: systemd_user_postun        %{nil}
-14: systemd_user_postun_with_restart   %{nil}
-14: systemd_user_preun
systemd-sysusers %{?*} >/dev/null 2>&1 || :
echo %{?*} | systemd-sysusers - >/dev/null 2>&1 || :
systemd-tmpfiles --create %{?*} >/dev/null 2>&1 || :

$ rpm --eval %{systemd_post}

if [ $1 -eq 1 ] ; then
        # Initial installation
        systemctl preset  >/dev/null 2>&1 || :
fi

$ rpm --eval %{systemd_postun}

systemctl daemon-reload >/dev/null 2>&1 || :

$ rpm --eval %{systemd_preun}

if [ $1 -eq 0 ] ; then
        # Package removal, not upgrade
        systemctl --no-reload disable  > /dev/null 2>&1 || :
        systemctl stop  > /dev/null 2>&1 || :
fi

4.3.5. Triggers 지시문

Trigger 는 패키지 설치 및 제거 중에 상호 작용 방법을 제공하는 RPM 지시문입니다.

주의

트리거 는 예기치 않은 시간에 실행될 수 있습니다(예: 포함된 패키지의 업데이트). 트리거 는 디버그하기 어렵기 때문에 예기치 않게 실행될 때 아무 것도 손상시키지 않도록 강력한 방식으로 구현해야 합니다. 이러한 이유로 Red Hat은 트리거 사용을 최소화할 것을 권장합니다.

단일 패키지 업그레이드에 대한 실행 순서와 각 기존 트리거에 대한 세부 정보는 다음과 같습니다.

all-%pretrans
…​
any-%triggerprein (%triggerprein from other packages set off by new install)
new-%triggerprein
new-%pre      for new version of package being installed
…​           (all new files are installed)
new-%post     for new version of package being installed

any-%triggerin (%triggerin from other packages set off by new install)
new-%triggerin
old-%triggerun
any-%triggerun (%triggerun from other packages set off by old uninstall)

old-%preun    for old version of package being removed
…​           (all old files are removed)
old-%postun   for old version of package being removed

old-%triggerpostun
any-%triggerpostun (%triggerpostun from other packages set off by old un
            install)
…​
all-%posttrans

위의 항목은 /usr/share/doc/rpm-4.*/triggers 파일에서 찾을 수 있습니다.

4.3.6. SPEC 파일에서 쉘이 아닌 스크립트 사용

SPEC 파일의 -p scriptlet 옵션을 사용하면 사용자가 기본 쉘 스크립트 인터프리터(-p /bin/sh) 대신 특정 인터프리터를 호출할 수 있습니다.

다음 절차에서는 pello.py 프로그램 설치 후 메시지를 출력하는 스크립트를 생성하는 방법을 설명합니다.

절차

  1. pello.spec 파일을 엽니다.
  2. 다음 행을 찾으십시오.

    install -m 0644 %{name}.py* %{buildroot}/usr/lib/%{name}/
  3. 위 줄 아래에 다음을 삽입합니다.

    %post -p /usr/bin/python3
    print("This is {} code".format("python"))
  4. RPM 구축에 설명된 대로 패키지를 빌드합니다.
  5. 패키지를 설치합니다.

    # yum install /home/<username>/rpmbuild/RPMS/noarch/pello-0.1.2-1.el8.noarch.rpm
  6. 설치 후 출력 메시지를 확인합니다.

    Installing       : pello-0.1.2-1.el8.noarch                              1/1
    Running scriptlet: pello-0.1.2-1.el8.noarch                              1/1
    This is python code
참고

Python 3 스크립트를 사용하려면 SPEC 파일에 install -m 아래에 다음 행을 추가하십시오.

%post -p /usr/bin/python3

Lua 스크립트를 사용하려면 SPEC 파일에 install -m 아래에 다음 행을 추가하십시오.

%post -p <lua>

이렇게 하면 SPEC 파일에서 인터프리터를 지정할 수 있습니다.

4.4. RPM 조건

RPM 조건을 사용하면 SPEC 파일의 다양한 섹션을 조건부로 포함할 수 있습니다.

조건부 포함은 일반적으로 다음을 처리합니다.

  • 아키텍처별 섹션
  • 운영 체제별 섹션
  • 다양한 버전의 운영 체제 간 호환성 문제
  • 매크로의 존재 및 정의

4.4.1. RPM 조건 구문

RPM 조건에서는 다음 구문을 사용합니다.

expression 이 true이면 몇 가지 작업을 수행합니다.

%if expression
…​
%endif

expression 이 true이면 다른 작업을 수행하는 경우 다른 작업을 수행합니다.

%if expression
…​
%else
…​
%endif

4.4.2. %if 조건

이 섹션에서는 %if RPM 조건을 사용하는 방법을 보여줍니다.

예 4.3. %if 조건부를 사용하여 Red Hat Enterprise Linux 8과 기타 운영 체제 간의 호환성 처리

%if 0%{?rhel} == 8
sed -i '/AS_FUNCTION_DESCRIBE/ s/^/#/' configure.in
sed -i '/AS_FUNCTION_DESCRIBE/ s/^/#/' acinclude.m4
%endif

이 조건부는 AS_FUNCTION_DESCRIBE 매크로를 지원하는 측면에서 RHEL 8과 기타 운영 체제 간의 호환성을 처리합니다. RHEL용으로 패키지를 빌드하면 %rhel 매크로가 정의되고 RHEL 버전으로 확장됩니다. 해당 값이 8이므로 패키지가 RHEL 8에 대한 빌드인 경우 RHEL 8에서 지원하지 않는 AS_FUNCTION_DESCRIBE에 대한 참조가 autoconfig 스크립트에서 삭제됩니다.

예 4.4. %if 조건부를 사용하여 매크로 정의 처리

%define ruby_archive %{name}-%{ruby_version}
%if 0%{?milestone:1}%{?revision:1} != 0
%define ruby_archive %{ruby_archive}-%{?milestone}%{?!milestone:%{?revision:r%{revision}}}
%endif

이 조건부는 매크로의 정의를 처리합니다. %milestone 또는 %revision 매크로가 설정된 경우 업스트림 tarball의 이름을 정의하는 %ruby_archive 매크로가 다시 정의됩니다.

4.4.3. %if 조건의 특수 변형

%ifarch 조건, %ifnarch 조건, %ifnarch 조건부 및 %ifos 조건은 %if 조건의 특수 변형입니다. 이러한 변형은 일반적으로 사용되며, 따라서 자체 매크로가 있습니다.

%ifarch 조건

%ifarch 조건부는 아키텍처별 SPEC 파일 블록을 시작하는 데 사용됩니다. 그런 다음 각각 쉼표 또는 공백으로 구분된 하나 이상의 아키텍처 분류자가 뒤에 옵니다.

예 4.5. %ifarch 조건을 사용하는 예

%ifarch i386 sparc
…​
%endif

%ifarch%endif 사이의 SPEC 파일의 모든 내용은 32비트 AMD 및 Intel 아키텍처 또는 Sunmtls 기반 시스템에서만 처리됩니다.

%ifnarch 조건

%ifnarch 조건부에는 %ifarch 조건보다 역방향 논리가 있습니다.

예 4.6. %ifnarch 조건을 사용하는 예

%ifnarch alpha
…​
%endif

%ifnarch%endif 사이의 SPEC 파일의 모든 내용은 Digital Alpha/AXP 기반 시스템에서 수행되지 않은 경우에만 처리됩니다.

%ifos 조건

%ifos 조건부는 빌드의 운영 체제에 따라 처리를 제어하는 데 사용됩니다. 한 개 이상의 운영 체제 이름을 뒤에 넣을 수 있습니다.

예 4.7. %ifos 조건 사용 예

%ifos linux
…​
%endif

%ifos%endif 간 SPEC 파일의 모든 내용은 Linux 시스템에서 빌드가 수행된 경우에만 처리됩니다.

4.5. Python 3 RPM 패키지

대부분의 Python 프로젝트는 패키징을 위해 Setuptools를 사용하고 setup.py 파일에 패키지 정보를 정의합니다. Setuptools 패키지에 대한 자세한 내용은 Setuptools 설명서 를 참조하십시오.

Python 프로젝트를 RPM 패키지로 패키징할 수도 있습니다. 이 패키지는 Setuptools 패키징에 비해 다음과 같은 이점을 제공합니다.

  • 다른 RPM에 대한 패키지의 종속 항목 사양 (Python이 아닌)
  • 암호화 서명

    암호화 서명을 사용하면 RPM 패키지의 콘텐츠를 다른 운영 체제와 함께 확인, 통합 및 테스트할 수 있습니다.

4.5.1. Python 패키지에 대한 SPEC 파일 설명

SPEC 파일에는 rpmbuild 유틸리티에서 RPM을 빌드하는 데 사용하는 지침이 포함되어 있습니다. 지침은 일련의 섹션에 포함되어 있습니다. SPEC 파일에는 섹션이 정의된 두 가지 주요 부분이 있습니다.

  • Preamble (본문에 사용되는 일련의 메타데이터 항목 포함)
  • 본문 (명령어의 주요 부분을 포함)

Python 프로젝트용 RPM SPEC 파일에는 Python RPM SPEC 파일에 비해 몇 가지 특정 사항이 있습니다. 특히 Python 라이브러리의 RPM 패키지 이름에 항상 버전을 결정하는 접두사(예: python3 for Python 3.6, python38 for Python 3.8, Python 3.9용 python 39)가 포함되어야 합니다.

기타 세부 사항은 python3-detox 패키지에 대한 다음 SPEC 파일 예에 나와 있습니다. 이러한 세부 사항에 대한 자세한 내용은 예제 아래에 있는 노트를 참조하십시오.

%global modname detox                                                           1

Name:           python3-detox                                                   2
Version:        0.12
Release:        4%{?dist}
Summary:        Distributing activities of the tox tool
License:        MIT
URL:            https://pypi.io/project/detox
Source0:        https://pypi.io/packages/source/d/%{modname}/%{modname}-%{version}.tar.gz

BuildArch:      noarch

BuildRequires:  python36-devel                                                  3
BuildRequires:  python3-setuptools
BuildRequires:  python36-rpm-macros
BuildRequires:  python3-six
BuildRequires:  python3-tox
BuildRequires:  python3-py
BuildRequires:  python3-eventlet

%?python_enable_dependency_generator                                            4

%description

Detox is the distributed version of the tox python testing tool. It makes efficient use of multiple CPUs by running all possible activities in parallel.
Detox has the same options and configuration that tox has, so after installation you can run it in the same way and with the same options that you use for tox.

    $ detox

%prep
%autosetup -n %{modname}-%{version}

%build
%py3_build                                                                      5

%install
%py3_install

%check
%{__python3} setup.py test                                                      6

%files -n python3-%{modname}
%doc CHANGELOG
%license LICENSE
%{_bindir}/detox
%{python3_sitelib}/%{modname}/
%{python3_sitelib}/%{modname}-%{version}*

%changelog
...
1
modname 매크로에는 Python 프로젝트의 이름이 포함되어 있습니다. 이 예에서는 detox 입니다.
2
Python 프로젝트를 RPM에 패키징할 때 python3 접두사를 항상 프로젝트의 원래 이름에 추가해야 합니다. 원래 이름은 detox 이고 RPM의 이름은 python3-detox 입니다.
3
BuildRequires 는 이 패키지를 빌드하고 테스트하는 데 필요한 패키지를 지정합니다. BuildRequires에는 항상 Python 패키지( python36-develpython3-setuptools )를 빌드하는 데 필요한 툴을 제공하는 항목이 포함되어 있습니다. /usr/bin/python3 인터프리터 지시문이 있는 파일이 자동으로 /usr/bin/python3.6 으로 변경되도록 python36-rpm-macros 패키지가 필요합니다.
4
모든 Python 패키지는 제대로 작동하기 위해 다른 패키지가 필요합니다. 이러한 패키지도 SPEC 파일에서 지정해야 합니다. 종속 항목을 지정하려면 %python_enable_dependency_generator 매크로를 사용하여 setup.py 파일에 정의된 종속성을 자동으로 사용할 수 있습니다. 패키지에 Setuptools를 사용하여 지정되지 않은 종속 항목이 있는 경우 추가 Requires 지시문으로 지정합니다.
5
%py3_build%py3_install 매크로는 각각 setup.py buildsetup.py install 명령을 실행하여 설치 위치를 지정하는 추가 인수, 사용할 인터프리터 및 기타 세부 정보를 제공합니다.
6
확인 섹션에서는 Python의 올바른 버전을 실행하는 매크로를 제공합니다. %{__python3} 매크로에는 Python 3 인터프리터의 경로가 포함되어 있습니다(예: /usr/bin/python3 ). 항상 리터럴 경로가 아닌 매크로를 사용하는 것이 좋습니다.

4.5.2. Python 3 RPM용 공통 매크로

SPEC 파일에서 항상 값을 하드 코딩하지 않고 다음 Macros for Python 3 RPMs 테이블에 설명된 매크로를 사용합니다.

매크로 이름에서 버전이 없는 python 대신 항상 python3 또는 python2 를 사용합니다. SPEC 파일의 BuildRequires of the SPEC 파일에서 python36-rpm-macros,python38-rpm-macros 또는 python39-rpm-macros.

표 4.3. Python 3 RPM용 매크로

macro일반 정의설명

%{__python3}

/usr/bin/python3

Python 3 인터프리터

%{python3_version}

3.6

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

%{python3_sitelib}

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

여기서 pure-Python 모듈이 설치됩니다.

%{python3_sitearch}

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

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

%py3_build

 

시스템 패키지에 적합한 인수를 사용하여 setup.py build 명령을 실행합니다.

%py3_install

 

시스템 패키지에 적합한 인수를 사용하여 setup.py install 명령을 실행합니다.

4.5.3. Python RPM에 자동 제공

Python 프로젝트를 패키징할 때 이러한 디렉터리가 있는 경우 결과 RPM에 다음 디렉터리가 포함되어 있는지 확인합니다.

  • .dist-info
  • .egg-info
  • .egg-link

이러한 디렉토리에서 RPM 빌드 프로세스는 가상 pythonX.Ydist 를 자동으로 생성합니다(예: python3.6dist(detox) ). 이러한 가상은 %python_enable_dependency_generator 매크로에 의해 지정된 패키지에서 사용됩니다.

4.6. Python 스크립트에서 인터프리터 지시문 처리

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

#!/usr/bin/python3
#!/usr/bin/python3.6
#!/usr/bin/python2

RPM 패키지를 빌드할 때 /usr/lib/rpm/redhat/brp-mangle-shebangs BRP(Buildroot 정책) 스크립트가 자동으로 실행되고 모든 실행 파일에서 인터프리터 지시문을 수정하려고 합니다.

BRP 스크립트는 다음과 같은 모호한 인터프리터 지시문을 사용하여 Python 스크립트가 발생할 때 오류를 생성합니다.

#!/usr/bin/python

또는

#!/usr/bin/env python

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

RPM 빌드 시 빌드 오류를 유발하는 Python 스크립트의 인터프리터 지시문을 수정합니다.

사전 요구 사항

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

절차

인터프리터 지시문을 수정하려면 다음 작업 중 하나를 완료합니다.

  • platform-python-devel 패키지에서 pathfix.py 스크립트를 적용합니다.

    # pathfix.py -pn -i %{__python3} PATH …​

    여러 개의 PATHs 를 지정할 수 있습니다. PATH 가 디렉터리인 경우 pathfix.py 는 모호한 인터프리터 지시문이 있는 뿐만 아니라 ^[a-zA-Z0-9_]+\.py$ 패턴과 일치하는 Python 스크립트를 반복적으로 스캔합니다. %prep 섹션 또는 %install 섹션의 끝에 이 명령을 추가합니다.

  • 패키지된 Python 스크립트가 예상 형식을 준수하도록 수정합니다. 이를 위해 pathfix.py 는 RPM 빌드 프로세스 외부에서도 사용할 수 있습니다. RPM 빌드 외부에서 pathfix.py 를 실행하는 경우 위의 예에서 %{__python3}/usr/bin/python3 과 같은 인터프리터 지시문의 경로로 바꿉니다.

패키지된 Python 스크립트에 Python 3.6 이외의 버전이 필요한 경우 필요한 버전을 포함하도록 이전 명령을 조정합니다.

4.6.2. 사용자 정의 패키지에서 /usr/bin/python3 인터프리터 지시문 변경

기본적으로 /usr/bin/python3 형식의 인터프리터 지시문은 Red Hat Enterprise Linux가 있는 시스템 툴에 사용되는 platform-python 패키지에서 Python을 가리키는 인터프리터 지시문으로 교체됩니다. 사용자 지정 패키지의 /usr/bin/python3 인터프리터 지시문을 변경하여 AppStream 리포지토리에서 설치한 특정 Python 버전을 가리킬 수 있습니다.

절차

  • 특정 Python 버전에 대한 패키지를 빌드하려면 해당 python 패키지의 python*-rpm-macros 하위 패키지를 SPEC 파일의 BuildRequires 섹션에 추가합니다. 예를 들어 Python 3.6의 경우 다음 행을 포함합니다.

    BuildRequires:  python36-rpm-macros

    결과적으로 사용자 지정 패키지의 /usr/bin/python3 인터프리터 지시문이 자동으로 /usr/bin/python3.6 으로 변환됩니다.

참고

BRP 스크립트가 인터프리터 지시문을 확인 및 수정하지 못하도록 하려면 다음 RPM 지시문을 사용합니다.

%undefine __brp_mangle_shebangs

4.7. RubyGems 패키지

이 섹션에서는 RubyGems 패키지가 무엇인지, 그리고 RPM으로 다시 패키징하는 방법에 대해 설명합니다.

4.7.1. RubyGems의 정의

Ruby는 동적, 해석, 반사, 객체 지향, 일반 목적의 프로그래밍 언어입니다.

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

RubyGems에서 만든 패키지는 gems라고 하며 RPM으로도 다시 패키징할 수 있습니다.

참고

이 문서는 gem 접두사와 함께 RubyGems 개념과 관련된 용어(예: .gemspec)는 gem 사양에 사용되며 RPM 관련 용어는 정규화되지 않습니다.

4.7.2. RubyGems의 RPM 관련 방법

RubyGems는 Ruby의 자체 패키징 형식을 나타냅니다. 그러나 RubyGems에는 RPM에 필요한 메타데이터가 포함되어 있으며 RubyGems에서 RPM으로 변환할 수 있습니다.

Ruby Packaging guidelines 에 따르면 RubyGems 패키지를 RPM으로 다시 패키징할 수 있습니다.

  • 이러한 RPM은 나머지 배포에 적합합니다.
  • 최종 사용자는 적절한 RPM 패키지 gem을 설치하여 gem의 종속성을 충족할 수 있습니다.

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

나머지 RHEL RPM 배포에 적합하려면 RubyGems에서 생성한 패키지는 아래 나열된 규칙을 따라야 합니다.

  • gems의 이름은 다음 패턴을 따라야 합니다.

    rubygem-%{gem_name}
  • shebang 라인을 구현하려면 다음 문자열을 사용해야 합니다.

    #!/usr/bin/ruby

4.7.3. RubyGems 패키지에서 RPM 패키지 생성

RubyGems 패키지에 대한 소스 RPM을 만들려면 다음 파일이 필요합니다.

  • gem 파일
  • RPM SPEC 파일

다음 섹션에서는 RubyGems에서 만든 패키지에서 RPM 패키지를 만드는 방법에 대해 설명합니다.

4.7.3.1. RubyGems SPEC 파일 규칙

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

  • gem의 사양의 이름인 %{gem_name} 를 포함합니다.
  • 패키지 소스는 릴리스된 gem 아카이브에 대한 전체 URL이어야 합니다. 패키지 버전은 gem의 버전이어야 합니다.
  • 빌드에 필요한 매크로를 가져올 수 있도록 다음과 같이 정의된 지시문인 BuildRequires 가 포함되어 있습니다.

    BuildRequires:rubygems-devel
  • RubyGems Requires 또는 Provides 가 자동으로 생성되기 때문에 포함되어 있지 않습니다.
  • Ruby 버전 호환성을 명시적으로 지정하지 않으려면 다음과 같이 정의된 BuildRequires: 지시문을 포함하지 않습니다.

    Requires: ruby(release)

    RubyGems에 자동으로 생성된 종속성(필수: ruby(rubygems))이면 충분합니다.

4.7.3.2. RubyGems 매크로

다음 표에는 RubyGems에서 만든 패키지에 유용한 매크로가 나열되어 있습니다. 이러한 매크로는 rubygems-devel 패키지에서 제공합니다.

표 4.4. 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 확장을 위한 디렉터리입니다.

4.7.3.3. RubyGems SPEC 파일 예

이 섹션에서는 특정 섹션에 대한 설명과 함께 gems를 빌드하는 데 필요한 SPEC 파일 예제를 제공합니다.

RubyGems SPEC 파일의 예

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

# Modify the gemspec if necessary
# Also apply patches to code if necessary
%patch0 -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}/

다음 표에서는 RubyGems SPEC 파일의 특정 항목에 대한 세부 사항을 설명합니다.

표 4.5. RubyGems의 SPEC 지시문 특정

SPEC 지시문RubyGems 세부 정보

%Prep

RPM은 gem 아카이브의 직접 압축을 풀 수 있으므로 gem에서 소스를 추출하기 위해 gem 압축 을 풀 수 있습니다. %setup -n %{gem_name}-%{version} 매크로는 gem의 압축을 풀 수 있는 디렉터리를 제공합니다. 동일한 디렉터리 수준에서 %{gem_name}-%{version} .gemspec 파일이 자동으로 생성됩니다. 이 파일은 나중에 gem을 다시 빌드하거나 .gemspec을 수정하거나 .gemspec을 코드에 패치를 적용하는 데 사용할 수 있습니다.

%build

이 지시문에는 소프트웨어를 머신 코드로 빌드하는 명령 또는 일련의 명령이 포함되어 있습니다. %gem_install 매크로는 gem 아카이브에서만 작동하며 gem은 다음 gem 빌드로 다시 생성됩니다. 그런 다음 %gem_install 에서 생성된 gem 파일은 기본적으로 ./%{gem_dir} 인 임시 디렉터리에 코드를 빌드하고 설치하는 데 사용됩니다. %gem_install 매크로는 한 단계로 코드를 빌드하고 설치합니다. 설치하기 전에 빌드된 소스는 자동으로 생성된 임시 디렉터리에 배치됩니다.

%gem_install 매크로는 설치에 사용되는 gem을 재정의할 수 있는 -n <gem_file>, gem 설치 대상을 재정의할 수 있는 -d <install_dir>; 이 옵션을 사용하는 것은 권장되지 않습니다.

%gem_install 매크로는 %{buildroot} 에 설치하는 데 사용해서는 안 됩니다.

%install

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

추가 리소스

4.7.3.4. gem2rpm을 사용하여 RubyGems 패키지를 RPM SPEC 파일로 변환

gem2rpm 유틸리티는 RubyGems 패키지를 RPM SPEC 파일로 변환합니다.

다음 섹션에서는 다음 방법을 설명합니다.

  • gem2rpm 유틸리티 설치
  • 모든 gem2rpm 옵션 표시
  • gem2rpm 을 사용하여 RPM SPEC 파일에 RubyGems 패키지를 포함
  • gem2rpm 템플릿 편집
4.7.3.4.1. gem2rpm 설치

다음 절차에서는 gem2rpm 유틸리티를 설치하는 방법을 설명합니다.

절차

  • RubyGems.org 에서 gem2rpm 을 설치하려면 다음을 실행합니다.
$ gem install gem2rpm
4.7.3.4.2. gem2rpm의 모든 옵션 표시

다음 절차에서는 gem2rpm 유틸리티의 모든 옵션을 표시하는 방법을 설명합니다.

절차

  • gem2rpm 의 모든 옵션을 보려면 다음을 실행합니다.

    gem2rpm --help
4.7.3.4.3. gem2rpm을 사용하여 RPM SPEC 파일에 RubyGems 패키지 포함

다음 절차에서는 gem2rpm 유틸리티를 사용하여 RPM SPEC 파일에 RubyGems 패키지를 다루는 방법을 설명합니다.

절차

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

    $ gem2rpm --fetch <gem_name> > <gem_name>.spec

설명된 프로시저는 gem의 메타데이터에 제공된 정보를 기반으로 RPM SPEC 파일을 생성합니다. 그러나 gem은 라이센스 및 변경 로그와 같은 RPM에서 일반적으로 제공되는 몇 가지 중요한 정보를 놓치고 있습니다. 따라서 생성된 SPEC 파일을 편집해야 합니다.

4.7.3.4.4. gem2rpm 템플릿

gem2rpm 템플릿은 다음 표에 나열된 변수를 포함하는 표준 임베디드 Ruby(ERB) 파일입니다.

표 4.6. gem2rpm 템플릿의 변수

Variable설명

패키지

gem의 Gem::Package 변수.

spec

gem의 Gem::Specification 변수( format.spec과 동일).

config

사양 템플릿 도우미에 사용되는 기본 매크로 또는 규칙을 재정의할 수 있는 Gem2Rpm::Configuration 변수.

runtime_dependencies

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

development_dependencies

Gem2Rpm::RpmDependencyList 변수는 패키지 개발 종속 항목 목록을 제공합니다.

테스트

Gem2Rpm::TestSuite 변수는 실행할 수 있는 테스트 프레임워크 목록을 제공합니다.

파일

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

main_files

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

doc_files

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

형식

gem의 Gem::Format 변수. 이 변수는 더 이상 사용되지 않습니다.

4.7.3.4.5. 사용 가능한 gem2rpm 템플릿 나열

다음 절차에서는 사용 가능한 모든 gem2rpm 템플릿을 나열하도록 설명합니다.

절차

  • 사용 가능한 모든 템플릿을 보려면 다음을 실행합니다.

    $ gem2rpm --templates
4.7.3.4.6. gem2rpm 템플릿 편집

생성된 SPEC 파일을 편집하는 대신 RPM SPEC 파일이 생성되는 템플릿을 편집할 수 있습니다.

gem2rpm 템플릿을 편집하려면 다음 절차를 사용하십시오.

절차

  1. 기본 템플릿을 저장합니다.

    $ gem2rpm -T > rubygem-<gem_name>.spec.template
  2. 필요에 따라 템플릿을 편집합니다.
  3. 편집된 템플릿을 사용하여 SPEC 파일을 생성합니다.

    $ gem2rpm -t rubygem-<gem_name>.spec.template <gem_name>-<latest_version.gem > <gem_name>-GEM.spec

RPM 빌드에 설명된 대로 편집된 템플릿을 사용하여 RPM 패키지를 빌드할 수 있습니다. ???

4.8. Perls 스크립트를 사용하여 RPM 패키지를 처리하는 방법

RHEL 8부터 Perl 프로그래밍 언어는 기본 buildroot에 포함되지 않습니다. 따라서 Perl 스크립트를 포함하는 RPM 패키지는 RPM SPEC 파일에서 BuildRequires: 지시문을 사용하여 Perl에 대한 종속성을 명시적으로 나타내야 합니다.

4.8.2. 특정 Perl 모듈 사용

빌드 시 특정 Perl 모듈이 필요한 경우 다음 절차를 사용하십시오.

절차

  • RPM SPEC 파일에 다음 구문을 적용합니다.

    BuildRequires: perl(MODULE)
    참고

    시간이 지남에 따라 perl 패키지로 이동할 수 있기 때문에 Perl core 모듈에도 이 구문을 적용합니다.

4.8.3. 패키지를 특정 Perl 버전으로 제한

패키지를 특정 Perl 버전으로 제한하려면 다음 절차를 따르십시오.

절차

  • RPM SPEC 파일에서 원하는 버전 제약 조건과 함께 perl(:VERSION) 종속성을 사용합니다.

    예를 들어 패키지를 Perl 버전 5.22 이상으로 제한하려면 다음을 사용합니다.

    BuildRequires: perl(:VERSION) >= 5.22
주의

epoch 번호가 포함되어 있기 때문에 perl 패키지 버전에 대한 비교를 사용하지 마십시오.

4.8.4. 패키지가 올바른 Perl 인터프리터를 사용하는지 확인

Red Hat은 완전히 호환되지 않는 여러 Perl 인터프리터를 제공합니다. 따라서 Perl 모듈을 제공하는 모든 패키지는 빌드 시 사용된 것과 동일한 Perl 인터프리터를 런타임에 사용해야 합니다.

이를 확인하려면 다음 절차를 따르십시오.

절차

  • Perl 모듈을 제공하는 모든 패키지에 대해 RPM SPEC 파일에 버전 지정된 MODULE_COMPAT Requires 를 포함합니다.

    Requires:  perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))

5장. RHEL 8의 새로운 기능

이 섹션에서는 Red Hat Enterprise Linux 7과 8 간의 RPM 패키지 변경 사항에 대해 설명합니다.

5.1. Weak 종속 항목 지원

약한 종속성Requires 지시문의 변형입니다. 이러한 변형은 virtual Provides:Epoch-Version-Release 범위 비교를 사용하여 패키지 이름과 일치합니다.

약한 종속성 에는 다음 표에 요약된 대로 두 가지 장단점(주요 및 힌트)과 두 가지 방향(전 방향 및 이전)이 있습니다.

참고

진행 방향은 Requires:.와 유사합니다. 이전 종속성 시스템은 이전 종속성 시스템에 비유되어 있지 않습니다.

표 5.1. 자주 묻는 질문 (FAQ)

power/DirectionforwardBackward

약함

권장 사항:

제품 이름:

힌트

권장 사항:

개선 사항:

Weak 종속성 정책의 주요 장점은 다음과 같습니다.

  • 기본 설치 기능을 다양하게 유지하면서 최소 설치를 줄일 수 있습니다.
  • 패키지는 가상의 유연성을 유지하면서 특정 공급자에 대한 기본 설정을 지정할 수 있습니다.

5.1.1. Weak 종속 항목 소개

기본적으로 Weak 종속성 은 일반 Requires: 와 유사하게 처리됩니다. 일치하는 패키지는 YUM 트랜잭션에 포함되어 있습니다. 패키지를 추가하면 기본적으로 YUM 에서 종속성을 무시합니다. 따라서 사용자는 Weak 종속성 에서 추가한 패키지를 제외하거나 나중에 제거할 수 있습니다.

사용 조건

패키지가 종속성 없이 계속 작동하는 경우에만 Weak 종속성 을 사용할 수 있습니다.

참고

약한 요구 사항을 추가하지 않고 기능이 매우 제한된 패키지를 만들 수 있습니다.

사용 사례

Weak 종속성 은 특히 패키지의 전체 기능 세트가 필요하지 않은 가상 머신 또는 컨테이너 빌드와 같은 적절한 사용 사례에 대한 설치를 최소화할 수 있는 경우 특히 사용합니다.

Weak 종속성 의 일반적인 사용 사례는 다음과 같습니다.

  • 문서

    • 누락된 경우 문서 뷰어가 정상적으로 처리됩니다.
  • 플러그인 또는 애드온

    • 파일 형식 지원
    • 프로토콜 지원

5.1.2. 힌트의 강점

힌트는 YUM 에서 기본적으로 무시합니다. GUI 도구에서 기본적으로 설치되지 않은 애드온 패키지를 제공하는 데 사용할 수 있지만 설치된 패키지와 함께 유용할 수 있습니다.

패키지 의 주요 사용 사례의 요구 사항에 힌트 를 사용하지 마십시오. 대신 이러한 요구 사항을 강력하거나 Weak 종속성 에 포함합니다.

패키지 환경 설정

YUMWeak 종속성힌트 를 사용하여 여러 개의 동일한 유효한 패키지를 선택할지 여부를 결정합니다. 설치된 패키지 또는 설치된 패키지의 종속성에 의해 가리키는 패키지가 우선합니다.

참고: 종속성 확인의 일반적인 규칙은 이 기능의 영향을 받지 않습니다. 예를 들어 Weak 종속성 은 선택한 이전 버전의 패키지를 적용할 수 없습니다.

종속성에 대한 공급자가 여러 개인 경우 require 패키지에서 Suggests 를 추가하여 옵션이 우선하는 종속성 확인기에 힌트를 제공할 수 있습니다.

enhances: 기본 패키지와 기타 공급자가 필요한 패키지에 힌트를 추가하는 데 동의한 경우에만 사용됩니다.

예 5.1. Hints를 사용하여 한 패키지를 다른 패키지 선호

Package A: Requires: mysql

Package mariadb: Provides: mysql

Package community-mysql: Provides: mysql

community-mysql 패키지를 통해 mariadb 패키지를 선호하는 경우 다음을 사용합니다.

Suggests: mariadb to Package A.

5.1.3. forward 및 Backward 종속 항목

전달 종속성 은 설치 중인 패키지에 대해 평가되는 Requires 와 유사하게 입니다. 일치하는 최상의 패키지도 설치됩니다.

일반적으로 종속 항목을 선호하는 것이 좋습니다. 다른 패키지를 시스템에 추가할 때 패키지에 종속성을 추가합니다.

Backward 종속성 의 경우 일치하는 패키지가 설치된 경우 종속성을 포함하는 패키지가 설치됩니다.

이전 종속 항목은 주로 플러그인, 애드온 또는 확장을 배포 또는 타사 패키지에 연결할 수 있는 타사 벤더용으로 설계되었습니다.

5.2. 부울 종속 항목 지원

버전 4.13부터 RPM은 다음 종속성에서 부울 표현식을 처리할 수 있습니다.

  • 필수 항목
  • 권장
  • 권장 사항
  • Supplemental
  • enhances
  • 충돌

다음 섹션에서는 부울 종속성 구문에 대해 설명하고 부울 종속성 연산자 목록 , 부울 종속성 중첩부울 종속성 의미에 대해 설명합니다.

5.2.1. 부울 종속 항목 구문

부울 표현식은 항상 괄호로 묶습니다.

일반적인 종속성에서 빌드됩니다.

  • 이름 또는 이름
  • 비교
  • 버전 설명

5.2.2. 부울 연산자

RPM 4.13에는 다음과 같은 부울 Operator가 도입되었습니다.

표 5.2. RPM 4.13을 사용하여 도입된 부울 Operator

부울 연산자설명사용 예

용어가 true가 되도록 모든 피연산자가 충족되어야 합니다.Requires all operands to be fulfilled for the term to be true.

충돌: (pkgA 및 pkgB)

또는

용어가 true인 경우 피연산자 중 하나가 충족되어야 합니다.

필수: (pkgA >= 3.2 또는 pkgB)

if

첫 번째 피연산자가 충족되어야 하는 경우 두 번째 피연산자가 충족되어야 합니다.

권장 사항: (langsupportCZ의 경우myP throughout-langCZ)

기타

if 연산자와 같으며, 두 번째 피연산자가 실행되지 않으면 세 번째 피연산자가 충족되어야 합니다.

필요 사항: ma spring-backend-mariaDB if mariaDB else sqlite

RPM 4.14에는 다음과 같은 추가 부울 Operator가 도입되었습니다.

표 5.3. RPM 4.14로 도입된 부울 Operator

부울 연산자설명사용 예

with

용어가 true인 경우 동일한 패키지에서 모든 피연산자를 충족해야 합니다.Requires all operands to be fulfilled by the same package for the term to be true.

필요 사항: (pkgA-foo with pkgA-bar)

without

첫 번째 피연산자를 충족하지만 두 번째 피연산자를 충족하는 단일 패키지가 필요합니다. (set subtraction)

필요 사항: (pkgA-bar 없이 pkgA-foo)

unless

두 번째 피연산자가 실행되지 않으면 첫 번째 피연산자가 충족되어야 합니다.(반도 음수 부정확함)

충돌: ( driverB 제외)

기타 없음

unless 연산자와 마찬가지로, 두 번째 피연산자가 두 번째 피연산자가 인 경우 세 번째 피연산자가 충족되어야 합니다.

충돌: ( myP throughout-backend-SDL1이 아닌 경우, myP throughout-backend-SDL2 기타 SDL2)

중요

if 연산자는 또는 연산자와 동일한 컨텍스트에서 사용할 수 없으며 및 와 동일한 컨텍스트에서 연산자를 사용할 수 없는 경우 .

5.2.3. 중첩

피연산자 자체는 아래 예제와 같이 부울 표현식으로 사용할 수 있습니다.

이러한 경우 피연산자는 괄호로 묶어야 합니다. 또는 연산자를 주변 괄호 중 하나만 사용하여 동일한 연산자를 반복하여 연결할 수 있습니다.

예 5.2. 부울 식으로 적용된 피연산자 사용 예

Requires: (pkgA or pkgB or pkgC)
Requires: (pkgA or (pkgB and pkgC))
Supplements: (foo and (lang-support-cz or lang-support-all))
Requires: (pkgA with capB) or (pkgB without capA)
Supplements: ((driverA and driverA-tools) unless driverB)
Recommends: myPkg-langCZ and (font1-langCZ or font2-langCZ) if langsupportCZ

5.2.4. 의미 체계

부울 종속성을 사용하면 일반 종속성의 의미가 변경되지 않습니다.

부울 종속성을 사용하는 경우 일치하는 모든 이름을 확인하고 부울 연산자를 통해 일치하는 부울 값을 일치시킬 수 있습니다.

중요

Conflicts 를 제외한 모든 종속 항목의 경우 설치를 방지하려면 결과를 True 로 설정해야 합니다. Conflicts:.의 경우 설치를 방지하려면 결과가 False 여야 합니다.

주의

provides는 종속성이 아니며 부울 식을 포함할 수 없습니다.

5.2.5. if Operator의 출력 이해

또한 if 연산자는 부울 값을 반환하며, 이는 일반적으로 직관적인 이해에 가깝습니다. 그러나 아래 예제에서는 일부의 경우 잘못 이해 될 수 있는지에 대한 직관적 인 이해를 보여줍니다.

예 5.3. if Operator의 잘못된 출력

pkgB가 설치되지 않은 경우 이 설명은 true입니다. 그러나 이 문을 기본 결과가 false인 경우 상황이 복잡해집니다.

Requires: (pkgA if pkgB)

이 설명은 pkgB가 설치되고 pkgA가 아닌 한 충돌입니다.

Conflicts: (pkgA if pkgB)

대신 다음을 사용할 수 있습니다.

Conflicts: (pkgA and pkgB)

if 연산자가 조건 또는 조건에 중첩된 경우도 마찬가지입니다.

Requires: ((pkgA if pkgB) or pkgC or pkg)

이는 pkgB가 설치되지 않은 경우 용어가 true이기 때문에 전체 용어인 true를 만듭니다. pkgA가 pkgB가 설치된 경우에만 도움이 되는 경우, 대신 을 사용합니다.

Requires: ((pkgA and pkgB) or pkgC or pkg)

5.3. 파일 트리거 지원

파일 트리거 는 패키지의 SPEC 파일에 정의된 일종의 RPM scriptlets 입니다.

Trigger 와 마찬가지로 하나의 패키지로 선언되지만 일치하는 파일이 포함되어 있거나 제거된 다른 패키지가 실행되는 경우 실행됩니다.

파일 트리거 의 일반적인 사용은 레지스트리 또는 캐시를 업데이트하는 것입니다. 이러한 사용 사례에서 레지스트리 또는 캐시를 포함하거나 관리하는 패키지에는 하나 이상의 파일 트리거 가 포함되어야 합니다. 파일 트리거를 포함하면 패키지가 자체 업데이트를 제어하는 상황에 비해 시간이 절약됩니다.

5.3.1. 파일 트리거 구문

파일 트리거에 는 다음과 같은 구문이 있습니다.

%file_trigger_tag [FILE_TRIGGER_OPTIONS] — PATHPREFIX…​
body_of_script

다음과 같습니다.

file_trigger_tag 는 파일 트리거의 유형을 정의합니다. 허용되는 유형은 다음과 같습니다.

  • filetriggerin
  • filetriggerun
  • filetriggerpostun
  • transfiletriggerin
  • transfiletriggerun
  • transfiletriggerpostun

FILE_TRIGGER_OPTIONS-P 옵션을 제외한 RPM 스크립트릿 옵션과 동일한 목적을 갖습니다.

트리거의 우선순위는 숫자로 정의됩니다. 숫자가 클수록 파일 트리거 스크립트가 더 빨리 실행됩니다. 100000보다 큰 우선순위가 있는 트리거는 표준 스크립트릿보다 먼저 실행되고 다른 트리거는 표준 스크립트릿 다음에 실행됩니다. 기본 우선순위는 1000000으로 설정됩니다.

각 유형의 파일 트리거에는 하나 이상의 경로 접두사 및 스크립트가 포함되어야 합니다.

5.3.2. 파일 트리거 구문의 예

이 섹션에서는 파일 트리거 구문의 구체적인 예를 보여줍니다.

%filetriggerin — /lib, /lib64, /usr/lib, /usr/lib64
/usr/sbin/ldconfig

이 파일 트리거는 /usr/lib 또는 /lib 로 시작하는 파일이 포함된 패키지를 설치한 직후 /usr/bin/ldconfig 를 직접 실행합니다. 패키지에 /usr/lib 또는 /lib 로 시작하는 경로가 여러 개 포함되어 있어도 파일 트리거가 한 번만 실행됩니다. 그러나 다음과 같이 스크립트 내에서 필터링할 수 있도록 /usr /lib 또는 /lib로 시작하는 모든 파일 이름이 트리거 스크립트의 표준 입력으로 전달됩니다.

%filetriggerin — /lib, /lib64, /usr/lib, /usr/lib64
grep "foo" && /usr/sbin/ldconfig

이 파일 트리거는 /usr/lib 로 시작하고 foo 를 동시에 포함하는 파일을 포함하는 각 패키지에 대해 /usr/bin/ldconfig 를 실행합니다. 접두사와 일치하는 파일에는 일반 파일, 디렉터리, 심볼릭 링크를 포함한 모든 유형의 파일이 포함됩니다.

5.3.3. 파일 트리거 유형

파일 트리거에 는 다음 두 가지 주요 유형이 있습니다.

파일 트리거 는 다음과 같이 실행 시간에 따라 추가로 나뉩니다.

  • 패키지의 설치 전 또는 삭제
  • 트랜잭션 전 또는 후에

5.3.3.1. 패키지 파일 트리거당 한 번 실행

패키지당 한 번 실행되는 파일 트리거 는 다음과 같습니다.

  • %filetriggerin
  • %filetriggerun
  • %filetriggerpostun
%filetriggerin

이 파일 트리거는 이 트리거의 접두사와 일치하는 하나 이상의 파일이 포함된 경우 패키지를 설치한 후에 실행됩니다. 이 파일은 이 파일 트리거가 포함된 패키지를 설치한 후 rpmdb 데이터베이스에 이 파일 트리거의 접두사와 일치하는 하나 이상의 파일이 있습니다.

%filetriggerun

이 파일 트리거는 이 트리거의 접두사와 일치하는 하나 이상의 파일이 포함된 경우 패키지를 제거하기 전에 실행됩니다. 이 파일 트리거가 포함된 패키지를 제거하기 전에 실행되고 rpmdb 에서 이 파일 트리거의 접두사와 일치하는 파일이 하나 이상 있습니다.

%filetriggerpostun

이 파일 트리거는 이 트리거의 접두사와 일치하는 하나 이상의 파일이 포함된 경우 패키지를 제거한 후 실행됩니다.

5.3.3.2. 트랜잭션 파일 트리거당 한 번 실행

트랜잭션당 한 번 실행되는 파일 트리거 는 다음과 같습니다.

  • %transfiletriggerin
  • %transfiletriggerun
  • %transfiletriggerpostun
%transfiletriggerin

이 파일 트리거는 이 트리거의 접두사와 일치하는 하나 이상의 파일이 포함된 모든 설치된 패키지에 대한 트랜잭션 후에 한 번 실행됩니다. 해당 트랜잭션에 이 파일 트리거가 포함된 패키지가 있고 rpmdb 에서 이 트리거의 접두사와 일치하는 파일이 하나 이상 있는 경우에도 트랜잭션이 실행됩니다.

%transfiletriggerun

이 파일 트리거는 다음 조건을 충족하는 모든 패키지에 대한 트랜잭션 이전에 한 번 실행됩니다.

  • 이 트랜잭션에서 패키지가 제거됨
  • 패키지에는 이 트리거의 접두사와 일치하는 파일이 하나 이상 포함됩니다.

해당 트랜잭션에 이 파일 트리거가 포함된 패키지가 있고 rpmdb 에서 이 트리거의 접두사와 일치하는 파일이 하나 이상 있는 경우에도 트랜잭션 전에 실행됩니다.

%transfiletriggerpostun

이 파일 트리거는 이 트리거의 접두사와 일치하는 하나 이상의 파일이 포함된 모든 제거 패키지에 대한 트랜잭션 후에 한 번 실행됩니다.

참고

이 트리거 유형에서는 트리거 파일 목록을 사용할 수 없습니다.

따라서 라이브러리가 포함된 여러 패키지를 설치하거나 제거하면 전체 트랜잭션이 끝나면 ldconfig 캐시가 업데이트됩니다. 이를 통해 캐시가 각 패키지에 대해 별도로 업데이트된 RHEL 7에 비해 성능이 크게 향상됩니다. 또한 모든 패키지의 SPEC 파일에서 %post 및 %postun을 ldconfig라고 하는 스크립트가 더 이상 필요하지 않습니다.

5.3.4. glibc에서 파일 트리거 사용 예

이 섹션에서는 glibc 패키지 내에서 파일 트리거 사용의 실제 예를 보여줍니다.

RHEL 8에서 파일 트리거 는 설치 또는 제거 트랜잭션이 끝나면 ldconfig 명령을 호출하기 위해 glibc 에서 구현됩니다.

이는 glibc 의 SPEC 파일에 다음 scriptlet을 포함하여 확인됩니다.

%transfiletriggerin common -P 2000000 – /lib /usr/lib /lib64 /usr/lib64
/sbin/ldconfig
%end
%transfiletriggerpostun common -P 2000000 – /lib /usr/lib /lib64 /usr/lib64
/sbin/ldconfig
%end

따라서 여러 패키지를 설치하거나 제거하면 전체 트랜잭션이 완료된 후 설치된 모든 라이브러리에 대해 ldconfig 캐시가 업데이트됩니다. 따라서 개별 패키지의 RPM SPEC 파일에 ldconfig 를 호출하는 scriptlets를 더 이상 포함할 필요가 없습니다. 이렇게 하면 각 패키지에 대해 캐시가 업데이트된 RHEL 7에 비해 성능이 향상됩니다.

5.4. 더 엄격한 SPEC 구문 분석기

SPEC 구문 분석기는 이제 몇 가지 변경 사항이 통합되어 있습니다. 따라서 이전에 무시했던 새로운 문제를 식별할 수 있습니다.

5.5. 4GB 이상의 파일 지원

Red Hat Enterprise Linux 8에서 RPM 은 64비트 변수와 태그를 사용할 수 있으므로 4GB보다 큰 파일 및 패키지에서 작동할 수 있습니다.

5.5.1. 64비트 RPM 태그

여러 RPM 태그는 64비트 버전과 이전 32비트 버전 모두에 있습니다. 64비트 버전에는 이름 앞에 LONG 문자열이 있습니다.

표 5.4. RPM 태그는 32비트 및 64비트 버전에서 모두 사용 가능

32비트 변형 태그 이름62-bit 변형 태그 이름태그 설명

RPMTAG_SIGSIZE

RPMTAG_LONGSIGSIZE

헤더 및 압축 페이로드 크기.

RPMTAG_ARCHIVESIZE

RPMTAG_LONGARCHIVESIZE

압축되지 않은 페이로드 크기.

RPMTAG_FILESIZES

RPMTAG_LONGFILESIZES

파일 크기의 배열입니다.

RPMTAG_SIZE

RPMTAG_LONGSIZE

모든 파일 크기의 합계입니다.

5.5.2. 명령줄에서 64비트 태그 사용

LONG 확장은 항상 명령줄에서 활성화됩니다. rpm -q --qf 명령이 포함된 스크립트를 이전에 사용한 경우 해당 태그 이름에 오래 추가할 수 있습니다.

rpm -qp --qf="[%{filenames} %{longfilesizes}\n]"

5.6. 기타 기능

Red Hat Enterprise Linux 8의 RPM 패키지와 관련된 기타 새로운 기능은 다음과 같습니다.

  • 비verbose 모드에서 단순화된 서명 확인 출력
  • 강제 페이로드 확인 지원
  • 강제 서명 검사 모드 지원
  • 매크로 추가 및 사용 중단

추가 리소스

이 섹션에서는 RPM, RPM 패키지, RPM 빌드와 관련된 다양한 주제를 참조합니다. 이 중 일부는 고급이며 이 문서에 포함된 소개 자료를 확장합니다.

Red Hat Software Collections 개요 - Red Hat Software Collections 오퍼링은 안정적인 최신 버전에서 지속적으로 업데이트된 개발 툴을 제공합니다.

Red Hat Software Collections - 패키징 가이드에 대해서는 Software Collections에 대한 설명과 이를 빌드하고 패키징하는 방법을 자세히 설명합니다. RPM을 사용한 소프트웨어 패키지에 대한 기본적인 이해가 있는 개발자 및 시스템 관리자는 이 가이드를 사용하여 Software Collections를 시작할 수 있습니다.

mock - Mock은 빌드 호스트가 있는 것보다 다양한 아키텍처 및 다양한 Fedora 또는 RHEL 버전에 대해 커뮤니티 지원 패키지 구축 솔루션을 제공합니다.

RPM 문서 - 공식 RPM 문서.

Fedora 패키징 지침 - Fedora의 공식 패키징 지침, 모든 RPM 기반 배포에 유용합니다.