Создание RPM-пакетов. Собираем RPM пакет своими руками Установка сборочных зависимостей

Но часто бывает так, что вам необходимо собрать пакет с необходимыми опциями (включить поддержку 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 у нас собран успешно, теперь осталось только установить или обновить его.

Все найденные мною в интернете мануалы в большинстве случаев сводятся к двум видам:
— перевод документации (с которым я всё-таки советую ознакомиться, тк в моей статье будет освещена лишь часть информации, которая вам в дальнейшем понадобится)
краткие инструкции, как запустить rpmbuild когда у нас уже есть всё.
Лично я столкнулся с необходимость собрать пакет из исходника, вместе с которым небыло ничего, а главное spec-файла, по которому необходимо собрать пакет. В итоге мы напишем собственный spec-файл для сборки пакета и добавим туда сразу собственные конфиги (этот вопрос тоже не сильно освящён).

Я буду собирать пакет из исходников ffmpeg для AirVideoServer, который я уже рассказывал как . Я сторонник того, что бы в дистрибутиве, который использует пакетный менеджер, приложения ставились именно через него, по этому на CentOS я не люблю собирать ПО из исходников. По этой причине я решил собрать себе всё в пакеты. Сборка так же необходимых lame (он идёт уже со spec-файлов в комплекте) и x264 (под него вы сможете написать spec-файл сами, после прочтения этой статьи) не должна вызвать у вас проблем в будущем.

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

Yum install gcc gcc-c++ automake autoconf libtool yasm nasm ncurses-devel git ftp rpmdevtools

а теперь заведём специального пользователя

Useradd rpmbuild

и войдём под ним

Su - rpmbuild

выполним команду

Rpmdev-setuptree

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

Wget http://inmethod.com/airvideo/download/ffmpeg-for-2.4.5-beta7.tar.bz2

разворачиваем его

Tar -xjf ffmpeg-for-2.4.5-beta7.tar.bz2

Положим рядом конфигурационный файл с содержимым:

Nano airvideoserver.conf path.ffmpeg = /usr/bin/ffmpeg password = subtitles.encoding = utf-8 subtitles.font = Verdana folders = Movies:/home/share/films

Сюда же скачаем файл сервера:

Wget http://inmethod.com/airvideo/download/linux/alpha6/AirVideoServerLinux.jar

И init-скрипт:

Nano AirVideoServer #!/bin/bash #chkconfig: - 80 20 #description: AirVideo server # Source function library. . /etc/rc.d/init.d/functions PREFIX_DIR=/usr/local/AirVideo case "$1" in start) echo -n "Starting AirVideo server: " daemon java -jar ${PREFIX_DIR}/AirVideoServerLinux.jar ${PREFIX_DIR}/properties.conf > /dev/null 2>&1 & [ $? -eq 0 ] && success || failure echo ;; stop) echo -n "Stopping AirVideo server: " killproc java echo ;; status) status java ;; restart | reload) $0 stop ; $0 start ;; *) echo "Usage: airvideo {start|stop|status|reload|restart" exit 1 ;; esac

Теперь можно переходить к написанию нашего spec-файла для сборки.
Сначала у нас идут различные заголовки. Имя пакета, версия и релиз — имеют значение, от них будет зависеть в какую директорию будет разворачиваться исходник перед сборкой. В Source1 , Source2 и Source3 мы указываем наши 3 дополнительных файл, конфиг, сервер и init-скрипт, которые необходимо добавить в пакет при сборке.

Name: ffmpeg Version: 2.4.5 Release: beta7 Summary: ffmpeg for AirVideoServer License: GPL URL: http://inmethod.com/airvideo/ Source: http://inmethod.com/airvideo/download/ffmpeg-for-2.4.5-beta7.tar.bz2 Source1: airvideoserver.conf Source2: AirVideoServer Source3: AirVideoServerLinux.jar BuildRoot: %{_tmppath}/%{name}-for-%{version}-%{release}

%description Utility and library for encoding H264/AVC video streams for AirVideoServer.

Секция %prep отвечает за команды, необходимые для начала сборки, что бы мне не мучится с переименованием директории под формат -, я просто ключом -n указываю где лежат распакованные исходники

%prep %setup -n /home/rpmbuild/rpmbuild/BUILD/ffmpeg/

Секция %build отвечает за непосредственную сборку исходника, ключи вы можете менять на необходимые вам, как при обычной сборке и установке из исходников:

%build ./configure \ --prefix="%{_prefix}" \ --bindir="%{_bindir}" \ --libdir="%{_libdir}" \ --enable-pthreads \ --disable-shared \ --enable-static \ --enable-gpl \ --enable-libx264 \ --enable-libmp3lame

Секция %install содержит команды установки файлов пакета в систему, здесь нам необходимо дополнительно указать, куда инсталлировать наши файл конфига, сервер и init-скрипт

%install %{__rm} -rf %{buildroot} %{__make} install DESTDIR="%{buildroot}" mkdir -p $RPM_BUILD_ROOT/usr/local mkdir -p $RPM_BUILD_ROOT/usr/local/AirVideo/ install -m 644 %{SOURCE1} $RPM_BUILD_ROOT/usr/local/AirVideo/ install -m 644 %{SOURCE2} $RPM_BUILD_ROOT/etc/init.d install -m 644 %{SOURCE3} $RPM_BUILD_ROOT/usr/local/AirVideo/

Уберём за собой мусор и выполним ldconfig

%clean %{__rm} -rf %{buildroot} %post -p /sbin/ldconfig %postun -p /sbin/ldconfig

Команды в секции %files задают списки файлов и каталогов, которые с соответствующими атрибутами должны быть скопированы из дерева сборки в rpm-пакет и затем будут копироваться в целевую систему при установке этого пакета.

%files %defattr(-,root,root,-) %doc COPYING* CREDITS README* %{_bindir}/avconv %{_bindir}/avprobe %{_bindir}/avserver %{_bindir}/ffmpeg /usr/include/* /usr/lib64/* /usr/share/avconv/* /usr/local/AirVideo/airvideoserver.conf /etc/init.d/AirVideoServer /usr/local/AirVideo/AirVideoServerLinux.jar

Макрос %doc отмечает файлы документации, копирайты и прочие вещи.
На этом наш spec-файл готов, теперь нам необходимо запустить саму сборку

Rpmbuild -bb ffmpeg/ffmpeg.spec

При успешной сборке пакета, после завершения, в директории RPMS/_архитектура_/ у нас появится наш пакет ffmpeg-2.4.5-beta7.x86_64.rpm который теперь можно выложить и развернуть на любой машине.

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

RPM пакеты имеют собственную структуру, отличную от других. Но зачем создавать свои RPM, если можно просто скомпилировать исходники? Ответ на этот вопрос в рутинной установке, а также помощи разработчикам Fedora или другим дистрибутивам. Устанавливая каждый раз одни и те же программы из исходников, можно написать скрипт для автоматизации этого, однако, если есть RPM, то не надо тратить много времени на установку, также как и необходимая программа будет постоянно доступна онлайн из репозитория (конечно же, если вы ее туда отправите).

Итак приступим к подготовке рабочей среды для создания RPM.

# yum groupinstall "Development Tools"
# yum install rpmdevtools
На данной стадии происходит установка необходимых утилит и различных библиотек разработчика.

НИКОГДА НЕ СОЗДАВАЙТЕ RPM ОТ ROOT! (это может нарушить работу системы, увеличить возможность взлома и так далее)

После окончания установки, запустите

rpmdev-setuptree
Это приведет к создание ветки директорий
BUILD BUILDROOT RPMS SOURCES SPECS SRPMS

Из всех директорий нас интересует только SOURCES SPECS, информация в остальных, если все сделано верно, сгенерируется автоматически.

Теперь нам нужен.spec файл, примеры можно найти путем стачивания.src.rpm с репозитория, после распаковки, будет.spec файл, который необходимо поправить под наши нужды.

Сами исходники с патчами или без, копируем в SOURCES.

Когда все готово, запускаем компилирование и создание RPM

rpmbuild -ba ПУТЬ/NAME.spec для создания.src.rpm
rpmbuild -bi ПУТЬ/NAME.spec для создания бинарника или просто.rpm

Для установки и/или тестирования

# rpm -ivh sourcepackage-name*.src.rpm
или
# rpm -ivh package-name*.rpm
Если все сделано правильно, то программа установится с предупреждением, что rpb database изменена сторонней программой (правильно, мы же ее еще не залили на Fedora сервер).

Объяснение часто используемых областей в.spec файле

Name : Базовое имя пакета удовлетворяющее требованиям Packagen Naming Guidelines . После этого, макрос %{name} будет обращаться к данному разделу.

Version : Номер версии, при использовании даты в версии, используйте формат, гг.мм (пример 11.02). %{version} для последующего обращения к данной области.

Release : Должно быть 1%{?dist} , таким образом, число будет увеличиваться каждый раз, когда создается пакет для одной и той же версии дистрибутива.

Summary : Краткое описание пакета.

Group : Существующая группа пакетов, например Applications/Databases.

Чтобы узнать весь список
# less /usr/share/doc/rpm-*/GROUPS
Для документации будет соответственно группа Documentation.

License : Лицензия на программу, обязана быть для открытых исходников, например "GPLv2+" (GPL версии 2 или новее). Для нескольких лицензий используйте "and" или "or" "GPLv2 and BSD". Следует указывать лицензию максимально точно, можно указывать несколько лицензий с помощью "and" и "or", например "GPLv2 and BSD".

Source0 : Ссылка на архив с исходным кодом. Если указана полная ссылка, то одноименный пакет должен быть в папке SOURCES. Если источников исходного кода несколько, то используем Source1 , Source2 и т.д.

Patch0 : Название первого патча для программы, имя файла должно заканчиваться на.patch и лежать в директории ~/rpmbuild/SOURCES. Патчей может быть несколько.

BuildArch : Архитектура программы под определенные процессоры. Для универсальных пакетов "noarch".

BuildRoot : Место, выделенное для компиляции и установки исходников приложения во время выполнения процесса "%install". По стандарту Fedora, будет создана специальная директория в /var/tmp. Более новые версии RPM пропустят это значение и поместят build root в %{_topdir}/BUILDROOT/

BuildRequires : Список необходимых приложений для сборки пакета (через запятую). Автоматически не определяются . Некоторые стандартные приложения могут быть опущены в данном списке. Полный список приложений, которые могут быть пропущены здесь (https://fedoraproject.org/wiki/Packaging/Guidelines).

Requires : Список необходимых приложений для работы после установки (через запятую). В большинстве случаев определяются автоматически rpmbuild .

%description : Описание программы, строки не должны быть длиннее 80 символов.
%prep : Скрипты для подготовки программы, распаковки и подготовки к сборке.
%build : Скрипты для сборки программы, компиляции и подготовки к установке.
%test : Скрипты для тестирования программы, выполняются после %build, но до %install.
%install : Скрипты для установки программы, команды скопируют файлы из "build directory" %{_builddir} (которая находится ~/rpmbuild/BUILD) в директорию buildroot %{buildroot}, которая обычно находится в /var/tmp.
%clean : Инструкции для очистки buildroot, например,
rm -rf %{buildroot}
%files : Список устанавливаемых файлов.
%changelog : Изменения в программе.

Статья подготовлена опираясь на официальный источник от

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

В продолжение темы:
Безопасность компьютера

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

Новые статьи
/
Популярные