it-swarm-ru.tech

Каковы плюсы / минусы deb против rpm?

По любым причинам я всегда использовал дистрибутивы на основе RPM (Fedora, Centos и в настоящее время openSUSE). Я часто слышал, что там говорится, что deb лучше, чем rpm, но когда его спрашивают, почему, никогда не удавалось получить внятный ответ (обычно вместо этого получают ревностные разглагольствования и обильные плевки).

Я понимаю, что могут быть некоторые исторические причины, но для современных дистрибутивов, использующих два различных метода упаковки, может ли кто-нибудь дать технические (или другие) преимущества одного против другого?

173
Evan

Основным отличием для сопровождающего пакета (я думаю, что это будет "разработчик" в Debian Lingo) является способ объединения метаданных пакета и сопутствующих сценариев.

В мире RPM все ваши пакеты (поддерживаемые вами RPM) находятся в чем-то вроде ~/rpmbuild. Внизу есть каталог SPEC для ваших spec-файлов, каталог SOURCES для архивов исходного кода, каталоги RPMS и ​​SRPMS для размещения вновь созданных RPM и SRPMs, и некоторые другие вещи, которые не имеют отношения сейчас.

Все , что связано с тем, как будет создан RPM, находится в spec-файле: какие патчи будут применены, возможные пре- и пост-скрипты , метаданные, журнал изменений, все. Все исходные архивы и все патчи всех ваших пакетов находятся в ИСТОЧНИКАХ.

Теперь лично мне нравится тот факт, что все идет в spec-файл, и что spec-файл является отдельной сущностью от исходного архива, но я не слишком рад иметь все источники в ИСТОЧНИКАХ. ИМХО, ИСТОЧНИКИ довольно быстро загромождаются, и вы склонны терять представление о том, что там находится. Однако мнения расходятся.

Для RPM важно использовать точный тот же тарбол, что и вышедший проект, до отметки времени. Как правило, нет никаких исключений из этого правила. Пакеты Debian также требуют того же tarball, что и upstream, хотя политика Debian требует перепаковки некоторых tarballs (спасибо, Umang).

Пакеты Debian используют другой подход. (Простите за любые ошибки: у меня гораздо меньше опыта работы с deb, чем с RPM.) Файлы разработки пакетов Debian содержатся в каталоге для каждого пакета.

Что (я думаю) нравится в этом подходе, так это то, что все содержится в одном каталоге.

В мире Debian более приемлемо использовать патчи в пакете, который (пока) не является апстримом. В мире RPM (по крайней мере, среди производных Red Hat) это осуждается. Смотрите "FedoraProject: оставаясь ближе к проектам, связанным с исходным кодом" .

Кроме того, Debian имеет огромное количество сценариев, которые способны автоматизировать огромную часть процесса создания пакета. Например, создать простой пакет setuptool'ed Python) так же просто, как создать пару файлов метаданных и запустить debuild. spec-файл для такого пакета в формате RPM будет довольно коротким, и в мире RPM тоже есть много вещей, которые в наши дни автоматизированы.

87
wzzrd

Многие люди сравнивают установку программного обеспечения с apt-get до rpm -i, и поэтому лучше скажи DEB. Это, однако, не имеет ничего общего с форматом файла DEB. Реальное сравнение - dpkg vs rpm и ​​aptitude/apt-* vs zypper/yum.

С точки зрения пользователя, в этих инструментах нет большой разницы. Форматы RPM и DEB - это просто архивные файлы, к которым прикреплены некоторые метаданные. Они оба в равной степени таинственны, имеют жестко запрограммированные пути установки (чёрт!) И отличаются только тонкими деталями. Обе dpkg -i а также rpm -i не имеют возможности выяснить, как установить зависимости, кроме случаев, когда они указаны в командной строке.

Помимо этих инструментов, существует управление хранилищем в виде apt-... или zypper/yum. Эти инструменты загружают репозитории, отслеживают все метаданные и автоматизируют загрузку зависимостей. Окончательная установка каждого отдельного пакета передается инструментам низкого уровня.

Надолго, apt-get превосходно справился с обработкой огромного количества метаданных действительно быстро, в то время как yum потребовалось бы много времени, чтобы это сделать. RPM также страдает от таких сайтов, как rpmfind, где вы найдете более 10 несовместимых пакетов для разных дистрибутивов. Apt полностью скрыл эту проблему для пакетов DEB, поскольку все пакеты были установлены из одного источника.

На мой взгляд, zypper действительно сократил разрыв до apt, и в наши дни нет причин стыдиться использования дистрибутива на основе RPM. Это так же хорошо, если не проще использовать с доступным сервисом сборки openSUSE для огромного совместимого индекса пакета.

97
vdboor

