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

Создание RPM-пакетов с нуля на примерах

В данной инструкции мы научимся готовить Linux-среду для работы и рассмотрим примеры по созданию своих пакетов RPM. Мы будем работать в системе CentOS (Red Hat / Fedora).

Подготовка системы

Для работы по сборке пакетов лучше использовать отдельный компьютер, виртуальную машину или контейнер Docker.

1. Установим пакеты:

yum install rpmdevtools rpmlint

• rpmdevtools — позволит нам использовать утилиту rpmdev-setuptree, с помощью которой мы сможем создать рабочую среду в виде каталогов для сборки.
• rpmlint — позволяет протестировать пакет RPM.

yum group install «Development Tools»

* данная группа пакетов включает все необходимое для сборки. Ее не рекомендуется ставить на рабочий компьютер, так как устанавливается много ненужного для стандартной системы мусора.

2. Создаем пользователя.

Делать готовые установочные сборки пакетов очень опасно от пользователя root. Если мы допустим ошибку с путями, файлы могут перетереть или удалить важные для работы директории. Стоит создать отдельного пользователя и работать под ним. Однако, если мы работаем в виртуальной среде или контейнере Docker, нам это не страшно. Тогда данный пункт можно пропустить и работать из под root.

useradd builder -m

* в данном примере мы создадим пользователя builder. Опция -m сразу создаст домашний каталог для пользователя.

Теперь заходим под данным пользователем — последующие команды мы будем выполнять от него:

3. Создадим структуру каталогов для сборки:

В нашей текущем каталоге должна появиться папка rpmbuild — а в ней:

1. BUILD — содержит все файлы, которые появляются при создании пакета.
2. RPMS — сюда будут складываться готовые пакеты.
3. SOURCES — для исходников, из которых и будут собираться RPM-пакеты.
4. SPECS — для файлов с описанием процесса сборки.
5. SRPMS — для исходников RPM-файлов.

Мы готовы к сборке.

Сборка из исходников

Рассмотрим пример создания RPM из пакета, который нужно собирать из исходников с помощью команды make. Например, возьмем данную программу: github.com/brettlaforge/pg_redis_pubsub.

Создадим файл spec:

Теперь откроем его и приведем к виду:

Name: pg_redis_pubsub
Version: 1.0.2
Release: 1%
Summary: Redis Publish from PostgreSQL
License: X11 License
URL: https://github.com/brettlaforge/pg_redis_pubsub
Source0: %-%.tar.gz

BuildRequires: postgresql-devel postgresql-server-devel
BuildRequires: hiredis-devel
Requires: postgresql
%if 0% = 0.13.3-1
%else
Requires: hiredis = 0.15
%endif

%define _build_id_links none

%description
Redis Publish from PostgreSQL

