Создание rpm пакетов. Создание RPM пакетов из исходников

29.06.2020

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

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

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

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

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

rpmbuild

Сборка пакетов осуществляется с помощью утилиты rpmbuild . Перед ее использованием необходимо сконфигурировать окружение сборки. Создадим необходимое дерево каталогов, например, в директории ~/rpmbuild:

$ mkdir ~/rpmbuild $ mkdir ~/rpmbuild/{BUILD,BUILDROOT,RPMS,SOURCES,SPECS,SRPMS}

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

$ echo "%_topdir %(echo $HOME)/rpmbuild" >~/.rpmmacros

rpmbuild при запуске будет искать файлы пакета в директории ~/rpmbuild/BUILDROOT/<имя_пакета>. Разберемся, как именуются RPM-пакеты, на примере zeromq:

zeromq-3.2.4-1.rhel6.x86_64.rpm

  • zeromq - собственно, имя пакетируемого ПО;
  • 3.2.4 - версия ПО;
  • 1.rhel6 - номер сборки пакета (release number) - сколько раз данная версия ПО собиралась в rpm-пакет. Суффиксом rhel6 или el6 обычно обладают пакеты для Red Hat Enterprise Linux 6;
  • x86_64 - процессорная архитектура, под которую скомпилировано ПО.

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

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

$ mkdir ~/rpmbuild/BUILDROOT/zeromq-3.2.4-1.rhel6.x86_64

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

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

$ ./configure $ make

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

$ make install DESTDIR="$HOME/rpmbuild/BUILDROOT/zeromq-3.2.4-1.rhel6.x86_64"

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

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

В RPM-пакетах помимо заархивированного дерева файлов хранится метаинформация об этом пакете. При сборке она должна задаваться в spec-файле, который находится в папке ~/rpmbuild/SPECS. Рассмотрим пример файла zmq.spec для библиотеки zeromq:

Name: zeromq Version: 3.2.4 Release: 1.rhel6 Summary: Software library for fast, message-based applications Packager: My organization Group: System Environment/libraries License: LGPLv3+ with exceptions %description The 0MQ lightweight messaging kernel is a library which extends the standard socket interfaces with features traditionally provided by specialized messaging middle-ware products. 0MQ sockets provide an abstraction of asynchronous message queues, multiple messaging patterns, message filtering (subscriptions), seamless access to multiple transport protocols and more. This package contains the ZeroMQ shared library for versions 3.x. %post /sbin/ldconfig %postun /sbin/ldconfig %files %defattr(-,root,root) /usr/lib64/libzmq.so.3 /usr/lib64/libzmq.so.3.0.0 %package devel Summary: Development files for zeromq3 Group: Development/Libraries Requires: %{name} = %{version}-%{release} %description devel The zeromq3-devel package contains libraries and header files for developing applications that use zeromq3 3.x. %files devel %defattr(-,root,root) /usr/include /usr/share /usr/lib64/pkgconfig /usr/lib64/libzmq.so /usr/lib64/libzmq.a /usr/lib64/libzmq.la

