Spec-файл, сокращение от «файл спецификации», определяет все действия утилиты rpmbuild, которые должны быть выполнены при построении приложения, так же как и все действия, необходимые при установке/удалении приложения. Каждый src.rpm-пакет имеет в своем составе spec-файл для последующей пересборки пакета.
Текст внутри spec-файла имеет специальный синтаксис. Синтаксические определения имеют значения, задающие порядок сборки, номер версии, информацию о зависимостях и вообще всю информацию о пакете, которая может быть впоследствии запрошена из БД RPM.
8.2.3.1 Секция общей информации (introduction)
Summary: java source to bytecode compiler
Summary(ru): Исходный код компилятора байт-кода java
%define version 1.17
%description The IBM Jikes compiler translates Java source files to bytecode. It also supports incremental compilation and automatic makefile generation, and is maintained by the Jikes Project: http://ibm.com/developerworks/opensource/jikes/
Из этого примера, в общем, понятно, как устроена секция общей информации. Этот пример не следует всем требованиям RPM. Например, тэг Copyright в настоящее время утратил значение и не используется, номер версии можно задать непосредственно, в примере задается через определение макроса.
Для отслеживания изменений требований от версии к версии rpm можно проанализировать spec-файлы пакетов современных сборок и сравнить их с прежними сборками.
Секция подготовки отвечает за команды, необходимые для начала сборки. Например, если в SOURCES положен тарболл проекта, его необходимо распаковать. В секции указываются для этого соответствующие макросы rpm:
Секция начинается со строки %prep. Этот пример использует макрос %setup, который умеет распаковывать компрессированные архивы. Как правило, это единственная строка в данной секции.
Секция build содержит команды сборки ПО. Обычно здесь присутствует всего несколько команд, например:
В данном примере задействованы два параметра скрипта configure (флаги оптимизации компилятора и имя временного каталога сборки) и команда make (без параметра, то есть для цели all). Секция начинается строкой %build.
8.2.3.4 Секция install
Секция содержит команды установки файлов пакета в систему. Например:
Команды в этой секции вычищают файлы, созданные на других стадиях:
Секция начинается строкой %clean.
И, наконец, команды в секции files задают списки файлов и каталогов, которые с соответствующими атрибутами должны быть скопированы из дерева сборки в rpm-пакет и затем будут копироваться в целевую систему при установке этого пакета. Например:
Секция начинается строкой %files. Макрос %doc отмечает файлы документации. Это позволяет составить документацию из подходящих файлов проекта.
После окончания редактирования spec-файла осталось поместить его в каталог SPECS под /usr/src/redhat, а тарболл с исходным кодом в SOURCES. Все готово для сборки rpm.
Построить пакеты RPM довольно легко, особенно если вы можете получить программное обеспечение, которые вы пытаетесь упаковать чтобы построить для себя.
Основные процедуры чтобы построить пакет RPM следующие:
При нормальных условиях, RPM построит и двоичный пакет и пакет с исходным кодом.
RPM также сейчас поддержку для построения пакетов для множественных архитектур. Файл rpmrc может содержать переменную «optflags» для построения вещей, которые требуют специфических для данной архитектуры флагов для построения. Смотрите следующие разделы для описания как использовать эту переменную.
В добавление к вышеприведенным макросам, существует еще несколько. Вы можете использовать:
Мы начнем с обсуждения spec-файла. Spec-файл требуется для построения пакета. Spec-файл это описание программного обеспечения вместе с инструкциями как построить пакет и списком файлов для всех устанавливаемых файлов.
Вы можете захотеть назвать ваш spec-файл согласно стандартному соглашению. Имя должно быть следующим: имя пакета-тире-номер версии-тире-номер выпуска (релиз)-точка-spec.
Здесь приведен маленький spec-файл (vim-3.0-1.spec):
Заголовок имеет несколько стандартных полей, которые вам необходимо заполнить. Также существует несколько предостережений. Поля должны быть заполнены как показано:
48.7 Опциональные скрипты выполняемые до и после установки/удаления пакета
Есть несколько доступных макросов для выполнения специальных действий. Они перечислены и описаны здесь:
Дерево директорий исходных текстов
Вам надо создать следующие директории чтобы создать дерево построения:
Тестовое построение пакета
Это создаст для вас заплатку, которую вы сможете использовать в вашем spec-файле. Заметим что «linux», который вы видите в имени заплатки это просто идентификатор. Вы можете захотеть использовать что-нибудь более описательное как «config» или «bugs» для описания почему вы сделали эту заплатку. Также хорошая идея посмотреть в файл заплатки, который вы создали, до его использования чтобы убедиться что бинарные файлы случайно не включены.
Создание списка файлов
Сейчас у вас есть исходные тексты, которые будут строиться и вы знаете как построить и установить их. Посмотрите в вывод установочной последовательности и постройте на его основе список ваших файлов для использования в spec-файле. Мы обычно создаем spec-файл параллельно со всеми описанными шагами. Вы можете сначала создать его и заполнить самые легкие его части, а затем затем заполнять его по мере прохождения всех этапов.
Построение пакета с помощью RPM
После того как вы сделали свой собственный пакет RPM из чего-либо (предполагая что этого еще нет в виде RPM) вы можете предлагать свою работу другим людям (также предполагая, что ваш RPM свободно распространяемый). Чтобы сделать это вы можете захотеть загрузить пакет на сервер ftp.redhat.com.
По этой причине мы рекомендуем сборщикам пакетов использовать следующий шаблон spec-файла, это упростит жизнь остальным, если кто-то подберёт ваш пакет или захочет внести в него изменения. Если каждый будет следовать одному и тому же формату, не будет возникать никаких сюрпризов.
Подробнее о политиках, например, о политиках сборки библиотек, политике альтернатив и т. п. см. раздел политики сборки пакетов.
Содержание
Заголовок (Spec Header)
Заголовок Spec-файла содержит важную информацию, необходимую для сборки, о версии пакета, исходном коде, патчах, зависимостях.
Определение макросов
В начале Spec-файла содержатся определения макросов. Например:
Все %define должны быть определены именно в этом месте с соответствующими комментариями. Для выравнивания макроопределений используется табуляция как показано выше (используйте двойную табуляцию после определения name или столбец 25 (конец третьей табуляции); это позволит использовать более длинные имена в определениях). Если имя определения длиннее и следующий символ табуляции будет находиться за 26-й колонкой, используйте одиночный пробел, например:
Название, версия, релиз
Первый раздел должен содержать стандартное название, версию и тэг релиза:
Краткая сводка, название, исходники и патчи
Следующий раздел заголовка должен выглядеть следующим образом:
Как видите, всё располагается в линейном порядке:
Файлы исходников должны начинаться с Source0, не используйте Source:; если в пакете содержится один единственный исходник, используйте Source0, поскольку нет гарантии, что в пакете всегда будет использоваться один исходник. Тоже самое относится к ключевому слову Patch0; всегда начинайте с Patch0:, и никогда не используйте Patch:. Если исходный код имеет URL, по которому его можно получить, то эту информацию необходимо включить.
Табуляции здесь чуть короче, чем определения, главным образом потому, что определения могут быть длиннее, но Source, Name и др. тэгов это не касается. Вместо столбца 25, используйте столбец 17 или конец второй табуляции. Важно, чтобы все значения ключевых слов, и вообще содержимое второй колонки, было выровнено по левому краю, поскольку такое оформление наиболее удобно для чтения.
Наименование патчей
Патчам должны даваться имена в очень ясной манере, чтобы можно быть быстро понять, какая версия патча была применена и откуда он был взят. Поэтому патчи должны удовлетворять следующему соглашению о наименовании: [название_пакета]-[версия]-[описание].patch:
Зависимости сборки
Requires, Obsoletes, Provides, Conflicts и тому подобное
Последний набор тэгов в заголовке RPM указывает, что пакет предоставляет (тэг Provides; такие предоставляемые возможности можно потом указывать в тэгах Requires и BuildRequires других пакетов), какие пакеты он делает устаревшими (тэг Obsoletes), с какими пакетами конфликтует (тэг Conflicts) и от каких зависит (тэг Requires); обратите внимание, что в скобках после этого тэга можно дополнительно указывать ключевые слова post-, pre- и так далее, если зависимость требуется для выполнения соответствующих скриптов).
Для удобства, мы рекомендуем не мешать разные тэги, а следовать определенному порядку:
Описание
Тэг %description находится в самом конце, в нём содержится описание пакета. Длина строки должна составлять 76 символов.
В итоге, RPM-spec должен выглядеть следующим образом:
Для пакетов, которые создают несколько подпакетов, следуйте выше изложенному руководству для каждого подпакета.
Раздел %prep находится после всех определений пакета. По крайней мере 2 пустые строки должны отделять конец раздела %description от %prep. Простейший раздел %prep выглядит следующим образом:
Другие соглашения
Системные макросы и макросы пользователя
Стандартные макросы
При условии использования сходных названий для макросов повышается читабельность spec-файла.
Переменные
Журналы изменений
Журналы изменений хранятся в журналах Git. При выполнении коммита в Git журнал становится частью итогового spec-файла (т. к. журналы коммита создают журнал изменений RPM во время сборки). Делайте записи в журнале достаточно подробными, чтобы позднее не приходилось использовать diff ддя просмтра изменений. Пример плохой записи в журнале:
Подобная запись ни о чём не говорит и, кто бы ни сделал это изменение, он не сможет сказать, что же было сделано в этом коммите. Вместо этого нужно было записать что-то в этом духе:
Такая запись в большей степени информирует о сделанных изменениях. Заметьте, что исходники должны ссылаться на свои полные имена (как в примере: вместо S23 используется длинное имя foo-manpages.tar.bz2). Патчам нет необходимости ссылаться на полные имена, но могут ссылаться на часть описания патча. Например, первый комментарий «переработан description.patch для новой версии foo», может относиться к патчу с именем foo-1.2-rosa-description.patch. Префикс foo-1.2-rosa можно опустить, если нет других патчей со словом «description» в содержательной части имени. Если же есть два похожих патча (например, foo-1.2-rosa-description.patch и foo-1.0-cvs-description.patch), то ссылка на «description.patch» в комментарии будет неоднозначна; таких ситуаций следует избегать.
Обработка исходников
Вместо, в spec-файле предпочтительно использовать % /foo, т. к. это упрощает чтение файла. Например, сравните:
В данной инструкции мы научимся готовить Linux-среду для работы и рассмотрим примеры по созданию своих пакетов RPM. Мы будем работать в системе CentOS (Red Hat / Fedora).
Подготовка системы
Для работы по сборке пакетов лучше использовать отдельный компьютер, виртуальную машину или контейнер Docker.
1. Установим пакеты:
yum install rpmdevtools rpmlint
yum group install «Development Tools»
* данная группа пакетов включает все необходимое для сборки. Ее не рекомендуется ставить на рабочий компьютер, так как устанавливается много ненужного для стандартной системы мусора.
2. Создаем пользователя.
Делать готовые установочные сборки пакетов очень опасно от пользователя root. Если мы допустим ошибку с путями, файлы могут перетереть или удалить важные для работы директории. Стоит создать отдельного пользователя и работать под ним. Однако, если мы работаем в виртуальной среде или контейнере Docker, нам это не страшно. Тогда данный пункт можно пропустить и работать из под root.
* в данном примере мы создадим пользователя builder. Опция -m сразу создаст домашний каталог для пользователя.
Теперь заходим под данным пользователем — последующие команды мы будем выполнять от него:
3. Создадим структуру каталогов для сборки:
В нашей текущем каталоге должна появиться папка rpmbuild — а в ней:
Мы готовы к сборке.
Сборка из исходников
Рассмотрим пример создания RPM из пакета, который нужно собирать из исходников с помощью команды make. Например, возьмем данную программу: github.com/brettlaforge/pg_redis_pubsub.
* чтобы понять, как заполнить spec-файл, рекомендуется для начала собрать и установить приложение вручную с помощью make и make install. Также необходимо изучить документацию устанавливаемого пакета или (при наличие возможности) поговорить с разработчиками программного обеспечения.
Установим зависимости, которые необходимы для сборки (BuildRequires):
* утилита yum-builddep сама читает зависимости, необходимые для сборки и устанавливает недостающие пакеты.
Можно это сделать и вручную. В данном примере это:
* конкретно, в моем примере для установки hiredis-devel необходимо поставить репозиторий epel-release. Список пакетов, необходимый для сборки конкретного пакета необходимо уточнить в документации.
Теперь копируем исходник на свой компьютер. В моем примере клонируем репозиторий:
Если она пройдет без ошибок, мы должны найти RPM-пакет в каталоге rpmbuild/RPMS/x86_64, где x86_64 — архитектура пакета.
Описание файла SPEC
Данный файл является инструкцией по сборке пакета. В нем мы описываем сам пакет, задаем метаданные и указываем, как извлекать файлы и куда их копировать при установке пакета. Синтаксис файла включает такие элементы, как разделы, макросы, операторы, опции. Рассмотрим их отдельно.
Опции заголовка
Определяют описание пакета, а также некоторые важные для сборки параметры.
Сценарии
Мы можем описать команды, которые будут выполняться на конечном компьютере при установке или удалении пакета:
Сценарий
Описание
%pre
Выполняется перед установкой пакета в систему
%post
Выполняется после установки пакета в систему
%preun
Выполняется перед удалением пакета из системы
%postun
Выполняется после удаления пакета из системы
Макросы для сценариев
Внутри сценариев могут быть запущены свои макросы:
Макросы для команд
Некоторые системные команды лучше писать не напрямую, а через макросы. Это позволит добиться большей стабильности при сборке на различных системах. Приведем в пример данные команды:
Макросы для каталогов
Каталоги лучше писать не буквально, а через макросы:
Макрос
Путь
%
/usr
%
/usr
%
%<_prefix>/lib64
%
%<_prefix>/share
%
%
%
/etc
%
/var
%
/var
%
/var/lib
Операторы сравнения
SPEC файл позволяет задавать логику с помощью операторов сравнения. Приведем примеры их использования:
Пример
Описание
%if 0% = 0.13.3-1 %else Requires: hiredis %endif
В данном примере мы проверяем версию системы, на которой идет сборка. Если rhel (релиз системы) меньше 8, то мы указываем в качестве требования hiredis-last. В данном примере это имеет смысл, так как в CentOS 8 пакет hiredis-last переименовали в hiredis.
%if 0% == 8 . %endif
В данном условии мы проверяем, является ли версия релиза 8.
%if % != «el» . %endif
Проверяем значение переменной osname. Если она не равна «el», выполняем действие.
Возможные ошибки
Рассмотрим примеры ошибко, с которыми мы можем столкнуться.
Installed (but unpackaged) file(s) found
Ошибка появляется в конце процесса сборки пакета.
Причина: обнаружены файлы, которые были установлены с помощью make install, но которые не были перечислены в %files. Таким образом, сборщик пакета не знает, что с ними делать.
Решение: секция %files должна содержать все файлы, необходимые для работы приложения. Их нужно перечислить.
Но если у нас есть полная уверенность, что мы перечислили все необходимое, а оставшиеся файлы нам ни к чему, то добавляем в файл spec:
Полное имя формата файлов, которые используют расширение SPEC: RPM Specification Format. Формат файла SPEC совместим с программным обеспечением, которое может быть установлено на системной платформе Linux. SPEC файл относится к категории Файлы разработчика так же, как #NUMEXTENSIONS # других расширений файлов, перечисленных в нашей базе данных. Text editor является наиболее используемой программой для работы с SPEC файлами.
Программы, которые поддерживают SPEC расширение файла
Ниже приведена таблица со списком программ, которые поддерживают SPEC файлы. Файлы с расширением SPEC, как и любые другие форматы файлов, можно найти в любой операционной системе. Указанные файлы могут быть переданы на другие устройства, будь то мобильные или стационарные, но не все системы могут быть способны правильно обрабатывать такие файлы.
Программы, обслуживающие файл SPEC
Как открыть файл SPEC?
Отсутствие возможности открывать файлы с расширением SPEC может иметь различное происхождение. С другой стороны, наиболее часто встречающиеся проблемы, связанные с файлами RPM Specification Format, не являются сложными. В большинстве случаев они могут быть решены быстро и эффективно без помощи специалиста. Приведенный ниже список проведет вас через процесс решения возникшей проблемы.
Шаг 1. Скачайте и установите Text editor
Основная и наиболее частая причина, препятствующая открытию пользователями файлов SPEC, заключается в том, что в системе пользователя не установлена программа, которая может обрабатывать файлы SPEC. Решение этой проблемы очень простое. Загрузите Text editor и установите его на свое устройство. Полный список программ, сгруппированных по операционным системам, можно найти выше. Если вы хотите загрузить установщик Text editor наиболее безопасным способом, мы рекомендуем вам посетить сайт и загрузить его из официальных репозиториев.
Шаг 2. Обновите Text editor до последней версии
Вы по-прежнему не можете получить доступ к файлам SPEC, хотя Text editor установлен в вашей системе? Убедитесь, что программное обеспечение обновлено. Может также случиться, что создатели программного обеспечения, обновляя свои приложения, добавляют совместимость с другими, более новыми форматами файлов. Если у вас установлена более старая версия Text editor, она может не поддерживать формат SPEC. Самая последняя версия Text editor обратно совместима и может работать с форматами файлов, поддерживаемыми более старыми версиями программного обеспечения.
Шаг 3. Свяжите файлы RPM Specification Format с Text editor
Если проблема не была решена на предыдущем шаге, вам следует связать SPEC файлы с последней версией Text editor, установленной на вашем устройстве. Процесс связывания форматов файлов с приложением по умолчанию может отличаться в деталях в зависимости от платформы, но основная процедура очень похожа.
Изменить приложение по умолчанию в Windows
Изменить приложение по умолчанию в Mac OS
Шаг 4. Убедитесь, что SPEC не неисправен
Если проблема по-прежнему возникает после выполнения шагов 1-3, проверьте, является ли файл SPEC действительным. Вероятно, файл поврежден и, следовательно, недоступен.
Если SPEC действительно заражен, возможно, вредоносное ПО блокирует его открытие. Рекомендуется как можно скорее сканировать систему на наличие вирусов и вредоносных программ или использовать онлайн-антивирусный сканер. Если сканер обнаружил, что файл SPEC небезопасен, действуйте в соответствии с инструкциями антивирусной программы для нейтрализации угрозы.
2. Убедитесь, что структура файла SPEC не повреждена
Если файл SPEC был отправлен вам кем-то другим, попросите этого человека отправить вам файл. Возможно, файл был ошибочно скопирован, а данные потеряли целостность, что исключает доступ к файлу. Если файл SPEC был загружен из Интернета только частично, попробуйте загрузить его заново.
3. Проверьте, есть ли у вашей учетной записи административные права
Существует вероятность того, что данный файл может быть доступен только пользователям с достаточными системными привилегиями. Переключитесь на учетную запись с необходимыми привилегиями и попробуйте снова открыть файл RPM Specification Format.
4. Убедитесь, что ваше устройство соответствует требованиям для возможности открытия Text editor
Если в системе недостаточно ресурсов для открытия файлов SPEC, попробуйте закрыть все запущенные в данный момент приложения и повторите попытку.
5. Убедитесь, что у вас установлены последние версии драйверов, системных обновлений и исправлений
Регулярно обновляемая система, драйверы и программы обеспечивают безопасность вашего компьютера. Это также может предотвратить проблемы с файлами RPM Specification Format. Возможно, файлы SPEC работают правильно с обновленным программным обеспечением, которое устраняет некоторые системные ошибки.
Вы хотите помочь?
Если у Вас есть дополнительная информация о расширение файла SPEC мы будем признательны, если Вы поделитесь ею с пользователями нашего сайта. Воспользуйтесь формуляром, находящимся здесь и отправьте нам свою информацию о файле SPEC.
Основная и наиболее частая причина, препятствующая открытию пользователями файлов SPEC, заключается в том, что в системе пользователя не установлена программа, которая может обрабатывать файлы SPEC. Решение этой проблемы очень простое. Загрузите Text editor и установите его на свое устройство. Полный список программ, сгруппированных по операционным системам, можно найти выше. Если вы хотите загрузить установщик Text editor наиболее безопасным способом, мы рекомендуем вам посетить сайт и загрузить его из официальных репозиториев.
Вы по-прежнему не можете получить доступ к файлам SPEC, хотя Text editor установлен в вашей системе? Убедитесь, что программное обеспечение обновлено. Может также случиться, что создатели программного обеспечения, обновляя свои приложения, добавляют совместимость с другими, более новыми форматами файлов. Если у вас установлена более старая версия Text editor, она может не поддерживать формат SPEC. Самая последняя версия Text editor обратно совместима и может работать с форматами файлов, поддерживаемыми более старыми версиями программного обеспечения.
