Наши партнеры

Книги по Linux (с отзывами читателей)

Библиотека сайта rus-linux.net

Ошибка базы данных: Table 'a111530_forumnew.rlf1_users' doesn't exist
На главную -> MyLDP -> Тематический каталог -> Установка новых программных пакетов

Сравнение форматов бинарных установочных пакетов

Оригинал: ATOL: Comparison of binary package formats
Автор: Miloš Jakubíček
Дата публикации: 28 марта 2008 г.
Перевод: Максим Белозеров
Дата перевода: 28 октября 2009 г.

Основная задача бинарных пакетов, или, точнее, систем управления пакетами (независимо от используемого формата) &mdash предоставить готовые сборки программ, включающие в себя метаинформацию в форме, которая позволит пользователям и администраторам легко обслуживать систему и прикладные программы (устанавливать, обновлять, удалять и т. д.), не нарушая целостности системы и эффективно используя ее ресурсы.

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

Сравнение форматов бинарных установочных пакетов

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

RPM (сокращение от Redhat package management, управление пакетами Redhat) используется в таких системах как SUSE/openSUSE, Mandriva, CentOS и, конечно, RHEL и Fedora.

Формат deb в основном используется в Debian и дистрибутивах на основе Debian, таких как Ubuntu. TGZ &mdash нестандартизированный формат пакетов, так как существует несколько дистрибутивов (в основном менее распространенных, таких как ArchLinux, Slackware и др.), использующих tar и gzip для хранения бинарных пакетов самых разных форматов.

Эта статья посвящена сравнению форматов deb и RPM, так как эти форматы сейчас наиболее распространены и наиболее функционально богаты. Кроме того, существует alien &mdash инструмент для конвертации между RPM и deb.

RPM

Стандартный способ упаковки программ с помощью RPM &mdash создать SPEC-файл с метаинформацией о пакете, такой как название, версия, выпуск (часто сокращается как N-V-R &mdash name, version, release), зависимости для запуска и сборки, различные установочные сценарии (скриптлеты) или триггеры (сценарии, запускаемые особыми действиями других пакетов: установкой, обновлением, удалением) и т. д.

Затем из SPEC-файла и файлов с исходным кодом создается пакет SRPM (source RPM), с помощью которого можно легко собрать установочный пакет или распространять исходники. Из SRPM создается один или несколько финальных RPM-пакетов для установки. Для автоматизированной проверки формата SPEC-файлов и пакетов SRPM есть полезная программа rpmlint.

deb

Структура deb-пакетов состоит из трех основных компонентов: во-первых, файл debian-binary, в котором содержится номер версии формата deb; во-вторых, архив control.tar.gz, содержащий всю метаинформацию о пакете, аналогично SPEC-файлу RPM, только разбитую на множество файлов (такие как файл control с основной метаинформацией или установочные скрипты, каждый также в отдельном файле).

И, наконец, в-третьих, архив data.tar.gz, в котором хранятся бинарные файлы и другие файлы программы. Аналогично с rpmlint для RPM, для deb есть lintian.

Сравнение

Прежде всего надо предупредить, что есть несколько аспектов, затрудняющих сравнение, но их важно учитывать. Один из них &mdash то, что в каждом дистрибутиве обычно определены более или менее строгие правила подготовки установочных пакетов, сильно влияющие на удобство использования систем управления пакетами. Более того, обычно пользователи выбирают дистрибутив не по системе управления пакетами. И хотя существует техническая возможность использовать любую систему управления пакетами в любом дистрибутиве, для большинства пользователей это слишком сложно.

По этой причине (и некоторым другим) здесь отмечены только некоторые плюсы и минусы форматов RPM и deb.

RPM

  • + DeltaRPM позволяет экономить интернет-трафик пользователя, загружая только разницу (diff) между версиями пакетов.
  • + Пакеты с подписью GPG.
  • + Хорошая поддержка систем с multilib (например, 32- и 64-битных)
  • + Точная автоматическая генерация зависимостей среды исполнения в большинстве случаев.
  • &minus Нет инструментов управления рекомендованными (необязательными) зависимостями.
  • &minus Нестандартный формат (для распаковки требуется rpm2cpio).
  • &minus Богатая функциональность подразумевает более сложное устройство.

deb

  • + Рекомендованные зависимости.
  • + Для классификации пакетов по важности есть приоритеты.
  • + Стандартный формат (tar).
  • + Часть разработчиков предпочитает децентрализованное хранение метаинформации.
  • &minus Нет непосредственной поддержки multilib.
  • &minus Нет файловых зависимостей.

Заключение

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

  • Хотя пакеты deb могут быть подписаны GPG, эта возможность еще не реализована в Debian.
  • Формат deb разрабатывался для десктопов и, следовательно, интерактивен, тогда как формат RPM разрабатывался для серверов и крайне неинтерактивен. Но, как ни странно, сейчас RPM чаще используется на десктопах, а не на серверах.

Комментарии