1.11.2.2 Файл спецификации
Скачать документ
Файл спецификации можно рассматривать как «рецепт», согласно которому утилита rpmbuild создаёт готовый пакет. В спецификации задаются команды для системы сборки, определяются инструкции в ряде разделов. Фактически спецификация представляет собой сценарий, выраженный языком макросов. Написание спецификации является важнейшим этапом при создании двоичных пакетов программного обеспечения.
Макрос RPM — это прямая текстовая подстановка, осуществляемая на основе раскрытия заданных выражений и условий, реализованная на базе встроенной функциональности сборочной системы. Иными словами, макросы являются псевдонимами для часто используемых фрагментов текста, применение которых сокращает не только объём ввода, но и делает спецификацию легче читаемой и воспринимаемой. Имена макросов начинаются с символа «%».
Файл спецификации разделяют на преамбулу, содержащую ряд элементов метаданных, которые используются в дальнейшем тексте, и текст (тело) спецификации, в котором содержится основная часть инструкций. В русскоязычных источниках преамбулу также называют заголовком спецификации.
Каждый из этих двух разделов сценария сборки содержит как обязательные, так и опциональные подразделы и элементы.
В случае написания спецификации «с нуля» можно создать её заготовку с типовыми блоками с помощью утилиты rpmdev-newspec, которой в качестве аргумента указывается имя нового проекта:
rpmdev-newspec hello hello.spec created; type minimal, rpm version >= 4.13.
Созданный файл hello.spec будет иметь следующее содержимое:
Преамбула
В нижеприведенной таблице перечислены элементы, используемые в преамбуле файла спецификации RPM, которые называются директивами или тэгами. В таблице жирным шрифтом выделены обязательные директивы.
Директивы | Определение |
|---|---|
Name | Базовое имя пакета, которое должно совпадать с именем файла спецификации |
Version | Номер версии программного обеспечения |
Release | Количество раз, когда данная версия программного продукта была собрана. Как правило, при первой сборке конкретной версии пакета значение устанавливается равным 1 и увеличивается на единицу с каждой новой сборкой пакета. После цифры указывают суффикс макросом %{?dist} |
Epoch | Способ определения взвешенных зависимостей на основе номеров версий. Если директива явно не задана, то значение по умолчанию равно 0. Данный параметр влияет на полную версию пакета при построении зависимостей в базе данных RPM или в репозитории Полная версия выглядит как Epoch:Version-Release |
Summary | Краткое, однострочное описание пакета |
License | Лицензия на упаковываемое программное обеспечение |
URL | Полный URL (адрес) для получения дополнительной информации о программе. Обычно это веб-сайт проекта для упаковываемого программного обеспечения |
Source[X] | Путь (абсолютный или относительный) или URL-адрес к исходным файлам проекта. Директива может указывать как на сжатые архивы исходных кодов, так и на отдельные файлы. Проект может содержать несколько исходных файлов, тогда для их нумерации вместо [X] указывается цифра, например: Source3. Если имеется только один исходный файл, то нумерацию можно опустить, указав просто Source. |
Patch[X] | Файлы патчей, которые при необходимости будут применены к исходному коду. Проект может содержать несколько патчей, тогда вместо [X] указывают их номер, например: Patch2. Если патч единственный, то номер можно не присваивать (Patch) |
BuildArch | Явное указание архитектуры, под которую собирается двоичный пакет. Если параметр не задан, то пакет автоматически наследует архитектуру машины, на которой он собран. В случае с архитектурно-независимыми пакетами указание данной директивы обязательно: BuildArch: noarch |
ExcludeArch | Если программное обеспечение, для которого собирается двоичный пакет, не может работать на определённой архитектуре процессора, то можно исключить эту архитектуру данной директивой |
BuildRequires | Список пакетов, разделённых запятыми или пробелами либо указанных по одному в строке с данной директивой, необходимых для компиляции/создания программы или формирования пакета |
Requires | Список пакетов, разделённых запятыми или пробелами, необходимых программному обеспечению для запуска после установки. В файле спецификации может быть несколько записей Requires, каждая из которых находится в отдельной строке |
Provides | Указание дополнительных имён, библиотек или иных сущностей, которые предоставляет данный пакет. Используется для создания псевдонимов пакета, которые можно использовать как в тэгах спецификаций при сборке других пакетов, так и для установки пакета через пакетный менеджер |
Obsoletes | Перечисление имён пакетов, которые данный пакет делает устаревшими. При установке данного пакета устаревшие пакеты будут автоматически удалены из системы пакетным менеджером |
Confilcts | Перечисление имён пакетов, с которыми конфликтует данный пакет, т. е. все эти пакеты не могут быть одновременно установлены в системе |
Каждая директива обязательно разделяется от её значения символом «:», между директивой и двоеточием не должно быть пробелов!
Например:
Name: openssl
Version: 1.0.2
Release: 4%{?dist} Завершается преамбула обязательным блоком описания назначения пакета, идущим после тэга %description, в котором, в отличие от директивы Summary, даётся развёрнутая информация о пакете. Описание может занимать любое количество строк и быть разбито на абзацы по желанию автора спецификации.
В одном файле спецификации может быть описано несколько двоичных пакетов!
В таком случае один проект будет представлен несколькими двоичными RPM-файлами. Заголовки других пакетов в подобной спецификации должны начинаться с макроса %package <ИМЯ_ПАКЕТА>, причём имя другого пакета тэгом Name задавать не нужно — оно будет сформировано из опций указанного макроса. Также можно не указывать версию и релиз, если они совпадают (или должны совпадать по задумке автора спецификации) со значениями таковых же директив всего проекта. Например:
Name: superproj
Version: 1.0
Release: 1%{?dist}
Summary: Super Project
...
%description
This is the Super Project from our Company for all people.
%package devel
Summary: Development files for Super Project
...
%desctiption devel
This package contains libraries and header files for development
with Super Project.
...В результате успешного завершения сборки согласно данной спецификации будут получены два пакета, например (для архитектуры x86_64):
superproj-1.0-1.el7.x86_64.rpm и superproj-devel-1.0-1.el7.x86_64.rpm
Тело спецификации
В таблице ниже перечислены основные блоки, используемые в тексте (теле) спецификации, причём все они, кроме %check, являются обязательными.
Важно заметить, что сколько бы двоичных пакетов не было описано в спецификации, все ниже приведённые директивы, кроме %files, фигурируют в тексте только один раз — разделение на разные двоичные RPM происходит именно в блоках %files согласно преамбуле.
Блоки | Определение |
|---|---|
%prep | Команды для подготовки программного обеспечения к сборке, например, распаковка архива, указанного в Source или Source0. |
%build | Команды для фактической сборки программного обеспечения в машинный код (для компилируемых языков) или байт-код (для некоторых интерпретируемых языков) |
%install | Команды установки/копирования файлов из сборочного каталога в псевдо-корневую директорию |
%check | Команды для тестирования программного обеспечения. Данный блок обычно включают в себя модульные тесты |
%files | Список файлов для каждого двоичного пакета (если их создаётся несколько по одной спецификации), которые будут установлены в системе конечного пользователя |
%changelog | Список изменений, произошедших в пакете между сборками разных версий или релизов |
Командами внутри блоков могут быть как макросы сборочной системы RPM, так и вызовы внешних приложений, включая сценарии оболочки.
Если при сборке какого-либо пакета нет необходимости в каком-то блоке, всё равно его название необходимо указать в спецификации. Например, упаковывается тема пиктограмм и компилировать просто нечего при сборке двоичного пакета, то в спецификации такого пакета блок %build будет пустым.
Если вы нашли ошибку, пожалуйста, выделите текст и нажмите Ctrl+Enter.