Библиотека сайта rus-linux.net
Упаковка программ с помощью RPM, часть 1: Создание и распространение пакетов
Оригинал: "Packaging software with RPM, Part 1: Building and distributing packages"Автор: Martin Streicher
Дата публикации: 12 January 2010
Перевод: Н.Ромоданов
Дата перевода: 2010 г.
Краткое содержание: В этой первой статье из серии трех статей, посвященных менеджеру пакетов RPM, изучается не только как с помощью RPM устанавливать программы и сопутствующие им файлы, но также как делать пакеты практически из всего — из системных скриптов, исходных кодов или документации.
Основным преимуществом программного обеспечения с открытым кодом является, как следует из названия, доступность внутренней информации об особенностях работы приложений. Имея исходный код, вы можете изучить, как приложение работает, изменить, улучшить и расширять его функции, заимствовать и повторно использовать код (в пределах лицензионного приложения), а также портировать приложение на новые и развивающиеся платформы.
Однако, такой либеральный подход требуется не всегда. Например, пользователь, возможно, не захочет заниматься созданием приложения из исходного кода. Вместо этого, он, возможно, захочет просто установить программное обеспечение точно так же, как и традиционные "коробочного" приложение: вставить носитель, запустить программу установки, ответить на несколько подсказок, и — вперед. В самом деле, для большинства пользователей предпочтительнее такое предварительно созданное программное обеспечение. Предварительно созданный код менее чувствителен к капризам системы и, следовательно, более устойчив и предсказуемым.
Обычно предварительно созданное приложение с открытым исходным кодом называется пакетом и объединяет в себе все исполняемые файлы, данные и конфигурационные файлы, необходимые для работы приложения. Пакет также пошагово выполняет все действия, требуемые для развертывания приложения в системе, обычно для этого используются скрипты. Скрипт может генерировать данные, запускать и останавливать системные службы, и выполнять операции с файлами и каталогами. Скрипт также может выполнять обновление существующего программного обеспечения — апгрейд на новую версию.
Поскольку в каждой операционной системе имеют свои особенности, пакет, как правило, подстраивается под конкретную систему. Кроме того, в каждой операционной системе имеется свой собственный менеджером пакетов - специальная утилита для добавления и удаления пакетов из системы. Например, в Linux системах, основанных на Debian, используется менеджер пакетов Advanced Package Tool (APT), а в системах Fedora Linux используется менеджер пакетов RPM. Менеджер пакетов исключает частичную и неправильную установку и "удаление" за счет того, что пакет автоматически добавляет и удаляет файлы. С помощью менеджера пакетов также поддерживается работа с манифестом — специальным описанием всех пакетов, установленных в системе, что позволяет знать о всех ранее установленных пакетах и особенностях, имеющихся в системе.
Если Вы разработчик программного обеспечения или системный администратор, предлагайте свое приложение в виде пакета, который облегчает установку, обновление и сопровождение приложения. В настоящей статье мы рассмотрим, как использовать популярный менеджер пакетов RPM и как с его помощью использовать утилиту. Для демонстрационных целей мы рассмотрим сетевую утилиту wget, которая загружает файлы из интернета. Утилита wget является полезной, но она обычно не входит в состав стандартных дистрибутивов (в дистрибутивах часто используется ее аналог - curl). Не забывайте, что вы можете использовать RPM для распространения (дистрибуции) практически всего - скриптов, документации и данных, и выполнять практически любые задачи обслуживания.
Сборка утилиты wget вручную
Утилиту wget, подобно многим другим приложениям с исходным кодом, можно собрать вручную. Понимаете этого процесса является отправной точкой для сборки утилиты wget в пакетном режиме. С общей точки зрения сборка утилиты wget состоит из следующих четырех шагов:
- Загрузка и распаковка исходного кода.
- Конфигурирование средств сборки.
- Сборка кода.
- Установка программного обеспечения.
Вы можете загрузить последнюю версию исходного кода утилиты wget с сайта ftp.gnu.org (на момент написания статьи текущей версией была версия 1.12). Остальные шаги выполняются в командной строке так, как это показано в листинге 1.
Листинг 1: Установка утилиты wget
$ tar xzf wget-latest.tar.gz $ cd wget-1.12 $ ./configure configure: configuring for GNU Wget 1.12 checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... build-aux/install-sh -c -d checking for gawk... no checking for mawk... no checking for nawk... no ... $ make $ sudo make install
Команда ./configure опрашивает систему и устанавливает настройки компиляции в соответствие с обнаруженым аппаратным и программным обеспечением. Команда make компилирует код, а команда sudo make install устанавливает код в системные директории. По умолчанию используются директории, находящиеся в корне /usr/local, хотя вы можете изменить коневой директории с помощью параметра --prefix=/some/full/path/name, используемого в команде ./configure.
Для того, чтобы сделать так, чтобы этот процесс был выполнен менеджером пакетов RPM, вы помещаете исходный код в репозитарий и пишите конфигурационный файл, в котором указывается, где можно найти исходный код, который будет компилироваться, как собирать этот код и как его устанавливать. Конфигурационный файл, называемый файлом спецификаций, подается на вход утилиты rpmbuild. Файл спецификаций и двоичные файлы упаковываются утилитой rpmbuild в RPM пакет. Когда другой пользователь загружает ваш RPM пакет, утилита rpm читает файл спецификаций файлов и устанавливает пакет в соответствие с предварительно записанной инструкцией.
Создаем наш первый пакет RPM
Прежде, чем продолжить, сделаем одно предупреждение. В прошлом пакеты создавались только пользователем root, т. е. суперпользователем, поскольку только root был единственным пользователем, имеющим доступ к репозитарию с системным кодом. Однако, такой подход потенциально опасен. Поскольку пользователь root может изменить любой файл в системе, он легко по неосторожности может изменить работу системы из-за добавления лишних файлов, либо удаления важных файлов во время промежуточных операций при сборке пакета RPM. Совсем недавно система RPM была изменена с тем, чтобы позволить любому пользователю собирать пакеты RPM в собственном домашнем директории. Построение пакета RPM без привилегий пользователя root защищает важные файлы системы от изменений. Ниже описывается более новый подход.
Для того, чтобы создать пакет RPM, вы должны:
- Создать иерархию директориев в соответствие со
спецификациями утилиты
rpmbuild. - Поместить исходный код и дополнительные файлы в надлежащие места в этой иерархии.
- Создать файл спецификаций.
- Собрать пакет RPM. Дополнительно вы собрать пакет RPM исходных кодов (source RPM) для того, чтобы разрешить другим пользоваться исходным кодом.
Сначала создадим эту иерархию. В вашем домашнем директории, скажем, $HOME/mywget, создадим следующие пять поддиректорий:
- BUILD. Директорий BUILD используется для компилирования программного обеспечения.
- RPMS. В директории RPMS содержится бинарный
пакет RPM, который создается утилитой
rpmbuild. - SOURCES. Директорий SOURCES используется для исходных кодов.
- SPECS. В директории SPECS находится ваш файл спецификаций или несколько файлов спецификаций — по одному для каждого пакета RPM, который вы хотите собрать.
- SRPMS. В директории SRPMS хранится пакет RPM с исходными кодами, который был создан в процессе сборки.
Как минимум, вам потребуется исходный код в директории SOURCES и файл спецификаций в директории SPECS.
Скопируйте ваш ваш исходный код, в идеале он должен иметь вид tar архива (tarball), в директорий SOURCES так, как это показано в листинге 2. При необходимости переименуйте архив так, чтобы в его имени был указан номер версии приложения с тем, чтобы можно было отличить текущую версию от других версий. В соответствие с общепринятым соглашением имя должно иметь вид пакет-версия .tar.gz. В случае с утилитой wget, вы должны выполнить следующее:
Листинг 2: Копируем ваш исходный код
$ cd ~ $ mkdir mywget $ cd mywget $ mkdir BUILD RPMS SOURCES SPECS SRPMS $ cd SOURCES $ cp wget-latest.tar.gz . $ mv wget-latest.tar.gz wget-1.12.tar.gz $ cd ..
Затем, создаем файл спецификаций. Файл спецификаций является ничем иным, как обычным текстовым файлом, имеющим специальный синтаксис. В листинге 3 показан пример файла спецификаций.
Листинг 3: Пример файла спецификаций
# This is a sample spec file for wget
%define _topdir /home/strike/mywget
%define name wget
%define release 1
%define version 1.12
%define buildroot %{_topdir}/%{name}-%{version}-root
BuildRoot: %{buildroot}
Summary: GNU wget
License: GPL
Name: %{name}
Version: %{version}
Release: %{release}
Source: %{name}-%{version}.tar.gz
Prefix: /usr
Group: Development/Tools
%description
The GNU wget program downloads files from the Internet using the command-line.
%prep
%setup -q
%build
./configure
make
%install
make install prefix=$RPM_BUILD_ROOT/usr
%files
%defattr(-,root,root)
/usr/local/bin/wget
%doc %attr(0444,root,root) /usr/local/share/man/man1/wget.1
Давайте просмотрим файл спецификаций с начала и до конца. В строках с 1 по 5 определен набор удобных переменных, которые используются в остальной части файла. В строках с 7 по 15 задается ряд требуемых параметров, для этого используется формат параметр:значение. В строке 7 и в других местах показывается как можно получать настроечные значения в зависимости от значений отдельных переменных их их совокупности.
Параметр names в значительной степени понятен сам по себе, но параметр BuildRoot заслуживает некоторого пояснения с тем, чтобы отличать его от директория BUILD, который вы уже создали. BuildRoot является прокси элементом для указания окончательного директория установки. Иными словами, если wget, в конечном счете устанавливается в /usr/local/bin/wget и в другие поддиректории в /usr/local, такие как /usr/local/man для документации, BuildRoot служит в качестве указателя на /usr/local в процессе сборки пакета RPM. Как только вы зададите значение BuildRoot, вы сможете получать его значение, используя переменную среды RPM_BUILD_ROOT. Вы должны всегда устанавливать значение BuildRoot в вашем файле спецификаций и проверить что происходит, когда устанавливается пакет.
Имеется несколько особенностей:
- Не используйте
./configure —prefix=$RPM_BUILD_ROOT. С помощью этой команды будет создан весь пакет с предположением, что окончательное место расположения файлов будет находиться в корневом директории сборки пакета. Почти наверняка это приведет к сбою в работе любой программы, которая попытается в время своего исполнения разместить файлы, поскольку когда ваш пакет RPM будет окончательно будет установлен в систему пользователя, файлы уже не будут находиться в корневом директории сборки проекта — это всего лишь временный директорий в вашей системе, в которой происходит создание пакета. - Не указывайте путь в определении переменной Source.
- Переменные Version (версия) и Release (релиз) исключительно важны. Каждый раз, когда вы меняете исходный код или данные в вашем приложении и делаете доступным новый пакет RPM, убедитесь в том, что изменили значения переменных Version и Release в соответствие с существенными или незначительным изменениям. Даже в том случае, если вы собираете пакет RPM для собственных нужд, вы можете посчитать нужным каждый раз, когда вы собираете пакет RPM увеличивать номер релиза для того, чтобы отличать вариант от варианта.
Следующий раздел начинается с %description. Сюда вы должны поместить краткое, но ясное описание программы. Эта будет выдаваться всякий раз, когда вы будете запускать команду rpm -qi для того, чтобы сделать запрос к базе данных RPM. Вы можете указать, что делает пакет, указать какое-нибудь предупреждение или привести дополнительные инструкции по установке, и т.п.
Далее последовательно идут разделы %prep, %build и %install. В каждом разделе создается шелл скрипт, который добавляется в пакет RPM и последовательно исполняется как часть процесса установки. В разделе %prep указываются операции по подготовке исходного кода, такие, как распаковка tar архива. Указанная здесь команда %setup -q является макрооперацией раздела %prep, которая автоматически распаковывает tar архив с именем, указанным в переменной Source.
Инструкции в разделе %build будут выглядеть аналогичным образом. Они идентичны тем пошаговым операциям, которые делали при ручном конфигурировании и сборке пакета. Раздел %install также идентичен. Однако, если при ручной сборке целевым директорием был директорий /usr/local в вашей системе, то целевой директорий инструкции %install это директорий ~/mywget/BUILD.
В разделе %files перечисляются файлы, которые должны быть добавлены в пакет RPM и дополнительно можно задать права доступа, а также указать другую информацию. Внутри раздела %files, вы можете использовать макрокоманду %defattr, с помощью которой задаются права доступа, владелец и группа, используемые по умолчанию для файлов, входящих с состав пакета RPM; в нашем примере команда %defattr(-,root,root) устанавливает для всех файлов владельца root независимо от того, кто был владельцем, когда они были взяты из системы при сборке пакета RPM.
В разделе %files вы можете указать несколько файлов — по одному файлу в каждой строке. Вы можете пометить файлы, указав в строке %doc или %config. Пометка %doc укажет менеджеру RPM, что это файл с документацией, так что если пользователь устанавливает пакет с указанием параметра --excludedocs, этот файл устанавливаться не будет. Пометка %config укажет менеджеру RPM, что это конфигурационный файл. Во время обновления пакета менеджер RPM попытается избежать замены конфигурации, аккуратно сделанной пользователем, на конфигурацию, указанную в пакете RPM как используемую по умолчанию.
Имейте в виду, что если вы в разделе %files укажите имя директория, то в пакет RPM будут включены все файлы, содержащиеся в этом каталоге.
Собираем пакет RPM
Теперь, когда ваши файлы находятся на должном месте и определен файл спецификации, вы готовы собрать файл RPM. Для того, чтобы его собрать, используйте утилиту rpmbuild с надлежащим образом указанными параметрами:
$ rpmbuild -v -bb --clean SPECS/wget.spec
В указанной выше команде используется файл спецификаций для того, чтобы собрать бинарный пакет (-bb - "build binary", т. е. собрать бинарный) с подробной выдачей диагностических сообщений (-v). Утилита сборки удалит дерево сборки после того, как пакеты будут собраны (--clean). Если вы хотите также собрать пакет RPM с исходными кодами, то укажите -ba ("build all" — собрать все) вместо -bb. Полный список параметров смотрите на страницах man утилиты rpmbuild.
Утилита rpmbuild выполняет следующие операции:
- Читает и анализирует файл спецификаций wget.spec.
- Выполняет операции раздела
%prep— распаковывает исходный код во временный директорий. В нашем случае временный директорий - BUILD. - Выполняет операции раздела
%build— компилирует исходный код. - Выполняет операции раздела
%install— устанавливает код в директории на машине, где собирается пакет. - Читает список файлов из раздела
%files, находит их и создает бинарный пакет RPM (и пакет RPM с исходными кодами, если это выбрано).
Если вы проверите ваш директорий $HOME/mywget, вы должны найти в нем новый директорий с именем wget-1.12-root.Этот директорий выполняет роль прокси для целевого директория. Вы также должны обнаружить новый директорий с именем RPMS/i386, в котором должен находиться ваш пакет RPM, имеющий имя wget-1.12-1.i386.rpm. В имени отражается, что это версия 1.12 утилиты wget, предназначенной для работы на процессоре i386
Для того, чтобы проверить, что в пакете RPM имеются все нужные файлы, вы можете использовать команду rpm так, как это показано в листинге 4.
Листиег 4: Проверяем содержимое пакета RPM
$ rpm -Vp RPMS/i386/wget-1.12-1.i386.rpm missing /usr/local/bin/wget .M....G. /usr/local/etc missing c /usr/local/etc/wgetrc .M....G. /usr/local/share missing /usr/local/share/info missing d /usr/local/share/info/wget.info missing /usr/local/share/locale missing /usr/local/share/locale/be missing /usr/local/share/locale/be/LC_MESSAGES missing d /usr/local/share/locale/be/LC_MESSAGES/wget.mo . . .
С помощью команды rpm -Vp RPMS/i386/wget-1.12-1.i386.rpm проверяется, какие файлы были добавлены в пакет. Хотя видно, что в выходном потоке указывается о большом количестве ошибок, с помошьюэтой команды можно проверить, что содержимое пакета RPM было правильное. Если вы ожидаете, что файл должен быть установлен, но его нет в выходном списке, то это означает, что он не включен в пакет. В подобном случае проверьте файл спецификаций и удостоверьтесь, что файл указан в разделе %files.
После того, как вы проверили содержимое пакета RPM, вы можете отправить его своим коллегам. Как только коллеги получат файл, они могут запустить следующую команду rpm для того, чтобы установить утилиту wget в своих системах:
$ sudo rpm -i wget-1.12-1.i386.rpm
Другие варианты использования пакетов RPM
Это краткое вступление лишь малое упоминаете того, что можно делать с помощью RPM. Хотя эта технология наиболее часто используется для установки программного обеспечения и сопутствующих файлов, вы можете упаковывать все, что угодно — от системных скриптов и исходного кода и до документации. И, как вы увидите, во второй статье данной серии, вы можете использовать технологию RPM для пропатчивания исходного кода, а также восстановления и переустановки программ. Формат, в котором распространяются пакеты RPM, поддерживается во многих системах Linux и он является основным, используемым для установки бинарных программ на системах Red Hat, Fedora и некоторых других.
Другие статьи об управлении программным обеспечением в Linux в нашей Библиотеке.