Сборка пакета не так проста, как бы мы этого хотели. Часто приходится делать одно и то же снова и снова, чтобы получить работающий rpm. Эта глава рассказывает о лучшей для применения практике сборки.

13.2.2.1 Используйте инструменты
Использование инструментов часто помогает ускорить процесс сборки, а также помогает пониманию механизмов работы RPM. Утилиты, применимые в сборке, например, Red Hat плагин для Eclipse IDE, есть живое доказательство этой полезности.

Даже так называемые "реальные Линукс-хакеры", могущие смоделировать работающую систему виртуальной памяти с помощью одной команды cat, не пренебрегают утилитами, поскольку время - настоящая ценность.

Пример утилиты, имеющей действительную пользу - программа gendiff, входящая в RPM. Она позволяет избегнуть необходимости хранить отдельную директорию оригинальных исходников. gendiff позволяет создать патч на каталог исходников, если было изменено много файлов внутри каталога.

Для работы gendiff нужно сохранить копии всех файлов, которые вы хотите модифицировать. Задайте сохраняемым файлам одинаковое расширение, например, .orig . После редактирования файлов запускается gendiff таким образом:

Файл патча patch_name.patch будет содержать все изменения для всех файлов в каталоге.

13.2.2.2 Никогда не собирайте пакеты из-под root
Никогда не собирайте пакеты из-под пользователя root (Never, never, never build RPMs logged in as the root user - весьма эмоционально, прим. перев.). Поскольку для тестирования собранных пакетов их требуется установить, а это происходит с правами root, этот аспект приходится держать в голове. Но все-таки опасность велика. В spec-файле присутствует множество скриптов и команд и даже одна ошибка в одной команде может обрушить систему, если эта команда выполняется с правами суперпользователя. Права root допускают возможность модификации файлов, в том числе системных, удаление файлов и запись нового содержания поверх существующего. Вряд ли это допустимо для системы, в которой вы собираете пакеты.

13.2.2.3 Создайте цифровую подпись
В RPM версии 4.1 и новее гораздо большее значение придано цифровой подписи пакетов. Команда rpm в поведении по умолчанию проверяет подпись каждого пакета, к которому обращается.

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

13.2.2.4 "Умное" копирование
Возможно, ваш дистрибутив содержит сотни rpm-пакетов и каждый их них имеет spec-файл. Почему бы не просмотреть эти спецификации? Вместо старта с пустого spec-файла множество определений могут быть перенесены в виде готовых решений. Однако, не все spec-файлы идеальны. Вряд ли стоит копировать не оптимальные подходы и решения.

13.2.2.5 Определение BuildRoot
Директива BuildRoot задает каталог, в котором будет собираться ПО. В соответствии со стандартным подходом мы должны определить каталог под каталогом _tmppath. Например:

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

В команде rpmbuild можно использовать опцию --buildroot для переопределения директивы BuildRoot из spec-файла.

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

Всегда определяйте BuildRoot.

13.2.2.6 Добавляйте запись в журнал изменений для каждой новой версии сборки
Каждый раз, когда собирается новая версия пакета, в секцию %changelog должна быть добавлена запись. Благодаря этому администраторы систем могут отслеживать последовательность изменений и устанавливать те версии, в которых нужные изменения есть (или наоборот, нет ненужных изменений).

Эта информация также помогает понять, нуждается ли пакет в обновлении.

Важной информацией в журнале изменений являются сообщения об исправлении различных уязвимостей.

13.2.2.7 Задайте группу пакета
Все пакеты категорированы по группам. Имена групп позволяют, например, облегчить пользователю поиск нужных пакетов. Они выводятся графическими утилитами управления пакетами в свойствах пакетов.

Если ваше приложение представляет собой общесистемную консольную утилиту, поместите ее в группу System Environment/Shells и не помещайте ее в группы Development/Languages или System Environment/Daemons. Это сравнительно незначительная деталь во всем стеке информации о пакете, но она помогает поиску в огромном массиве пакетов дл я Linux.

Официальный список групп пакетов Red Hat для RPM версии 4.1 содержится в файле /usr/share/doc/rpm-4.1/GROUPS и где-нибудь в похожей локации для других версий RPM.

Далее - Раздел 14. Автоматизация операций RPM с помощью скриптов
Назад - Передовой опыт: подготовка к сборке
Содержание