Linux deb или rpm в чем разница

Обновлено: 05.07.2024

Дистрибутивы Linux — это программные пакеты, включающие ядро системы и большой набор различных приложений и программного обеспечение для установки ОС.

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

Особенности дистрибутивов

Хотя все дистрибутивы Linux и основаны на ядре Linux, у каждого из них есть набор основных отличительных признаков, характеризующих тот или иной дистрибутив:

Архитектура — тип процессоров, которые поддерживает дистрибутив.

Система инициализации — основополагающий подход к запуску и управлению процессами.

Менеджер пакетов — заданный по умолчанию инструмент управления пакетами дистрибутива.

Окружение рабочего стола — графический пользовательский интерфейс дистрибутива.

Сейчас мы всё это детально рассмотрим.

Архитектура

x86 (или i586/i686) — 32-битный процессор, совместимый с Intel и AMD.

x86_64 — 64-битный процессор, совместимый с Intel и AMD.

ARM — архитектура процессора, оптимизированного для использования на мобильных устройствах (планшетах, смартфонах).

PowerPC — устаревшая архитектура процессоров, применявшихся в свое время в компьютерах компании Apple.

Система инициализации

Cистема инициализации — это самый первый процесс (daemon), который запускается при загрузке компьютера с ОС на базе ядра Linux и функционирует в течение всего времени работы системы; является родительским процессом каждого последующего процесса, который запускается на устройстве.

Вопрос выбора системы инициализации является горячо оспариваемым: есть как сторонники/противники системы инициализации SysV, так и сторонники/противники системы systemd. А учитывая, что данное программное обеспечение определяет то, каким образом система будет управлять процессами, то выбор становится не таким простым и тривиальным, как может показаться на первый взгляд.

SysV — это традиционная система инициализации, уходящая своими корнями к Unix System V. Она считается более стабильной, но, возможно, менее функциональной, чем systemd.

Примечание: Вы также можете столкнуться и с другими системами инициализации, но SysV и systemd являются неоспоримыми лидерами среди них. Если вы не относите себя к опытным пользователям, то не имеет значения, какую систему инициализации вы выберете. Большинство современных дистрибутивов стали полагаться на systemd, поэтому дистрибутивы с SysV (или альтернативными её) на данный момент встречаются все реже и реже.

Менеджер пакетов

Менеджер пакетов (или «пакетный менеджер») — это заданный по умолчанию инструмент управления пакетами дистрибутива.

В Linux всё программное обеспечение поставляется в виде пакетов. Работу по архивированию и управлению данными пакетами выполняют пакетные менеджеры. Большинство пакетов не являются взаимозаменяемыми, хотя такие утилиты, как alien, могут выполнить преобразование между некоторыми типами пакетов.

Различные дистрибутивы имеют разные менеджеры пакетов:

RPM Package Manager — устанавливает/управляет пакетами формата .rpm. Использует такие инструменты, как dnf, yum и zypper.

flatpak — кроссплатформенный формат песочницы/контейнера.

pacman — пакетный менеджер в Arch Linux и производных от него дистрибутивах.

portage — разработан для Gentoo Linux, а теперь также используется ChromeOS и несколькими другими дистрибутивами.

snap — специфичная для Ubuntu форма развертывания контейнерных приложений.

eopkg — используется в дистрибутиве Solus.

Примечание: Хотя вы и можете выбрать конкретный инструмент для управления пакетами, но тип пакета жестко привязан к конкретному дистрибутиву. Таким образом, вы никогда не увидите версию Ubuntu, использующую пакеты формата .rpm. Различные дистрибутивы эксплуатируют разные репозитории программного обеспечения. Некоторые программы, созданные независимыми разработчиками, могут появляться только в одном или двух форматах пакетов. Если приоритетом для вас является возможность широкого доступа к программному обеспечению с открытым исходным кодом, то дистрибутив, использующий пакеты формата .deb или .rpm, скорее всего, будет наилучшим выбором.

Окружение рабочего стола

Когда речь заходит о главных различиях между дистрибутивами Linux, то люди почему-то считают, что всё сводится к отличиям в используемом окружении рабочего стола. Ирония же заключается в том, что большинство дистрибутивов поддерживают установку самых разнообразных вариантов рабочих столов.

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

