Linux сборка пакетов rpm

Руководство по сборке RPM-пакетов для дистрибутивов Альт

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

В тексте документации присутствуют ссылки на дополнительную информацию. Мы настоятельно рекомендуем Вам переходить по этим ссылкам и ознакомляться с материалами более подробно. Это поможет Вам лучше понимать темы, раскрытые в руководстве, и получить полезную дополнительную информацию.

PDF Версия

Структура документации

Перед тем, как приступить к сборке, нужно создать структуру каталогов, необходимую RPM, находящуюся в Вашем «домашнем» каталоге:

$ tree ~/RPM/ /home/user/RPM/ |-- BUILD |-- BUILDROOT |-- RPMS | |-- i586 | |-- x86_64 | `-- noarch |-- SOURCES |-- SPECS `-- SRPMS

Name: bello Version: Release: alt1 Summary:

• — команды без административных привилегий будут начинаться с символа “$”
• — команды с административными привилегиями будут начинаться с символа “#”

# control sudowheel enabled

Вклад в руководство

Вы можете внести свой вклад в это руководство, отправив запрос на принятие изменений (Pull Request) в репозиторий.

Установка необходимых пакетов для процесса сборки

Чтобы следовать данному руководству, Вам потребуется установить следующие пакеты:

# apt-get update Получено: 1 http://ftp.altlinux.org p10/branch/x86_64 release [4223B] Получено: 2 http://ftp.altlinux.org p10/branch/x86_64-i586 release [1665B] Получено: 3 http://ftp.altlinux.org p10/branch/noarch release [2844B] Получено 8732B за 0s (81,8kB/s). Найдено http://ftp.altlinux.org p10/branch/x86_64/classic pkglist Найдено http://ftp.altlinux.org p10/branch/x86_64/classic release Найдено http://ftp.altlinux.org p10/branch/x86_64/gostcrypto pkglist Найдено http://ftp.altlinux.org p10/branch/x86_64/gostcrypto release Найдено http://ftp.altlinux.org p10/branch/x86_64-i586/classic pkglist Найдено http://ftp.altlinux.org p10/branch/x86_64-i586/classic release Найдено http://ftp.altlinux.org p10/branch/noarch/classic pkglist Найдено http://ftp.altlinux.org p10/branch/noarch/classic release Чтение списков пакетов. Завершено Построение дерева зависимостей. Завершено # apt-get install gcc rpm-build rpmlint make python gear hasher patch rpmdevtools

Введение в пакетные менеджеры

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

• наборе макросов, используемых в .spec-файлах,
• различном поведении RPM при сборке «по умолчанию» — при отсутствии каких-либо указаний в .spec-файлах,
• формате строк зависимостей,
• мелких отличиях в семантике операций (например, в операциях сравнения версий пакетов),
• мелких отличиях в формате файлов.

Для пользователя различия чаще всего заключаются в невозможности поставить «неродной» пакет из-за проблем с зависимостями или из-за формата пакета.

RPM в проекте Сизиф также не является исключением. Основные отличия RPM в Альт и Сизиф от RPM других крупных проектов заключаются в следующем:

• обширный набор макросов для сборки различных типов пакетов,
• отличающееся поведение «по умолчанию» для уменьшения количества шаблонного кода в .spec-файлах,
• наличие механизмов для автоматического поиска межпакетных зависимостей,
• наличие так называемых set-version зависимостей (начиная с 4.0.4-alt98.46 ), обеспечивающих дополнительный контроль за изменением ABI библиотек,
• до p8 и выпусков 8.x включительно — очень древняя версия «базового» RPM (4.0.4), от которого началось развитие ветки RPM в Sisyphus (в Sisyphus и p9 осуществлён частичный переход на rpm 4.13 ).

Основные команды RPM

Для ознакомления с данным разделом потребуется пакет. В качестве примера мы будем использовать пакет Yodl-docs.

После скачивания пакета можно посмотреть данные о нём перед установкой. Для этого используется -qip, (Query|Install|Package)чтобы вывести информацию о пакете.

$ rpm -qip yodl-docs-4.03.00-alt2.noarch.rpm

