What is rpm and deb in linux

Что лучше deb или rpm

Установка программного обеспечения — очень важный момент в работе с операционной системой. Сейчас есть две самые распространенные системы установки программного обеспечения. Это используемая в Debian и всех ее производных, в том числе и в Ubuntu — deb, а также разработанная в RedHat и используемая в Red Hat и всех основанных на ней дистрибутивов — rpm.

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

Основы

С точки зрения пользователя, эти два варианта установки пакетов не имеют очень больших различий. Оба файла и Deb и Rpm — это всего лишь архивы, созданные с помощью утилиты ar. Эти архивы включают в себя файлы программ, исполняемые файлы, библиотеки, или файлы конфигурации. Кроме этого, в каждый пакет входят метаданные системы управления пакетами, именно этим и отличаются rpm и deb. Собственно файлы пакетов отличаются в основном только этим, но еще есть система управления пакетами. А там уже различий в базе данных намного больше.

Давайте рассмотрим каждую систему управления пакетами подробнее, а затем сравним что же в них особенного, и что лучше rpm или deb.

RPM (Red Hat Package Manager)

Как мы уже говорили, RPM — это менеджер пакетов, используемый в операционных системах, основанных на Red Hat, это вся ветка дистрибутивов: Fedora, OpenSUSE, Red Hat, CentOS и т д. Изначально этот пакетный менеджер был разработан в компании Red Hat еще в 1997 году и только для их дистрибутива, но затем он распространился и в другие операционные системы. Вместо обычного сжатия здесь используется сжатие gzip по алгоритму cpio и особый формат файла архива, его мы рассмотрим ниже. Здесь в сравнении rpm или deb, первый кажется лучше, но не все так просто, если в системе нет нужных утилит, то вы не сможете распаковать такой пакет. Кроме cpio могут использоваться и другие алгоритмы сжатия, например, lzma или xz. В последнее время все программное обеспечение подписывается ключами для удостоверения подлинности, вот и RPM поддерживает подпись с помощью GPG и MD5. Технология PatchRPMs или DeltaRPMs позволяет грамотно обновлять RPM пакеты без больших затрат трафика.

Хоть и сказано, что файл rpm — это обычный архив, это не совсем так. Вначале файла находится заголовок, который идентифицирует файл как rpm архив, затем идет подпись, для проверки целостности и подлинности файла. Дальше идет заголовок, в котором содержаться данные о самом пакете, версия, архитектура, список файлов и т д. И только после всего этого идет сам архив с файлами пакета.

Для работы с RPM могут использоваться несколько различных пакетных менеджеров, это универсальная утилита rpm, пакетный менеджер zypper в OpenSUSE, dnf в Fedora, urpmi в Mageia, yum — во многих дистрибутивах, основанных на Fedora.

Рассмотрим основные особенности RPM:

• Автоматическое разрешение зависимостей в большинстве случаев корректно
• Файл архива имеет специальный формат
• Не поддерживается реализация зависимостей с выбором завистимости от пакет1 или пакет2.
• Не поддерживаются рекомендованные пакеты
• Позволяет настроить зависимость от файла, а не пакета
• Все данные об установленных пакетах хранятся в базе данных поэтому при надобности можно проверить контрольные суммы
• Поддерживаются сценарии как до, так и после установки программ
• Поддерживается формат SRPM, который содержит в себе исходники программы все патчи с инструкции по сборке, позволяющие собрать программу из исходников на локальной машине.
• Отличная поддержка Multilib пакетов

Deb (Debian Package Manager)

Файлы deb — это архивы, созданные с помощью утилиты ar. Они могут быть сжаты с помощью GZIP, Bzip2, lzma, или XZ. Чаще всего для управления пакетами deb в терминале используется утилита dpkg, Но могут и другие, например, gdebi, apt, aptitude и т д. Deb пакеты используются для установки программного обеспечения во многих операционных системах, основанных на Debian, это ветка Ubuntu со многими основанными на ней дистрибутивами и так далее. Поскольку Ubuntu в последнее время набирает популярность среди новичков, то пакетов для нее становится больше.

Из особенностей системы управления пакетами DEB можно назвать использование приоритетов для классификации пакетов по важности, а также поддержку рекомендованных пакетов. Это пакеты, которые не находятся в зависимостях программы, но желательны для установки вместе с ней. Рекомендованные утилиты устанавливаются автоматически в таком инструменте, как apt. Чтобы сравнить rpm vs deb рассмотрим особенности deb:

• Файл пакета — обычный архив
• Поддержка приоритетов для пакетов различной важности
• Поддержка рекомендованных пакетов
• Не поддерживаются файловые зависимости
• Не поддерживается технология Delta для экономии трафика

Аналоги команд

Давайте рассмотрим аналоги команд для выполнения одних и тех же действий в этих системах управления пакетами с помощью утилит rpm и dpkg:

Источник

How to install software in Linux (RPM/DEB systems)

In this tutorial, we’ll be covering packages, package managers and how to find, install and remove software for most popular Linux distributions.

Package

Typically when you install software in a Linux system you do so with a package. A package is just a collection of files that make up an application. Additionally, a package contains data about the application as well as any steps required to successfully install and remove that application.

Data / Metadata

The data or metadata that is contained within a package can include such information as the description of the application, the version and the list of dependencies or other packages that this particular application needs in order to function.

Package Manager

