2.11.2.2.2 Файл спецификации
Скачать документ
Консультации и оказание технической поддержки по данной статье не предоставляются.
Вы можете подробнее ознакомиться с принципами сборки пакетов для РЕД ОС, просмотрев наши обучающие видео:
на RuTube — Курс по принципам сборки пакетов для РЕД ОС;
в Яндекс.Дзен — Курс по принципам сборки пакетов для РЕД ОС;
в VK Видео — Курс по принципам сборки пакетов для РЕД ОС.
На наших каналах вы также сможете найти много другой полезной информации.
Файл спецификации можно рассматривать как «рецепт», согласно которому утилита 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
...
%descrtiption 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 будет пустым.
Дата последнего изменения: 09.09.2024
Если вы нашли ошибку, пожалуйста, выделите текст и нажмите Ctrl+Enter.