Сборка пакета стороннего ПО

Рассмотрим сборку пакета на примере проекта 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

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 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 * Tue Jan 19 2021 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

Вывод информации на экран при работе данной команды весьма обширный, приведём только некоторые выдержки из него:

• начало сборки, выполнение блока %prep:

 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:

 Выполняется(%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:

 Выполняется(%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'
 ...  

• блок %files:

 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
 ... 

• после завершения всех действий, заданных в спецификации, сборочная система начинает анализировать полученные в ходе сборки файлы на предмет определения зависимостей (Requires), которые будут добавлены в метаданные пакета, чтобы пакетные менеджеры при установке данных RPM знали, что должно присутствовать в системе к моменту установки пакета, а в случае отсутствия — установить из репозитория. Также на данном этапе записывается в метаданные информация о компонентах, которые предоставляет пакет (Provides):

 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 можно передавать кому-либо для использования/установки, перед этим желательно подписать их своей цифровой подписью.

Дата последнего изменения: 04.10.2024

Если вы нашли ошибку, пожалуйста, выделите текст и нажмите Ctrl+Enter.