Name : yodl-docs Epoch : 1 Version : 4.03.00 Release : alt2 DistTag : sisyphus+271589.100.1.2 Architecture: noarch Install Date: (not installed) Group : Documentation Size : 3701571 License : GPL Signature : DSA/SHA1, Чт 13 мая 2021 05:44:49, Key ID 95c584d5ae4ae412 Source RPM : yodl-4.03.00-alt2.src.rpm Build Date : Чт 13 мая 2021 05:44:44 Build Host : darktemplar-sisyphus.hasher.altlinux.org Relocations : (not relocatable) Packager : Aleksei Nikiforov Vendor : ALT Linux Team URL : https://gitlab.com/fbb-git/yodl Summary : Documentation for Yodl Description : Yodl is a package that implements a pre-document language and tools to process it. The idea of Yodl is that you write up a document in a pre-language, then use the tools (eg. yodl2html) to convert it to some final document language. Current converters are for HTML, ms, man, LaTeX SGML and texinfo, plus a poor-man's text converter. Main document types are "article", "report", "book" and "manpage". The Yodl document language is designed to be easy to use and extensible. This package contais documentation for Yodl.

Для установки используется параметр -ivh (Install|Verbose|Hash).

$ rpm -ivh yodl-docs-4.03.00-alt2.noarch.rpm

Источник

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

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

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

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

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

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

tasks: - name: 'Copy the artifact' copy: src: 'my_app' dest: '/usr/bin/my_app' - name: 'Copy configuration files' template: src: config.json dest: /etc/my_app/config.json 

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

 tasks: - name: 'Install my_app' yum: name: 'my_app' 

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

package main import ( "encoding/json" "flag" "fmt" "io/ioutil" "log" "net/http" ) type config struct < Text string `json:"string"` >func main() < var filename = flag.String("config", "config.json", "") flag.Parse() data, err := ioutil.ReadFile(*filename) if err != nil < log.Fatalln(err) >var config config err = json.Unmarshal(data, &config) if err != nil < log.Fatalln(err) >http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) < fmt.Fprintf(w, config.Text) >) log.Fatal(http.ListenAndServe(":8081", nil)) > 

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

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

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

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

[Unit] Description=My App [Service] Type=simple ExecStart=/usr/bin/my_app -config /etc/my_app/config.json [Install] WantedBy=multi-user.target 

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

1. Скомпилировать проект.
2. Скопировать его в /usr/bin/my_app .
3. Скопировать файл config.json в /etc/my_app/config.json .
4. Скопировать my_app.service в /etc/systemd/system/ .
5. Запустить сервис.

Создание .spec-файла

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

$ sudo dnf install git $ sudo dnf module install go-toolset $ sudo dnf groupinstall "RPM Development Tools" 

После того, как всё это установлено, мы готовы к тому, чтобы создать файл определений для пакета, известный ещё как .spec-файл:

Составить подобный файл может быть непросто. Нам, в деле создания этого файла, поможет утилита rpmdev-newspec . Вот его содержимое:

Name: my_app Version: 1.0 Release: 1% Summary: A simple web app License: GPLv3 Source0: %-%.tar.gz BuildRequires: golang BuildRequires: systemd-rpm-macros Provides: % = % %description A simple web app %global debug_package % %prep %autosetup %build go build -v -o % %install install -Dpm 0755 % %%/% install -Dpm 0755 config.json %%/%/config.json install -Dpm 644 %.service %%/%.service %check # go test should be here. :) %post %systemd_post %.service %preun %systemd_preun %.service %files %dir %/% %/% %/%.service %config(noreplace) %/%/config.json %changelog * Wed May 19 2021 John Doe - 1.0-1 - First release%changelog 

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

• Запись Source0 может представлять собой ссылку на репозиторий с исходным кодом. Например, она может выглядеть так: https://github.com/user/my_app/archive/v%version.tar.gz .
• Если в Source0 используется URL, то для загрузки исходного кода приложения можно воспользоваться командой spectool -g my_app.spec .
• Git позволяет быстро, не создавая удалённый репозиторий, генерировать tar-архивы:

$ git archive --format=tar.gz --prefix=my_app-1.0/ -o my_app-1.0.tar.gz HEAD 

$tar tf my_app-1.0.tar.gz my_app-1.0/ my_app-1.0/config.json my_app-1.0/main.go my_app-1.0/my_app.service 

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

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

$ rpmdev-setuptree $ mv my_app-1.0.tar.gz ~/rpmbuild/SOURCES 

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

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

$ sudo dnf install ~/rpmbuild/RPMS/x86_64/my_app-1.0-1.el8.x86_64.rpm $ sudo systemctl start my_app $ curl -L http://localhost:8081 

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

А что если появится новая версия нашего приложения? Как создать новый пакет для её установки? Сделать это очень просто — достаточно увеличить номер версии программы в .spec-файле и снова собрать пакет. А DNF обнаружит, что появилось обновление нашей программы.

А если вы пользуетесь репозиторием пакетов — нужно лишь выполнить команду dnf update my_app .

Итоги

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

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

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

Источник