Глава 3. Создание пакетов

При создании пакетов надо принимать во внимание множество моментов, особенно если пакеты предоставляются через Red Hat Network. Эта глава содержит обзор методов создания пакетов для их последующей передачи в Red Hat Network, включая использование RPM, сборку пакетов для RHN и способы подписи пакетов.

3.1. Сборка пакетов для Red Hat Network

Red Hat Network использует менеджер пакетов RPM (сокр. от RPM Package Manager) для определения дополнений и обновлений, применимых к каждой системе клиента. Обычно вы получите пакеты в формате RPM с Red Hat Network. ISO-образы доступны на вкладке Программы сайта Red Hat Network, но они недоступны для установок RHN Satellite. Если Satellite включает поддержку Solaris, можно использовать RHN Push для отправления пакетов Solaris в частные каналы, которые используются клиентами Solaris.
RPM облегчает процесс установки, удаления, обновления и проверки версий пакетов, а также позволяет разработчикам осуществлять компиляцию и сборку программ.

3.1.1. Достоинства RPM

Основные достоинства RPM:
Простота обновлений
RPM позволяет выполнить обновление отдельных компонентов системы без необходимости переустановки. Например, если Red Hat выпускает новую версию Red Hat Enterprise Linux, переустановка не потребуется — RPM выполнит установку обновлений. Состояние файлов конфигурации останется неизменным между обновлениями, поэтому настройки не будут потеряны. Для установки и обновления пакета используется один и тот же файл RPM.
Поиск пакетов
RPM позволяет осуществить поиск пакетов в базе данных RPM. Например, можно легко определить, какому пакету принадлежит конкретный файл. Файлы в составе пакета сжаты, а двоичный заголовок содержит важную информацию о пакете и его содержимом. RPM может быстро проверять заголовки.
Проверка пакетов
RPM позволяет проверить подлинность пакета. Например, если вы думаете, что отдельный файл принадлежит удаленному пакету, можно запросить статус файлов в его составе. В случае ошибки можно просто переустановить файлы. Модифицированные файлы конфигурации не будут изменены в процессе переустановки.
Исходные источники
Основной целью RPM является возможность использования исходных программных источников в формате, созданном авторами. RPM позволяет упаковать пакеты, включить все исправления и инструкции по сборке. Так, например, при выпуске новой версии нет необходимости в ручной компиляции приложения. Изменения обычно могут быть применены с помощью RPM.
Поддержка целостности исходного кода может казаться важной лишь разработчикам, но на самом деле это позволяет повысить качество программ и для конечных пользователей.

3.1.2. Принципы RPM в RHN

Основным достоинством RPM является возможность определения зависимостей и точной идентификации конфликтов. Именно поэтому Red Hat Network полагается в этом вопросе на RPM. Red Hat Network предоставляет автоматизированное окружение, что исключает необходимость ручной настройки в ходе установки пакета. Поэтому во избежание проблем при сборке для предоставления пакетов через Red Hat Network следуйте перечисленным ниже правилам:
  1. Ознакомьтесь с принципами работы RPM. В этом помогут следующие ресурсы:
  2. При сборке для дочернего канала создайте пакет для Red Hat Enterprise Linux, версия которой совпадает с версией базового канала. Но сначала не забудьте применить все обновления, полученные с Red Hat Network.
  3. Не используйте --force и --nodeps при установке пакета. Если не получается установить пакет, вероятно, Red Hat Network не сможет установить его автоматически.
  4. Имя файла должно следовать формату имя-версия-выпуск.архитектура.rpm. Пример: pkgname-0.84-1.i386.rpm, где имя — pkgname, версия — 0.84, выпуск — 1, архитектура — i386.
  5. Пакет должен быть подписан сопровождающим пакета. Пакеты без подписи могут распространяться через Red Hat Network, но надо настроить принудительную установку в up2date. Настоятельно рекомендуется подписывать пакеты (см. Раздел 3.2, «Цифровая подпись пакетов RHN»).
  6. Если пакет был модифицирован, изменена его подпись, или он был заново скомпилирован, его номер версии и выпуска увеличится на единицу. Другими словами, имя пакета всегда должно соответствовать версии сборки.
  7. RPM-пакет не может быть устаревшим по отношению к самому себе.
  8. Если пакет подразделяется на отдельные пакеты, будьте исключительно осторожны с зависимостями. Не разделяйте существующий пакет без веской причины.
  9. Пакеты не должны полагаться на интерактивные сценарии пред- и пост-установки. Если в процессе установки или удаления необходимо вмешательство пользователя, пакет не сможет работать с Red Hat Network.
  10. Никакие сценарии, выполняемые до или после установки и удаления, не должны передавать данные в stderr или stdout. Вместо этого следует перенаправить вывод в /dev/null (если в нем нет необходимости) или сохранить в файл.
  11. При создании файла используйте определения групп из /usr/share/doc/rpm-<версия>/GROUPS. Если точного соответствия нет, выберите наиболее близкое.
  12. Следует проверять зависимости RPM, чтобы убедиться, что программа успешно запускается после установки.

Важно

Не создавайте RPM путем архивирования файлов с последующей разархивацией в сценарии пост-установки. Это нарушает саму идею использования RPM.
Если файлы в архиве не включены в список файлов, их невозможно будет проверить в случае конфликтов. В большинстве случаев RPM может самостоятельно упаковать и распаковать архивы. Не создавайте файлы в %post, если вы не собираетесь их удалить в секции %postun.