spec файл что это

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 CXXFLAGS=-O3 \
—prefix=$RPM_BUILD_ROOT/usr

В данном примере задействованы два параметра скрипта configure (флаги оптимизации компилятора и имя временного каталога сборки) и команда make (без параметра, то есть для цели all). Секция начинается строкой %build.

8.2.3.4 Секция install

Секция содержит команды установки файлов пакета в систему. Например:

Команды в этой секции вычищают файлы, созданные на других стадиях:

Секция начинается строкой %clean.

И, наконец, команды в секции files задают списки файлов и каталогов, которые с соответствующими атрибутами должны быть скопированы из дерева сборки в rpm-пакет и затем будут копироваться в целевую систему при установке этого пакета. Например:

Секция начинается строкой %files. Макрос %doc отмечает файлы документации. Это позволяет составить документацию из подходящих файлов проекта.

После окончания редактирования spec-файла осталось поместить его в каталог SPECS под /usr/src/redhat, а тарболл с исходным кодом в SOURCES. Все готово для сборки rpm.

Источник

Сборка пакетов библиотек для rpm-based дистрибутивов Linux

Во многих наших проектах используются open-source библиотеки. Когда разработка ведется под одну конкретную платформу, нет смысла собирать одни и те же библиотеки из исходников каждый раз, когда к проекту подключается новый разработчик. Кроме того, установка библиотек а-ля make && sudo make install считается плохим тоном, поскольку система засоряется «бесхозными» файлами, о которых нет информации в базе данных менеджера пакетов RPM.

В качестве решения предлагается из скомпилированных библиотек собирать RPM-пакеты и хранить их в едином репозитории, доступном для всех разработчиков. Ниже приводится инструкция и некоторые советы по сборке пакетов.

Инструкция будет основываться на примере Red Hat Enterprise Linux 6, но с небольшими изменениями ее можно будет адаптировать и для других дистрибутивов. Для примера будем собирать пакет из библиотеки zeromq.

Перед сборкой пакета

Первое, что нужно сделать перед сборкой — убедиться, что нужный вам пакет не собрал кто-то до вас. Часто на таких ресурсах, как rpmfind.net и rpm.pbone.net можно найти то, что вам нужно. Но если не нашлось необходимой версии библиотеки или нет сборки под вашу платформу, то придется собирать пакет самому.

rpmbuild

Создаем файл конфигурации утилиты rpmbuild, чтобы она узнала, где находится созданное дерево каталогов:

rpmbuild при запуске будет искать файлы пакета в директории

Итак, создаем директорию для zeromq в BUILDROOT:

Сборка библиотеки

Само собой, перед сборкой бинарного пакета, нужно скомпилировать саму библиотеку. Если библиотека использует систему сборки GNU Autotools, то обычно это делается командами:

Теперь устанавливаем библиотеку в созданную нами директорию в BUILDROOT:

Параметр DESTDIR не всегда обрабатывается в мейкфайлах. Например, qmake генерирует мейкфайлы, которые игнорируют этот параметр. Если библиотека использует систему сборки, отличную от GNU Autotools, то прочитайте в соответствующем руководстве, какие параметры нужно передать при сборке, чтобы установить библиотеку в указанную директорию.

spec-файл для сборки пакета

/rpmbuild/SPECS. Рассмотрим пример файла zmq.spec для библиотеки zeromq:

В начале файла указывается минимальный набор полей с информацией о пакете. Из значений первых трех полей (Name, Version, Release) формируется имя пакета, поэтому важно, чтобы там были указаны правильные значения. Если значения не будут соответствовать имени каталога с деревом файлов собираемого пакета, rpmbuild выдаст ошибку. Поле License также является обязательным — без него rpmbuild откажется собирать пакет.