Современные рабочие столы, как правило, менее настраиваемы — они делают упор на эстетический дизайн и внешний вид.

Конфигурация окружений рабочего стола:

К более настраиваемым рабочим столам можно отнести Xfce, LDXE, Cinnamon, MATE и KDE.

К менее настраиваемым рабочим столам можно отнести DDE (Deepin), GNOME 3 и Pantheon.

То, что остается неизменным

В любом дистрибутиве остаются неизменными следующие основные принципы:

Всегда есть ядро Linux. Ядро является основным компонентом дистрибутивов Linux, которое Линус Торвальдс написал еще в 1991 году (сейчас у него тысячи авторов!). Ядро — это интерфейс между аппаратным обеспечением вашего компьютера (клавиатуры, мыши, дисплеи и пр.) и его программным обеспечением.

Стандартное программное обеспечение GNU (такие инструменты, как bash, ls, rm и т.д.). В большинстве своем это утилиты командной строки, которые составляют основную (но критически важную) часть любой Linux-системы. Можно считать, что ядро — это автобус, курсирующий между аппаратным и программным обеспечением компьютера, а ПО GNU — это набор инструментов, который нужен вам, чтобы удерживать автобус на дороге!

Программное обеспечение общего назначения, поставляемое вместе с дистрибутивом Linux. Обычно в этот список входят: текстовые редакторы, веб-браузер, почтовый клиент, (возможно) текстовый процессор или офисный пакет и т.д.

Платить или не платить?

Покупка Linux может дать вам такие преимущества, которых нет у бесплатных версий, а именно:

Физические руководства (SUSE Linux Enterprise Server & Red Hat Enterprise Linux особенно хороши).

Поддержка от поставщиков дистрибутива в течение определенного периода времени. Такие дистрибьюторы, как Red Hat, предоставляют корпорациям гарантии высокого уровня сервиса поддержки клиентов.

Дополнительное коммерческое ПО (которое защищено авторским правом).

Обзор дистрибутивов Linux

Есть много компаний и организаций, создавшие свои собственные дистрибутивы или разновидности Linux-систем, которые смогут удовлетворить потребности любого пользователя. Наверное, даже чересчур много дистрибутивов! В нашем руководстве мы постараемся сделать этот список более простым и коротким, рассматривая только самые популярные дистрибутивы.

Debian

Debian — это дедушка всех дистрибутивов Linux, у него очень много ответвлений, включая Ubuntu. Дистрибутив был выпущен в сентябре 1993 года. Изначально, отличия Debian от систем на базе Red Hat Linux заключались в том, что он имел огромную библиотеку программных пакетов (около 50 000 библиотек) и у него была автоматическая система управления программным обеспечением под названием apt. Это означало, что вместо того, чтобы загружать множество пакетов приложений по отдельности, вы могли просто сказать Debian, какое приложение вам нужно, и он автоматически сделает всё остальное за вас. Дистрибутив традиционно известен тем, что отстает от некоторых других дистрибутивов с точки зрения наличия самых современных пакетов, но компенсирует это хорошей стабильностью, поскольку основные пакеты хорошо протестированы.

Ubuntu

Ubuntu была выпущена в 2004 году компанией Canonical и быстро стала популярной. Canonical позиционировала Ubuntu в качестве простого Linux-дистрибутива с графическим рабочим столом, который должен был вытеснить использование командной строки. Это самый известный дистрибутив Linux.

Ubuntu — это простая в использовании система для новичков, являющаяся ответвлением от Debian Linux. Она поставляется с большим количеством предустановленных приложений и еще большим количеством самого разнообразного ПО, находящимся в её репозиториях. Компания Canonical также предлагает и коммерческую поддержку Ubuntu. Существует много различных сборок на основе Ubuntu:

Edubuntu — сборка, ориентированная на образовательные учреждения.

Kubuntu — в качестве окружения рабочего стола используется KDE.

Lubuntu — облегченная версия Ubuntu.

Помимо официальных сборок, сегодня в обращении находится более 40 сторонних версий!

Linux Mint

