Сборка пакетов библиотек для rpm-based дистрибутивов Linux. Создание RPM пакета для Fedora 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 у нас собран успешно, теперь осталось только установить или обновить его.
Сперва давайте разберёмся, что должно быть в системе для сборки rpm-пакета. Обязательно должен быть установлен пакет rpm-build . Без него не будет доступна команда rpmbuild. Наряду с ним, по зависимостям поставится еще ряд пакетов, используемых при сборке. В зависимостях для сборки пакета в РОСЕ обычно не принято прописывать компилятор C/C++, по этому поводу рано или поздно вам понадобятся пакеты gcc и gcc-c++ Все остальные зависимости должен попросить сам пакет. Конечно бывают промахи, и в процессе сборки вы понимаете, что что-то упустили, но это обычно бывает довольно редко и не критично.
А что собственно из себя представляет RPM пакет? RPM-пакеты делятся на пакеты с исходниками - src.rpm и пакеты, готовые к установке - %{arch}.rpm . В src.rpm пакетах содержится исходный тарболл (исходник программы), какие-либо другие исходники, пачти и самый главный spec-файл, который управляет процессом сборки. Все эти файлы упакованы в cpio архив. Когда вы пытаетесь войти в src.rpm пакет при помощи файлового менеджера mc , вы его увидите. Также в пакете присутствует некоторые файлы с информацией.
В %{arch}.rpm-пакетах содержится cpio-архив с файлами, которые после установки разложатся по соответствующим каталогам, файлы информации и установочные скрипты.
Также вы можете встретить без исходного кода. Обычно их создают для проприетарных программ, которые нельзя включать в дистрибутив (исходников нет, а бинарник каким-то образом нужно переделать либо просто запрещено размещать на зеркалах дистрибутива лицензией). Внутри этого пакета находится обычно только spec-файл, а бинарник скачивается и, при необходимости, модифицируется, в процессе установки пакета (например, в post-скрипте, о котором речь пойдет ниже).
Собирать пакеты можно из-под любого пользователя. Делать это из-под root"а не рекомендуется, т.к. есть вероятность, что корнем для секции инсталляции окажется каталог / и тогда команда rm -rf %{buildroot} уничтожит все на свете. Также бывает, что «кривые» пакеты не правильно выполняют инсталляцию, и ставятся не во временный каталог, а прямо куда-нибудь в %{_prefix} (/usr ). Часть файлов будет потеряна, хотя на работоспособности пакета на этой машине понятное дело это не скажется.
Что нужно сделать, чтобы можно было собирать пакеты из-под обычного пользователя? Первым делом нужно создать в своём домашнем каталоге файл директорию rpmbuild со следующей структурой:
~/rpmbuild |-- BUILD |-- BUILDROOT |-- RPMS | |-- i586 | |-- x86_64 | `-- noarch |-- SOURCES |-- SPECS `-- SRPMS
Каталоги BUILD , RPMS , SOURCES , SPECS , SRPMS вам необходимо создать вручную, подкаталоги каталога RPMS должны создаться автоматически во время сборки в зависимости от архитектуры.
В РОСЕ не принято писать сборщика пакета и вендора в spec-файлах; эти значения выставляются автоматически системой сборки ABF. Также ABF автоматически подписывает собранные пакеты ключом соответствующего репозитория. Поэтому эти вопросы мы здесь затрагивать не будем.
Теперь давайте посмотрим что из себя представляет самый главный файл rpm-пакета, spec-файл. Для примера возьмём его из пакета stardict . Этот пакет хорошо подходит для обучения, так как в нем есть несколько тарболов (исходник программы, упакованный tar ’ом), получается несколько пакетов и есть такая вещь, как схемы. Обычно spec-файл имеет такое же имя, как и сам пакет (stardict.spec ). Однако вы можете добавить версию пакета (stardict-2.spec ), удобно если вы пытаетесь поддерживать несколько веток программ. Можно даже дать какое-нибудь другое название, однако это мягко говоря не удобно.
Итак, содержимое файла stardict.spec приведено ниже. Мы сразу будем вставлять комментарии после определенных секций, но если вы соедините все блоки в один и тот же файл, то получите полноценный stardict.spec .
Spec-файл состоит из секций и шапки:
Summary: StarDict dictionary Name: stardict Version: 2.4.8 Release: 4 License: GPL URL: Group: User Interface/Desktops Source0: %{name}-%{version}.tar.bz2 Source1: %{name}-tools-%{version}.tar.bz2 Patch0: %{name}-2.4.8-desktop.patch
Summary - краткое описание пакета, Name - название, Version - версия, Release - релиз. Последним трем тегам соответствуют макроопределения %{name} , %{version} , %{release} . Их часто используют в дальнейшем. Name и Version обычно совпадает с название тарбола. Если же они отличаются, то в принципе ничего страшного, но придётся в некоторых местах spec-файла действовать нестандартными методами. Если вы собираете пакет из cvs, svn и т. д., то рекомендуется в самом начале файла сделать макроопределение %define date 20070422 (именно в таком формате, сами догадайтесь почему) и тег Release определить следующим образом:
Release: 0.git%{date}.4
Source* - исходные тексты, тарболы, просто файлы. В данном примере идут два тарбола с разными программами, что делает сборку намного сложнее. Обычные файлы, например, конфигурации, могут просто копироваться в секции %%install при помощи команды install . У нее простой синтаксис, install -m маска_как_у_chmod что куда . При помощи нее можно также создавать каталоги. В нашем примере она не используется, но подробнее про неё можно почитать в man.
Patch - патчи, исправления, которые вы или кто-то другой выпустили для данного пакета. Не принято изменять исходный текст самой программы, а затем завертывать ее в тарбол. Принято накладывать заплатки. Делать их можно следующим образом. Распаковываете исходный тарбол, у нас это будет stardict-2.4.8, далее копируете stardict-2.4.8 в stardict-2.4.8.orig. После этого изменяете код в каталоге stardict-2.4.8, выходите из него и отдаете команду diff -ur stardict-2.4.8.orig stardict-2.4.8 > stardict-2.4.8-название_патча.patch. Как видно, до навания патча идёт %{name}-%{version} пакета. В самом spec-файле обязательно следует писать название патча без макроопределений. По крайней мере версию, точно. Иначе при обновлении версии пакета, у вас и обновится версия патча, определённая макросом %{version} , а патч может быть подойдёт к новой версии программы и без каких либо изменений. Если же во время самой сборки патч не смог наложиться, то его следует либо переделать под данную версию программы, либо отключить в секции %setup .
В spec-файлах пакетов многих дистрибутивов вы также можете в заголовке встретить определение BuildRoot - каталога, в котором осуществляется сборка. В РОСЕ в этом определении нет необходимости, имя BuildRoot формируется автоматически.
BuildRequires: libgnomeui-devel >= 2.2.0 BuildRequires: scrollkeeper BuildRequires: gettext Requires(post): GConf2 Requires(post): scrollkeeper Requires(postun): scrollkeeper
BuildRequires - секция, в которую через запятую или через пробел прописываются пакеты, которые требуются для сборки нашей программы. Почерпнуть их можно из каких-нибудь файлов README и INSTALL (хотя там редко бывает что-то полезное по этому поводу), из процесса конфигурации (на данный момент обычно это скрипт configure ) и из самого процесса сборки (иногда configure что-нибудь пропустит и сборка остановится).
Requires - в эту секцию записываются пакеты или файлы(!), которые будет требовать данный пакет при установке. При сборке в зависимости автоматически пропишутся все библиотеки, которые наш пакет потребует, но вы также можете указать пакеты вручную. Rpm также автоматически прописывает зависимости perl, python, mono и некоторые другие (все эти зависимости прописываются не в spec-файл разумеется, а в сам пакет). Если вам не нужно, чтобы зависимости прописывались автоматически, следует прописать в spec-файл новый тег AutoReq: no. Обычно его прописывают при сборки проприетарных программ, так как rpm добавляет внутренние зависимости из собираемой программы.
В нашем примере используются конструкции Requires(post) и Requires(postun) для зависимостей в скриптах установки и удаления. В принципе достаточно и простого Requires . Здесь особенно нечего комментировать. Просто самому StarDict в процессе работы эти зависимости не нужны. Нужны они только при инсталляции и удалении.
Есть ещё несколько полезных тегов, которые здесь не используются.
Provides: название1, название2
Другие названия, помимо %{name} , на которые будет откликаться данный пакет. Удобно указывать, если вы сменили название пакета, а другие пакеты продолжают зависеть от старого названия.
Obsoletes: название1, название2
Удаление указанных пакетов при установки текущего пакета. Как бы говорится, что данный пакет замещает собой указанные (по функциональности, по набору файлов и т. п.). Можно использовать конструкцию название < . Тут вы должны сами понимать, что к чему.
Conflicts: название1, название2
Перечисляются пакеты, которые конфликтуют с текущим. Подразумевается что указанные пакеты нужно вручную удалить, перед установкой нашего. Также используются конструкции со знаками сравнения и версиями (см. выше).
Suggests: название1, название2
- мягкие зависимости - пакеты, которые добавляют данному пакету дополнительную функциональность (например, кодеки для медиапроигрывателя), но без которых можно обойтись.
Epoch: число
Обычно или не указывается совсем или равняется 0. Суть этого параметра вот в чем. Пусть всё наш же пакет stardict имеет версию 2.4.8 , а также есть более старый 2.4.5 . Так вот если %{epoch} у stardict 2.4.5 будет 1 , а у 2.4.8 - 0 , то пакет 2.4.5 будет всегда новее, чем 2.4.8 . О чём при установки вам RPM и скажет. Этот параметр удобен, если вы хотите откатиться на предыдущую версию (разумеется, если вы это все выкладываете в публичный репозиторий и хватаете все через urpmi или rpmdrake . Для «домашних» нужд подойдёт параметр к rpm --force ). Если определён тег Epoch: 0 , то пакет будет иметь приоритет перед пакетом с непоределённым тегом Epoch .
BuildArch: архитектура
Архитектура, под которую будет собираться наш пакет. Если эта опция не указана, то пакет соберётся под текущую архитектуру. Обычно эту опцию указывают для того, чтобы собирать пакет архитектуры noarch , то есть пакет, в котором нет бинарников.
ExclusiveArch: архитектура1 архитектура2
Архитектуры, под которые данный пакет может быть собран. Обычно используется при сборки модулей к ядру.
На этом шапка заканчивается и начинаются отдельные секции.
%description StarDict is an international dictionary written for the GNOME environment. It has powerful features such as "Glob-style pattern matching," "Scan seletion word," "Fuzzy search," etc.
Описание главного пакета, того, у которого будет имя %{name}
%package tools Summary: StarDict-Editor Requires: %{name} = %{version}-%{release} Group: User Interface/Desktops
Здесь мы создаём новый пакет, название которого будет %{name}-tools . Если нужно обозвать пакет совсем по другому, то следует сделать, например, так: %package -n tools-stardict . Версия нового пакета берётся из заданного тега Version . Обратите внимание на Requires . В нём прописана зависимость на главный пакет stardict . Если бы он имел %{epoch} , то необходимо было бы обязательно указать Requires: %{name}-%{epoch}:%{version}-%{release} . Иначе вам просто не удастся установить это пакет.
%description tools A simple tool for StarDict.
Описание второго пакета
%prep %setup -q -a1 %patch0 -p1
Секция %prep в ней начинается подготовка к сборке. %setup распаковывает исходники. Опция -q не показывает вывод распаковывания архива. Опция -a1 используется для распаковки %{SOURCE1} , второго тарбола внутрь(!) каталога первого тарбола. Соответственно цифра указывает на номер SOURCE. Ещё иногда используется параметр -b , тогда второй тарбол распаковывается в тот же каталог, что и первый. Соответственно если у нас один тарбол, то опции -a , -b не используются.
Если у вас первый каталог в тарболе имеет отличное от %{name}-%{version} название, то rpm не сможет войти автоматом в этот каталог. В таком случае следует немного изменить %setup . Если в архиве stardict-2.4.8.tar.bz2 первый каталог имеет название, например, просто stardict , то выглядеть это будет так:
%setup -q -n %{name} -a1
Сразу после распаковки пакета, перед %patch , если нужно, можно скопировать файлы, или запустить какие либо программы для изменения исходников. Допустим скопировать файл русификации, или подправить sed’ом какой-нибудь исходник. Просто вызываете здесь cp , sed или ещё что-то. В качестве корня здесь выступает каталог, в который распаковался первый тарболл (за него отвечает переменная $RPM_BUILD_DIR, но она крайне редко используется).
При помощи %patch накладываются патчи. Если вы делали патч, как мы писали выше, то у вас всегда будет параметр -p1 . Также часто используют параметр -b .название_патча , для создания резервной копии.
%build pushd %{name}-tools-%{version} %configure %make popd %configure %make
Секция %build , именно здесь происходит сборка пакета. Обратите внимание на pushd и popd . Этими командами мы переходим и выходим из каталога второго тарбола. Именно он будет корневым каталогом после pushd . После команды popd мы вернёмся в каталог первого тарбола. Соответственно если у вас один исходник, то не нужно использовать эти команды.
Так как у нас две программы в одном пакете, то мы выполняем два раза концигурацию %configure и два раза make . Если пакет конфигурируется при помощи autotools , то макросом %configure запускается скрипт configure из корня распакованного тарбола. У него обычно бывает много параметров, их можно посмотреть из командной строки при помощи ./configure --help . После %configure вы можете указать нужные вам параметры. Заметьте, что вызов %configure и ./configure отличаются. В первом случае конфигуратору будут переданы правильные каталоги для инсталляции (а также стандартные параметры), во втором - каталоги по умолчанию.
После успешной конфигурации идет сборка, а именно макрос %make , вызывающий одноименную команду с некоторыми дополнтельными параметрами (в частности, на многопроцессорных машинах используется параллельная сборка - опиця -j ).
Если пакет не использует autotools , то %configure , а может и %make использовтаь не нужно, для сборки прочтите файл README и INSTALL. В РОСЕ есть макросы и на другие случаи жизни - например, %cmake для одноименного инструмента сборки.
Когда сборка успешна закончена, в действие вступает секция %install .
%install pushd %{name}-tools-%{version} %makeinstall_std popd %makeinstall_std %find_lang %{name}
%%find_lang , поиск файлов локализации. Параметром у неё является название файлов, которые будут лежать после установки в каталоге %{buildroot}/usr/share/locale/*/LC_MESSAGES/*.mo . Обычно оно соответствует %{name} . Если это не так, пишите другое имя.
Во многих spec-файлах вы можете заметить выполнение команды rm -rf %{buildroot} или rm -rf $RPM_BUILD_ROOT в самом начале секции %install , а также секцию %clean с такими же строками. В современной РОСЕ в этом нет необходимости, такая зачистка выполняется автоматически.
%preun %preun_uninstall_gconf_schemas %{name}
Секции для установочных скриптов. Вообще их бывает несколько. %pre - выполняется перед установкой, %post - после установки, %preun - перед удалением, %postun - после удаления. В нашем примере при удалении удаляются схемы Gconf. Здесь мы предполагаем, что в пакете только одна схема и ее имя совпадает с именем пакета. Обратите внимание, что для удаления схем мы вызываем специальный макрос; этот макрос раскрывается rpmbuild РОСЫ в набор необходимых команд оболочки Shell, которые, собственно, и удаляют схему. Установка схем при установке пакета выполняется автоматически за счет файловых триггеров RPM .
Для каждого пакета могут быть свои скрипты, поэтому следует также почитать документацию. Если никаких скриптов для правильной работы не нужно, то и секции эти не следует использовать. В этих секциях можно применять bash-скрипты (впрочем как и в любых других секциях).
В секциях %files мы должны указать какие файлы должны быть упакованы в пакеты. Все файлы должны быть оговорены, в противном случае rpmbuild выдаст сообщение о неупакованных файлах.
Опцией -f указываются файл, содержащий список обрабатываемых файлов. В нашем случае этот файл содержит пути к файлам локализации. Вы в принципе можете создать свой файл и подсунуть его.
Для определения каталогов используются специальные макроопределения.
- %{_prefix} - /usr
- %{_sysconfdir} - /etc
- %{_bindir} - /usr/bin
- %{_datadir} - /usr/share
- %{_libdir} - /usr/lib или /usr/lib64 в зависимости от разрядности системы
- %{_lib} - соответственно /lib или /lib64
- %{_libexecdir} - /usr/libexec
- %{_includedir} - /usr/unclude
- %{_mandir} - /usr/share/man
- %{_sbindir} - /usr/sbin
- %{_localstatedir} - /var .
- %{systemd_libdir} - /usr/lib/systemd
%doc помечает файлы как документацию. Третья строка копирует указанные файлы в каталог %{_datadir}/doc/%{name}-%{version} . По умолчанию файлы в rpm пакете будут иметь владельцем root’а, а права доступа у низ будут такие же, как и в процессе установки. Если это необходимо поменять, то воспользуйтсь конструкцией %defattr .
%files tools %{_bindir}/stardict-editor
Тоже самое для пакета stardict-tools . Если бы он назывался tools-stardict , то %files выглядел бы так:
%files -n tools-%{name}.
Последнее, что идёт в spec-файле, это %changelog . В changelog’е вы указывает изменения в пакете по сравнению с предыдущей версией. Синтаксис его примерно следующий.
%changelog
* Sun Apr 22 2007 Your Name
Макроопределения
Теперь пора познакомиться поближе с макросами и переменными. Допустим, мы собираем пакет из SVN, в данном случае в релиз обычно включается дата ревизии. В самом начале spec-файла нужно определить переменную date:
%define date 20070612
Как мы видим, за определение переменных отвечает макроопределение %define . Теперь в любом месте spec-файла мы можем использовать нашу переменную в виде %{date} (скобки не обязательны, но в РОСЕ принято брать в скобки переменные, и не брать - макроопределения; так их проще различать). Например, определение основных параметров будет выглядеть примерно так:
Version: 0.5 Release: 0.svn%{date}.3
Обратите внимание, что перед датой стоит 0. , а после даты - число, которое и увеличивается при необходимости поднять релиз. Зачем так сделано? Когда наконец выйдет окончательная версия (в нашем случае - 0.5 ), ревизию можно будет убрать, а в релиз прописать просто 1 . При этом литерально 1 больше, чем любая строка, начинающаяся на 0 , и пакет будет считаться более новым, чем предварительные пакеты, собиравшиеся на основе ревизий SVN.
Крайне популярным макроопределением является конструкция
%if условие действие1 %else действие2 %endif
или просто %if без %else . Суть проста, если условие стоящее при %if истина, то выполняется действие1 , в противном случае выполняется действие2 .
Допустим, мы опять же собираем что-нибудь из SVN. Обычно внутри архива, если он из SVN, вместо каталога %{name}-%{version} указывают просто %{name} (архив sim-0.9.5.tar.bz2 внутри имеет каталог sim , так как финального релиза sim 0.9.5 не существует. Конечный же релиз будет иметь первым каталогом sim-0.9.5 ). Чтобы всякий раз не переписывать spec-файл, можно сделать следующие макроопределения:
%define svn 1 ... %prep %if %{svn} %setup -q -n %{name} %else %setup -q %endif
Если переменная svn не определена, то будет выполняться часть сценария после %else . Можно также использовать более строгое условие (не забудьте про кавычки):
%define svn 1 ... %prep %if "%{svn}" == "1" %setup -q -n %{name} %else %setup -q %endif
Внутри всех секций spec-файла мы можем использовать любые команды Linux, без каких либо «наворотов», а вот в шапке файла не всё так просто. Например, нам нужно определить версию firefox для пакета (допустим epiphany) и прописать ее в секцию Requires: . Выглядеть это будет следующим образом:
Requires: firefox = %(rpm -q firefox --qf "%%{version}")
Обратите внимание на то, что внешняя команда выполняется в %() (почти, как в bash - $() ) и в spec-файле необходимо ставить два знака % в параметрах. Таким образом можно вызывать любые команды Linux, например, для определения версии ядра.
Ещё одним популярным макроопределение является конструкция %ifarch .. %endif . Если архитектура соответствует указанной после %ifarch , то выполняется какое либо действие. Архитектуры бывают i386, i486, i586, i686, i?86, x86_64, и понятное дело некоторые другие, с которыми вы наверно не столкнётесь.
Как уже отмечалось выше во всех секциях spec-файла вы можете использовать любые команды Shell, включая for, while, if и др.
Сборка пакета
Теперь перейдём непосредственно к сборке пакета. Исходники и патчи должны лежать в каталоге SOURCES , а spec файл в каталог SPECS . После этого нужно отдать команду:
Rpmbuild -ba spec-файл
После этого пакет соберётся (или не соберётся, а вывалится с ошибками), и в подкаталогах каталога RPMS появятся бинарные пакеты, а в каталоге SRPMS появится исходник.
Очень часто, перед самым завершением сборки, rpmbuild выдаёт сообщение о найденных, но неупакованных файлах. Это означает, что вы просто не указали их в секции %files . Необходимо просто добавить их туда. Если же вы не хотите чтобы эти файлы попадали в пакет, то можно воспользоваться одним из следующих способов:
- Добавить в секцию %files макроопределение
- Добавить в начало spec-файла макроопределение
Если необходимо собрать только бинарник или только исходник, то вместо -ba следует использовать -bb и -bs соответственно. Из полезных параметров rpmbuild можно отметить -clean (удалить весь мусор), -rmsource (удалить исходники из каталога SOURCE ) и -target=архитектура (собрать пакет под конкретную архитектуру).
Можно также выполнять сценарии только в определённой секции. Описывать подобные параметры мы здесь не будем, см. man rpmbuild .
Сборка RPM пакета из уже установленного в системе
Иногда случается ситуация, что какой-то пакет уже установлен в системе (может быть в очень старой системе) и очень хочется получить rpm’ку с ним, а она как раз и не сохранилась. Также может захотеться собрать по быстрому пакет с изменёнными под ваши нужды конфигурационными файлами.
Для решения этой проблемы следует воспользоваться утилитой rpmrebuild. Эта написанная на bash утилита доступна в contrib-репозитории РОСЫ.
Работать с ней крайне просто. Нужно отдать всего лишь команду:
Rpmrebuild название_установленного_пакета
Если какой-либо файл был изменён, то вам об этом сообщат, но процесс сборки не прервётся.
Rpmrebuild обладает огромным количеством параметров, например, вы можете изменять release пакета, changelog, скрипты, секции Requires, описания пакета и многое другое. Можете даже просто напросто изменить spec-файл, который скрипт сгенерирует сам. Он правда будет немного страшный, но это все же лучше, чем ничего.
Все параметры можно посмотреть при помощи
Rpmrebuild --help
Внимание! Действия пунктов 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
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
: Изменения в программе.
Статья подготовлена опираясь на официальный источник от
Программа RPM предназначена для произведения всех видов операций с программным обеспечением, в том числе и для создания пакетов для установки (RPM-пакетов).
Прежде, чем описать много сухих фактов, взятых из документации, рассмотрим простой пример создания небольшого RPM-пакета. Я создал этот пакет для своей программки, которая контролирует состояние указанного последовательного порта.
Будем считать, что программа уже откомпилирована
и все файлы, необходимые для ее работы, уже подготовлены. Нам нужны следующие
файлы:
port - откомпилированный бинарный файл
README - файл
port.1 -
файл для справочной системы man
Все эти файлы я поместил в каталог /root/port. Конечно, это не совсем корректно, но об этом будет сказано немного позже.
Для создания пакета нам нужно создать файл спецификаций. В файле спецификаций указывается вся информация о создаваемом пакете: название, версия, файлы программ, файлы документации, действия, выполняемые при установке пакета и при его удалении.
Вот мой файл спецификаций для программы port
Листинг 1.
# /root/port/port.spec # Файл спецификаций для программы port # Общее описание программы Summary: Program to control your serial device # Название пакета Name: port # Его версия Version: 1.0 # Релиз Release: 99 # Группа программного обеспечения. Группы (или категории) используются многими # программами для манипуляции пакетами, например gnorpm, которая строит дерево # категорий установленного программного обеспечения Group: Monitoring # Если хотите, можете указать свое имя, но обычно указывается GPL License: GPL # Можно также указать и copyleft # Copyright: GPL # Наш пакет ни с чем не конфликтует # Conflicts: # Менеджер сам заполнит это поле при необходимости # (только для создания двоичных пакетов!) # Require: # Информация о создателе пакета Packager: Denis Kolisnichenko URL: http://dkws.narod.ru # Тэги Summary, Name, Version, Release, Group, License являются обязательными # Из вышеуказанной информации видно, что будет создан пакет: # port-1.0-99.i686.rpm # Архитектура у вас может отличаться # Полное описание пакета %description Программа port предназначена для мониторинга состояния последовательного порта. При получении сигнала (1) на какой-нибудь контакт указанного порта, port отправляет сообщение запустившему ее пользователю на указанный email # Файлы, которые будут помещены в пакет %files %doc /root/port/README /root/port/port /root/port/port.1
Для построения пакета нужно ввести команду:
# rpm -bb /root/port/port.spec
Если вы не допустили никаких ошибок при создании файла спецификаций, на экране вы увидите примерно такое сообщение:
Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.33439 Processing files: port-1.0-99 Finding Provides: (using /usr/lib/rpm/find-provides)... Finding Requires: (using /usr/lib/rpm/find-requires)... Requires: ld-linux.so.2 libc.so.6 libc.so.6(GLIBC_2.0) Записан: /usr/src/RPM/RPMS/i686/port-1.0-99.i686.rpm
При этом будет создан пакет port-1.0-99.i686.rpm. Этот пакет будет помещен в каталог /usr/src/RPM/RPMS/i686
Проведем небольшой эксперимент. Запустите Midhight Commander (mc), перейдите в каталог /usr/src/RPM/RPMS/i686/ и "войдите" в пакет port-1.0-99.i686.rpm как в обычный каталог. В нем будет "подкаталог" INFO, в котором и содержится вся информация о пакете.
Что ж, мы успешно разобрались с построением простого пакета, но для создания реальных пакетов установки наших знаний все еще не хватает. Теперь настала очередь той сухой теории, о которой я упомянул в начале статьи.
Традиционно, процедура создания RPM-пакетов состоит из следующих этапов:
- Извлечения исходных текстов программы из архива
- Компилирование программы из исходных текстов
- Создание RPM-пакета
Первые два этапа можно пропустить, что мы и сделали при создании нашего пакета. Это можно сделать только в случае, если программа уже откомпилирована из исходных текстов.
Программа RPM использует файл конфигурации rpmrc. Поиск этого файла происходит в каталогах /usr/lib/rpm, /etc, $HOME. Просмотреть этот файл можно с помощью команды:
# rpm --showrc
Запись topdir файла конфигурации rpmrc содержит название каталога, в котором находится дерево подкаталогов, которое используется менеджером RPM для постороения пакетов. Введите команду:
# rpm --showrc | grep topdir -14: _builddir %{_topdir}/BUILD -14: _rpmdir %{_topdir}/RPMS -14: _sourcedir %{_topdir}/SOURCES -14: _specdir %{_topdir}/SPECS -14: _srcrpmdir %{_topdir}/SRPMS -14: _topdir %{_usrsrc}/RPM
У меня эти подкаталоги находятся в каталоге /usr/src/RPM. Как вы видите, в этом каталоге находятся подкаталоги BUILD, RPMS, SOURCES, SPECS, SRPMS.
В каталоге BUILD создается RPM-пакет. В каталоге SOURCES находятся сжатые исходные тексты программы. В каталог RPMS помещаются созданные пакеты. Точнее, они помещаются в один из его подкаталогов, в какой именно - это зависит от архитектуры. В каталог SRPMS помещаются пакеты, содержащие исходные тексты программы.
В каталоге SPECS находятся файлы спецификаций. Обычно файл спецификации называется название_программы-версия-релиз.spec.
Например, если у вас есть исходный текст программы в архиве, из которого вы хотите создать пакет RPM, скопируйте его в каталог SOURCES
# cp source_code-1.0.tar.gz /usr/src/RPM/SOURCES
По умолчанию менеджер RPM работает с пакетами, расположенным в каталоге с именем, совпадающем с названием пакета и его версией. Для нашего пакета port это будет каталог port-1.0-99. Менеджер пакетов будет компилировать наш пакет в каталоге /usr/src/RPM/port-1.0-99
Думаю, уже достаточно информации о каталогах RPM. Теперь перейдем к файлу спецификаций. Файл спецификаций состоит из четырех сегментов: заголовка, подготовительного, файлового, установочного.
В заголовке указывается общая информация о пакете. В листинге 1 к сегменту заголовка относятся тэги Summary, Name, Version, Release, Group и Licese. На них мы останавливаться не будем, так как их назначение понятно из листинга 1.
Есть еще очень полезный тэг: BuildRoot. Он изменяет расположение дерева BUILD. Значением по умолчанию является /usr/src/RPM или другой каталог, задаваемый переменной окружения $RPM_BUILD_ROOT. В целях экономии дискового пространства полезно после установки удалить дерево %RPM_BUILD_ROOT. Но дерево по умолчанию может содержать другие файлы, относящиеся к другим пакетам. Поэтому сначала с помощью тэга BuildRoot нужно задать какой-нибудь временный каталог, а после установки удалить его.
В каждом сегменте находятся макрокоманды. С некоторыми мы уже знакомы - это %description, %files, %doc, %install. В таблице 1 приведено полное описание макрокоманд.
Таблица 1.
| Макрокоманда | Описание |
| %description | Полное описание пакета |
| %prep | Подготовка архива. Здесь задаются команды для извлечения исходного текста программы и его распаковки, дополнительная подготовка исходного текста. После макрокоманды %prep задаются обычные команды shell. |
| %setup | Макрокоманда извлечения файлов из архивов. Опция -n позволяет указать каталог, в котором будет создаваться новый пакет. Обычно распаковывается архив, расположенный в каталоге SOURCES в каталог BUILD |
| %build | Макрокоманда компилирования. Обычно здесь запускается программа make с необходимыми параметрами |
| %files | Задает список файлов, входящих в состав пакета. При указании имен файлов должен быть указан полный, а не относительный путь. Для указания полного пути можно использовать переменную окружения $RPM_BUILD_ROOT. Необходимые файлы уже должны быть помещены в каталог BUILD. Этого можно достичь с помощью макрокоманды %setup или с помощью %pre (см. ниже) |
| %config список | Задает список файлов, которые будут помещены в каталог /etc |
| %doc список | Задает список файлов, которые будут помещены в каталог /usr/doc/--. |
| %install | Этап установки программного обеспечения. Здесь нужно записать команды, которые будут устанавливать файлы, входящие в состав пакета. Удобнее использовать команду install, которую я использовал в листинге 1 |
| %pre | Действия, которые будут выполнены до инсталляции пакета |
| %post | Действия, которые будут выполнены после инсталляции пакета |
| %preun | Действия, которые будут выполнены перед удалением пакета |
| %postun | Действия, которые будут выполнены после удаления пакета |
| %clean | Удаление дерева BUILD. Используется вместо опции --clean программы rpm. Обычно содержит одну команду: rm -rf $RPM_BUILD_ROOT |
Нужно сделать небольшое замечание относительно макрокоманд %config и %doc. В этом случае список задается не так, как в макрокоманде %files. Если после макрокоманды %files можно было просто указать по одному файлу в каждой строке, то в макрокоманде %doc каждому файлу (или каждому списку) должна предшествовать команда %doc. Например,
%doc README TODO Changes %doc Install а не %doc README TODO Changes Install
Еще раз отмечу, что наличие всех макрокоманд в файле спецификаций не является обязательным.
При создании пакета мы использовали опцию -bb программы rpm. При указании этой опции создается только двоичный RPM-пакет, если вы хотите создать также пакет, содержащий исходный текст программы, используйте опцию -ba. Созданный пакет помещается в каталог SRPMS и будет иметь имя port-1.0-99.src.rpm. То есть вместо названия архитектуры будет указано, что данный пакет содержит исходный текст программы. Для создания такого пакета в каталоге SOURCES должны находиться исходные тексты программы.
Для полноты картины осталось рассмотреть опции менеджера rpm, которые используются для создания пакетов.
Таблица 2.
| -ba | Создаются два пакета: двоичный и содержащий исходный текст. При этом не пропускается ни один этап установки, указанный в файле спецификаций |
| -bb | Создается только двоичный пакет. Не пропускается ни один этап установки, указанный в файле спецификаций |
| -bc | Выполняются этапы %pre и %build. При этом пакет распаковывается и компилируется |
| -bi | Выполняются этапы %pre, %build, %install |
| -bl | Выполняется проверка списка файлов, указанных в макрокоманде %files |
| -bp | Выполняется только этап %pre, то есть распаковывается архив |
| --recompile package.src.rpm | Указанный пакет, содержащий исходные тексты, сначала устанавливается, а потом компилируется |
| --rebuild package.src.rpm | Устанавливает и компилируется пакет исходных текстов, а затем создается новый двоичный пакет |
| --test | Проверка файла спецификаций |
| --clean | Удаление дерева каталогов BUILD после создания пакета |
| --showrc | Выводит файл конфигурации |