Что такое .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 там, которые делают ту же работу , хотя и с различными основными механизмами.
Источник
RPM vs DEB
Можете считать что этот топик — срач и холивар. Но мне это очень нужно.
А теперь настройте Ваш мозг, т.к. все ниже этой фразы очень запутано (Увы, такова моя особенность — писать длиннющие сообщения)
Проблема вот в чем: я сейчас изобретаю велосипед, точнее — еще один дистрибутив 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?
Источник
Каковы плюсы / минусы 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, и они работали просто отлично, несмотря на то, что эта совместимость официально не гарантирована.
Обратите внимание, что это не предназначено для того, чтобы начать пламенную войну, я просто делюсь своим опытом использования обоих миров параллельно в течение нескольких лет (работа против дома).
Источник