Если вам не нравится внешний вид рабочего стола Ubuntu, то вы можете посмотреть в сторону Linux Mint. Он основан на Ubuntu и ориентирован на начинающих пользователей, а в качестве окружения рабочего стола можно использовать Cinnamon, Xfce, MATE, LXDE или KDE.

Red Hat Enterprise Linux (RHEL)

Компания Red Hat была основана в 1993 году. Они стали, пожалуй, самой коммерчески успешной распространяющей Linux компанией в мире, и теперь принадлежат IBM.

У Red Hat Linux (дистрибутив от Red Hat, который выпускался в период с 1995 по 2003 год включительно) было девять мажорных (бесплатных) релизов дистрибутивов Linux, пока в 2003 году компания не решила сделать упор на коммерческий подход в распространении Linux. В результате чего был создан Red Hat Enterprise Linux (RHEL). Этот продукт используется многими фирмами по всему миру и является коммерческим дистрибутивом Linux с полноценной поддержкой. Большинство пользователей RHEL применяют его в качестве серверной операционной системы, а не настольной.

CentOS

CentOS — это бесплатная версия RHEL, которая является бинарно-совместимой с RHEL (т.е. имеет точно такое же программное обеспечение). Многие компании, которым не нужна коммерческая поддержка, используют CentOS.

Fedora

Когда в 2003 году Red Hat перешла на коммерческую модель распространения своих продуктов, она также выпустила дистрибутив под названием Fedora. Fedora — это ультрасовременный, полностью бесплатный, настольный дистрибутив Linux от Red Hat. По умолчанию в нем используется рабочий стол GNOME, однако, как и в случае с Ubuntu, существует большое множество различных сборок на основе Fedora. Поскольку дистрибутив Fedora всегда стремится быть на переднем крае технологий, то его стабильность может быть ниже, по сравнению с другими дистрибутивами (Debian или Ubuntu LTS).

Примечание: Fedora имеет репутацию компании, которая фокусируется на инновациях, интегрирует новые технологии на ранних стадиях и тесно сотрудничает с другими сообществами Linux.

openSUSE

SUSE когда-то был независимым немецким дистрибьютором Linux, который позже был куплен компанией Novell, а затем приобретен компанией Micro Focus. С тех пор они были приобретены и проданы несколько раз.

Как и Red Hat, SUSE также добавил коммерческую модель дистрибуции к своему дистрибутиву.

Полностью бесплатная версия Linux от SUSE называется openSUSE. Также есть версия openSUSE Tumbleweed — система, в которой постоянно появляются новые обновления программного обеспечения (т.н. rolling-release). В дистрибутиве вы можете найти различные инструменты разработчика ПО, утилита openQA создана для автоматизированного тестирования программного обеспечения, в то время как Kiwi создает образы Linux для развертывания на реальном оборудовании. По умолчанию в OpenSUSE используется рабочий стол KDE.

elementary OS

elementary OS — это настольный дистрибутив на базе Ubuntu. Он является невероятно интуитивно понятным для нового пользователя, пришедшего из другой системы (особенно из macOS). Некоторые из его наиболее интересных функций включают в себя кастомную среду рабочего стола под названием Pantheon, которая берет пример с внешнего вида macOS.

Gentoo Linux

Gentoo — это свободная операционная система на базе Linux, разрабатываемая с 1992 года. Благодаря тому, что пакеты с программным обеспечением собираются из исходных кодов непосредственно на компьютере пользователя, система может быть автоматически оптимизирована и настроена практически под любое аппаратное обеспечение или задачу.

Сердцем Gentoo является portage — мощная и гибкая система настройки и распространения программного обеспечения (менеджер пакетов), которая выполняет многие ключевые функции. Например, устанавливая новое программное обеспечение, portage автоматически создаст пользовательскую версию пакета, оптимизированного конкретно под целевое оборудование, гарантируя, что в пакете не будет ненужного, обременяющего ваш компьютер функционала. Благодаря portage, Gentoo может стать идеальным защищенным сервером, рабочей станцией разработчика, встроенным решением или чем-то еще, что вы пожелаете. Из-за его почти неограниченной адаптивности, Gentoo часто называют метадистрибутивом.

Также стоит отметить дистрибутивы Sabayon Linux и Calculate Linux, созданные на основе Gentoo:

Calculate Linux поддерживает оптимальный баланс между новейшими версиями программного обеспечения и безупречной работой системы, обеспечивая пользователя последними версиями приложений и стабильными версиями библиотек. Как правило, применение Calculate Linux подразумевает использование его вместе с Calculate Directory Server — службой каталогов, обеспечивающую централизованную и управляемую установку программного обеспечения, хранения почты, файлов, перемещение профилей пользователей и т.п. Поскольку Calculate Linux является rolling-release дистрибутивом (т.е. дистрибутивом с непрерывным циклом обновления), вы устанавливаете систему один раз и далее только лишь обновляете её в течение всего срока службы вашего оборудования.

MX Linux

MX Linux (сокр. от «MEPIS и antiX») — это легковесный дистрибутив Linux, основанный на стабильной версии Debian, являющийся совместной разработкой сообщества Linux-дистрибутивов antiX и MEPIS. Позиционируется как не очень требовательный к ресурсам компьютера дистрибутив, сочетающий довольно неплохое окружение рабочего стола вместе с высоким показателем стабильности системы, достаточной производительностью и простой настройкой. В качестве окружений рабочего стола используются Xfce, KDE и Fluxbox.

Kali Linux

Kali Linux (ранее известный как BackTrack Linux) — это дистрибутив Linux на базе Debian, содержащий несколько сотен программ и утилит, нацеленных на решение различных задач, затрагивающих такие аспекты информационной безопасности, как:

тестирование на возможность проникновения в компьютеры и компьютерные сети;

исследования уязвимости веб-приложений;

реверс-инжиниринг программного обеспечения и многое другое.

В качестве устанавливаемого окружения рабочего стола на выбор предлагаются Xfce, GNOME, KDE Plasma, LXDE, MATE. Также Kali Linux имеет поддержку широкого спектра устройств с процессорами, построенными на базе архитектуры ARM. Дистрибутив разрабатывается, финансируется и поддерживается компанией Offensive Security, ведущей компанией по обучению информационной безопасности.

Arch Linux/Manjaro/Slackware

Arch Linux не является производным от дистрибутивов Debian или Red Hat Linux. Он стоит особняком и почитается гиками за то, что является невероятно быстрым дистрибутивом, потому что создан на простой (но прочной) базе. Всё остальное может быть добавлено через его систему управления пакетами — pacman.

Manjaro — это самостоятельный дистрибутив, основанный на Arch Linux. Позиционирует себя как user-friendly настольный дистрибутив. И Arch Linux, и Manjaro относятся к rolling-release дистрибутивам.

Slackware, пожалуй, был первым настоящим дистрибутивом Linux, начиная с 1993 года! Подобно Arch Linux и Manjaro, он использует .tar.gz-пакеты, а не более популярные системы apt или yum. Если вы считаете себя продвинутым пользователем, но не хотите возиться с компиляцией пакетов, то, возможно, Arch Linux или Manjaro будут лучшим выбором для вас, так как они предлагают тот же уровень кастомизации, что и Slackware.

Если же вы только начинаете знакомиться с Linux, то Arch Linux, Manjaro и Slackware, вероятно, будут не самым лучшим выбором.

Zorin OS/Solus/Deepin

Если вам нравятся дистрибутивы, которые имеют схожий внешний вид с внешним видом Windows или macOS, или, возможно, просто что-то с действительно красивым интерфейсом, то обязательно ознакомьтесь с Zorin OS, Solus и Deepin. Например, Solus имеет свой собственный оконный менеджер под названием Budgie, и он был создан полностью с нуля, а не является производным дистрибутивом от Ubuntu или Fedora.

Так какой же дистрибутив мне выбрать?

В следующей таблице кратко представлены критерии для выбора дистрибутива Linux:

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