%clean
% <__rm>-rf $RPM_BUILD_ROOT
% <__rm>-rf $RPM_BUILD_DIR/*

%files
%defattr(-,root,root)
%<_libdir>/pgsql/redis.so
%<_datadir>/pgsql/extension/redis.control
%<_datadir>/pgsql/extension/redis—0.0.1.sql
%doc %<_datadir>/doc/extension/redis.mmd

%changelog
* Fri Jul 9 2021 root
—

* чтобы понять, как заполнить spec-файл, рекомендуется для начала собрать и установить приложение вручную с помощью make и make install. Также необходимо изучить документацию устанавливаемого пакета или (при наличие возможности) поговорить с разработчиками программного обеспечения.

Установим зависимости, которые необходимы для сборки (BuildRequires):

* утилита yum-builddep сама читает зависимости, необходимые для сборки и устанавливает недостающие пакеты.

Можно это сделать и вручную. В данном примере это:

yum install epel-release

yum install postgresql-devel postgresql-server-devel hiredis-devel

* конкретно, в моем примере для установки hiredis-devel необходимо поставить репозиторий epel-release. Список пакетов, необходимый для сборки конкретного пакета необходимо уточнить в документации.

Теперь копируем исходник на свой компьютер. В моем примере клонируем репозиторий:

git clone https://github.com/brettlaforge/pg_redis_pubsub.git

Готовим архив и помещаем его в каталог rpmbuild/SOURCES:

tar -czvf rpmbuild/SOURCES/pg_redis_pubsub-1.0.2.tar.gz pg_redis_pubsub

Если бы в качестве Source мы указали внешний URL, можно было бы предварительно загрузить исходники командой:

spectool -g -R rpmbuild/SPECS/pg_redis_pubsub.spec

Данная команда разместит загруженные файлы в каталоге rpmbuild/SOURCES/.

Проверяем корректность SPEC-файла:

В моем примере команда вернула ответ:

rpmbuild/SPECS/pg_redis_pubsub.spec: W: invalid-url Source0: pg_redis_pubsub-1.0.2.tar.gz
0 packages and 1 specfiles checked; 0 errors, 1 warnings.

Данное предупреждение можно проигнорировать.

rpmbuild -bb rpmbuild/SPECS/pg_redis_pubsub.spec

Если она пройдет без ошибок, мы должны найти RPM-пакет в каталоге rpmbuild/RPMS/x86_64, где x86_64 — архитектура пакета.

Описание файла SPEC

Данный файл является инструкцией по сборке пакета. В нем мы описываем сам пакет, задаем метаданные и указываем, как извлекать файлы и куда их копировать при установке пакета. Синтаксис файла включает такие элементы, как разделы, макросы, операторы, опции. Рассмотрим их отдельно.

Опции заголовка

Определяют описание пакета, а также некоторые важные для сборки параметры.

Источник

Упаковка программ с помощью RPM, часть 1: Создание и распространение пакетов

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

Основным преимуществом программного обеспечения с открытым кодом является, как следует из названия, доступность внутренней информации об особенностях работы приложений. Имея исходный код, вы можете изучить, как приложение работает, изменить, улучшить и расширять его функции, заимствовать и повторно использовать код (в пределах лицензионного приложения), а также портировать приложение на новые и развивающиеся платформы.

Однако, такой либеральный подход требуется не всегда. Например, пользователь, возможно, не захочет заниматься созданием приложения из исходного кода. Вместо этого, он, возможно, захочет просто установить программное обеспечение точно так же, как и традиционные «коробочного» приложение: вставить носитель, запустить программу установки, ответить на несколько подсказок, и — вперед. В самом деле, для большинства пользователей предпочтительнее такое предварительно созданное программное обеспечение. Предварительно созданный код менее чувствителен к капризам системы и, следовательно, более устойчив и предсказуемым.

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

Поскольку в каждой операционной системе имеют свои особенности, пакет, как правило, подстраивается под конкретную систему. Кроме того, в каждой операционной системе имеется свой собственный менеджером пакетов — специальная утилита для добавления и удаления пакетов из системы. Например, в Linux системах, основанных на Debian, используется менеджер пакетов Advanced Package Tool (APT), а в системах Fedora Linux используется менеджер пакетов RPM. Менеджер пакетов исключает частичную и неправильную установку и «удаление» за счет того, что пакет автоматически добавляет и удаляет файлы. С помощью менеджера пакетов также поддерживается работа с манифестом — специальным описанием всех пакетов, установленных в системе, что позволяет знать о всех ранее установленных пакетах и особенностях, имеющихся в системе.

Если Вы разработчик программного обеспечения или системный администратор, предлагайте свое приложение в виде пакета, который облегчает установку, обновление и сопровождение приложения. В настоящей статье мы рассмотрим, как использовать популярный менеджер пакетов RPM и как с его помощью использовать утилиту. Для демонстрационных целей мы рассмотрим сетевую утилиту wget , которая загружает файлы из интернета. Утилита wget является полезной, но она обычно не входит в состав стандартных дистрибутивов (в дистрибутивах часто используется ее аналог — curl ). Не забывайте, что вы можете использовать RPM для распространения (дистрибуции) практически всего — скриптов, документации и данных, и выполнять практически любые задачи обслуживания.

Сборка утилиты wget вручную

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

1. Загрузка и распаковка исходного кода.
2. Конфигурирование средств сборки.
3. Сборка кода.
4. Установка программного обеспечения.

Вы можете загрузить последнюю версию исходного кода утилиты wget с сайта ftp.gnu.org (на момент написания статьи текущей версией была версия 1.12). Остальные шаги выполняются в командной строке так, как это показано в листинге 1.

Листинг 1: Установка утилиты wget

Команда ./configure опрашивает систему и устанавливает настройки компиляции в соответствие с обнаруженым аппаратным и программным обеспечением. Команда make компилирует код, а команда sudo make install устанавливает код в системные директории. По умолчанию используются директории, находящиеся в корне /usr/local, хотя вы можете изменить коневой директории с помощью параметра —prefix=/some/full/path/name , используемого в команде ./configure .

Для того, чтобы сделать так, чтобы этот процесс был выполнен менеджером пакетов RPM, вы помещаете исходный код в репозитарий и пишите конфигурационный файл, в котором указывается, где можно найти исходный код, который будет компилироваться, как собирать этот код и как его устанавливать. Конфигурационный файл, называемый файлом спецификаций, подается на вход утилиты rpmbuild . Файл спецификаций и двоичные файлы упаковываются утилитой rpmbuild в RPM пакет. Когда другой пользователь загружает ваш RPM пакет, утилита rpm читает файл спецификаций файлов и устанавливает пакет в соответствие с предварительно записанной инструкцией.

Создаем наш первый пакет RPM

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

Для того, чтобы создать пакет RPM, вы должны:

• Создать иерархию директориев в соответствие со спецификациями утилиты rpmbuild .
• Поместить исходный код и дополнительные файлы в надлежащие места в этой иерархии.
• Создать файл спецификаций.
• Собрать пакет RPM. Дополнительно вы собрать пакет RPM исходных кодов (source RPM) для того, чтобы разрешить другим пользоваться исходным кодом.

Сначала создадим эту иерархию. В вашем домашнем директории, скажем, $HOME/mywget, создадим следующие пять поддиректорий:

• BUILD. Директорий BUILD используется для компилирования программного обеспечения.
• RPMS. В директории RPMS содержится бинарный пакет RPM, который создается утилитой rpmbuild .
• SOURCES. Директорий SOURCES используется для исходных кодов.
• SPECS. В директории SPECS находится ваш файл спецификаций или несколько файлов спецификаций — по одному для каждого пакета RPM, который вы хотите собрать.
• SRPMS. В директории SRPMS хранится пакет RPM с исходными кодами, который был создан в процессе сборки.

Как минимум, вам потребуется исходный код в директории SOURCES и файл спецификаций в директории SPECS.

Скопируйте ваш ваш исходный код, в идеале он должен иметь вид tar архива (tarball), в директорий SOURCES так, как это показано в листинге 2. При необходимости переименуйте архив так, чтобы в его имени был указан номер версии приложения с тем, чтобы можно было отличить текущую версию от других версий. В соответствие с общепринятым соглашением имя должно иметь вид пакет-версия .tar.gz. В случае с утилитой wget , вы должны выполнить следующее:

Листинг 2: Копируем ваш исходный код

Затем, создаем файл спецификаций. Файл спецификаций является ничем иным, как обычным текстовым файлом, имеющим специальный синтаксис. В листинге 3 показан пример файла спецификаций.

Листинг 3: Пример файла спецификаций

Давайте просмотрим файл спецификаций с начала и до конца. В строках с 1 по 5 определен набор удобных переменных, которые используются в остальной части файла. В строках с 7 по 15 задается ряд требуемых параметров, для этого используется формат параметр:значение. В строке 7 и в других местах показывается как можно получать настроечные значения в зависимости от значений отдельных переменных их их совокупности.

Параметр names в значительной степени понятен сам по себе, но параметр BuildRoot заслуживает некоторого пояснения с тем, чтобы отличать его от директория BUILD, который вы уже создали. BuildRoot является прокси элементом для указания окончательного директория установки. Иными словами, если wget, в конечном счете устанавливается в /usr/local/bin/wget и в другие поддиректории в /usr/local, такие как /usr/local/man для документации, BuildRoot служит в качестве указателя на /usr/local в процессе сборки пакета RPM. Как только вы зададите значение BuildRoot , вы сможете получать его значение, используя переменную среды RPM_BUILD_ROOT . Вы должны всегда устанавливать значение BuildRoot в вашем файле спецификаций и проверить что происходит, когда устанавливается пакет.

Имеется несколько особенностей:

• Не используйте ./configure —prefix=$RPM_BUILD_ROOT . С помощью этой команды будет создан весь пакет с предположением, что окончательное место расположения файлов будет находиться в корневом директории сборки пакета. Почти наверняка это приведет к сбою в работе любой программы, которая попытается в время своего исполнения разместить файлы, поскольку когда ваш пакет RPM будет окончательно будет установлен в систему пользователя, файлы уже не будут находиться в корневом директории сборки проекта — это всего лишь временный директорий в вашей системе, в которой происходит создание пакета.
• Не указывайте путь в определении переменной Source.
• Переменные Version (версия) и Release (релиз) исключительно важны. Каждый раз, когда вы меняете исходный код или данные в вашем приложении и делаете доступным новый пакет RPM, убедитесь в том, что изменили значения переменных Version и Release в соответствие с существенными или незначительным изменениям. Даже в том случае, если вы собираете пакет RPM для собственных нужд, вы можете посчитать нужным каждый раз, когда вы собираете пакет RPM увеличивать номер релиза для того, чтобы отличать вариант от варианта.

Следующий раздел начинается с %description . Сюда вы должны поместить краткое, но ясное описание программы. Эта будет выдаваться всякий раз, когда вы будете запускать команду rpm -qi для того, чтобы сделать запрос к базе данных RPM. Вы можете указать, что делает пакет, указать какое-нибудь предупреждение или привести дополнительные инструкции по установке, и т.п.

Далее последовательно идут разделы %prep , %build и %install . В каждом разделе создается шелл скрипт, который добавляется в пакет RPM и последовательно исполняется как часть процесса установки. В разделе %prep указываются операции по подготовке исходного кода, такие, как распаковка tar архива. Указанная здесь команда %setup -q является макрооперацией раздела %prep , которая автоматически распаковывает tar архив с именем, указанным в переменной Source.

Инструкции в разделе %build будут выглядеть аналогичным образом. Они идентичны тем пошаговым операциям, которые делали при ручном конфигурировании и сборке пакета. Раздел %install также идентичен. Однако, если при ручной сборке целевым директорием был директорий /usr/local в вашей системе, то целевой директорий инструкции %install это директорий

В разделе %files перечисляются файлы, которые должны быть добавлены в пакет RPM и дополнительно можно задать права доступа, а также указать другую информацию. Внутри раздела %files , вы можете использовать макрокоманду %defattr , с помощью которой задаются права доступа, владелец и группа, используемые по умолчанию для файлов, входящих с состав пакета RPM; в нашем примере команда %defattr(-,root,root) устанавливает для всех файлов владельца root независимо от того, кто был владельцем, когда они были взяты из системы при сборке пакета RPM.

В разделе %files вы можете указать несколько файлов — по одному файлу в каждой строке. Вы можете пометить файлы, указав в строке %doc или %config . Пометка %doc укажет менеджеру RPM, что это файл с документацией, так что если пользователь устанавливает пакет с указанием параметра —excludedocs , этот файл устанавливаться не будет. Пометка %config укажет менеджеру RPM, что это конфигурационный файл. Во время обновления пакета менеджер RPM попытается избежать замены конфигурации, аккуратно сделанной пользователем, на конфигурацию, указанную в пакете RPM как используемую по умолчанию.

Имейте в виду, что если вы в разделе %files укажите имя директория, то в пакет RPM будут включены все файлы, содержащиеся в этом каталоге.

Собираем пакет RPM

Теперь, когда ваши файлы находятся на должном месте и определен файл спецификации, вы готовы собрать файл RPM. Для того, чтобы его собрать, используйте утилиту rpmbuild с надлежащим образом указанными параметрами:

В указанной выше команде используется файл спецификаций для того, чтобы собрать бинарный пакет ( -bb — «build binary», т. е. собрать бинарный) с подробной выдачей диагностических сообщений ( -v ). Утилита сборки удалит дерево сборки после того, как пакеты будут собраны ( —clean ). Если вы хотите также собрать пакет RPM с исходными кодами, то укажите -ba («build all» — собрать все) вместо -bb. Полный список параметров смотрите на страницах man утилиты rpmbuild .

Утилита rpmbuild выполняет следующие операции:

• Читает и анализирует файл спецификаций wget.spec.
• Выполняет операции раздела %prep — распаковывает исходный код во временный директорий. В нашем случае временный директорий — BUILD.
• Выполняет операции раздела %build — компилирует исходный код.
• Выполняет операции раздела %install — устанавливает код в директории на машине, где собирается пакет.
• Читает список файлов из раздела %files , находит их и создает бинарный пакет RPM (и пакет RPM с исходными кодами, если это выбрано).

Если вы проверите ваш директорий $HOME/mywget, вы должны найти в нем новый директорий с именем wget-1.12-root.Этот директорий выполняет роль прокси для целевого директория. Вы также должны обнаружить новый директорий с именем RPMS/i386, в котором должен находиться ваш пакет RPM, имеющий имя wget-1.12-1.i386.rpm. В имени отражается, что это версия 1.12 утилиты wget , предназначенной для работы на процессоре i386

Для того, чтобы проверить, что в пакете RPM имеются все нужные файлы, вы можете использовать команду rpm так, как это показано в листинге 4.

Листиег 4: Проверяем содержимое пакета RPM

С помощью команды rpm -Vp RPMS/i386/wget-1.12-1.i386.rpm проверяется, какие файлы были добавлены в пакет. Хотя видно, что в выходном потоке указывается о большом количестве ошибок, с помошьюэтой команды можно проверить, что содержимое пакета RPM было правильное. Если вы ожидаете, что файл должен быть установлен, но его нет в выходном списке, то это означает, что он не включен в пакет. В подобном случае проверьте файл спецификаций и удостоверьтесь, что файл указан в разделе %files .

После того, как вы проверили содержимое пакета RPM, вы можете отправить его своим коллегам. Как только коллеги получат файл, они могут запустить следующую команду rpm для того, чтобы установить утилиту wget в своих системах:

Другие варианты использования пакетов RPM

Это краткое вступление лишь малое упоминаете того, что можно делать с помощью RPM. Хотя эта технология наиболее часто используется для установки программного обеспечения и сопутствующих файлов, вы можете упаковывать все, что угодно — от системных скриптов и исходного кода и до документации. И, как вы увидите, во второй статье данной серии, вы можете использовать технологию RPM для пропатчивания исходного кода, а также восстановления и переустановки программ. Формат, в котором распространяются пакеты RPM, поддерживается во многих системах Linux и он является основным, используемым для установки бинарных программ на системах Red Hat, Fedora и некоторых других.

Источник