Назначение секции %description очевидно. Секции %post и %postun содержат скрипты, выполняющиеся после установки файлов пакета в систему и после удаления файлов пакета из системы, соответственно. Это полезно, если пакет устанавливает динамические библиотеки (.so) в нестандартные директории (т. е. не в /lib, /usr/lib, /lib64 или /usr/lib64). В этом случае пакет должен предоставлять файл конфигурации для ldconfig и устанавливать его в /etc/ld.so.conf.d. Команда ldconfig обновляет кэш динамического загрузчика, добавляя в него все библиотеки, найденные в директориях, указанных в конфигурационных файлах.

В секции %files указывается список файлов, которые пакуются в rpm. Директива %defattr указывает атрибуты файлов по умолчанию в формате:

указывается в восьмеричном виде, например, «644» для rw-r—r—. Атрибут может быть опущен. Вместо атрибутов, которые не должны меняться для устанавливаемых файлов, можно указать дефис. Директории, указанные в секции %files, будут внесены в пакет вместе со всем их содержимым.

Дальше самое интересное. Фактически существует два типа RPM-пакетов библиотек. В одних находятся собственно сами файлы динамических библиотек, необходимые для работы программ, которые скомпонованы с этими библиотеками. Например, пакет zeromq-3.2.4-1.rhel6.x86_64.rpm предоставляет только два файла: /usr/lib64/libzmq.so.3.0.0 и символьную ссылку на него, /usr/lib64/libzmq.so.3. Другой тип пакетов содержит файлы, необходимые для разработки приложений с использованием предоставляемой библиотеки. К имени таких пакетов добавляется суффикс «-devel», например, zeromq-devel-3.2.4-1.el6.x86_64.rpm. В таких пакетах обычно содержатся заголовочные файлы C/C++, документация, статические библиотеки (.a), и эти пакеты являются зависимыми от пакетов первого типа.

В приведенном выше spec-файле директива %package позволяет собрать «дочерний» пакет одним запуском rpmbuild. Значения полей заголовков дочернего пакета наследуются от родительского, но их можно переопределить. Поле Requires задает дополнительную зависимость от родительского пакета. Заметьте, что секция %files пакета zeromq-devel содержит файл /usr/lib64/libzmq.so. Это символьная ссылка на настоящий файл с динамической библиотекой. Он необходим компоновщику ld на этапе сборки приложения с использованием библиотеки, поскольку он ищет файлы динамических библиотек, начинающиеся на «lib» и заканчивающиеся на «.so».

Сборка

Перед сборкой нужно иметь в виду две вещи.
Первое: при успешной сборке пакета rpmbuild очистит директорию BUILDROOT. Так что на всякий случай сделайте резервную копию пакетируемых файлов.
Второе: никогда не собирайте пакеты с правами root. Здесь объясняется, почему так нельзя делать.

Теперь все готово для сборки пакета. Запускаем rpmbuild:

В случае успеха полученный rpm-пакет будет сохранен в папке RPMS.

Пара советов

Если не знаете, что писать в полях заголовка spec-файла для пакетируемой библиотеки, можно взять RPM-пакет для другого дистрибутива c указанных выше ресурсов и посмотреть, что пишут там:

Здесь «q» означает «режим запросов (query)», «i» — получение информации о пакете, «p» — получение информации об указанном файле пакета (без этой опции будет получена информация о пакете, установленном в системе, если он установлен).

Если не знаете, какие файлы принадлежат пакету devel, а какие — пакету с библиотеками, но у вас есть оба пакета для другого дистрибутива, можно распаковать дерево файлов, предоставляемых данным пакетом, в текущую директорию:

Утилита rpm2cpio пишет в стандартный вывод cpio-архив, хранящийся в rpm-пакете; утилита cpio распаковывает архив, принятый из стандартного ввода. Параметр «i» включает режим распаковки, а «d» создает нужные директории.

Посмотреть, какие файлы предоставляет пакет, можно и не распаковывая его, с помощью опции «l»:

Источник

Структура RPM SPEC-файла

Содержание