Каталог debian не входит в вышестоящий архив, он остается в .diff.gz или в .debian.tar.gz файлах исходного пакета, хотя этот debian каталог находится внутри дерева исходного кода, когда извлекается исходный пакет. Кстати, когда политика не требует переупаковки, MD5 тарбола должен совпадать с тарболлом вышестоящего. Также, чтобы уточнить, патчи, сделанные мэйнтейнером для исходного кода, хранятся в каталоге debian (исходный формат 3.0) и в .diff.gz (формат 1.0). Уман, спасибо за твоё исправление. Я уберу часть, касающуюся изменения тарбола в апстриме, чтобы никто не ошибся. Теперь выглядит хорошо, за исключением того, что у вас все еще есть «Для RPM важно использовать тот же тарбол, что и вышедший проект, до отметки времени». Из-за моего полного отсутствия опыта работы с RPM я не знаю, насколько велика разница в политике, но, как я уже сказал, разработчик Debian будет настаивать на том, чтобы она была точной с отметкой времени, если только вышестоящий архив не нарушает политику Debian и ему не нужно быть переупакованным. @wzzrd, на самом деле легко собрать ваши исходные файлы в каталог для каждого пакета, определив% _specdir и% _sourcedir в вашем файле

Многие люди сравнивают установки программного обеспечения с 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 для огромного совместимого индекса пакета.

По моему мнению, я презирал RPM по той причине, которую вы упомянули: «RPM также страдает от таких сайтов, как rpmfind, где вы найдете 10+ несовместимых пакетов для разных дистрибутивов». Также я нахожу чрезмерно трудным найти RPM для программного обеспечения, в котором я нуждаюсь. Для DEB: «Apt полностью скрыл эту проблему для пакетов DEB, потому что все пакеты были установлены из одного источника». которые действительно легко найти и использовать. Кроме того, кажется, что DEB всегда лучше находит и устанавливает зависимости, в то время как RPM всегда позволяет мне зависнуть . мое мнение после 15 лет использования обоих! Я считаю, что этот ответ направлен на вопрос с точки зрения потребителя, в отличие от @ wzzrd, который полностью ориентирован на разработчиков / упаковщиков. Также очень четко про уровень разделения. Ваш текст был скопирован в WikiVS , похоже, правильно приписан. С точки зрения пользователя, это лучший ответ. И я хотел бы добавить, что использовать PPA намного проще, чем добавлять новое репозиторий yum.

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

Похоже, что в наши дни он сохраняет новый файл конфигурации *.rpmnew вместо того, чтобы забивать ваш измененный - по крайней мере, на openSUSE. И то, и другое готово, поэтому вы получаете файлы rpmsave и rpmnew. Вы ошибаетесь в том, что RPM не используют стандартные форматы. RPMS использует CPIO для раздела данных - это стандартный формат архива. Другие разделы в основном заголовки. Вы можете использовать инструмент rpm2cpio для извлечения только раздела данных RPM и извлечения файлов, содержащихся в rpm. Например: rpm2cpio foobar.rpm | cpio -idmv Единственное критическое изменение в deb формате, которое я помню, было, когда data.tar.gz стало data.tar.xz , когда старые dpkg перестали иметь возможность открывать новые пакеты.

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

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

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

Разве «растущая популярность» не является в основном «Ubuntu основана на Debian, и так, понимаешь, ты идешь?» «dpkg vs yum» - неправильное сравнение, так как первый - менеджер пакетов, а второй - нет (точно так же, как apt / 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, и они работали просто отлично, несмотря на то, что эта совместимость официально не гарантирована.

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

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

Можете считать что этот топик — срач и холивар. Но мне это очень нужно.

Проблема вот в чем: я сейчас изобретаю велосипед, точнее — еще один дистрибутив Linux [По книге LFS], и уже почти закончил. Сразу хочу предупредить, что я не тролль и не Денис. Этот дистрибутив нужен лично мне и моим знакомым из фирмы, в которой я работаю (собсно для нее и собираю). Не пытайтесь меня отговорить, т.к. тот факт, что я прошел LFS на 100% и BLFS на 50%, уже меня не остановит.

Теперь проблема в том, какой менеджер пакетов выбрать. Так как мой дистрибутив (В котором действительно нет никакого кода из Ubuntu) будет предназначаться для простых смертных [пользователей], то я не стал трогать менеджеры пакетов Portage, Pacman и из Slackware (не помню названия ПМ), т.к. на основе моего эксперимента, проведенного 1.5 месяца назад, можно считать, что для пользователя из Windows 7 это будет слишком сложно (а такие пользователи — основная масса моей фирмы). По всему этому я решил остановиться на Rpm- или Deb-ветках. А вот что из этого — пока не могу определиться. Я пользовался Aptitude, Apt-get, Urpmi и той свалкой менеджеров пакетов в ALT Linux. Все они оказались [для меня] удобными. И потому — выбор для меня сложен. А ковыряться над своим — нет ни времени, ни денег, ни желания.

В общем — цель этого топика такая: Прошу Вас всех описать достоинства и недостатки пакетных менеджеров из этих веток дистрибутивов Linux, с указанием названия пакетеного менеджера и формата пакетов, используемых им (*.deb или *.rpmx; на место х — версию rpm).

P.S. Прошу не обижаться пользователям Gentoo и Arch Linux, ибо я разделяю Ваш выбор, мне нравятся эти системы, но это действительно не подходит пользователям Windows.

P.P.S. Можете поливать дерьмом друг друга и меня сколько угодно, ибо я даже на основе этого могу определить, что мне выбрать! Но лучше такого не делать, потому что я сегодня добрый и не хочется портить настроение :-)