A package manager is used to install, upgrade and remove packages. The package manager uses a package’s metadata to automatically install any required dependencies. Package managers keep track of what files belong to what packages, what packages are installed and what versions of those packages are installed.

Installing Software on RPM Distros

Here’s a list of distributions that are based on the RPM package format. RPM stands for RedHat Package Manager.

• RedHat
• CentOS
• Fedora
• Oracle Linux
• Scientific Linux

The yum command-line utility is a package management program for those Linux distributions that use rpm packages.

Note: Installing or removing software requires root or superuser privileges.

Find packages to install using yum

Display information about a package using yum

Install a package with yum

yum will typically ask you to review your request and say yes or no. If you want to continue to automatically answer yes to yum’s question use:

Remove a package with yum

In addition to the yum command, you can also use the rpm command to interact with the package manager.

List installed packages using rpm

List the file’s package usign rpm

rpm -qf with path to a file will tell you what file a package belongs to.

List package’s files

List all the files that belong to that particular package

Install package using rpm

Erase (uninstall) pacakge using rpm

Installing Software on DEB Distros

Another popular package format is the Debian package format. In addition to Debian, distributions like Mint and Ubuntu use deb packages.

apt — Advanced Packacking Tool

The Debian-based distributions use a package manager called apt (advanced packaging tool). apt is comprised of a few small utilities with the two most commonly used being apt-cache and apt-get .

Find packages to install using apt-cache

Install a package with apt-get

Remove a package but keep configurations

Remove a package and delete configurations

Display information about a package using apt-cache

In addition to the app utilities, you can use the dpkg command to interact with the package manager.

List installed packages using dpkg

List file’s package using dpkg

List all files in a package using dpkg

Install a package with dpkg

Watch the video for live examples of searching, installing and removing some actual software like Dropbox using the above mentioned methods.

Summary

Packages are used to install software on Linux system. You can manipulate packages with a package manager. Two of the most popular package formats are RPM and Debian. For RPM-based distributions use the yum and rpm commands to manage packages. For Debian-based distributions use apt and dpkg to manage packages.

Help us improve this content by editing this page on GitHub

Источник

Что такое .deb и .rpm и чем они отличаются от .msi? [закрыто]

Что это за форматы файлов и чем они отличаются от .msi формата в Windows? И каковы плюсы и минусы этих схем управления пакетами?

Файлы, такие как .deb и .rpm более сродни .zip файлу. Это дерево каталогов файлов и подкаталогов, которые содержат файлы, относящиеся к конкретному приложению и / или библиотеке файлов.

дистрибутивы

Эти .deb файлы предназначены для распределения Linux , которые вытекают из Debian (Ubuntu, Linux Mint и т.д.). Эти .rpm файлы используются в первую очередь распределениями , которые вытекают из дистрибутивов Redhat основы (Fedora, CentOS, RHEL), а также в дистрибутиве OpenSUSE.

Что в них особенного?

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

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

Как насчет файлов .msi?

.msi файлы похожи на .deb & .rpm файлы, но, вероятно, еще более сложные. Эти .msi файлы используются установщиком Windows и предлагают дополнительные функции, такие как:

• GUI Framework
• генерация последовательностей удаления
• Фреймворк внутри себя — для использования сторонними установщиками
• Rollbacks
• Рекламное объявление
• Пользовательский интерфейс
• и т.п.

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

Ссылки

Другие ответы касаются качеств .deb и .rpm сходных с ними .msi . Все они содержат программное обеспечение в сжатом формате, которое может делать некоторые дополнительные вещи. Эти дополнительные вещи, которые уже упоминались, включали добавление пользователей, задачи до и после установки, регистрацию программы в системе (например, реестр Windows, xdg-dirs, OpenRC / systemd init и т. Д.).

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

Вы , как правило , непосредственно не взаимодействуют с .deb и .rpm файлы , как вы делаете с .msi файлами. На самом деле, как упоминалось ранее, a, .deb как правило, представляет собой просто архив (ar или tar), сжатый с помощью xz с содержащимися файлами в определенной структуре каталогов. Вместо этого вы используете такие инструменты, как dpkg и rpm для управления этими файлами.

dpkg и rpm установит содержимое .deb и .rpm файлы и проверит, установлено ли все необходимое программное обеспечение. Запуск этих программ аналогичен нажатию на .msi файл. Пользователи, однако, обычно не взаимодействуют с dpkg или rpm вместо этого используют apt-get и yum для установки пакетов. Эти инструменты не имеют точных аналогов на окнах.

Оба apt-get и yum имеют возможность получить файлы с удаленных (или локальных) хранилищ и использовать информацию о зависимостях , хранящуюся в .deb и .rpm файлы для загрузки и установки каких — либо предпосылок не встречались. С этими инструментами мне не нужно знать или беспокоиться о том, какое другое программное обеспечение мне нужно, я могу просто указать apt-get install chromium и знать, что apt-get будет гарантировать, что у меня установлены gtk +, alsa, некоторые библиотеки X и т. Д., Без необходимости вручную находить и устанавливать их .deb и .rpm файлы.

apt-get и yum является большими два менеджером пакетов, вы также найдете emerge и pacman там, которые делают ту же работу , хотя и с различными основными механизмами.

Источник

Каковы плюсы / минусы 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. Реальное сравнение 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 для огромного совместимого индекса пакета.

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

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

• Растущая популярность
• Позволяет рекомендации и предложения (возможно, более новые 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, и они работали просто отлично, несмотря на то, что эта совместимость официально не гарантирована.

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

Источник