Заголовок SPEC-файла

Заголовок SPEC-файла включает название, версию, релиз, макросы и описание собираемого пакета RPM.

Название, версия и релиз

Наиболее важной частью информации о пакете является Name, Version и Release (Имя, Версия и Релиз), так как эта информация критична для работы RPM и используется в механизмах сравнения версий и отслеживания изменений. Первый раздел должен содержать стандартные директивы: название, версия и релиз. Директивы задаются простым синтаксисом: имя поля, двоеточие, пробел, значение. Например:

Номера эпох задаются целым числом.

Определение макросов

Кроме задания различных значений можно определять макросы с использованием RPM-синтаксиса %define. Например:

Этот пример определяет макрос по имени major со значением 2. Однажды определив макрос, можно получать к нему доступ посредством инструкции % <имя_макроса>или, проще, %имя_макроса. Например:

Примечание: определенный явно макрос для названия, версии и релиза бесполезен, так как те неявно определяются соответствующими директивами.
Остальные возможности макроопределений обсуждаются ниже.

Главные секции SPEC-файла также маркируются разделителем %.

Описание пакета

Для задания национальных описаний используется синтаксис:

В секции %description используется некоторое количество опций форматирования. Пустые линии интерпретируются как разделители абзацев. Строки, начинающиеся с пробелов или табуляций, интерпретируются как предварительно отформатированные абзацы и отображаются как есть, как правило, моноширинным шрифтом.

Директива License: предоставляет правовую информацию о пакете.
Директива Group: задает классификатор пакета. Для классификаторов лучше использовать имеющиеся группы пакетов, определенные в системе.
Директива URL: предоставляет информацию о нахождении сетевого ресурса ПО (или его производителя).
Директива Source определяет источники исходного кода. Большинство пакетов имеют более одного источника исходного кода, к которым необходимо обращаться из SPEC-файла. Как правило, это tar.gz-архивы с файлами кода. Это могут быть архивы от вендора или загруженные с сайтов сторонних разработчиков. Также допустимо использовать ссылки на сетевые источники кода (FTP или HTTP). Однако RPM не загружает файлы по этим ссылкам, они нужны только для дальнейшего обращения к источнику кода. Код по-прежнему будет загружаться из каталога SOURCES по имени файла. Определять источники кода следует с помощью полей Source, начиная счет с 0. Если существует только один файл с исходниками, можно не указывать номер источника.

Довольно часто возникает необходимость исключить какие-то файлы исходного кода из src.rpm-пакета по соображениям проприетарности или чтобы сократить объем пакета. Для выполнения этой операции используется директива NoSource:

Данный пример означает, что из коллекции исходников, помещаемых в src.rpm будет исключен источник №3. Подобным же образом действует директива NoPatch, она позволяет не включать в пакет с исходным кодом патчи разработчика. Директивы NoSource: и NoPatch: принимают только один номер патча (файла исходного кода) за раз. Если необходимо исключить несколько источников, потребуется задать соответствующее количество строк.
Если в SPEC-файле присутствуют директивы NoSource: или NoPatch:, вместо src.rpm будет собран пакет nosrc.rpm.
Патчи (директива Path) именуются подобно исходному коду. Следует обратить внимание, что номера патчей могут образовывать увеличивающуюся последовательность, но не обязаны следовать подряд, один за другим. Кроме того, можно добавлять патчи и вручную. Патчи могут быть отдельными файлами или патчами, сжатыми gzip.

Окончательно заголовок SPEC-файла будет выглядеть так:

Сценарий сборки

Следующий обязательный раздел SPEC-файла – это раздел подготовки к сборке %prep. Он содержит инструкции для распаковки архива исходных кодов и, при необходимости, внесения в них изменений перед сборкой. В простейшем случае данный раздел включает всего две строки

Раздел %build отвечает за сборку пакета и в общем случае выглядит следующим образом :