С точки зрения системного администратора, я обнаружил несколько незначительных отличий, в основном в наборе инструментов dpkg/rpm, а не в формате пакета.

  • dpkg-divert позволяет сделать так, чтобы ваш собственный файл заменил файл, полученный из пакета. Это может быть спасением, если у вас есть программа, которая ищет файл в /usr или /lib и ​​не возьму /usr/local для ответа. Идея была предложена, но, насколько я могу судить, не принята, в оборотах.

  • Когда я в последний раз управлял системами на основе rpm (что, как известно, было много лет назад, возможно, ситуация улучшилась), rpm всегда перезаписывал измененные файлы конфигурации и перемещал мои настройки в *.rpmsave (IIRC). Это сделало мою систему не загружаемой хотя бы один раз. Dpkg спрашивает меня, что делать, с настройками по умолчанию.

  • Двоичный пакет rpm может объявлять зависимости от файлов, а не от пакетов, что обеспечивает более точное управление, чем пакет deb.

  • Вы не можете установить пакет rpm версии в системе с версией N-1 инструментов rpm. Это может относиться и к dpkg, за исключением того, что формат меняется не так часто.

  • База данных dpkg состоит из текстовых файлов. База данных rpm является двоичной. Это позволяет легко исследовать и восстанавливать базу данных dpkg. С другой стороны, до тех пор, пока ничего не происходит не так, rpm может быть намного быстрее (установка deb требует чтения тысяч маленьких файлов).

  • Пакет deb использует стандартные форматы (ar, tar, gzip), так что вы можете легко и просто проверить пакеты deb. Пакеты Rpm не так дружелюбны.

40
Gilles 'SO- stop being evil'

RPM:

  • "Стандартизировано" (не то, чтобы не было спецификации deb)
  • Используется многими различными дистрибутивами (но пакеты из одного не обязательно работают в другом)
  • IIRC допускает зависимости от файлов, а не только от пакетов

DEB:

  • Растущая популярность
  • Позволяет рекомендации и предложения (возможно, более новые RPM также позволяет)

Вероятно, более важный вопрос - это менеджер пакетов (dpkg против yum против aptitude и т.д.), А не формат пакета (так как оба сопоставимы).

19
Maciej Piechotka

Как сказали несколько респондентов, это не так, что определенный формат пакета явно лучше. Технически они могут быть более или менее сопоставимы. С моей точки зрения, многие различия и то, почему люди предпочитают одно другому, связаны с:

  • Философия оригинального дизайна упаковки и целевая аудитория
  • Размер сообщества и, соответственно, качество и богатство хранилищ

Философия:

В мире Ubuntu/Debian/Mint/... пользователи ожидают, что установленный пакет будет "просто работать" после его установки. Это означает, что во время установки ожидается, что пакеты позаботятся обо всем, что необходимо для правильной работы, в том числе:

  • настройка необходимых или дополнительных заданий cron
  • настройка альтернатив/псевдонимов
  • настройка сценариев запуска/выключения
  • включая все необходимые файлы конфигурации со значениями по умолчанию, которые имеют смысл
  • сохранение старых версий библиотек и добавление верных символических ссылок в библиотеки (.so) для обратной совместимости
  • чистая поддержка многоархивовых (32 и 64-битных) двоичных файлов на одной машине и так далее.

В мире rpm - по общему признанию, это было ситуацией несколько лет назад, и с тех пор она могла улучшиться - я обнаружил, что должен выполнить дополнительные шаги (например, chkconfig, включение заданий cron), чтобы фактически заставить пакеты действительно работать. Это может быть хорошо для системных администраторов или людей, которые разбираются в Unix, но это заставляет страдать новичков. Обратите внимание, что дело не в том, что сам формат пакета RPM предотвращает это, а в том, что многие пакеты де-факто не "полностью выполнены" из перспектива новичка.

Размер сообщества, участие и богатство репозиториев:

Так как сообщество ubuntu/debian/mint/... стало больше, все больше людей занимаются упаковкой и тестированием программного обеспечения. Я обнаружил, что богатство и качество хранилищ превосходно. В Ubuntu мне редко, если вообще нужно, нужно скачивать исходники и строить из них. Когда я переключился с Red Hat на Ubuntu дома, в типичном репозитории RHEL было ~ 3000 пакетов, в то же время ubuntu + universe + multiverse, доступный напрямую из любого зеркала Canonical, имел ~ 30 000 пакетов (примерно в 10 раз). Большинство пакетов, которые я искал в формате RPM, не были легко доступны с помощью простого поиска и щелчка в диспетчере пакетов. Им потребовалось переключиться на альтернативные репозитории, выполнить поиск на веб-сайте службы rpmfind и т.д. Это, в большинстве случаев, вместо того, чтобы решить проблему, сломало мою установку из-за невозможности ограничить то, какие зависимости могут или не могут быть обновлены корректно. Я столкнулся с феноменом "ада зависимости", как описано выше Шоном Дж. Гоффом.