В начале файла указывается минимальный набор полей с информацией о пакете. Из значений первых трех полей (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 указывает атрибуты файлов по умолчанию в формате:

%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:

$ cd ~/rpmbuild/SPECS $ rpmbuild -bb zmq.spec

Параметр -bb означает «build binary», то есть, собрать бинарный пакет. Помимо бинарных пакетов есть еще пакеты исходных кодов, но они здесь не обсуждаются.

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

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

$ rpm -qip package.rpm

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

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

$ rpm2cpio package.rpm | cpio -di

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

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

$ rpm -qfp package.rpm

Итого

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

Внимание! Действия пунктов 1 и 4 настоящей инструкции выполняются с административными правами (root)!

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

# apt-get install rpm-build

2. Установка src.rpm пакета нужного ПО, которое требуется собрать

Находим и качаем src.rpm пакет нужного ПО, которое будем собирать, и устанавливаем его (от пользователя!):

$ rpm -i название_пакета_с_версией.src.rpm

При этом исходники (исходный код) пакета разместятся в ~/RPM/SOURCES , а спек - в ~/RPM/SPECS .
Наличие исходного кода программного обеспечения и спека, т.е. описания процесса сборки, является необходимым и достаточным условием для сборки rpm пакета (или пересборки, например, пакета из более нового бранча для более старого).

3. Сборка пакета

Приступаем к сборке, делается это командой:

$ rpm -ba --target (i586|x86_64) ~/RPM/SPECS/имя_спека_нужного_пакета_для_сборки.spec

При этом необходимо раскрыть скобки в зависимости от архитектуры, под которую происходит сборка пакета.

Собранные пакеты разместятся в ~/RPM/RPMS .

Примечание:

Пересобрать пакет без его установки (распаковки) можно и так:

$ rpmbuild --rebuild --target (i586/x86_64) название_пакета_с_версией.src.rpm

При этом необходимо также раскрыть скобки в зависимости от архитектуры, под которую происходит сборка пакета.

Примечание: Что касается процессоров, не относящихся к семейству x86_64, то само по себе указание "--target i586" опционально (сборка отработает и без него, но при этом компилятор соберет пакет, точно заточенный под Ваш тип процессора и наименование пакета будет отличаться от наименования пакетов бранчей, к примеру, xxx.athlon.rpm или xxx.pentium4.rpm). Отсутствие параметра "--target i586" при сборке совершенно не гарантирует устанавливаемость собранного таким образом пакета на другом компьютере с другим процессором. Если же сборка совершается под 64-битную систему (на 64-битном процессоре с установленной 64-битной системой), то ключ "--target x86_64" теряет свой смысл и ставить его совершенно не обязательно.

Примечание: Если rpm ругается на не найденные макросы примерно так: "ошибка: Macro %groupadd not found" или "ошибка: Macro %license not found", то помочь в дальнейшей сборке пакета должна установка в систему одного из пакетов rpm-build-* , который, фактически, является дополнительной зависимостью для сборки (пересборки) вашего пакета и отвечает за присвоение требуемых значений этим самым не найденным макросам.

4. Установка сборочных зависимостей

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

# apt-get build-dep название_пакета_с_версией.src.rpm

Если srpm пакета нет и имеется отдельно спек и исходный код, то почти 100% сборка сразу не пойдёт - в самом начале вывода в консоли будут показаны пакеты, которые должны быть установлены в систему, прежде чем сборка сможет пойти далее. Вы их (эти выведенные в консоль зависимости сборки) установите

# apt-get install пакет1 пакет2 пакет3 ...

а после повторите сборку (возврат к шагу 3).

5. Автоматический поиск зависимостей для вновь собираемого пакета

Если вы собираете новый пакет, а не пересобираете уже существующий srpm, то хорошим подспорьем в рамках оформления (поиска и прописывания) нужных зависимостей в спек вам послужит утилита buildreq из пакета rpm-utils :

$ buildreq имя_спек_файла.spec

Но часто бывает так, что вам необходимо собрать пакет с необходимыми опциями (включить поддержку mysql, postgresql или cyrus-sasl2 и т.п.), которые отсутствуют в rpm пакете, поставляемом на диске с дистрибутивом. Выходом из этой ситуации является сборка своего собственного пакета.

Для облегчения сборки rpm пакетов существует специально предназначенный для этих целей пакет - rpm-build.

# rpm -qi rpm-build Name: rpm-build Relocations: (not relocatable) Version: 4.3.3 Vendor: CentOS Release: 7_nonptl Build Date: Пнд 21 Фев 2005 20:21:52 Install Date: Сбт 09 Апр 2005 22:14:57 Build Host: guru.build.karan.org Group: Development/Tools Source RPM: rpm-4.3.3-7_nonptl.src.rpm Size: 1576124 License: GPL Signature: DSA/SHA1, Вск 27 Фев 2005 00:36:59, Key ID a53d0bab443e1821 Packager: Karanbir Singh

Как видно из описания этот пакет содержит набор скриптов и программ, предназначенных для сборки пакетов.

Для того, чтобы собрать какой-либо пакет для начала необходимо загрузить т.н. исходники для сборки пакета, как правило, это файлы с расширением src.rpm. Иногда, как в случае с courier-imap, spec файл включается в исходные коды.

Очень удобным для поиска rpm и src.rpm пакетов является сайт www.rpmfind.net . Например, мы нашли необходимый нам пакет - postfix, squid и т.д. Мы сразу можем узнать какие пакеты, необходимы для его сборки. Вот стандартная страница с информацией о пакете для postix и для squid . Также там указывается контрольная сумма для проверки целостности пакета.

После того, как мы получили исходники и проверили их целостность, необходимо установить соответствующий пакет.

# rpm -ivh postfix-2.2.8-1.2.src.rpm 1:postfix ###########################################

После выполнения данной операции исходники postfix и все необходимые пачти, а также скрипты были установлены в /usr/src/redhat/SOURCES/, а spec файл (инструкция для сборки rpm пакета) в /usr/src/redhat/SPECS/.

# ls /usr/src/redhat/SOURCES/ pflogsumm-1.1.0.tar.gz postfix-etc-init.d-postfix postfix-2.1.1-config.patch postfix-hostname-fqdn.patch postfix-2.1.1-obsolete.patch postfix-large-fs.patch postfix-2.1.5-aliases.patch postfix-pam.conf postfix-2.2.5-cyrus.patch postfix-sasl.conf postfix-2.2.8.tar.gz README-Postfix-SASL-RedHat.txt postfix-alternatives.patch # ls /usr/src/redhat/SPECS/ postfix.spec

Это стандартное месторасположение файлов при установке src.rpm. В принципе названия папок говорят сами за себя.

И так, для того, чтобы начать собирать пакет необходимо перейти в папку с spec файлом и выполнить следующую команду

# cd /usr/src/redhat/SPECS/ # rpmbuild -ba --target=i686 postfix.spec Платформы для сборки: i686 Сборка для платформы i686 Выполняется(%prep): /bin/sh -e /var/tmp/rpm-tmp.82019 + umask 022 + cd /usr/src/redhat/BUILD + umask 022 + cd /usr/src/redhat/BUILD + rm -rf postfix-2.2.8 + /bin/gzip -dc /usr/src/redhat/SOURCES/postfix-2.2.8.tar.gz + tar -xf - + STATUS=0 + "[" 0 -ne 0 "]" + cd postfix-2.2.8 ++ /usr/bin/id -u + "[" 0 = 0 "]" + /bin/chown -Rhf root . ++ /usr/bin/id -u + "[" 0 = 0 "]" + /bin/chgrp -Rhf root . + /bin/chmod -Rf a+rX,u+w,g-w,o-w . + echo "Patch #1 (postfix-2.1.1-config.patch):" Patch #1 (postfix-2.1.1-config.patch): + patch -p1 -b --suffix .config -s ... ... ... Записан: /usr/src/redhat/SRPMS/postfix-2.2.8-1.2.src.rpm Записан: /usr/src/redhat/RPMS/i686/postfix-2.2.8-1.2.i686.rpm Записан: /usr/src/redhat/RPMS/i686/postfix-pflogsumm-2.2.8-1.2.i686.rpm Выполняется(%clean): /bin/sh -e /var/tmp/rpm-tmp.73987 + umask 022 + cd /usr/src/redhat/BUILD + cd postfix-2.2.8 + /bin/rm -rf /var/tmp/postfix-buildroot + exit 0

Из последних строчек видно, что готовый rpm пакет называется postfix-2.2.8-1.2.i686.rpm и сохранен в папке /usr/src/redhat/RPMS/i686/, так как при сборке пакета мы указали ключ --target=i686.

Собственно сборка не должна вызвать никаких проблем. Но что если нам необходимо собрать пакет со своими опциями, например, включить поддержку mysql или sasl2 и т.п.? Для этих целей необходимо будет подправить spec файл.

Рассмотрим часть spec файла postfix, надо заметить, что у postfix так сказать нестандартный spec файл.

Например, мы захотели собрать postfix с поддержкой MySQL, для этого в самом начале меняем %define MYSQL 0 на %define MYSQL 1. и снова выполняем команду

# rpmbuild -ba --target=i686 postfix.spec Платформы для сборки: i686 Сборка для платформы i686 ошибка: Неудовлетворенные зависимости сборки: mysql-devel нужен для postfix-2.2.8-1.2.i686

Он нам пишет, что для сборки необходимо установить пакет mysql-devel. Обратите внимание, что версия не указывается, это значит, что можно установить любую версию, которую поддерживает postfix или нужный вам пакет.

Если бы вы собирали из исходных кодов, то вам пришлось бы самому искать, какие пакеты необходимы для сборки данного пакета. В этом и заключается одно из преимуществ сборки из src.rpm по сравнению с tar.gz или tar.bz2.

Устанавливаем соответствующий пакет

# rpm -ivh MySQL-devel-4.1.9-0.i386.rpm Подготовка... ########################################### 1:MySQL-devel ###########################################

И заново запускаем сборку postfix. На этот раз мы видим, что все необходимые пакеты для сборки установлены и теперь необходимо, лишь дождаться окончания сборки.

# rpmbuild -ba --target=i686 postfix.spec Платформы для сборки: i686 Сборка для платформы i686 Выполняется(%prep): /bin/sh -e /var/tmp/rpm-tmp.86320 + umask 022 + cd /usr/src/redhat/BUILD + umask 022 + cd /usr/src/redhat/BUILD + rm -rf postfix-2.2.8 ... ... ... Записан: /usr/src/redhat/SRPMS/postfix-2.2.8-1.2.src.rpm Записан: /usr/src/redhat/RPMS/i686/postfix-2.2.8-1.2.i686.rpm Записан: /usr/src/redhat/RPMS/i686/postfix-pflogsumm-2.2.8-1.2.i686.rpm Выполняется(%clean): /bin/sh -e /var/tmp/rpm-tmp.52381 + umask 022 + cd /usr/src/redhat/BUILD + cd postfix-2.2.8 + /bin/rm -rf /var/tmp/postfix-buildroot + exit 0

Все пакет у нас собран, теперь необходимо установить его и радоваться жизни.

# rpm -ivh /usr/src/redhat/RPMS/i686/postfix-2.2.8-1.2.i686.rpm Подготовка... ########################################### 1:postfix ###########################################

Для лучшего понимания рассмотрим сборку squid, который имеет более стандартную структуру spec файла. Как всегда для начала устанавливаем src.rpm, при этом не забываем проверить размер и контрольную сумму.

# rpm -ivh squid-2.5.STABLE11-2.src.rpm 1:squid ###########################################

Узнать все возможные ключи можно следующим образом.

# cd /usr/src/redhat/SPECS # rpmbuild --bp squid.spec # cd ../BUILD/squid-2.5.STABLE11/ # ./configure --help Usage: configure Options: Configuration: --cache-file=FILE cache test results in FILE --help print this message --no-create do not create output files --quiet, --silent do not print `checking..." messages --site-file=FILE use FILE as the site file --version print the version of autoconf that created configure Directory and file names: --prefix=PREFIX install architecture-independent files in PREFIX --exec-prefix=EPREFIX install architecture-dependent files in EPREFIX --bindir=DIR user executables in DIR --sbindir=DIR system admin executables in DIR --libexecdir=DIR program executables in DIR --datadir=DIR read-only architecture-independent data in DIR --sysconfdir=DIR read-only single-machine data in DIR --sharedstatedir=DIR modifiable architecture-independent data in DIR --localstatedir=DIR modifiable single-machine data in DIR --libdir=DIR object code libraries in DIR --includedir=DIR C header files in DIR --oldincludedir=DIR C header files for non-gcc in DIR --infodir=DIR info documentation in DIR --mandir=DIR man documentation in DIR --srcdir=DIR find the sources in DIR --program-prefix=PREFIX prepend PREFIX to installed program names --program-suffix=SUFFIX append SUFFIX to installed program names --program-transform-name=PROGRAM run sed PROGRAM on installed program names Host type: --build=BUILD configure for building on BUILD --host=HOST configure for HOST --target=TARGET configure for TARGET Features and packages: --disable-FEATURE do not include FEATURE (same as --enable-FEATURE=no) --enable-FEATURE[=ARG] include FEATURE --with-PACKAGE[=ARG] use PACKAGE --without-PACKAGE do not use PACKAGE (same as --with-PACKAGE=no) --x-includes=DIR X include files are in DIR --x-libraries=DIR X library files are in DIR --enable and --with options recognized: --disable-dependency-tracking Speeds up one-time builds --enable-dependency-tracking Do not reject slow dependency extractors --enable-maintainer-mode enable make rules and dependencies not useful (and sometimes confusing) to the casual installer --enable-dlmalloc[=LIB] Compile & use the malloc package by Doug Lea --enable-gnuregex Compile GNUregex. Unless you have reason to use this option, you should not enable it. This library file is usually only required on Windows and very old Unix boxes which do not have their own regex library built in. --enable-xmalloc-statistics Show malloc statistics in status page --enable-carp Enable CARP support --enable-async-io[=N_THREADS] Shorthand for --with-aufs-threads=N_THREADS --with-pthreads --enable-storeio=ufs,aufs --with-aufs-threads=N_THREADS Tune the number of worker threads for the aufs object store. --with-pthreads Use POSIX Threads --with-aio Use POSIX AIO --with-dl Use dynamic linking --enable-storeio="list of modules" Build support for the list of store I/O modules. The default is only to build the ufs module. See src/fs for a list of available modules, or Programmers Guide section
for details on how to build your custom store module
--enable-heap-replacement
Backwards compatibility option. Please use the
new --enable-removal-policies directive instead.
--enable-removal-policies="list of policies"
Build support for the list of removal policies.
The default is only to build the lru module.
See src/repl for a list of available modules, or
Programmers Guide section 9.9 for details on how
to build your custom policy
--enable-icmp Enable ICMP pinging
--enable-delay-pools Enable delay pools to limit bandwidth usage
--enable-useragent-log Enable logging of User-Agent header
--enable-referer-log Enable logging of Referer header
--disable-wccp Disable Web Cache Coordination Protocol
--enable-kill-parent-hack
Kill parent on shutdown
--enable-snmp Enable SNMP monitoring
--enable-cachemgr-hostname[=hostname]
Make cachemgr.cgi default to this host
--enable-arp-acl Enable use of ARP ACL lists (ether address)
--enable-htcp Enable HTCP protocol
--enable-ssl Enable ssl gatewaying support using OpenSSL
--with-openssl[=prefix]
Compile with the OpenSSL libraries. The path to
the OpenSSL development libraries and headers
installation can be specified if outside of the
system standard directories
--enable-forw-via-db Enable Forw/Via database
--enable-cache-digests Use Cache Digests
see http://www.squid-cache.org/FAQ/FAQ-16.html
--enable-default-err-language=lang
Select default language for Error pages (see
errors directory)
--enable-err-languages="lang1 lang2.."
Select languages to be installed. (All will be
installed by default)
--with-coss-membuf-size COSS membuf size (default 1048576 bytes)
--enable-poll Enable poll() instead of select(). Normally poll
is preferred over select, but configure knows poll
is broken on some platforms. If you think you are
smarter than the configure script, you may enable
poll with this option.
--disable-poll Disable the use of poll().
--disable-http-violations
This allows you to remove code which is known to
violate the HTTP protocol specification.
--enable-ipf-transparent
using IP-Filter network address redirection.
--enable-pf-transparent
Enable Transparent Proxy support for systems
using PF network address redirection.
--enable-linux-netfilter
Enable Transparent Proxy support for Linux 2.4.
--with-large-files Enable support for large files (logs etc).
--enable-large-cache-files
Enable support for large cache files (>2GB).
WARNING: on-disk cache format is changed by this option
--with-build-environment=model
The build environment to use. Normally one of
POSIX_V6_ILP32_OFF32 32 bits
POSIX_V6_ILP32_OFFBIG 32 bits with large file support
POSIX_V6_LP64_OFF64 64 bits
POSIX_V6_LPBIG_OFFBIG large pointers and files
XBS5_ILP32_OFF32 32 bits (legacy)
XBS5_ILP32_OFFBIG 32 bits with large file suppor
XBS5_LP64_OFF64 64 bits (legacy)
XBS5_LPBIG_OFFBIG large pointers and files
default The default for your OS
--enable-leakfinder
Enable Leak Finding code. Enabling this alone
does nothing; you also have to modify the source
code to use the leak finding functions. Probably
Useful for hackers only.
--disable-ident-lookups
This allows you to remove code that performs
Ident (RFC 931) lookups.
--disable-internal-dns This prevents Squid from directly sending and
receiving DNS messages, and instead enables the
old external "dnsserver" processes.
--enable-truncate This uses truncate() instead of unlink() when
removing cache files. Truncate gives a little
performance improvement, but may cause problems
when used with async I/O. Truncate uses more
filesystem inodes than unlink..
--disable-hostname-checks
Squid by default rejects any host names with
odd characters in their name to conform with
internet standards. If you disagree with this
you may use this switch to turn off any such
checks, provided that the resolver used by
Squid does not reject such host names.. This
may be required to participate in testbeds for
international domain names.
--enable-underscores Squid by default rejects any host names with _
in their name to conform with internet standards.
If you disagree with this you may allow _ in
hostnames by using this switch, provided that
the resolver library on the host where Squid runs
does not reject _ in hostnames...
--enable-auth="list of auth scheme modules"
Build support for the list of authentication schemes.
The default is to build support for the Basic scheme.
See src/auth for a list of available modules, or
Programmers Guide section authentication schemes
for details on how to build your custom auth scheme
module
--enable-auth-modules="list of helpers"
Backwards compatibility alias for
--enable-basic-auth-helpers
--enable-basic-auth-helpers="list of helpers"
This option selects which basic scheme proxy_auth
helpers to build and install as part of the normal
build process. For a list of available
helpers see the helpers/basic_auth directory.
--enable-ntlm-auth-helpers="list of helpers"
This option selects which proxy_auth ntlm helpers
to build and install as part of the normal build
process. For a list of available helpers see
the helpers/ntlm_auth directory.
--enable-digest-auth-helpers="list of helpers"
This option selects which digest scheme authentication
helpers to build and install as part of the normal build
helpers/digest_auth directory.
--enable-ntlm-fail-open Enable NTLM fail open, where a helper that fails
one of the Authentication steps can allow squid to
still authenticate the user.
--enable-external-acl-helpers="list of helpers"
This option selects which external_acl helpers to
build and install as part of the normal build
process. For a list of available helpers see the
helpers/external_acl directory.
--with-samba-sources=/path/to/samba-source-tree
Path where the correct Samba source files can be
found while building winbind helpers. (defaults to
use internal copies of the headers from Samba-2.2.7)

Disable-unlinkd Do not use unlinkd
--enable-stacktraces Enable automatic call backtrace on fatal errors
--enable-x-accelerator-vary
Enable support for the X-Accelerator-Vary
HTTP header. Can be used to indicate
variance within an accelerator setup.
Typically used together with other code
that adds custom HTTP headers to the requests.
--with-maxfd=N Override maximum number of filedescriptors. Useful
if you build as another user who is not privileged
to use the number of filedescriptors you want the
resulting binary to support

После того, как вы нашли необходимый ключ, добавляем его в %configure. Например, мы хотим собрать squid с поддержкой ssl. Из помощи мы определили, что для этого, необходимо добавить два ключа --enable-ssl и --with-openssl. Вносим соответствующие изменения

Сохраняем файл и начинаем сборку.

# rpmbuild -ba --target=athlon squid.spec Платформы для сборки: athlon Сборка для платформы athlon Выполняется(%prep): /bin/sh -e /var/tmp/rpm-tmp.59199 + umask 022 + cd /usr/src/redhat/BUILD + cd /usr/src/redhat/BUILD + rm -rf squid-2.5.STABLE11 + /usr/bin/bzip2 -dc /usr/src/redhat/SOURCES/squid-2.5.STABLE11.tar.bz2 ... ... ... SSL gatewaying using OpenSSL enabled
Using OpenSSL MD5 implementation
... ... ... Записан: /usr/src/redhat/SRPMS/squid-2.5.STABLE11-2.src.rpm Записан: /usr/src/redhat/RPMS/athlon/squid-2.5.STABLE11-2.athlon.rpm Выполняется(%clean): /bin/sh -e /var/tmp/rpm-tmp.7322 + umask 022 + cd /usr/src/redhat/BUILD + cd squid-2.5.STABLE11 + rm -rf /var/tmp/squid-2.5.STABLE11-root + exit 0 Выполняется(--clean): /bin/sh -e /var/tmp/rpm-tmp.7322 + umask 022 + cd /usr/src/redhat/BUILD + rm -rf squid-2.5.STABLE11 + exit 0

Все squid у нас собран успешно, теперь осталось только установить или обновить его.

Иногда встречаются полезные программы, доступные только в виде исходных кодов (и/или в виде установочных пакетов для других ОС), но есть необходимость их установки на несколько компьютеров. Чтобы не выполнять компиляцию на каждом компьютере отдельно, можно на одном подготовить установочный пакет и установить его штатными средствами на других компьютерах.
Ниже приведён пример создания RPM пакета для Fedora 21 (для других версий Fedora процедура не отличается) из исходных текстов очень приятной и полезной программы Boomaga версии 0.7.0.

Готовим инструменты сборки RPM

Для начала я попытался установить необходимые инструменты (как мне посоветовала ):
sudo dnf install @development-tools но эта команда не выполнилась, ссылаясь на отсутствие группы development-tools. Тогда я установил всё другой командой, которую мне подсказала :
sudo dnf groupinstall "Development Tools" и ещё две команды из обеих вышеуказанных статей:
sudo dnf install rpmdevtools sudo dnf install fedora-packager Затем надо сгенерировать рабочее пространство для сборки RPM:
rpmdev-setuptree В результате этой команды создадутся необходимые каталоги в домашнем каталоге текущего пользователя (показываю содержимое нового каталога rpmbuild ):
$ ls ~/rpmbuild/ BUILD BUILDROOT RPMS SOURCES SPECS SRPMS В каталог SOURCES сразу перемещаю архив исходников (boomaga-0.7.0.tar.gz), как он есть. Кстати, тут есть небольшой подвох от github, - ссылка на закачку не даётся напрямую, а генерируется только после клика по ней. Из-за этого не получилось указать прямую ссылку на архив в интернете в SPEC файле, о котором пойдёт речь ниже.

Готовим SPEC файл

Для упаковки исходных текстов программы в RPM пакет нужен специальный файл с описанием необходимых действий. Сгенерируем шаблон:
rpmdev-newspec boomaga В результате этой команды будет создан файл boomaga.spec в каталоге ~/rpmbuild/SPEC. Тут важно название SPEC файла. Оно должно совпадать с названием программы (т.е. без номера версии). После автоматической генерации SPEC файла переходим к его редактированию. В моём случае это получилось так:
Name: boomaga Version: 0.7.0 Release: 1%{?dist} Summary: Boomaga is a virtual printer for viewing a document before printing License: GPLv2 and LGPLv2+ URL: http://boomaga.github.io Source0: %{name}-%{version}.tar.gz BuildRequires: cmake,cups-devel,poppler-devel,poppler-cpp-devel,qt5-qtbase-devel,qt5-qttools-devel,snappy-devel Requires: cups %description Boomaga (BOOklet MAnager) is a virtual printer for viewing a document before printing it out using the physical printer. The program is very simple to work with. Running any program, click “print” and select “Boomaga” to see in several seconds (CUPS takes some time to respond) the Boomaga window open. If you print out one more document, it gets added to the previous one, and you can also print them out as one. %prep %setup -q %build mkdir build cd build cmake .. %make_install %files %defattr(0755,root,root,-) /usr/lib/cups/backend/boomaga /usr/lib/cups/filter/boomaga_pstopdf /usr/local/bin/boomaga /usr/local/lib/boomaga/boomagabackend /usr/local/lib/boomaga/boomagamerger /usr/local/share/applications/boomaga.desktop /usr/local/share/boomaga/translations/boomaga_cs.qm /usr/local/share/boomaga/translations/boomaga_de.qm /usr/local/share/boomaga/translations/boomaga_el.qm /usr/local/share/boomaga/translations/boomaga_fr.qm /usr/local/share/boomaga/translations/boomaga_it.qm /usr/local/share/boomaga/translations/boomaga_lt.qm /usr/local/share/boomaga/translations/boomaga_pl_PL.qm /usr/local/share/boomaga/translations/boomaga_ru.qm /usr/local/share/boomaga/translations/[email protected] /usr/local/share/dbus-1/services/org.boomaga.service /usr/local/share/icons/hicolor/128x128/apps/boomaga.png /usr/local/share/icons/hicolor/16x16/apps/boomaga.png /usr/local/share/icons/hicolor/32x32/apps/boomaga.png /usr/local/share/icons/hicolor/64x64/apps/boomaga.png /usr/local/share/mime/packages/boomaga.xml /usr/share/ppd/boomaga/boomaga.ppd %attr(0644,root,root) %doc /usr/local/share/man/man1/boomaga.1.gz %changelog * Mon Jun 22 2015 Oleg - Всё, что идёт после знака процента является макросом (например, %build) или предопределённым значением (например, %{name}). Как сказано в документации Fedora , перечень и описание всех макросов можно найти в каталогах:
  • /etc/rpm/*
  • /usr/lib/rpm
  • /usr/lib/rpm/macros
Много полезной информации можно почерпнуть, выполнив команду
rpm --showrc Прокомментирую указанные значения.
Параметр Name должен совпадать с именем SPEC файла и названием программы (указывается без номера версии).
Параметр Source0 должен по-хорошему указывать на архив в интернете, который имеет такое же название, как и файл в каталоге ~/rpmbuild/SOURCES, но т.к. ссылки на boomaga-0.7.0.tar.gz в интернете я не нашёл, то указал локальную ссылку. Без пути. Только название файла и с использованием переменных (берутся из указанных выше одноимённых параметров).
Перед тем, как пытаться собрать RPM пакет, я пробовал скомпилировать программу обычным образом. Для этого понадобилось установить инструмент cmake и зависимости данной программы: cups-devel, poppler-devel, poppler-cpp-devel, qt5-qtbase-devel, qt5-qttools-devel, snappy-devel. Все эти пакеты я указал в параметре BuildRequires .
Т.к. boomaga может работать в роли виртуального принтера как прослойка между CUPS, то я указал cups в параметре Requires .
Далее идут макросы, которые будут выполняться при сборке RPM пакета.
После макроса %description делаем переход на новую строку и вставляем описание из родного сайта проекта.
Макрос %setup -q распаковывает исходные коды в каталог ~/rpmbuild/BUILD/%{name}-%{version}, т.е. в нашем случае - ~/rpmbuild/BUILD/boomaga-0.7.0
Далее начинается самое ответственное. Нужно описать всё для автоматической компиляции проекта. Я поступил так. Открыл официальную инструкцию по установке данного приложения и переделал под текущую ситуацию. Инструкция по установке оказалась весьма лаконичной и понятной:
mkdir ~/boomaga/build cd ~/boomaga/build cmake .. make && sudo make install В форме макросов в SPEC файле эти инструкции выразились так:
%build mkdir build cd build cmake .. %make_install Первый макрос %build отвечает за сборку исходников. В этой фазе создаём каталог build в текущем каталоге (т.е. в ~/rpmbuild/BUILD/boomaga-0.7.0) и перемещаемся в него. Потом запуск cmake для генерации Makefile. Т.е. всё то, что написано в инструкции по обычной установке данной программы.
Затем макрос %make_install собирёт всё каталоге в ~/rpmbuild/BUILDROOT/boomaga-0.7.0-1.fc21.R.x86_64 так, как если бы шла нормальная установка. Т.е. там создаётся каталог usr со всеми задействованными подкаталогами.
Операции макросов %files (тут нужно указать список всех файлов, входящих в RPM пакет) и %doc (вся документация) заполнил в соответствии с подсказками после первых неудачных запусков, - при сборке пакета выводилось сообщение:
Processing files: boomaga-debuginfo-0.7.0-1.fc21.R.x86_64 Проверка на неупакованный(е) файл(ы): /usr/lib/rpm/check-files /home/oleg/rpmbuild/BUILDROOT/boomaga-0.7.0-1.fc21.R.x86_64 ошибка: Обнаружен(ы) установленный(е) (но не упакованный(е)) файл(ы): /usr/lib/cups/backend/boomaga /usr/lib/cups/filter/boomaga_pstopdf /usr/local/bin/boomaga /usr/local/lib/boomaga/boomagabackend /usr/local/lib/boomaga/boomagamerger /usr/local/share/applications/boomaga.desktop /usr/local/share/boomaga/translations/boomaga_cs.qm /usr/local/share/boomaga/translations/boomaga_de.qm /usr/local/share/boomaga/translations/boomaga_el.qm /usr/local/share/boomaga/translations/boomaga_fr.qm /usr/local/share/boomaga/translations/boomaga_it.qm /usr/local/share/boomaga/translations/boomaga_lt.qm /usr/local/share/boomaga/translations/boomaga_pl_PL.qm /usr/local/share/boomaga/translations/boomaga_ru.qm /usr/local/share/boomaga/translations/[email protected] /usr/local/share/dbus-1/services/org.boomaga.service /usr/local/share/icons/hicolor/128x128/apps/boomaga.png /usr/local/share/icons/hicolor/16x16/apps/boomaga.png /usr/local/share/icons/hicolor/32x32/apps/boomaga.png /usr/local/share/icons/hicolor/64x64/apps/boomaga.png /usr/local/share/man/man1/boomaga.1.gz /usr/local/share/mime/packages/boomaga.xml /usr/share/ppd/boomaga/boomaga.ppd Ошибки сборки пакетов: Обнаружен(ы) установленный(е) (но не упакованный(е)) файл(ы): /usr/lib/cups/backend/boomaga /usr/lib/cups/filter/boomaga_pstopdf /usr/local/bin/boomaga /usr/local/lib/boomaga/boomagabackend /usr/local/lib/boomaga/boomagamerger /usr/local/share/applications/boomaga.desktop /usr/local/share/boomaga/translations/boomaga_cs.qm /usr/local/share/boomaga/translations/boomaga_de.qm /usr/local/share/boomaga/translations/boomaga_el.qm /usr/local/share/boomaga/translations/boomaga_fr.qm /usr/local/share/boomaga/translations/boomaga_it.qm /usr/local/share/boomaga/translations/boomaga_lt.qm /usr/local/share/boomaga/translations/boomaga_pl_PL.qm /usr/local/share/boomaga/translations/boomaga_ru.qm /usr/local/share/boomaga/translations/[email protected] /usr/local/share/dbus-1/services/org.boomaga.service /usr/local/share/icons/hicolor/128x128/apps/boomaga.png /usr/local/share/icons/hicolor/16x16/apps/boomaga.png /usr/local/share/icons/hicolor/32x32/apps/boomaga.png /usr/local/share/icons/hicolor/64x64/apps/boomaga.png /usr/local/share/man/man1/boomaga.1.gz /usr/local/share/mime/packages/boomaga.xml /usr/share/ppd/boomaga/boomaga.ppd В результате успешной сборки формируются RPM пакеты:
~/rpmbuild/RPMS/x86_64/boomaga-0.7.0-1.fc21.R.x86_64.rpm
~/rpmbuild/RPMS/x86_64/boomaga-debuginfo-0.7.0-1.fc21.R.x86_64.rpm
~/rpmbuild/SRPMS/boomaga-0.7.0-1.fc21.R.src.rpm
А вот, собственно, как запускать сборку:
rpmbuild --target=x86_64 -ba ~/rpmbuild/SPECS/boomaga.spec Команда отрабатывает за пару минут. В это время в консоли пролетают красивые разноцветные строчки.

Позже, когда дистрибутив Fedora обновится до следующей версии, можно будет попробовать перепаковать пакет boomaga-0.7.0-1.fc21.R.src.rpm такой командой:
rpmbuild --rebuild boomaga-0.7.0-1.fc21.R.src.rpm Теоретически это позволит сократить время сборки RPM пакета.
Для проверки SPEC файла и формируемого пакета можно перейти в каталог ~/rpmbuild/SPEC и воспользоваться командой:
rpmlint boomaga.spec ../SRPMS/boomaga* ../RPMS/*/boomaga* В результате будут показаны различные предупреждения и ошибки. В моём случае есть ошибки расположения файлов. Но для личного пользования подойдёт и так. Хотя с такими ошибками в официальные репозитории не пропустят.
Посмотреть описание ошибки можно, указав её название после ключа -I в следующей команде:
rpmlint -I hardcoded-library-path

Полезные ссылки

Различных параметров и макросов существует довольно много. В официальной документации Fedora есть исчерпывающие полезные и обширные материалы "How to create an RPM package " и "Packaging:Guidelines ". Также есть пример с пояснениями SPEC файла в материале "Annotated spec file ".

Делаем RPM лучше

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

Основная ошибка состоит в том, что полученные файлы в системе устанавливаются не туда, куда положено. Во-первых, всё должно соответствовать стандарту Filesystem Hierarchy Standard , который недавно обновился . Во-вторых RPM пакет для Fedora должен соответствовать правилам этого дистрибутива.

Нужно избавиться от жёстко прописанных путей в секции %files. Для этого применяются макросы. В моём случае исходный код программы в нескольких местах имел жёстко прописанный путь в подкаталог lib, а для архитектуры x86_64 нужно было указывать lib64. Поэтому потребовалось немного подкорректировать исходный код программы .

В результате общения с разработчиками программы на github.com , SPEC файл пополнился также автоматическим прописыванием принтера в системе. Плюс программа Boomaga успела обновиться до версии 0.7.1. Результирующий SPEC файл:

Name: boomaga Version: 0.7.1 Release: 1%{?dist} Summary: A virtual printer for viewing a document before printing License: GPLv2 and LGPLv2+ URL: http://boomaga.github.io Source0: %{name}-%{version}.tar.gz BuildRequires: cmake,cups-devel,poppler-devel,poppler-cpp-devel,qt5-qtbase-devel,qt5-qttools-devel,snappy-devel Requires: cups,snappy %description Boomaga (BOOklet MAnager) is a virtual printer for viewing a document before printing it out using the physical printer. The program is very simple to work with. Running any program, click “print” and select “Boomaga” to see in several seconds (CUPS takes some time to respond) the Boomaga window open. If you print out one more document, it gets added to the previous one, and you can also print them out as one, and you can also print them out as one. Regardless of whether your printer supports duplex printing or not, you would be able to easily print on both sides of the sheet. If your printer does not support duplex printing, point this out in the settings, and Booklet would ask you to turn over the pages half way through printing your document. The program can also help you get your documents prepared a bit before printing. At this stage Boomaga makes it possible to: * Paste several documents together. * Print several pages on one sheet. * 1, 2, 4, 8 pages per sheet * Booklet. Folding the sheets in two, you’ll get a book. %prep %setup -q %build %ifarch x86_64 %cmake -DLIB_SUFFIX=64 -DCUPS_BACKEND_DIR=%{_libdir}/cups/backend -DCUPS_FILTER_DIR=%{_libdir}/cups/filter . %else %cmake -DCUPS_BACKEND_DIR=%{_libdir}/cups/backend -DCUPS_FILTER_DIR=%{_libdir}/cups/filter . %endif make %{?_smp_mflags} %install make install DESTDIR=%{buildroot} %__mkdir -p %{buildroot}%{_datadir}/%{name}/scripts %__install -m 755 scripts/installPrinter.sh %{buildroot}%{_datadir}/%{name}/scripts/ chmod +x %{buildroot}%{_datadir}/%{name}/scripts/installPrinter.sh # Add translation lang tags (cd %{buildroot} && find . -name "*.qm") | %__sed -e "s|^.||" | sed -e \ "s:\(.*/translations/boomaga_\)\(\+\)\(.*qm$\):%lang(\2) \1\2\3:"\ >> %{name}.lang %pre # Start cups if is stopped if [ "$(systemctl is-active cups.service)" != "active" ]; then systemctl start cups sleep 2 fi %post # Install the printer to cups backends if [ $1 = 1 ]; then sh %{_datadir}/%{name}/scripts/installPrinter.sh fi %preun # Uninstall the printer lpadmin -x "Boomaga" %files %defattr(755,root,root,-) %{_libdir}/cups/backend/%{name} %defattr(-,root,root,-) %{_libdir}/cups/filter/boomaga_pstopdf %{_bindir}/%{name} %{_libdir}/%{name}/boomagabackend %{_libdir}/%{name}/boomagamerger %{_datadir}/applications/boomaga.desktop %{_datadir}/%{name}/translations/* %{_datadir}/dbus-1/services/org.boomaga.service %{_datadir}/icons/hicolor/* %{_datadir}/mime/packages/boomaga.xml %{_datadir}/ppd/%{name}/boomaga.ppd %{_datadir}/%{name}/scripts/installPrinter.sh %doc COPYING GPL LGPL README.md %{_mandir}/man1/boomaga.1.gz %changelog * Tue Jun 30 2015 Oleg Ekhlakov 0.7.1-1.fc21.R - Initial version of the package