Каковы плюсы и минусы deb vs. rpm?

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

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

156 голосов | спросил Evan 18 AM00000050000001431 2010, 05:17:14

12 ответов


82

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

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

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

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

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

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

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

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

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

ответил wzzrd 18 PM00000060000004331 2010, 18:04:43
91

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

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

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

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

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

ответил vdboor 20 AM00000010000000731 2010, 01:53:07
38

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

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

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

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

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

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

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

ответил Gilles 20 PM00000040000003131 2010, 16:57:31
19

RPM:

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

DEB:

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

Вероятно, более важным вопросом является менеджер пакетов (dpkg против yum vs. aptitude и т. д.), а не формат пакета (поскольку оба они сопоставимы).

ответил Maciej Piechotka 18 AM00000060000004031 2010, 06:34:40
11

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

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

ответил Shawn J. Goff 18 42010vEurope/Moscow11bEurope/MoscowThu, 18 Nov 2010 02:32:11 +0300 2010, 02:32:11
11

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

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

Философия:

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

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

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

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

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

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

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

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

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

ответил arielf 7 Mayam13 2013, 02:55:37
7

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

ответил Luc Stepniewski 20 AM000000110000003631 2010, 11:22:36
5

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

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

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

ответил johansson 18 AM00000060000005531 2010, 06:30:55
5

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

ответил decriptor 18 PM00000080000004731 2010, 20:10:47
5

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

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

ответил Mike Gray 18 AM00000060000000031 2010, 06:55:00
4

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

ответил tex 14 TueEurope/Moscow2010-12-14T21:20:30+03:00Europe/Moscow12bEurope/MoscowTue, 14 Dec 2010 21:20:30 +0300 2010, 21:20:30
1

Поиск Google для

  1. rpm дубликаты пакетов
  2. dpkg дубликаты пакетов

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

ответил 6 Jpm1000000pmThu, 06 Jan 2011 21:25:57 +030011 2011, 21:25:57

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132