Ввиду текущих комментариев вопрос просто такой: в какую сторону смотреть? Deb или Rpm?

На заре разработки Linux установить приложение можно было только путем скачивания и компиляции исходников программы. Из-за использования сразу нескольких утилит и ошибок, возникавших в процессе сборки, установка одной программы отнимала много времени.

Чтобы сделать систему дружелюбней к пользователю, были разработаны пакетные менеджеры, которые полностью автоматизировали установку программ. Инсталляция приложений в них производится из пакетов – архивов с файлами скомпилированной программы. Исключение — система Gentoo, где менеджер компилирует программы по подготовленным скриптам.

Большинство популярных дистрибутивов на базе Unix/Linux уже оснащены пакетными менеджерами, способными устанавливать любое программное обеспечение. Будь то внешнее приложение или компоненты ОС. В этом заключается основное различие между пакетным менеджером и инсталлятором. Последний нужен для установки только одной специфической программы, тогда как система управления пакетами — универсальный установщик ПО.

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

О типах пакетных менеджеров и наиболее популярных вариантах реализации данного ПО расскажем в этой статье.

Теоретические основы

Категории пакетных менеджеров

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

Распространенные форматы пакетов

Разрешение зависимостей

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

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

При использовании высокоуровнего пакетного менеджера для установки программы, зависимые пакеты будут установлены в автоматическом режиме, без вмешательства пользователя.

Заключение

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

DPKG и RPM больше подойдут пользователям, ожидающим от системы лёгкой настройки и стабильной работы.
Pacman оперативно обеспечивает систему новейшим ПО, благодаря системе rolling-release.
Portage совмещает преимущества предыдущих пакетных менеджеров, но требует от пользователя внимательности и желания глубоко осваивать систему.

Чтобы даже самый требовательный дистрибутив Linux работал как швейцарские часы — выбирайте VDS от Eternalhost с оперативной техподдержкой 24/7 и бесплатной защитой от DDoS.

Читайте также:

Linux deb или rpm в чем разница

Особенности дистрибутивов

Архитектура

Система инициализации

Менеджер пакетов

Окружение рабочего стола

То, что остается неизменным

Платить или не платить?

Обзор дистрибутивов Linux

Debian

Ubuntu

Linux Mint

Red Hat Enterprise Linux (RHEL)

CentOS

Fedora

openSUSE

elementary OS

Gentoo Linux

MX Linux

Kali Linux

Arch Linux/Manjaro/Slackware

Zorin OS/Solus/Deepin

Так какой же дистрибутив мне выбрать?

Основы

RPM (Red Hat Package Manager)

Deb (Debian Package Manager)

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

Теоретические основы

Категории пакетных менеджеров

Распространенные форматы пакетов

Разрешение зависимостей

Популярные пакетные менеджеры

Особенности

Оболочки APT

APTITUDE

Synaptic

Особенности

Yum Extender

Pacman

Особенности

Оболочки Pacman

MakePKG

Pamac

Portage

Особенности

Интерфейсы Portage

Emerge

Kuroo

Заключение