Установка rpm пакетов в linux

Debian

Управление службой: /etc/init.d/openmcu-ru (start|stop)

Конфигурация запуска службы: /etc/default/openmcu-ru

Конфигурация службы: /etc/openmcu-ru/*

Служба выполняется от имени непривилегированного пользователя ‘mcu’.

Пакеты собраны скриптом автоматической сборки.

Debian 6 ‘Squeeze’

Установка осуществляется из репозитория на сайте openmcu.ru. Подключение репозитория и установка производится следующими командами:

wget http://openmcu.ru/public/OpenMCU-ru/Debian/openmcu-ru.asc -O - | apt-key add -
echo "deb http://openmcu.ru/public/OpenMCU-ru/Debian/ squeeze main" > /etc/apt/sources.list.d/openmcu-ru.list
apt-get update
apt-get install openmcu-ru

Debian 7 ‘Wheezy’

Установка осуществляется из репозитория на сайте openmcu.ru. Подключение репозитория и установка производится следующими командами:

wget http://openmcu.ru/public/OpenMCU-ru/Debian/openmcu-ru.asc -O - | apt-key add -
echo "deb http://openmcu.ru/public/OpenMCU-ru/Debian/ wheezy main" > /etc/apt/sources.list.d/openmcu-ru.list
apt-get update
apt-get install openmcu-ru

Для чего нужен файловый формат .RPM?

Расширение .rpm наиболее часто встречается в мире GNU/Linux, и его главная ассоциация принадлежит типу и формату файлов «Пакет ПО RPM» (RPM). RPM — это рекурсивная аббревиатура «RPM Package Manager» (Менеджер пакетов RPM), которая также расшифровывается как «Red Hat Package Manager» (Менеджер пакетов Red Hat). В ОС GNU/Linux корректным способом установки ПО является использование централизованного менеджера пакетов. RPM является одним из самых широко распространенных стандартных способов управления ПО, который принят в ряде дистрибутивов GNU/Linux (Fedora, SuSe, ALT Linux и др.).

Файл .rpm представляет собой пакет ПО, предназначенный для дистрибутивов GNU/Linux, которые используют систему RPM; в пакете содержатся фактические файлы ПО и инструкции по установке (инсталляционные скрипты). Пакет — это сжатый двоичный архив, применительно к которому могут использоваться различные архивные форматы (cpio, star) и методы сжатия (gzip, LZMA, bzip2). Для проверки целостности RPM-пакетов используют цифровые подписи GPG и контрольные суммы.

RPM-пакеты обрабатываются менеджером пакетов RPM (rpm), а также многими его ответвлениями и пользовательскими интерфейсами (front-end). Пакеты .rpm можно с некоторыми ограничениями конвертировать в другие форматы пакетов (.deb). Вне среды GNU/Linux файлы .rpm можно открыть с извлечением их содержимого при помощи нескольких архиваторов.

В совершенно ином значении расширение .rpm имеет также ассоциацию с форматом/типом файлов «Файл RealAudio» (RPM). RealAudio — разработанный RealNetworks проприетарный аудиоформат, в прошлом бывший довольно популярным для организации потоковой трансляции аудио. В настоящее время его популярность сильно упала по причине появления более совершенных потоковых форматов.

Файл .rpm RealAudio представляет собой текстовый файл-указатель, используемый главным образом для внедрения содержимого в формате RealAudio (а также в более широком смысле – и RealMedia) в веб-страницы на основе HTML. Файл .rpm содержит полный URL-адрес фактического медиафайла, который может воспроизводиться непосредственно на веб-странице при помощи плагина RealAudio (RealMedia).

Fedora

У Fedora есть ряд технических улучшений, обновлений ПО и скрытых возможностей. Разработчики Fedora тесно работали с исходными кодами для интеграции во всём — от ядра до GNOME, Systemd, Network Manager и GCC6. Однако на этом всё и заканчивается.

Когда речь идёт о полноценном настольном дистрибутиве, Fedora отстаёт, в основном из-за ограниченных репозиториев.

Установщик Anaconda

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

Ещё одна особенность установщика Anaconda — меню выбора программного обеспечения. Широкий спектр типов установки и множество коллекций пакетов, которые могут сделать настройку новой системы гладкой и безболезненной. А выбор определённых групп пакетов в процессе установки позволяет сэкономить время.

Характеристики

В рабочей станции Fedora среда GNOME занимает центральное место. Вся анимация GNOME плавная и выглядит естественно. GNOME 3.3x также имеет несколько приятных улучшений:

• ярлыки;
• элементы управления мультимедиа в верхней панели оболочки;
• улучшенный поиск через Nautilus;
• возможность запуска обновлений системы из центра программного обеспечения.

Что касается центра программного обеспечения, GNOME всё ещё нужно улучшать — загрузка пока слишком долгая.

Создан для программирования

Некоторые ключевые языки программирования также обновляются в Fedora. Fedora предлагает Go, Ruby и Python по умолчанию. Благодаря востребованным инструментам Fedora становится неплохим вариантом для всех разработчиков, ориентирующихся на Linux или Интернет.

Пакеты … или их отсутствие

Пока Fedora выглядит как фундамент для замечательного дистрибутива Linux. У него есть одна большая проблема — небольшие хранилища. Fedora поставляет только бесплатное ПО. Это само по себе ограничивает возможности, но дистрибутивы вроде Debian прекрасно справляются с этим.

Единственное, чем изобилует Fedora — это инструменты разработки. Помимо ранее упомянутых библиотек и языков, там присутствуют такие IDE, как Code Blocks, Eclipse и GNOME Builder.

Кому подойдёт Fedora?

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

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

Состав дистрибутива PostgreSQL

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

В состав PostgreSQL входят ряд приложений, утилит и каталогов с данными. Его главное приложение ( или s) содержит серверный код, отвечающий за обслуживание запросов на доступ к данным от клиентов. Утилиты, такие как , применяются для уп­равления главным серверным процессом, который должен выполнять­ся постоянно, обеспечивая работу сервера. В каталоге data находятся все файлы, необходимые базе данных. В них хранятся не только таб­лицы и записи, но и системные параметры.

По умолчанию устанавливаются все компоненты PostgreSQL, пере­численные в табл. 2, каждый в соответствующем подкаталоге. В ка­честве общего каталога (и каталога по умолчанию при установке из ис­ходного кода) обычно используется .

Главный каталог PostgreSQL включает в себя следующие подката­логи:

Таблица 2. Компоненты PostgreSQL

Каталог	Описание
	Приложения и утилиты, например и
	Файлы базы данных
	Документация в формате HTML
	Заголовочные файлы для разработки приложений PostgreSQL
	Библиотеки для разработки приложений PostgreSQL
	Руководство по PostgreSQL
	Примеры файлов конфигурации

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

Файлы, используемые PostgreSQL, можно разделить на несколько ка­тегорий. Файлы программ не могут и не должны изменяться во время работы. Файлы журналов, создаваемые сервером, содержат информа­цию о доступе к базе данных и могут быть очень полезны в решении проблем. Они растут по мере того, как в них добавляются новые запи­си. Файлы данных — это сердце системы, в них хранится вся информа­ция всех баз данных.

Из соображений эффективности и удобства администрирования фай­лы разных типов можно поместить в разные каталоги. Гибкость PostgreSQL позволяет хранить файлы программ, системных журналов и данных в различных местах, а дистрибутивы Linux позволяют извлечь из этой гибкости максимум выгоды.

Например, в SuSE 7.0 программы PostgreSQL размещаются вместе с остальными приложениями в , для журнальных файлов от­водится , а данные хранятся в . Благодаря этому можно легко разделить процедуры резервного копи­рования наиболее важных файлов данных и менее критичных жур­нальных файлов и т. п.

В других дистрибутивах могут применяться собственные схемы разме­щения файлов. Для просмотра списка файлов, установленных опреде­ленным пакетом, можно использовать утилиту RPM, запустив ее с та­кими параметрами:

Чтобы просмотреть все установленные файлы, придется запустить rpm для каждого из пакетов, входящих в PostgreSQL:

В разных дистрибутивах названия пакетов могут слегка отличаться, в данном случае серверному пакету дано имя . Вместо rpm мож­но использовать графический менеджер пакетов, например (рис. 2), поставляемый в комплекте с оболочкой KDE:

Рис. 2. Графический менеджер пакетов kpackage

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

Иногда бывает удобнее установить PostgreSQL из исходного кода.

Вас заинтересует / Intresting for you:

Устанавливать или обновлять Po… 788 просмотров Максим Николенко Sun, 12 Aug 2018, 11:07:20

Установка PostgreSQL 10.5 из и… 1112 просмотров Tarcoola Ningae Sun, 19 Aug 2018, 11:45:55

Основные типы данных PostgreSQ… 2190 просмотров Андрей Волков Mon, 30 Jul 2018, 11:44:18

Author: Tarcoola Ningae

Другие статьи автора:

6.12 Что теперь?

Пожалуйста смотрите выше разделы «Тестирование пакета» и «Что
делать с вашим новым пакетом RPM». Мы хотим сделать доступными все
пакеты RPM которые мы можем получить и хотим чтобы это были хорошо
сделанные пакеты. Пожалуйста найдите время для хорошего
тестирования пакетов и найдите время для их загрузки для общей
выгоды. Также пожалуйста будьте уверены, что вы загружаете
только свободно распространяемое программное обеспечение.
Коммерческое программное обеспечение и shareware не должны
быть загружены до тех пор пока не будут иметь авторские права,
которые определенно констатируют что это разрешено. Это включает
программное обеспечение Netscape, ssh, pgp, и т.п.

NextPrevious

Что такое пакеты

Как уже отмечалось, весь Linux состоит из пакетов. В RedHat работу
с пакетами выполняет программа rpm (RedHat Package Manager),
а сами файлы, содержащие пакеты, имеют расширение .rpm.
Кроме RedHat существует еще несколько дистрибутивов Linux, использующих
rpm; самые известные — Caldera, SuSE и KSI. Их так и
называют — rpm-системы.

Сразу после установки системы зачастую возникает необходимость
доставить некоторые пакеты, забытые при инсталляции, или убрать лишние.

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

Некоторые расширения .rpm-файлов

Расширение	Назначение
.i386.rpm	Пакет для Linux/Intel
.src.rpm	Исходный код пакета (никогда не устанавливайте .src.rpm — потом не удалите!)
.alpha.rpm	Пакет для Linux/Alpha
.sparc.rpm	Пакет для Linux/Sparc (Sun)
.ppc.rpm	Пакет для Linux/PowerPC
.noarch.rpm	Пакет для всех архитектур (обычно содержит данные — файлы конфигурации, шрифты и т.д.)

Кроме того, само имя пакета состоит из собственно названия и версии.
Например, lynx-2.8.2-3.i386.rpm — программа lynx,
версия 2.8.2, build 3. К сожалению, формальных правил, позволяющих
понять, где кончается имя и начинается версия, нет.

Файлы пакетов обычно расположены в одном из трех мест — в
дистрибутиве, в разделе дополнений (updates) или в резделе
«пожертвований» (contrib). В ИЯФ для RedHat 5.2/Intel это соответственно

Пакеты с исходными кодами всегда лежат в директориях
SRPMS/, и содержат исходный код для всех архитектур.

CentOS

CentOS является одним из самых молодых дистрибутивов и возник как платформа для разработки CAOS Linux. Название CentOS — это аббревиатура Community Enterprise Operating System. CentOS находится под крылом Red Hat.

RHEL проходит проверку оборудования производителями, чтобы гарантировать оптимальную работу операционной системы на оборудовании. CentOS создан из общедоступного исходного кода RHEL. Проверка оборудования также является косвенной функцией CentOS. Хотя есть некоторые бинарные файлы Red Hat (драйверы и утилиты), которые не доступны в CentOS.

CentOS поддерживается в течение 10 лет. Основные функции и версии пакетов представлены только в новых выпусках Milestone (CentOS 6, 7 и т. д.). CentOS выпускает точечные версии примерно раз в год. Основа CentOS — стабильность и безопасность, вы не найдёте там новейших компонентов Linux.

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

CentOS — это основанный на RPM дистрибутив, который использует yum в качестве менеджера пакетов systemd и по умолчанию применяет SELinux. Дистрибутив доступен в различных вариантах и ​​конфигурациях — от минимального .iso до образа Everything, включая специально созданные live iso Gnome и KDE.

Архитектура — x86–64, но ARM — одна из нескольких доступных альтернатив. Существуют образы контейнеров для Docker, Vagrant и других, а также CentOS Atomic, разработанный специально как хост-система для контейнеров Docker.

Кому подойдёт CentOS?

CentOS очень близок к RHEL. Если вам нужна совместимость с RHEL, то CentOS вам подойдёт. Эта операционная система предназначена для любого программного стека, где надёжность имеет первостепенное значение. Пакеты, которые не являются общедоступными в RHEL, нельзя установить в CentOS. По умолчанию дистрибутив полностью бесплатный и с открытым исходным кодом, но существуют сторонние репозитории для дополнительного ПО вроде медиа-кодеков.

И RHEL, и CentOS используются для крупномасштабных серверов и рабочих станций уровня предприятия. Новые функции добавляются редко: только обновления безопасности и исправления ошибок. То, что вы получите, — это до десяти лет работы в стабильной, надёжной операционной системе.

Рабочее окружение выбирается в зависимости от производительности компьютера. К примеру, так выглядит рабочий стол CentOS с GNOME:

6.9 Построение пакета

Дерево директорий исходных текстов

Первая вещь которая вам необходима — это правильно настроенное
дерево построения. Это настраивается используя файл
. Большинство людей просто используют директорию
.

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

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

Тестовое построение пакета

Первая вещь которую вы вероятно захотите сделать — это
построить исходные тексты без использования RPM. Чтобы сделать это
распакуйте исходные тексты и измените имя директории на
$NAME.orig. Затем еще раз распакуйте исходные тексты.
Используйте эти исходные тексты для построения. Перейдите в
директорию исходных текстов и следуйте инструкциям по их
построению. Если вы что-то редактировали вам необходимо сделать
заплатку. После того как вы построили исходные тексты, очистите
директорию исходных текстов. Убедитесь что вы удалили все файлы
созданные скриптом . Затем перейдите из директории
исходных текстов в директорию являющуюся для них родительской.
Затем сделайте что-то подобное:

Это создаст для вас заплатку, которую вы сможете использовать в
вашем spec-файле. Заметим что «linux», который вы видите в имени
заплатки это просто идентификатор. Вы можете захотеть использовать
что-нибудь более описательное как «config» или «bugs» для
описания почему вы сделали эту заплатку. Также хорошая идея
посмотреть в файл заплатки, который вы создали, до его
использования чтобы убедиться что бинарные файлы случайно не включены.

Создание списка файлов

Сейчас у вас есть исходные тексты, которые будут строиться и вы
знаете как построить и установить их. Посмотрите в вывод
установочной последовательности и постройте на его основе список
ваших файлов для использования в spec-файле. Мы обычно создаем
spec-файл параллельно со всеми описанными шагами. Вы можете сначала
создать его и заполнить самые легкие его части, а затем затем
заполнять его по мере прохождения всех этапов.

Построение пакета с помощью RPM

Когда вы имеете spec-файл, вы готовы попытаться и построить ваш
пакет. Наиболее полезный способ сделать это — использовать команду
похожую на следующую:

Также существуют другие опции полезные с переключателем :

• обозначает просто запуск раздела spec-файла.
• это проверка списка, который делает некоторые проверки
  раздела .
• выполняет раздел prep и компиляцию. Это полезно в
  случае, когда вы не уверены будут ли ваши исходные тексты
  построены. Это выглядит бесполезно, потому-что вы можете захотеть
  просто самому поиграть с исходными текстами до их построения и
  затем начать использовать RPM, но когда вы привыкнете использовать
  RPM вы найдете случаи когда этот ключ используется.
• выполняет prep, компиляцию и установку.
• выполняет prep, компиляцию, установку, и построения
  двоичного пакета.
• строит все (и двоичный пакет и пакет с исходными текстами).

Существует несколько модификаторов к переключателю . Это:

• будет пропускать действия до указанной
  стадии (может использоваться с ключами c и i).
• удаляет дерево построения когда все сделано.
• будет сохранять все временные файлы и
  скрипты которые созданы в /tmp. Вы можете в действительности
  посмотреть какие файлы созданы в директории /tmp используя опцию
  .
• не выполняет никакую реальную стадию, но делает keep-temp.

7.2 Установка программ из сорца (.src.rpm)

Программисты создают проект программы (например с помощью Kdevelop), в
котором есть все makefile и файлы конфигурации (configure), а потом упаковывают
их в тарболы.
В случае доработки пакета создаются Patch-и к исходным текстам,
которые заменяют одни строки текста программ на другие.
Тарболы и прикладываемые к ним patch-и упаковываются в пакеты-сорцы
(.SRC.RPM)(бывают и другие системы пакетов — но я говорю о дистрибутивах на
основе RPM — Red Hat, Mandrake, SuSe).
RPM-пакет — это особо организованный архив, в который помимо данных
(тарбола и патчей — для сырца, необходимых программ — для бинарного
RPM) упакованы скрипты установки и обновления.
C помощью сорца можно создать бинарный RPM — т.е. такой RPM, в
котором упакованы исполняемые пакеты.
Причем, если RPM создан на текущей машине, он теоретически будет
наилучшим образом подходить к текущей конфигурации пакетов
(именно поэтому многие администраторы наиболее важные пакеты
собирают из сырцов заново на своей машине).
В результате установки сорца- в директорию /usr/src/RPM/source
помещаются все необходимые тарболы (обычно один) и патчи (может быть
много, а может быть и не одного — все зависит от разработчика и
составителя конкретного RPM).
— В директорию /usr/src/RPM/spec помещается установочный скрипт (файл с
расширением spec) в котором разработчик RPM помещает все действия по
установке пакета — разархивирование тарбола, накладывания патчей,
транслирование и т.д. Разработано уже много макросов для spec-файлов.
С наиболее старыми из них и общей теорией их построения а также
опциями команды rpm можно познакомится в
RPM-HOWTO .
При построении пакета все операции с исходным текстом программ
обычно (но не всегда) помещаются в /usr/src/RPM/builder, а новые
полученные пакеты (новый сырец и новый бинарник) помещаются
соответственно в /usr/src/RPM/RPMS и /usr/src/RPM/SRPMS.
Получить из установленного сорца соответствующий пакет
можно с помощью команды

rpm -ba packet.....spec

(см. RPM-HOWTO )

Подготовка spec-файла[править]

Следующий необходимый элемент — это spec-файл, своего рода инструкция, по которой rpm-build производит сборку пакета.

Структура spec-файла подразделяется на заголовки и секции тела.

Name — базовое имя собираемого пакета, которое должно совпадать с именем spec-файла.Version — номер версии пакета.Release — релиз-номер пакета. Обычно устанавливают начальное значение в 1% {? Dist} и увеличивают его с каждым новым выпуском пакета.Summary — краткое однострочное описание пакета.License — лицензия, согласно которой распространяется пакет.URL — полный URL для получения дополнительной информации о программе. Чаще всего это веб-сайт исходного проекта.Source0 — путь или URL-адрес заархивированных файлов исходного кода (тарболов). При необходимости можно добавить дополнительные источники SourceX, увеличивая число каждый раз, например: Source1, Source2, Source3 и т.д.Patch0 — патчи и исправления для исходного кода. Патчей может быть несколько, как и исходников. Patch1, Patch2, Patch3 и т.д.BuildArch — архитектура, под которую будет собран пакет. Если пакет не зависит от архитектуры, например, он написан полностью на интерпретируемом языке программирования, необходимо установить значение BuildArch: noarch. Если значение не установлено, то пакет наследует архитектуру системы, в которой он собирается.BuildRequires — раздел, в котором через пробелы или запятые перечисляются все зависимые пакеты, необходимые для сборки нашего пакета.

%description — полное описание собираемого пакета. Может занимать несколько строк и может быть разбито на абзацы.%prep — команда или серия команд для подготовки исходного кода к сборке, например, распаковка архива в Source0. Здесь могут находиться bash-скрипты.%build — команды или серия команд из данной секции отвечают за непосредственную сборку пакета.%install — команда или серия команд из данной секции отвечают за то, чтобы сделать собранный пакет полностью готовым к установке на пользовательскую систему.%files — список файлов, необходимых для сборки пакета.%changelog — журнал изменений, произошедших с пакетом от релиза к релизу.

После того, как spec-файл будет готов, его необходимо переместить в каталог SPECS, а исходные коды собираемого пакета, тарболы, в каталог SOURCES.

Пример spec-файла

Устранение неполадок при открытии файлов RPMS

Общие проблемы с открытием файлов RPMS

Source Package Manager File не установлен

Дважды щелкнув по файлу RPMS вы можете увидеть системное диалоговое окно, в котором сообщается «Не удается открыть этот тип файла». В этом случае обычно это связано с тем, что на вашем компьютере не установлено Source Package Manager File для %%os%%. Так как ваша операционная система не знает, что делать с этим файлом, вы не сможете открыть его дважды щелкнув на него.

Совет: Если вам извстна другая программа, которая может открыть файл RPMS, вы можете попробовать открыть данный файл, выбрав это приложение из списка возможных программ.

Установлена неправильная версия Source Package Manager File

В некоторых случаях у вас может быть более новая (или более старая) версия файла Source Package Manager File, не поддерживаемая установленной версией приложения. При отсутствии правильной версии ПО Source Package Manager File (или любой из других программ, перечисленных выше), может потребоваться загрузить другую версию ПО или одного из других прикладных программных средств, перечисленных выше. Такая проблема чаще всего возникает при работе в более старой версии прикладного программного средства с файлом, созданным в более новой версии, который старая версия не может распознать.

Совет: Иногда вы можете получить общее представление о версии файла RPMS, щелкнув правой кнопкой мыши на файл, а затем выбрав «Свойства» (Windows) или «Получить информацию» (Mac OSX).

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

Даже если на вашем компьютере уже установлено Source Package Manager File или другое программное обеспечение, связанное с RPMS, вы все равно можете столкнуться с проблемами во время открытия файлов Source Package Manager File. Если проблемы открытия файлов RPMS до сих пор не устранены, возможно, причина кроется в других проблемах, не позволяющих открыть эти файлы. Такие проблемы включают (представлены в порядке от наиболее до наименее распространенных):

Установка RPM пакетов в Linux

Давайте сначала рассмотрим синтаксис самой утилиты rpm:

$ rpm -режим опции пакет

Утилита может работать в одном из режимов:

• -q – запрос, получение информации;
• -i – установка;
• -V – проверка пакетов;
• -U – обновление;
• -e – удаление.

Рассмотрим только самые интересные опции программы, которые понадобятся нам в этой статье:

• -v – показать подробную информацию;
• -h – выводить статус-бар;
• –force – выполнять действие принудительно;
• –nodeps – не проверять зависимости;
• –replacefiles – заменять все старые файлы на новые без предупреждений;
• -i – получить информацию о пакете;
• -l – список файлов пакета;

Теперь, когда вы уже имеете представление как работать с этой утилитой, может быть рассмотрена установка rpm пакета в Linux. Самая простая команда установки будет выглядеть вот так:

sudo rpm -i имя_пакета.rpm

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

Для того чтобы посмотреть более подробную информацию в процессе установки используйте опцию -v:

sudo rpm -iv имя_пакета.rpm

Также вы можете включить отображение статус бара в процессе установки:

sudo rpm -ivh имя_пакета.rpm

Чтобы проверить установлен ли пакет, нам уже нужно использовать режим запроса:

sudo rpm -q имя_пакета

Также сразу можно удалить пакет, если он не нужен:

sudo rpm -e имя_пакета

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

Для автоматической загрузки зависимостей во время выполнения установки rpm linux нужно использовать пакетный менеджер дистрибутива. Рассмотрим несколько команд для самых популярных RPM дистрибутивов. В RedHat и других дистрибутивах, использующих Yum используйте такую команду:

sudo yum –nogpgcheck localinstall имя_пакета.rpm

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

sudo dnf install имя_пакета.rpm

Пакетный менеджер Zypper и OpenSUSE справляются не хуже:

sudo zypper install имя_пакета.rpm

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