소프트웨어 패키징 및 배포

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

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

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

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

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

#include <stdio.h>

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

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

print("Hello World")

#!/bin/bash

printf "Hello World\n"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

사양 파일은 Scriptlets 또는 Trigger 와 같은 고급 항목을 포함할 수 있습니다.

스크립트릿 및 트리거는 빌드 프로세스가 아닌 최종 사용자의 시스템에서 설치 프로세스 중에 다른 지점에서 적용됩니다.

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

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

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

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

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

Python 프로그래밍 언어로 작성된 pello 프로그램에 대한 SPEC 파일은 다음과 같습니다.

%global python3_pkgversion 3.11                                       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 needed to be specified manually
BuildRequires:  python%{python3_pkgversion}-setuptools

# Test dependencies needed to be specified manually
# Also 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 supported projects with setup.py
%py3_build                                                            5


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


%check                                                                6
%{pytest}


# Note that there is no %%files section for the unversioned python module
%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/

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

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

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

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

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

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

생성된 바이너리 RPM은 ~/rpmbuild/RPMS/ YOURARCH 디렉터리에 있습니다. 여기서ARCH는 아키텍처별이 아닌 경우 ~/rpmbuild/RPMS/noarch/ 디렉터리에 있습니다.

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

다음 섹션에서 bello 사양 파일 및 bello 바이너리 RPM의 예에서 RPM에서 sanity를 확인할 때 발생할 수 있는 경고 및 오류를 조사합니다.

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

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

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

다음 섹션에서 pello 사양 파일 및 pello 바이너리 RPM의 예에서 RPM 기간을 확인할 때 발생할 수 있는 경고 및 오류를 조사합니다.

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

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

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

다음 섹션에서 cello 사양 파일 및 cello 바이너리 RPM의 예에서 RPM을 확인할 때 발생할 수 있는 경고 및 오류를 조사합니다.

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

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

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

다음 절차에 따라 패키지에 서명하는 데 필요한 GNU 개인 정보 보호 보호 (GPG) 키를 만듭니다.

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

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

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

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

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

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

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

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

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 매크로:

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

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

rm -rf 'cello-1.0'

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

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

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

다음 표에는 사양 파일의 %files 섹션에 필요한 고급 RPM Macros가 나열되어 있습니다.

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

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

권장 RPM 매크로 세트는 종종 RPM 패키지로 제공되며 dnf 패키지 관리자를 사용하여 설치할 수 있습니다.

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

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

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

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

%_smp_mflags -l3

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

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

이 지시문이 RPM 사양 파일에 나열되지 않으면 Epoch 지시문이 전혀 설정되지 않습니다. 이는 Epoch 가 0인 Epoch 를 설정하지 않는다는 일반적인 신념과는 대조적입니다. 그러나 dnf 유틸리티는 해독 목적으로 0의 Epoch 와 동일한 설정되지 않은 Epoch를 처리합니다.

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

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

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

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

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

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

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

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

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

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

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 파일에서 찾을 수 있습니다.

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

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

%post -p /usr/bin/python3

%post -p <lua>

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

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

%if expression
…​
%endif

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

%if expression
…​
%else
…​
%endif

다음 예제에서는 %if RPM 조건을 사용하는 방법을 보여줍니다.

%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 스크립트에서 삭제됩니다.

%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 매크로가 다시 정의됩니다.

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

%ifarch i386 sparc
…​
%endif

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

%ifnarch alpha
…​
%endif

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

%ifos linux
…​
%endif

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

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

Python 프로젝트의 RPM SPEC 파일에는 Python이 아닌 SPEC 파일에 비해 몇 가지 구체적인 내용이 있습니다.

기타 세부 사항은 python3*-pello 패키지에 대한 다음 SPEC 파일 예제에 표시되어 있습니다. 이러한 세부 사항에 대한 설명은 예제 아래의 노트를 참조하십시오.

%global python3_pkgversion 3.11                                       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 needed to be specified manually
BuildRequires:  python%{python3_pkgversion}-setuptools

# Test dependencies needed to be specified manually
# Also 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 supported projects with setup.py
%py3_build                                                            5


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


%check                                                                6
%{pytest}


# Note that there is no %%files section for the unversioned python module
%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/

SPEC 파일에서는 항상 값을 하드 코딩하지 않고 다음 Macros for Python 3 RPMs 테이블에 설명된 매크로를 사용합니다. SPEC 파일 상단에 python3_pkgversion 매크로를 정의하여 이러한 매크로에서 어떤 Python 3 버전이 사용되는지 확인할 수 있습니다( 5.5.1절. “Python 패키지에 대한 SPEC 파일 설명”참조). python3_pkgversion 매크로를 정의하는 경우 다음 표에 설명된 매크로 값은 지정된 Python 3 버전을 반영합니다.

다음 절차에서는 Python 프로젝트를 RPM으로 패키징할 때 자동으로 생성된 종속 항목을 사용하는 방법을 설명합니다.

다음 절차에 따라 RPM 빌드 시 빌드 오류가 발생하는 Python 스크립트에서 인터프리터 지시문을 수정합니다.

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

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

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

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

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

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

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

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

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

%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}/

$ gem install gem2rpm

BuildRequires 에 사용되는 Perl 관련 빌드 종속 항목은 다음과 같습니다.

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

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

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

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

Patch: 및 Source: 숫자가 없는 태그는 이제 나열된 순서에 따라 자동으로 번호가 지정됩니다.

번호 매기기는 마지막 수동으로 번호가 매겨진 항목부터 rpmbuild 유틸리티에 의해 내부적으로 실행되거나 이러한 항목이 없는 경우 0 이 실행됩니다.

예를 들어 다음과 같습니다.

Patch: one.patch
Patch: another.patch
Patch: yet-another.patch

이제 새로 추가된 %patchlist 및 %sourcelist 섹션을 사용하여 각 항목 앞에 각 항목 없이 패치 및 소스 파일을 나열할 수 있습니다.

예를 들어 다음 항목은 다음과 같습니다.

Patch0: one.patch
Patch1: another.patch
Patch2: yet-another.patch

이제 다음과 같이 교체할 수 있습니다.

%patchlist
one.patch
another.patch
yet-another.patch

이제 %autopatch 매크로는 -m 및 -M 매개변수를 수락하여 적용할 최소 및 최대 패치 번호를 제한합니다.

이 기능은 특정 패치 세트 간에 작업을 수행해야 하는 경우에 유용할 수 있습니다.