4.5. SPEC 파일 작업

절차

1. ~/rpmbuild/SPECS 디렉터리로 이동하여 rpmdev-newspec 유틸리티를 사용합니다.

   $ cd ~/rpmbuild/SPECS

2. Hello World의 세 가지 구현 각각에 대한 SPEC 파일을 만듭니다! rpmdev-newspec 유틸리티를 사용하여 프로그램:

   $ 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.spec 및 pello.spec 이라는 세 개의 SPEC 파일이 있습니다.

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

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

절차

1. rpmdev-newspec 유틸리티에서 제공하는 ~/rpmbuild/SPECS/<name>.spec 파일의 출력 템플릿을 엽니다.

   1. rpmdev-newspec 이 함께 그룹화된 다음 지시문을 포함하는 SPEC 파일의 첫 번째 섹션을 채웁니다.

      이름

      Name 은 rpmdev-newspec 에 대한 인수로 이미 지정되었습니다.

      버전

      소스 코드의 업스트림 릴리스 버전과 일치하도록 버전 을 설정합니다.

      릴리스 버전

      릴리스 가 자동으로 1%{?dist} 로 설정되어 있으며 이는 처음 1 입니다. 예를 들어 패치를 포함하는 경우 업스트림 릴리스 버전이 변경되지 않고 패키지를 업데이트할 때마다 초기 값을 늘립니다. 새 업스트림 릴리스 가 발생하면 릴리스를 1 로 재설정합니다.

      요약

      요약 은 이 소프트웨어가 무엇인지에 대한 간단한 한 줄 설명입니다.

   2. 라이센스,URL 및 Source0 지시문을 채웁니다.

      라이센스

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

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

      URL

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

      소스

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

   3. BuildRequires,Requires 및 BuildArch 지시문을 채웁니다.

      BuildRequires

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

      필수 항목

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

      BuildArch

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

   4. %description,%prep,%build,%install,%files, %license 지시문을 채웁니다. 이러한 지시문은 여러 줄, 다중 설명 또는 스크립팅된 작업을 수행할 수 있는 지시문이므로 섹션 제목으로 생각할 수 있습니다.

      %Description

      %description 은 요약 보다 소프트웨어에 대한 더 긴 전체 설명입니다. 이 지시문에는 하나 이상의 단락이 포함되어 있습니다.

      %Prep

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

      %build

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

      %install

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

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

      %files

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

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

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

      * 문자가 있는 %changelog 섹션의 첫 번째 줄을 시작하고 그 뒤에 Day-of-Week Day Name Surname <email> - Version-Release 를 시작합니다.

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

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