Консультации и оказание технической поддержки по данной статье не предоставляются.
Вы можете подробнее ознакомиться с принципами сборки пакетов для РЕД ОС, просмотрев наши обучающие видео:
на RuTube — Курс по принципам сборки пакетов для РЕД ОС;
в Яндекс.Дзен — Курс по принципам сборки пакетов для РЕД ОС;
в VK Видео — Курс по принципам сборки пакетов для РЕД ОС.
На наших каналах вы также сможете найти много другой полезной информации.
Рассмотрим сборку пакета на примере проекта libfakekey.
1) Получите исходные тексты программы, скачав архив актуальной версии по следующей ссылке.
2) Получив исходный архив, распакуйте его командой:
tar -xf libfakekey-0.3.tar.gz
3) В полученном дереве исходного кода найдите файл INSTALL, в случае его отсутствия — README. В них, как правило, описаны инструкции по сборке проекта.
В данном случае файл INSTALL отсутствует, а README имеет нулевую длину, но имеется сценарий autogen.sh со следующим содержимым:
#! /bin/sh autoreconf -v --install || exit 1 ./configure --enable-maintainer-mode "$@"
Значит, необходимые файлы могут быть сгенерированы с помощью утилиты autoreconf, для чего необходимо установить в систему пакеты autoconf и automake, если они отсутствуют. Находясь в каталоге исходных текстов, выполните следующую команду:
autoreconf -fiv
Файл INSTALL совместно с другими файлами появится в данной директории. Изучите содержащиеся в нём инструкции по сборке пакета.
4) Поскольку в РЕД ОС сборка бинарных файлов осуществляется с использованием динамического связывания, то можно для сценария конфигурации использовать опцию отключения сборки статической версии (--disable-static). Также нужно указать, что при сборке проекта скомпилированные библиотеки необходимо компоновать с библиотеками X Window, для чего утилите make передайте указание на это (AM_LDFLAGS=-lX11).
5) Затем следует определиться с пакетами, необходимыми для сборки. Откройте файл fakekey/fakekey.h, в котором будет интересовать секция #include, находящаяся в его начале:
#ifndef _HAVE_LIBFAKEKEY_H #define _HAVE_LIBFAKEKEY_H #include <stdio.h> #include <stdlib.h> #include <X11/X.h> #include <X11/Xlib.h> #include <X11/Xlibint.h> #include <X11/Xutil.h> #include <X11/cursorfont.h> #include <X11/keysymdef.h> #include <X11/keysym.h> #include <X11/extensions/XTest.h> #include <X11/Xos.h> #include <X11/Xproto.h> #ifdef __cplusplus extern "C" { #endif
Здесь представляют интерес заголовочные файлы системы X11. Проверьте, какими пакетами они поставляются, для чего выполните операцию поиска по репозиторию, например:
dnf provides "*X11/Xlib.h"
Использование джокерного символа «*» обязательно, поскольку в метаданных пакета может храниться полный путь к файлу, а утилита dnf выводит результаты поиска при условии полного совпадения строк.
Таким образом, проверив все .h-файлы, будет выведен список из следующих пакетов:
libX11-devel, libXi-devel, libXtst-devel, xorg-x11-proto-devel
6) Имея полученную информацию, перед тем как приступить к написанию спецификации пакета, создайте структуру сборочных каталогов (см. статью «Сборочное окружение»):
rpmdev-setuptree
В каталог SOURCES скопируйте исходный архив, затем перейдите в директорию SPECS и создайте в нём заготовку спецификации (см. статью «Файл спецификации»):
rpmdev-newspec libfakekey libfakekey.spec created; type minimal, rpm version >= 4.13.
7) Откройте на редактирование файл libfakekey.spec в любом текстовом редакторе и начните заполнять преамбулу. Учтите, что пакет устанавливает в систему не только двоичные компоненты, но и файлы, необходимые для разработки программного обеспечения. Считается «хорошим тоном» файлы для разработчиков выносить в отдельный двоичный пакет — отразите это в спецификации.
0 # spec file for package libfakekey 1 Name: libfakekey 2 Version: 0.3 3 Release: 1%{?dist} 4 Summary: Library for converting characters to X key-presses 5 License: LGPLv2+ 6 URL: http://projects.o-hand.com/matchbox/ 7 Source0: %{name}-%{version}.tar.gz 8 BuildRequires: gcc 9 BuildRequires: make 10 BuildRequires: autoconf 11 BuildRequires: automake 12 BuildRequires: libX11-devel 13 BuildRequires: libXi-devel 14 BuildRequires: libXtst-devel 15 BuildRequires: xorg-x11-proto-devel 16 BuildRequires: pkgconfig 17 18 %description 19 libfakekey is a simple library for converting UTF-8 characters 20 into 'fake' X key-presses. 21 22 %package devel 23 Summary: Development files for %{name} 24 Requires: %{name} = %{version}-%{release} 25 Requires: libX11-devel 26 Requires: libXi-devel 27 Requires: libXtst-devel 28 Requires: xorg-x11-proto-devel 29 Requires: pkgconfig 30 31 %description devel 32 The %{name}-devel package contains libraries and header files for 33 developing applications that use %{name}. 34
Здесь в строке № 0 находится комментарий. В спецификации к таковым относится вся символьная последовательность от «#» до конца строки.
В строке № 4 даётся краткое описание, а в строках 18–20 — развёрнутое описание пакета, которые можно взять, например, с сайта проекта.
Имя исходного архива в строке № 7 задаётся через макросы (как показывалось в статье «Основные макросы»), что будет удобным при обновлении пакета до новой версии, так как директиву Source0 исправлять не придётся — достаточно будет изменить только версию пакета в директиве Version в начале файла.
В строках с 8 по 16 находится перечисление пакетов по одному в строке, которые необходимы для сборки данного пакета. Здесь пакет pkgconfig необходим для обработки файла libfakekey.pc.in, имеющегося в дереве исходного кода проекта.
С 22 по 33 строки производится описание второго двоичного пакета, который получит имя libfakekey-devel, с файлами для разработчиков. В секции его описания дополнительно указываются те пакеты, которые будут необходимы для его использования при разработке программного обеспечения — они заданы директивами Requires. Содержимое %description определяются самостоятельно, исходя из общего описания в предыдущей подобной директивы, с указанием на то, что здесь содержатся файлы для разработки.
8) Далее перейдем к телу спецификации (нумерация строк сквозная, с продолжением после преамбулы):
35 %prep 36 %setup -q 37 38 %build 39 %{_bindir}/autoreconf -fiv 40 %configure --disable-static 41 %make_build AM_LDFLAGS=-lX11 42 43 %install 44 %make_install 45 %{__rm} -f %{buildroot}%{_libdir}/libfakekey.la 46 47 %ldconfig_scriptlets 48 49 %files 50 %license COPYING 51 %{_libdir}/libfakekey.so.* 52 53 %files devel 54 %{_includedir}/fakekey/ 55 %{_libdir}/libfakekey.so 56 %{_libdir}/pkgconfig/libfakekey.pc 57 58 %changelog 59 * Sun Jan 19 2025 Rodion Alexeev - 0:0.3-1 60 - Initial build 70
Со строки № 35 начинается блок подготовки к сборке, в нём с помощью макроcа %setup производится распаковка архива с подавлением вывода на экран информации об извлечении файлов.
Со строки № 38 следует блок сборки проекта. Согласно файлу autogen.sh, требуется выполнить autoreconf, а после него — сгенерированный configure. Необходимо выполнить данные действия, но лучше это сделать не запуском сценария, а явным указанием этих команд в спецификации, поэтому в строке № 39 осуществляется выполнение утилиты autoconf, а в строке № 40 — configure посредством соответствующего макроса. После всего этого выполните сборку проекта утилитой make также посредством макроса (строка № 41).
Собранный проект необходимо установить, т. е. инсталлировать, за что отвечает блок %install со строки № 43. Типовая установка (make install) осуществляется посредством соответствующего макроса (строка № 44), а затем из дерева установки удаляется файл Libtool Archive (.la) за ненадобностью. Обращаем внимание, что все пути указаны как абсолютные и с помощью макросов!
Поскольку в пакете будет поставляться динамическая библиотека, то при её установке или удалении необходимо перестраивать кэш библиотек утилитой ldconfig — данные действия осуществляются с помощью скриптлетов %post и %postun, соответственно. Можно это оформить в следующем виде:
%post -p /sbin/ldconfig %postun -p /sbin/ldconfig
В РЕД ОС имеется скриптлет, объединяющий вышеуказанные действия, он использован в строке № 47.
Затем следуют блоки описания файлов, размещаемых в двоичных пакетах. Поскольку необходимо разделить проект на два RPM-файла, то и блоков %files у нас тоже два — со строки № 49 для libfakekey, со строки № 53 - для libfakekey-devel. В строке № 50 используется макрос для копирования и описания файла лицензии, в остальных строках (№ 51, 54–56) идёт перечисление файлов, которые будут принадлежать тому или иному пакету.
В данном примере количество двоичных файлов не велико и их названия и расположение можно посмотреть в Makefile, но в случае больших проектов это, скорее всего, не поможет в заполнении данного блока.
При написании спецификации «с нуля» можно поступить следующим образом - блоки %files оставить пустыми, перейти к заполнению следующего раздела, после выполнить первую сборку пакета. В конце сборки будет показано сообщение об ошибке, что имеются неупакованные в RPM файлы с выводом их полного списка. Из данного списка уже можно взять имена файлов и их местоположение и внести в блок %files, не забывая заменять реальные имена каталогов на макросы, их обозначающие.
Последний раздел тела спецификации — журнал изменений (%changelog) — начинается со строки № 58. Здесь указаны дата сборки пакета, автор сборки, а также список изменений (оно в данном примере одно — Initial build). Допускается (и считается «хорошим тоном») после имени автора указывать его адрес электронной почты в виде <box@domain.tld>.
Обратите внимание на окончание строки № 59: 0:0.3-1. Первая цифра до двоеточия — это эпоха (Epoch), которая явно в преамбуле не задана, и по умолчанию принимается равной 0. После двоеточия до символа «-» идёт указание версии пакета (Version), а после минуса — релиза (Release) без суффикса. Часто опускают указание эпохи, если она нулевая. Можно опустить и всю данную цифровую конструкцию, но не рекомендуется этого делать, поскольку становится не понятным, к какой конкретно сборке относится запись в журнале изменений.
9) Завершив редактирование файла спецификации, приступаем к сборке двоичного пакета командой:
rpmbuild -bb libfakekey.spec
Вывод информации на экран при работе данной команды весьма обширный, приведём только некоторые выдержки из него:
rpmbuild -bb libfakekey.spec Выполняется(%prep): /bin/sh -e /var/tmp/rpm-tmp.yqu3Ha + umask 022 + cd /home/user/rpmbuild/BUILD + cd /home/user/rpmbuild/BUILD + rm -rf libfakekey-0.3 + /usr/bin/gzip -dc /home/user/rpmbuild/SOURCES/libfakekey-0.3.tar.gz + /usr/bin/tar -xof - + STATUS=0 + '[' 0 -ne 0 ']' + cd libfakekey-0.3 + /usr/bin/chmod -Rf a+rX,u+w,g-w,o-w . + exit 0 ...
Выполняется(%build): /bin/sh -e /var/tmp/rpm-tmp.Im8Y8n + umask 022 + cd /home/user/rpmbuild/BUILD + cd libfakekey-0.3 + autoreconf -fiv ...
продолжение %build — запуск макроса %configure:
... + ./configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu --program-prefix= --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --disable-static
запуск макроса %make_build и завершение блока %build:
+ make -j2 AM_LDFLAGS=-lX11 make all-recursive make[1]: Entering directory '/home/user/rpmbuild/BUILD/libfakekey-0.3' ... + exit 0 ...
Выполняется(%install): /bin/sh -e /var/tmp/rpm-tmp.Y0WCvw + umask 022 + cd /home/user/rpmbuild/BUILD + '[' /home/user/rpmbuild/BUILDROOT/libfakekey-0.3-1.el7.x86_64 '!=' / ']' + rm -rf /home/user/rpmbuild/BUILDROOT/libfakekey-0.3-1.el7.x86_64 ++ dirname /home/user/rpmbuild/BUILDROOT/libfakekey-0.3-1.el7.x86_64 + mkdir -p /home/user/rpmbuild/BUILDROOT + mkdir /home/user/rpmbuild/BUILDROOT/libfakekey-0.3-1.el7.x86_64 + cd libfakekey-0.3 + make install DESTDIR=/home/user/rpmbuild/BUILDROOT/libfakekey-0.3-1.el7.x86_64 Making install in fakekey make[1]: Entering directory '/home/user/rpmbuild/BUILD/libfakekey-0.3/fakekey' ...
Processing files: libfakekey-0.3-1.el7.x86_64 Выполняется(%license): /bin/sh -e /var/tmp/rpm-tmp.W2BVTI + umask 022 + cd /home/user/rpmbuild/BUILD + cd libfakekey-0.3 + LICENSEDIR=/home/user/rpmbuild/BUILDROOT/libfakekey-0.3-1.el7.x86_64/usr/share/licenses/libfakekey + export LC_ALL=C + LC_ALL=C + export LICENSEDIR + /usr/bin/mkdir -p /home/user/rpmbuild/BUILDROOT/libfakekey-0.3-1.el7.x86_64/usr/share/licenses/libfakekey + cp -pr COPYING /home/user/rpmbuild/BUILDROOT/libfakekey-0.3-1.el7.x86_64/usr/share/licenses/libfakekey + exit 0 ...
Provides: libfakekey = 0.3-1.el7 libfakekey(x86-64) = 0.3-1.el7 libfakekey.so.0()(64bit) Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 Requires: libX11.so.6()(64bit) libXtst.so.6()(64bit) libc.so.6()(64bit) libc.so.6(GLIBC_2.2.5)(64bit) libc.so.6(GLIBC_2.4)(64bit) rtld(GNU_HASH) Processing files: libfakekey-devel-0.3-1.el7.x86_64 Provides: libfakekey-devel = 0.3-1.el7 libfakekey-devel(x86-64) = 0.3-1.el7 pkgconfig(libfakekey) = 0.3 Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 Requires: /usr/bin/pkg-config Processing files: libfakekey-debuginfo-0.3-1.el7.x86_64 Provides: libfakekey-debuginfo = 0.3-1.el7 libfakekey-debuginfo(x86-64) = 0.3-1.el7 Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 Проверка на неупакованный(е) файл(ы): /usr/lib/rpm/check-files /home/user/rpmbuild/BUILDROOT/libfakekey-0.3-1.el7.x86_64 Записан: /home/user/rpmbuild/RPMS/x86_64/libfakekey-0.3-1.el7.x86_64.rpm Записан: /home/user/rpmbuild/RPMS/x86_64/libfakekey-devel-0.3-1.el7.x86_64.rpm Записан: /home/user/rpmbuild/RPMS/x86_64/libfakekey-debuginfo-0.3-1.el7.x86_64.rpm ...
... Выполняется(%clean): /bin/sh -e /var/tmp/rpm-tmp.hlC2sW + umask 022 + cd /home/user/rpmbuild/BUILD + cd libfakekey-0.3 + /usr/bin/rm -rf /home/user/rpmbuild/BUILDROOT/libfakekey-0.3-1.el7.x86_64 + exit 0
В случае успешного завершения сборки в каталоге ~/rpmbuild/RPMS будут созданы подкаталоги с именами архитектур, под которые собрались RPM-файлы. В этих подкаталогах будут размещены двоичные пакеты:
ls -1Rp ~/rpmbuild/RPMS /home/user/rpmbuild/RPMS: x86_64/ /home/user/rpmbuild/RPMS/x86_64: libfakekey-0.3-1.el7.x86_64.rpm libfakekey-debuginfo-0.3-1.el7.x86_64.rpm libfakekey-devel-0.3-1.el7.x86_64.rpm
Здесь видно, что собрано три пакета, хотя в спецификации описывалось два. Дело в том, что перед упаковкой файлов в архив cpio сборочная система извлекает из двоичных файлов отладочную информацию, которая затем помещается в отдельный файл RPM, что отражается в его названии:
libfakekey-debuginfo-0.3-1.el7.x86_64.rpm
Данные пакеты не нужны рядовым пользователям, они востребованы разработчиками для отладки работы программного обеспечения.
10) После успешного завершения сборки двоичных пакетов необходимо собрать исходный пакет:
rpmbuild -bs libfakekey.spec Записан: /home/user/rpmbuild/SRPMS/libfakekey-0.3-1.el7.src.rpm
На этом процесс сборки проекта libfakekey завершён — в результате созданы как исходный, так и двоичные пакеты. Двоичные RPM можно передавать кому-либо для использования/установки, перед этим желательно подписать их своей цифровой подписью.
Дата последнего изменения: 06.05.2025
Если вы нашли ошибку, пожалуйста, выделите текст и нажмите Ctrl+Enter.
Нажимая «Отправить запрос», вы соглашаетесь с условиями обработки персональных данных.
Вы будете получать только актуальную информацию по обновлению безопасности
Подписываясь на уведомления, вы соглашаетесь с условиями обработки персональных данных.
На ваш почтовый адрес отправлено письмо с подтверждением подписки.