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

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

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

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

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

Все, что связано с тем, как будет создаваться RPM, находится в spec-файле: какие патчи будут применены, возможные пре- и пост-скрипты, метаданные, журнал изменений, все. Все исходные архивы и все патчи всех ваших пакетов находятся в SOURCES.

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

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

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

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

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

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

Многие люди сравнивают установки программного обеспечения с apt-getк rpm -iи , следовательно , сказать , DEB лучше. Это, однако, не имеет ничего общего с форматом файла DEB. Реальное сравнение dpkgvs 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 для огромного совместимого индекса пакета.

С точки зрения системного администратора, я обнаружил несколько незначительных отличий, в основном в наборе инструментов 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 требует чтения тысяч маленьких файлов).

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

RPM:

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

DEB:

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

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

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

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

Философия:

В мире 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, я обнаружил, что мне почти никогда не нужно строить из исходного кода. Также из-за:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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