В отличие от Ubuntu/Debian, я обнаружил, что мне почти никогда не нужно строить из исходного кода. Также из-за:

  • Быстрый релиз (6 месяцев) в Ubuntu
  • Существование полностью совместимых PPA, которые работают из коробки
  • Репозитории с одним источником (все они размещены в Canonical) не нужно искать альтернативные/дополнительные репозитории
  • Удобный пользовательский опыт от клика до запуска

Мне никогда не приходилось идти на компромисс с более старыми версиями пакетов, которые меня волновали, даже если они не поддерживались официальными (Canonical) разработчиками. Мне никогда не приходилось оставлять свой любимый дружественный графический менеджер пакетов для удобного поиска по ключевым словам, чтобы найти и установить любой нужный мне пакет. Кроме того, несколько раз я устанавливал пакеты Debian (не Canonical) в Ubuntu, и они работали просто отлично, несмотря на то, что эта совместимость официально не гарантирована.

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

15
arielf

Я думаю, что смещение происходит не от формата пакета, а от несоответствий, которые существовали в репозиториях RedHat.

В те времена, когда RedHat был дистрибутивом (до появления RHEL, Fedora и Fedora Core), люди иногда оказывались в "RPM Hell" или "Ад зависимостей". Это происходило, когда хранилище получало пакет с зависимостями (обычно на несколько уровней), которые были взаимоисключающими. Или это может произойти, когда два разных пакета имеют две взаимоисключающие зависимости. Это была проблема с состоянием хранилища, а не с форматом пакета. "RPM Hell" оставил отвращение к RPM-системам среди некоторой части пользователей Linux, которые были сожжены этой проблемой.

12
Shawn J. Goff

Существует также "философское" различие, когда в пакетах Debian вы можете задавать вопросы и тем самым блокировать процесс установки. Плохая сторона этого в том, что некоторые пакеты будут блокировать ваши обновления, пока вы не ответите. Хорошая сторона этого, также как и философское отличие, в системах на основе Debian: когда пакет установлен, он настроен (не всегда так, как вам хотелось бы) и работает. Не в системах на основе Redhat, где вам нужно создать/скопировать из/usr/share/doc/* файл конфигурации по умолчанию/шаблона.

8
Luc Stepniewski

В RPM мне нравится одно (недавнее?) Добавление дельта-RPM. Это позволяет легче обновлять, уменьшая требуемую пропускную способность.

DEB - это стандартные ar-файлы (с более стандартными архивами внутри), RPM - это "проприетарные" двоичные файлы. Я лично считаю, что первое удобнее.

Всего лишь две вещи, которые я могу придумать. Оба очень сопоставимы. Оба имеют отличные инструменты для упаковки. Я не думаю, что есть так много достоинств для одного над другим или наоборот.

6
johansson

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

Вот довольно хороший справочник для сравнения некоторых специфических функций, доступных для каждого конкретного формата упаковки: http://debian-br.sourceforge.net/txt/alien.htm (в соответствии с Интернетом Сервер, этот документ довольно старый: Последнее изменение: Воскресенье, 15 октября 2000 г. , так что это может быть не лучший справочник.)

5
Mike Gray

OpenSUSE Build Service (OBS) и zypper - это две причины, по которым я предпочитаю RPM, а не deb с точки зрения упаковщика и пользователя. Зиппер прошел долгий путь и довольно чертовски быстр. OBS, хотя и может обрабатывать файлы debs, действительно хорош, когда дело доходит до упаковки rpms для различных платформ, таких как openSUSE, SLE, RHEL, centos, Fedora, mandriva и т.д.

5
decriptor

Ни один из других ответов не касается того, как следующие три фундаментальные различия имеют реальные последствия:

  1. deb файлы - это в основном ar архивы, содержащие два сжатых архива
  2. Пакеты deb и ​​система dpkg хранят ваши сценарии сопровождающего в виде отдельных файлов.
  3. dpkg и ​​rpm запускают сценарии сопровождающего в другом порядке во время обновлений.

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

Из-за # 1, если мне нужно изменить файл deb, я могу тривиально открыть его, внести любые изменения и перепаковать его используя стандартные инструменты, которые существуют в большинстве систем знак равно.

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

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

Из-за # 3 я могу сделать некоторые из этих исправлений, просто выпустив новую версию моего пакета, потому что во время обновления dpkg запускает сценарий "pre-install" новой версии пакета до скрипт "post-remove" старой версии.

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

А поскольку модифицировать пакет очень просто - фактические затраты на конкретный пакет и затраты на знания крошечные - он доступен большему количеству людей и требует меньше времени и усилий с файлами deb.

4
mtraceur

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

4
tex

Перейти поиск Google для

  1. повторяющиеся пакеты rpm
  2. двойные пакеты dpkg

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

2
user2472