Следующий раздел отвечает за установку программы и называется %install. В большинстве случаев установка выполняется при помощи команды make install, которой также передаётся переменная DESTDIR с указанием каталога назначения. Для этого служит макрос %makeinstall_std :

Комментарии

Комментарии отменяют действие единичного знака %. Например:

Источник

Spec файл что это

Построить пакеты 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.

Источник

Сборка собственного RPM-пакета, содержащего простую Go-программу

Процесс развёртывания программ обычно состоит из множества этапов. Некоторые из этих этапов могут представлять собой довольно-таки сложные последовательности действий. В наши дни имеется широкое разнообразие инструментов, позволяющих создавать описания процессов развёртывания программ, которые можно воспроизводить на разных системах.

А именно, в мире Linux уже довольно давно существуют менеджеры пакетов. Например — это RPM и YUM. Они упрощают установку, обновление и удаление программ в Linux-системах. Собственно говоря, в этой статье я хочу рассказать о том, как создать собственный простой RPM-пакет, хочу показать, что это совсем несложно.

Надо отметить, что во многих организациях менеджеры пакетов используются лишь для установки программ, предлагаемых разработчиком используемого этими организациями дистрибутива Linux. Для управления развёртываниями собственных программ менеджеры пакетов не применяются. Тому, кто попытается собрать свой первый RPM-пакет, может показаться, что это не так уж и просто. Но обычно тот, кто учится создавать такие пакеты, тратит время с пользой. Дело в том, что соответствующие знания способны помочь ему в деле оптимизации его рабочих процессов. Здесь мы рассмотрим процесс создания RPM-пакета, содержащего простую программу, написанную на Go.

Создание пакета

Во многих проектах для развёртывания ПО используют менеджеры конфигурации. Вот, например, как может выглядеть типичный плейбук Ansible:

Конечно, в плейбуках, применяющихся в реальных проектах, будет описано большее число этапов. Например, это может быть проверка ранее установленного ПО или управление сервисами. А почему бы не использовать нечто вроде следующей конструкции?

Теперь давайте посмотрим на наше Go-приложение. Это — простой сервер, поддерживающий работу веб-страницы. Вот код файла main.go :

Вот — содержимое config.json :

Добавление сервисов

А как насчёт сервисов? Использование сервисов — это отличный способ унификации управления приложением. Поэтому создадим файл my_app.service :

Каждый раз, когда мы соберёмся развернуть приложение, нужно будет выполнить следующие действия:

RPM, что характерно и для Ansible, нуждается в файле определений, в котором описываются этапы установки программы, её зависимости, и другие действия, которые может понадобиться выполнить для установки программы на сервер:

Тут мне хотелось бы обратить ваше внимание на несколько моментов:

Сборка RPM-пакета

Первым делом нам надо создать структуру директорий rpmbuild и поместить наш tar-архив в директорию SOURCES :

После этого соберём RPM-пакет для Red Hat Enterprise Linux 8:

Теперь у нас должна появиться возможность установить RPM-пакет и запустить наш сервис:

Если всё было сделано правильно, то, выполнив вышеописанную последовательность команд, вы должны увидеть содержимое файла config.json (который, кстати, находится в папке /etc/my_app ).

Итоги

Если вы хотите лучше разобраться с тем, как интегрировать RPM-файлы в свои рабочие процессы, советую взглянуть на это и это руководства.

Кроме того, существует множество восхитительных инструментов, способных помочь в деле сборки RPM-пакетов. Есть и инструменты, умеющие создавать репозитории, которыми может воспользоваться разработчик. Это, например, mock, fedpkg, COPR и Koji. Эти инструменты могут пригодиться в проектах, где реализуются сложные сценарии развёртывания ПО. Например — там, где есть множество зависимостей, где в процессе развёртывания имеются сложные этапы, или там, где нужна поддержка нескольких архитектур.

Применяете ли вы RPM-пакеты, созданные самостоятельно?

Источник