Product SiteDocumentation Site

5.2.2. Директивы преамбулы

В Директивы преамбулы spec-файла перечислены директивы, используемые в разделе преамбулы файла спецификации RPM.

Таблица 5.1. Директивы преамбулы spec-файла

SPEC Директива
Определение
Name
Базовое имя пакета, которое должно совпадать с именем spec-файла.
Version
Версия upstream-кода.
Release
Релиз пакета используется для указания номера сборки пакета при данной версии upstream-кода.
Для пакетов Sisyphus поле Release должно иметь вид в простых случаях — altN, а в сложных — altN[суффикс]. N начинается с 1 для каждой новой upstream-версии и увеличивается на 1 для каждой новой сборки:
  • 1.0-alt1
  • 1.0-alt2
Epoch
Поле Epoch используется тогда, когда по какой-то причине требуется уменьшить версию или релиз пакета по сравнению с имеющимся в репозитории. При этом значение поля Epoch увеличивается на единицу по сравнению с предыдущим (отсутствие поля Epoch эквивалентно значению 0), версия и релиз устанавливаются в нужное значение.
В имя RPM-файлов Epoch не входит, и поэтому необходимо избегать RPM с одинаковыми Version и Release и разными Epoch.
Summary
Краткое, однострочное описание пакета. Значение тэга Summary должно начинаться с заглавной буквы. В конце Summary не должно быть точки.
License
Лицензия на собираемое программное обеспечение. Лицензия должна быть указана в точности так, как сформулировано в upstream-пакете. При указании лицензии рекомендуется пользоваться макросами из пакета rpm-build-licenses, добавив его в список BuildRequires.
Сам текст лицензии упаковывать в пакет нужно только в том случае, если соответствующий текст отсутствует в /usr/share/license (пакет common-licenses). Если же таковой файл присутствует, то достаточно указать название лицензии в тэге пакета.
Group
Используется для указания категории, к которой относится пакет. Указанная группа должна находиться в списке групп, известном RPM. Этот список располагается в файле /usr/lib/rpm/GROUPS, находящемся в пакете rpm.
URL
Полный URL-адрес для получения дополнительной информации о программе.
В тэге URL настоятельно рекомендуется указывать действующий URL домашней страницы проекта, либо если таковой нет — любого другого места, где можно получить архив с исходным кодом.
Для директивы URL можно использовать утилиту rpmurl, например, проверка доступности URL:
$ rpmurl -c пакет.spec
Source0
Путь или URL-адрес к сжатому архиву исходного кода (не исправленный, исправления обрабатываются в другом месте). Этот раздел должен указывать на доступное и надежное хранилище архива, например, на upstream-страницу, а не на локальное хранилище сборщика. При необходимости можно добавить дополнительные исходные директивы, каждый раз увеличивая их номер, например: Source1, Source2, Source3 и так далее.
Patch0
Название первого патча, который при необходимости будет применен к исходному коду. При необходимости можно добавить дополнительные директивы PatchX, увеличивая их номер каждый раз, например: Patch1, Patch2, Patch3 и так далее.
BuildArch
Явное указание архитектуры, под которую собирается двоичный пакет. Если параметр не задан, то пакет автоматически наследует архитектуру машины, на которой он собран, например, x86_64.
Если пакет не зависит от архитектуры, например, если он полностью написан на интерпретируемом языке программирования, следует установить для этой директивы значение noarch.
BuildRequires, BuildPreReq, BuildRequires(pre)
Разделенный запятыми или пробелами список пакетов, необходимых для сборки программы. Может быть несколько записей BuildRequires, каждая в отдельной строке.
Тэг BuildRequires используется для хранения результатов работы утилиты buildreq. По этой причине дополнительные сборочные зависимости, не находящиеся buildreq, рекомендуется хранить в тэге BuildPreReq.
Requires, PreReq
Разделенный запятыми или пробелами список пакетов, необходимых программному обеспечению для запуска после установки. Это его зависимости. Может быть несколько записей Requires, каждая в отдельной строке.
ExcludeArch
Если программное обеспечение, для которого собирается двоичный пакет, не может работать на определенной архитектуре процессора, то можно исключить эту архитектуру данной директивой.
Conflicts
Разделенный запятыми или пробелами список пакетов, с которыми конфликтует данный пакет.
Применяется для указания наличия конфликта (обязательно в случае файлового/RPC и желательно в случае существенного смыслового) между данным пакетом и указываемым.
Provides
Используется для указания того факта, что данный пакет предоставляет функциональность иного (переименованного устаревшего названия, широко известного по другим дистрибутивам либо же виртуального). Следует применять только в случае реальной необходимости и, как правило, в форме
Provides: something = %version-%release
При переименовании пакета обязательно сочетается с Obsoletes.
Obsoletes
Перечисляет пакеты/версии, объявленные устаревшими. Обычно применяется при переименовании пакета в сочетании с Provides и с указанием версии, меньшей или равной последней известной версии пакета под старым названием.
Каждая директива разделяется от ее значения символом «:». Между директивой и двоеточием не должно быть пробелов!
Директивы Name, Version и Release содержат имя RPM-пакета. Эти три директивы часто называют N-V-R или NVR, поскольку имена RPM-пакетов имеют формат NAME-VERSION-RELEASE.
Увидеть пример NAME-VERSION-RELEASE можно, выполнив запрос с использованием rpm для конкретного пакета:
$ rpm -q rpmdevtools
rpmdevtools-8.10-alt2.noarch
Здесь rpmdevtools — это имя пакета, 8.10 — версия, а alt2 — релиз. Последний маркер noarch — сведения об архитектуре. В отличие от NVR, маркер архитектуры не находится под прямым управлением сборщика, а определяется средой сборки. Исключением из этого правила является архитектурно-независимый пакет noarch.