Меню Рубрики

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

ИТ База знаний

Полезно

— Узнать IP — адрес компьютера в интернете

— Онлайн генератор устойчивых паролей

— Онлайн калькулятор подсетей

— Калькулятор инсталляции IP — АТС Asterisk

— Руководство администратора FreePBX на русском языке

— Руководство администратора Cisco UCM/CME на русском языке

— Руководство администратора по Linux/Unix

Навигация

Серверные решения

Телефония

Настройка программных телефонов

Корпоративные сети

Популярное и похожее

Установка VirtualBox 6.0 на Linux

Как восстановить пароль от root в CentOS 7

8 крутых файловых менеджеров Linux: обзор и установка

Как создать пользователя Sudo на CentOS

RPM — установка и использование в Linux

Вам пакет нужен? Нет, я со своим.

RPM (Red Hat Package Manager) — это наиболее популярная утилита управления пакетами для Linux систем на базе Red Hat, таких как (RHEL, CentOS и Fedora). Она используется для установки, удаления, обновления, запроса и проверки пакетов программного обеспечения. Пакет состоит из архива файлов и информации о пакете, включая имя, версию и описание. Формат файлов также называется RPM.

Есть несколько способов откуда можно взять пакеты RPM: CD/DVD с программным обеспечением, CentOS Mirror, RedHat (нужен аккаунт) или любые открытые сайты репозитория.

В RPM используется несколько основных режимов команд: Install (используется для установки любого пакета RPM), Remove (используется для удаления, стирания или деинсталляции пакета), Upgrade (используется для обновления существующего пакета), Query (используется для запроса пакета) и Verify (используется для проверки пакетов RPM).

Рассмотрим это на примере. У нас есть пакет, и теперь посмотрим, что мы можем с ним делать.

Установка

Как узнать информацию о пакете RPM без установки?

После того, как мы скачали пакет мы хотим узнать информацию о пакете перед установкой. Мы можем использовать -qipoption (запрос информации о пакете), чтобы вывести информацию о пакете.

Мы можем использовать параметр -ivh для установки определенного пакета, как показано ниже.

Как проверить установленный пакет RPM?

Мы можем использовать параметр -q с именем пакета, и он покажет, установлен ли пакет или нет.

Как вывести список всех файлов для определенного установленного пакета RPM?

Мы можем перечислить все файлы установленных пакетов rpm, используя опцию -ql с командой rpm.

Как вывести список недавно установленных пакетов RPM?

Мы можем использовать параметр -qa с параметром —last, в котором будут перечислены все недавно установленные пакеты rpm.

Как установить RPM пакет без зависимостей?

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

Как заменить установленный пакет RPM?

Мы можем использовать параметры -ivh –replacepkgs для замены установленного пакета.

Удаление

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

Обновление

Как обновить установленный пакет RPM?

Для обновления пакета мы используем параметры -Uvh

Запрос

Как запросить все установленные пакеты?

Мы можем использовать параметры -a вместе с q для запроса всех установленных пакетов на сервере.

Как запросить конкретный пакет?

Мы можем использовать команду grep, чтобы узнать, установлен ли конкретный пакет или нет.

Как запросить файл, который принадлежит пакету RPM?

Чтобы узнать к какому пакету RPM относится файл /usr/lib64/libGeoIP.so.1.5.0. используем следующую команду.

Проверка

Как получить информацию для конкретного пакета?

Мы можем использовать параметры -i вместе с q, чтобы получить информацию для конкретного пакета, как показано ниже.

Мы можем проверить пакет, сравнив информацию об установленных файлах пакета с базой данных rpm, используя опцию -Vp.

Как проверить все пакеты RPM?

Мы можем проверить все установленные пакеты rpm, используя опцию -Va

Полезна ли Вам эта статья?

Пожалуйста, расскажите почему?

Нам жаль, что статья не была полезна для вас 🙁 Пожалуйста, если не затруднит, укажите по какой причине? Мы будем очень благодарны за подробный ответ. Спасибо, что помогаете нам стать лучше!

Подпишитесь на нашу еженедельную рассылку, и мы будем присылать самые интересные публикации 🙂 Просто оставьте свои данные в форме ниже.

источник

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

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

Раньше мы уже рассматривали установку deb пакетов в Ubuntu. А в этой статье будет подробно разобрана установка rpm пакетов в linux.

Что такое RPM?

RPM или RPM Package Manager — это пакетный менеджер, используемый в дистрибутивах Linux, основанных на Red Hat. Такое же название имеет формат файлов этого пакетного менеджера.

Этот формат не очень сильно отличается от того же самого Deb. Вы можете посмотреть их детальное сравнение в статье что лучше deb или rpm. Здесь же, только отмечу, что файл rpm — это обычный cpio архив, в котором содержатся сами файлы программы, а также метаданные, описывающие куда их нужно устанавливать. База всех установленных пакетов находится в каталоге /var/lib/rpm. Из особенностей можно отметить, что rpm не поддерживает рекомендованные пакеты, а также зависимости формата или-или.

Для управления пакетами, так же как и в Debian-системах, здесь существует консольная, низкоуровневая утилита с одноименным названием — rpm. Ее мы и будем рассматривать дальше в статье. В разных системах используются разные пакетные менеджеры, например в Red Hat используется Yum, в Fedora — DNF, а в OpenSUSE — zypper, но во всех этих системах будет работать утилита rpm.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Установка RPM файла в GUI

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

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

Выводы

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

источник

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

Видео: .rpm vs .deb в чем разница?

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

Очень часто разработчики размещают на своем официальном сайте пакеты для самых популярных дистрибутивов.

Обычно это deb и rpm. Последний встречается немного реже, но если вы используете дистрибутив на базе Red Hat, вам нужен именно этот формат пакетов.

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

Раньше мы уже рассматривали установку deb пакетов в Ubuntu. А в этой статье будет подробно разобрана установка rpm пакетов в linux.

Что такое RPM?

RPM или RPM Package Manager — это пакетный менеджер, используемый в дистрибутивах Linux, основанных на Red Hat. Такое же название имеет формат файлов этого пакетного менеджера. Этот формат не очень сильно отличается от того же самого Deb.

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

База всех установленных пакетов находится в каталоге /var/lib/rpm. Из особенностей можно отметить, что rpm не поддерживает рекомендованные пакеты, а также зависимости формата или-или. Для управления пакетами, так же как и в Debian-системах, здесь существует консольная, низкоуровневая утилита с одноименным названием — rpm.

Ее мы и будем рассматривать дальше в статье. В разных системах используются разные пакетные менеджеры, например в Red Hat используется Yum, в Fedora — DNF, а в OpenSUSE — zypper, но во всех этих системах будет работать утилита rpm.

Видео: OS.26 Установка rpm-пакетов Linux (openSUSE)

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

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

Видео: Linux — Компиляция программ из исходников в Ubuntu

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

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

Видео: Установка deb пакетов. Использование gdebi

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

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

Самая простая команда установки будет выглядеть вот так:

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

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

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

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

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

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

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

Установка RPM файла в GUI

Если вы используете OpenSUSE, то это делается очень просто. Универсальный конфигуратор системы YaST, кроме всего прочего позволяет установить rpm пакеты.

Вы можете сделать это с помощью файлового менеджера, выбрав пункт контекстного меню для файла открыть с помощью Yast или выполнив команду:

(Пока оценок нет)

источник

Fedora: управление пакетами. Rpm: формат и утилита

FOSS-системы вообще, и Fedora в частности, организованы по пакетному принципу. Точно также, в виде пакетов, распространяются и любые дополнительные программы для них, создаваемые независимыми разработчиками. И потому одна из важных задач пользователя – это интеграция пакетов в свою систему. Пакеты для Fedora распространяются в формате rpm.

Читайте также:  Установка разъединителя на кабельной вставке

Формат rpm

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

История

Формат пакетов RPM (что тогда расшифровывалось как Red Hat Package Manager) и одноимённая утилита для манипулирования такими пакетами, способная отслеживать зависимости и сообщать об их нарушении, сыграли очень большую роль в приобщении к Linux’у широких народных масс. Правда, разрешать зависимости эта утилита не умела, да и не научилась по сей день: задача эта решается более «продвинутыми» средствами пакетного менеджмента. Но по сравнению с молчаливым пакетным инструментарием из Slackware, зависимости вообще не отслеживающим, и это было большим прогрессом с точки зрения обычных пользователей.

Происхождение системы RPM (будем понимать под этим и набор утилит, и формат пакетов, с которыми они работают) теряется во мраке веков. В первых версиях Red Hat использовалась система RPP, обеспечивающая установку пакетов одной командой, запрос информации о них, а также проверку зависимостей. Однако сборка пакетов для неё требовала существенной модификации авторских исходников, что было напряжно для майнтайнеров дистрибутива.

Параллельно раннему Red Hat некоторое время развивался дистрибутив Bogus, ныне мало кому известный. В нём имелась собственная пакетная система — PMS (Package Management System), написанная Рикардом Файтом (Rikard E. Faith). Она обладала слабым механизмом запросов информации о пакетах, а проверка их зависимостей просто отсутствовала. Но зато пакеты для PMS можно было собирать непосредственно из авторских исходников, без всякой их модификации.

В ходе подготовки 2-го релиза Red Hat Рикард Файт вместе с Дугом Хоффманом (Doug Hoffman) по контракту с компанией Red Hat написали систему PM (Package Management), вобравшую в себя лучшие особенности RPP и PMS. Хотя практически она так и не была задействована, но послужила одной из основ для RPM.

Собственно система RPM была создана Марком Юингом (одним из сооснователей компании) и Эриком Троэном (Erik Troan), основывавшихся на всех достижениях предшественников — разработчиков RPP, PMS и PM. Вариант её, подготовленный для тестовых версий второго релиза, быстроты ради был написан на Perl’е, что создавало ряд проблем, например, при загрузке с дискеты (а в те времена это было достаточно обычным способом старта Linux’а). И непосредственно к выходу релиза Red Hat 2.0 система была полностью переписана на C, база данных пакетов перепроектирована для пущей надёжности и быстродействия, а для использования функциональности RPM сторонними разработчиками была создана библиотека rpmlib. Иными словами, система RPM приобрела практически тот вид, в каком мы знаем её ныне, подвергаясь с тех пор только корректировке ошибок и косметическим доделкам.

Система RPM (то есть формат и утилита), став штатными и общедоступными в релизе Red Hat 2.0, вышедшем в сентябре 1995 года, сразу завоевали популярность и вне родительской системы. Вскоре они были использованы в Caldera Linux (позднее именовавшаяся OpenLinux), которая поначалу была точным клоном Red Hat. Вслед за тем на пакетирование в формате rpm перешёл дистрибутив Suse (генетически — потомок Slackware). Разумеется, и все последующие клоны и дериваты Red Hat, например, Mandrake, также использовали RPM.

Могу свидетельствовать как очевидец, что к рубежу 1996–1997 годов (времени моих первых экспериментов с Linux) система RPM была широко распространённой, считалась стабильно работающей и использовалась далеко за пределами родного дистрибутива.

Общие сведения

За свою долгую жизнь формат rpm претерпевал различные изменения, однако в генеральной своей линии сохранял как свои характерные черты, так и обратную совместимость вплоть до настоящего времени. Текущая его версия из числа официально поддерживаемых одноимённым проектом на настоящий момент (01.02.2011) — 4.8.1. Она используется в бессчётном числе дистрибутивов, представляющих как прямые клоны Red Hat (CentOS, Scientific Linux, Oracle Enterprise Linux), так и его дериваты пусть даже удалившиеся от прародителя, вроде Mandriva или Altlinux. Кроме того, его можно видеть даже в некоторых системах, генетически с ним не связанных (например, во всех вариантах Suse).

Параллельно генеральной версии rpm развивается и её обновлённый вариант, известный как rpm5 . Он создан Джеффом Джонсоном (Jeff Johnson), бывшим до того одним из основных разработчиков “обычного” rpm . Согласно его мнению, новая версия существенно усовершенствована по сравнению со своим предком, за что, однако пришлось заплатить отсутствием совместимости между этими двумя форматами. Поэтому rpm5 официально не поддерживается ни проектом rpm , ни одним из распространённых rpm based дистрибутивов. Он используется, насколько я знаю, только в дистрибутиве PLD и, согласно анонсу, будет задействован в релизе Mandriva 2011.1

Не смотря на то, что в перечисленных rpm-based дистрибутивах (и многих других, не перечисленных) теоретически используется один и тот же формат пакетов, на самом деле детали их устройства отличаются. Особенно это касается пакетов исходников (о которых будет отдельный разговор). Однако на этих страницах я ограничусь рассмотрением rpm-пакетов для дистрибутива Fedora. Правда, сказанное о них будет иметь силу и для RHEL, CentOS, Scientific Linux, Oracle Enterprise Linux, ASPLinux.

Номенклатура пакетов

В составе дистрибутива Fedora можно обнаружить разные виды пакетов интересующего нас формата.

Во-первых, выделяются rpm-пакеты бинарные и они же, но с исходными текстами. Как явствует из названия, первые содержат прекомпилированные компоненты дистрибутивного пакета, как то:

  • исполняемые бинарные файлы;
  • возможно, библиотеки, необходимые для их функционирования;
  • конфигурационные файлы (или, по крайней мере, их примеры);
  • документацию.

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

Распознать те и другие очень легко по их именам, образованным по определённым правилам, каковые мы рассмотрим на примере самого показательного пакета — собственно пакета rpm

Имена бинарных rpm-пакетов образованы по следующей схеме:

где rpm — имя пакета, 4.8.1 — номер ветки, версии и конкретного релиза пакета, 6 — номер сборки для текущей версии данного дистрибутива, fc14 — имя и версия такового (то есть, в данном примере, — Fedora версии 14), x86_64 — архитектура, под которую пакет собирался.

Имя пакета с исходниками будет похожим:

Можно видеть, что отличие только в добавочном суффиксе src, символизирующего, что мы имеем дело именно с пакетом исходников, а не с прекомпилированным бинарником. И очевидно, что понятие архитектуры для исходных текстов смысла не имеет — они (теоретически) должны собираться для любой из них.

Среди бинарных пакетов также можно найти такие, которые не привязаны к какой-либо архитектуре — они опознаются по дополнительному суффиксу noarch . В их числе — сценарии на интерпретируемых языках типа Perl, Python etc, шрифтовые пакеты, документация и так далее. Например, так будет выглядеть пакет для одной из гарнитур шрифтового семейства Dejavu:

Выше уже говорилось, что бинарные rpm-пакеты могут содержать библиотеки функций, необходимых для их функционирования. Однако это — скорее исключение: как и во всех UNIX-подобных системах, в rpm-based дистрибутивах существует тенденция собирать библиотеки как отдельные пакеты. При этом каждая библиотека, как правило, представлена в виде двух пакетов.

Первый пакет содержит собственно код библиотечных функций, необходимых в любом случае; например, работу пакета rpm обеспечивает библиотечный пакет

Во второй же пакет включаются заголовочные файлы, необходимые только при самостоятельной сборке пакетов — в обыденной жизни без них можно обойтись:

Разобравшись с номенклатурой rpm-пакетов, можно перейти к вопросу их внутреннего устройства — то есть к собственно формату.

Устройство бинарных rpm-пакетов

Бинарный пакет rpm включает в себя два компонента. С одной стороны, это набор скомпилированных файлов, таких, как исполняемые бинарники и библиотеки, сопровождаемых необходимыми конфигами, документацией и т.д., готовый к инкорпорацию в файловую иерархию системы.

С другой стороны, пакет содержит метаинформацию — составленное по определённым правилам описание. Оно включает имя пакета, номер версии и сборки, сведения о разработчике и его мастер-сайте, список файлов, их положение в файловой иерархии, список зависимостей. При необходимости тут могут присутствовать установочные и настроечные сценарии. Всё это вместе позволяет контролировать целостность пакета, отслеживать зависимости, обеспечивать выполнение собственно процедуры инсталляции, а также удалять пакеты «вчистую».

Компоненты rpm-пакета запаковывается в архив cpio — одно из древнейших средств архивирования в UNIX, подвергнутый компрессии. Ранее, вплоть до Fedora версии 11 включительно, это делалось посредством утилиты gzip . Начиная с 12-й версии Fedora rpm-пакты сжимаются по алгоритму LZMA, обеспечивающему много большую степень компрессии — правда, ценой времени, на неё затрачиваемого. Что для пользователя, впрочем, неудобств не доставит — потому что распаковка lzma-файлов, как это ни парадоксально, осуществляется практически с той же скоростью, что и gzip . А вот скачивание их, разумеется, происходит много быстрее, что не может не радовать обладателей “толстых” и дешёвых каналов: при этих условиях установка пакетов по Сети происходит быстрее, нежели с локальных носителей.

Вернёмся, однако, к тому, что у rpm-пакета “внутре”. Для чего сначала распакуем пакет любым стандартным средством ( rpm2cpio , например, или с помощью утилиты rpm2tgz ) и посмотрим, что получилось:

То есть мы видим те компоненты пакета, которые будут инкорпорированы в файловую иерархию целевой системы.

Знакомство со вторым компонентом проще всего сделать с помощью Midnight Commander. По клавише F3 (по прежнему для примера рассматривается пакет rpm ) он выдаст всю метаинформацию в суммарном виде. Сначала это будет формальное описание пакета:

Смысл всех полей интуитивно понятен. Прошу только обратить внимание на поле Group : о групповой принадлежности пакета нам придётся вспомнить, когда дело дойдёт до управления пакетами с помощью системы yum .

Затем последует установочный сценарий:

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

Затем — библиотечные файлы:

И, наконец, файлы вариативные:

Всю эту информацию можно просмотреть и по частям — зафиксировав в Midnight Commander курсор на файле

и нажав Enter.
Теперь мы увидим список входящих в пакет “метаинформационных” файлов:

О содержимом файлов легко догадаться. Так, CONTENTS.cpio — полный список всех файлов и путей к ним:

и так далее. Файл HEADER содержит то самое описание, которое мы только что видели через F3, *INSTALL и *UPGRADE — исполняемые скрипты соответствующего назначения. А в каталоге /INFO лежит множество мелких файликов, из которых в итоге собирается суммарная метаинформация. Из них остановлюсь только на REQUIRENAME — это пресловутый перечень зависимостей, который для пакета rpm выглядит примерно так:

И так далее, единым списком, без разделения на зависимости “жесткие” и “мягкие”.

На самом деле пакет rpm никакой файловой иерархии внутри себя не содержит. А то, что нам представляется в виде таковой — всецело заслуга Midnight Commander, который восстанавливает её в том виде, в котором она была до сборки.

База данных RPM

База данных rpm-пакетов — компонент, необходимый для функционирования системы: именно она обеспечивает возможность получения информации о пакетах, их обновления и удаления. Она создаётся при инсталляции системы в каталоге /var/lib/rpm и изменяется при каждой операции с пакетами.

База данных rpm-пакетов использует Berkeley DB — древнюю (1986 года розлива), простую (нереляционную) СУБД, однако быструю, эффективную и потому широко используемую по сей день.

Файлы базы RPM — бинарные, и даже волшебство «ночного командира» не позволит разглядеть в них что-либо удобопонятное. Так что остаётся только поверить на слово авторам документации, что

  • файл Packages является главным и хранит индексированные поля заголовков пакетов,
  • файлы Basenames, Group, Requireversion и прочие служат для оптимизации запросов к базе, а
  • файлы __db.001, __db.002 и так далее — содержат в себе сведения о том, какие файлы менялись и создавались при установке и удалении пакетов.

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

Утилита rpm

Ознакомившись в общих чертах с устройством rpm-пакетов, посмотрим, что же с ними можно сделать. И начнём с одноимённой утилиты, предназначенной для работы с единичными пакетами. В давние времена она была благословением и проклятием начинающих пользователей дистрибутива Red Hat, его клонов и дериватов.

Введение

Как уже было сказано, утилита rpm стала благословением пользователей дистрибутива Red Hat и всех его наследников. Ибо она освобождала их от необходимости самостоятельной компиляции: практически все разработчики из числа не брезговавших распространением своих пакетов в бинарном виде, собирали их в rpm-формате, а службы вроде http://rpmfind.net позволяли легко отыскать их на просторах Сети. Помню, в те годы имела хождение такая жизненная максима:

с помощью rpm и Инета любые дистрибутивы можно сделать близнецами-братьями за одну ночь

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

Те времена канули в Лету: наступил век пакетных репозиториев и средств для работы с ними, таких, как apt-rpm , urpmi и, наконец, yum — главный герой следующего цикла заметок. Каковые и берут на себя заботу по рутинному манипулированию пакетами. Однако утилита rpm до сих пор остаётся самым простым средством для операций с единичными пакетами, особенно не входящими в официальные репозитории. А в некоторых случаях — например, при подключении репозиториев сторонних — она может оказаться практически незаменимой.

Читайте также:  Установка пеллетных горелок пеллетрон

Так что уделим толику времени знакомству с её базовыми, наиболее востребованными в повседневной жизни, функциями. Это просто краткий конспект для практического применения. Причём ориентированный на тех, кто ранее дела с rpm-based системами не имел. Тех, кто будет из зала кричать — давай подробности, авансом отсылаю к тёте Мане, она за всё расскажет.

Общая характеристика

Утилита rpm , подобно dpkg в Deb-based дистрибутивах, — лишь одна из представительниц целого семейства, разрабатываемого, вместе с одноимённым форматом, в рамках самостоятельного проекта .

Из числа дополнительных утилит стоит упомянуть rpm-build — средство для создания собственных пакетов, и rpm2html — утилиту для извлечения метаинформации из пакетов и представления её в человеческом виде (полный список всего семейства можно найти здесь). Однако в начале настоящего цикла страниц речь пойдёт только о собственно rpm .

Существует пять основных режимов использования утилиты rpm :

  • режим запроса (query);
  • режим проверки (verify);
  • режим установки (install);
  • режим обновления (upgrage);
  • режим удаления (erase).

Существует также режим построения пакета, но о нём мы пока говорить не будем.

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

  • -? , —help вывод подробной справки об использовании команды rpm (краткая справка выводится в ответ на команду без всяких опций и аргументов);
  • —version вывод номера версии пакета rpm ;
  • —quiet вывод минимума сообщений в ходе выполнения команды (обычно это только сообщения об ошибках);
  • -v вывод подробных сообщений о ходе выполнения команды.

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

Аргументом команды rpm обычно является имя файла пакета; часто таких аргументов может быть несколько (в пределе — сколько угодно). В одних случаях достаточно указания краткого имени пакета — например, для нашего постоянного примера просто rpm . В других же ситуациях требуется указание полного имени, с указанием номера версии, сборки, дистрибутива, архитектуры — например, rpm-4.8.1-5.fc14.x86_64.rpm . А если файл пакета находится не в текущем каталоге, то потребуется предварить его указанием полного пути к нему, скажем /var/cache/akmods/ .

Режим запроса…

… служит для получения информации о пакете, в частности, его статусе (установлен ли он в системе). Основная опция запроса — -q (или —query ), в ответ на неё последует вывод полного имени пакета:

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

Дополнительные опции зависят от цели запроса. Так, наличие пакета в системе проверяется следующей командой:

где дополнительная опция -a (или —all ) предписывает запрос ко всем наличным в базе пакетам. Если пакет установлен, ответом на эту команду будет

Если нет — последует возврат приглашения командной строки.

Формальное описание пакета можно получить командой

Легко видеть, что это та самая заголовочная часть (HEADER), которую мы ранее просматривали через Midnight Commander.

Дополнительная опция l позволит вытащить нам и содержимое CONTENTS.cpio:

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

Выше речь касалась получения информации об установленном пакете. Однако гораздо интересней получить сведения о пакете не установленном — на предмет нужности или не нужности его в нашем деле. И это возможно — путем добавления к -qi дополнительной опции p и указания полного имени пакета и пути к нему. А поскольку не установленный пакет, скорее всего, лежит на каком-либо сетевом источнике, то в качестве пути тут будет фигурировать URL, например:

Что выведет точно такую же информацию, что и при запросе к локальному пакету:

Дополнительная опция f позволяет определить имя пакета, которому принадлежит некий файл:

В режиме запроса возможны и ещё многие опции, с которыми при необходимости можно ознакомиться на man-странице пакета rpm .

Режим проверки…

… обеспечивает проверку целостности установленного пакета. Делается это путём сравнения его файлов с их аналогами из пакета оригинального по таким параметрам, как тип, размер, контрольная сумма (MD5), атрибуты принадлежности и доступа. Основная опция этого режима — -V ; без дополнительных опций, с указанием имени пакета, она проверяет правильность расположения его файлов в файловой иерархии.

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

  • 5 — контрольная сумма MD5
  • S — размер
  • L — символическая ссылка
  • T — дата изменения файла
  • D — устройство
  • U — пользователь
  • G — группа
  • M — режим (включая разрешения и тип файла)
  • ? — файл не удалось прочитать

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

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

мы на выводе увидим следующее:

Это означает всего-навсего, что исполняемый файлы пакета rpm после его установки подверглись процедуре предварительного связывния (prelink — что это такое, я расскажу со временем). В результате чего, разумеется, утратили идентичность со своими тёзками из оригинального пакета.

Дополнительные опции режима проверки позволяют выполнить верификацию конкретного файла:

сравнить установленный пакет с его исходным rpm-пакетом:

а также выполнить полную проверку всех установленных пакетов:

Поскольку вывод последней команды будет очень длинным, её целесообразно использовать в корнвейере с командой типа less или most . Можно также с помощью команды grep выявить только пакеты; содержащие расхождения с оригиналом по одному из перечисленных выше критериев. Например, командная конструкция

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

выявит различия контрольных сумм.

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

Кроме перечисленных, существуют ещё многочисленные опции верификации цифровой подписи и публичных ключей — с ними, как обычно, можно ознакомиться на странице man (8) rpm.

Режимы установки и обновления…

… тесно связаны между собой. Основными их опциями являются:

  • -i (от install — не путать с дополнительной опцией режима запроса) установка пакета, отсутствующего в системе;
  • -F обновление установленного пакета до более «свежей» версии;
  • -U обобщённая опция установки и обновления: при её использовании установленный пакет будет обновлён, а не установленный — инсталлирован.

Важно, что сферы действия опций -i и -F строго разграничены: команда с указанием первой откажется исполняться, если в системе имеется старая версия одноимённого пакета. И наоборот — команда при второй опции даст сообщение об ошибке, если предшествующая версия в системе не установлена. Поэтому обобщённая опция -U применяется чаще всего. Очевидно, что для успешного выполнения команд с любой их этих опций требуются привилегии администратора.

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

Ранее я уже говорил, что утилита rpm не просто устанавливает пакеты, но и проверяет их зависимости. Хотя, с сожалению, не разрешает их, а только рапортует о нарушениях. Например, попытка «в лоб» установить kdebase

выдаст длиннющий список неудовлетворённых зависимостей:

Это, как говорится, дело житейское, и как разруливать такую ситуацию — ясно. Ибо ставить такие большие пакеты со столь сложными зависимостями непосредственно через rpm — дело неблагодарное, на то другие инструменты придуманы. Например, yum , до которого мы со временем доберёмся.

Бывают ситуации более иные: вроде бы простой пакет при попытке установки требует как зависимость другой. А тот, в свою очередь, отказывается устанавливаться, так как ссылается на отсутствие первого. Так, давеча, затеяв апгрейд одной из экспериментальных своих систем до «сыромятной» (rawhide) версии, я столкнулся с тем, что пакет fedora-release-rawhide-15-0.3.noarch.rpm ни в какую не желал устанавливаться без fedora-release-15-0.3.noarch.rpm — и наоборот.

Вот в таких-то случаях и требуется указание всех взаимозависимых пакетов в качестве аргументов одной команды:

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

В последней команде неожиданно и без предупреждения всплыли две опции — v и h . Впрочем, первая уже раньше упоминалась — эта дополнительная всережимная опция предписывает выводить подробные сообщения о ходе выполнения любых задач. А опция -h (или —hash ), обеспечивает удобную форму представления этого вывода.

К основным опциям установки и обновления полагается ещё много дополнительных опций, но за ними, как всегда, к тёте Мане.

Режим удаления…

… часто оказывается не менее востребованным, нежели режимы установки и обновления. Впрочем, задача это не сложная, и в общем случае выполняется так:

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

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

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

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

Репозитории

Утилита rpm предназначена в первую очередь для установки индивидуальных пакетов из любых источников — локальных или сетевых (например, с сайтов разработчиков), но преимущественно первых. Система же управления пакетами yum ориентирована на доступ к репозиториям пакетов, причём главным образом сетевым. Хотя и использование её с репозиториями локальными также не возбраняется.

Что такое репозиторий

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

В переводе на русский язык слово репозиторий означает хранилище — и именно его рекомендуют употреблять языковые пуристы (они же те, кто предпочитает называть себя grammar nazi). Однако, как это обычно бывает по жизни, в народе утвердилось иное их именование — repo или, говоря по нашему, по бразильскому кириллическому, репы. Почему во множественном числе — станет понятно из дальнейшего рассказа. Ну а как синоним я предпочитаю термин хренилищще.

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

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

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

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

А теперь посмотрим, как все эти общие соображения выглядят на практике — применительно к репозиториям Fedora.

Физическая структура репозиториев

Физически репозитории Fedora — это набор вложенных подкаталогов на ftp- или http-серверах, и имеют они подчас довольно сложную и не вполне прозрачную структуру. Знание её для пользователя не обязательно — но в ряде нештатных ситуаций будет не лишним. А поскольку структура эта нигде не описана, по крайней мере, на русском языке, — уделим ей толику внимания.

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

Структура главного репозитория

Головное, если так можно выразиться, хренилище пакетов, как нетрудно догадаться, находится по адресу и далее вглубь. Однако практически пользователь туда почти никогда не попадает: как мы увидим в разделе об управлении пакетами, система эта автоматически посылает его…

Читайте также:  Установка почтового сервера kerio

нет, не туда, куда вы подумали в меру своей испорченности, а на наиболее быстрое зеркало. Причём именно наиболее быстрое физически и именно в данный момент — потому что это проверяется не по зональной принадлежности и прочим формальным признакам, а по отклику на всамделишний запрос. Если, конечно, установлен соответствующий плагин к yum ‘у — но об этом мы поговорим несколько позднее.

Так что, набрав в строке браузера что-нибудь типа http://download.fedoraproejct.org , наш советский пользователь окажется на сервере с URL типа http://mirror.имя_рек.ru/fedora/linux/ (а возможно, что даже и не ru вовсе). Имя этого самого имя река я изрекать не буду — полный список возможных вариантов можно увидеть здесь http://mirrors.fedoraproject.org/publiclist . И отдать предпочтение какому-то одному из них — значит, как сказал бы Шурик, проявить несправедливость к другому имя реку.

Естественно, что структура всех имя реков идентична, так что её можно рассматривать на примере любого зеркала.

Итак, оказавшись на имя_рек/fedora/linux/ , мы видим следующие каталоги:

Как нетрудно догадаться, в каталоге development помещаются пакеты, находящиеся в состоянии разработки (здесь важен подкаталог /development/rawhide/ , к которому мы со временем вернёмся), в каталоге updates — недавно обновлённые. А вот каталог releases — это именно то, что нас в данный момент интересует.

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

и подкаталог test . Иногда он пуст, содержимое в нём появляется, когда от разрабатываемой ветки (той самой rawhide ) отщепляется альфа-версия следующего релиза.

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

Первый включает в себя пакеты различных версий и сборок, произведённых за время существования релиза. Первый, как следует из названия, содержит текущие обновления сборок пакетов, а последний — образы LiveCD для обеих поддерживаемых архитектур ( i686 и x86_64 ). И о том, и о другом будет говориться своевременно. А вот по каталогу Fedora будем карабкаться дальше — тем более, что его можно рассматривать как пример устройства любого каталога на серверах проекта.

Итак, в каталоге fedora/linux/releases/14/Fedora/ можно видеть такие подкаталоги:

Второй из них включает в себя rpm-пакеты исходных текстов (так называемые *.src.rpm ), о которых также речь пойдёт отдельная. Первый же и третий содержат сборки для 32- и 64-битных архитектур, соответственно. Очевидно, что внутри они абсолютно одинаковы, поэтому их внутренности рассмотрим на примере более актуальной ныне архитектуры x86_64 .

В первом лежат образы установочных дисков — DVD, набора CD и диска для сетевой установки ( netinst ), о которых речь будет в разделе про установку системы. Второй содержит файлы метаданных для jigdo (Jigsaw Download) — системы распространения больших файлов (в данном случае — образов тех же установочных дисков) и служит той же цели, что и предыдущий. Ну а в третьем, в подкаталоге Packages, собственно, и находятся искомые пакеты.

Кроме этого, в каталоге fedora/linux/releases/14/Fedora/x86_64/os/ можно видеть служебные файлы, такие, как GPG-ключи для проверки подлинности, файлы описания репозитория (в подкаталогах repodata и repoview ), файлы для компоновки собственных образов загрузочных дисков (в подкаталогах images и isolinux ), которые в данный момент нас не интересуют.

Что же касается содержимого каталога Packages , то оно представлено rpm-пакетами — теми, которые непосредственно поддерживаются в рамках проекта Fedora.

Структура репозитория RPMFusion

Головным репозиторием, однако, список доступных для нашего дистрибутива пакетов не исчерпывается. Существует также репозиторий для дополнительных пакетов, поддерживаемых волонтёрами в рамках самостоятельного проекта — RPMFusion .

Собственно репозиторий дополнительных пакетов находится здесь . В нём мы видим два каталога — free и nonfree . Первый предназначен для безусловно свободных программ (в головном репозитории Fedora, кстати, только такие и имеются), второй — для программ, на распространение которых накладываются некоторые ограничения. Какие именно — к этому вопросу мы ещё вернёмся.

Внутренняя структура обоих каталогов одинакова. В них имеются подкаталоги el и fedora . Первый включает пакеты, обратно перенесённые (backports) из RHEL и нас сейчас не интересует. Второй же включает подкаталоги:

а также файлы описания репозитория.

Назначение каталогов более или менее понятно из их имён (к этому вопросу мы ещё вернёмся), так что остановимся только на каталоге releases . В нём есть подкаталоги для полудюжины последних релизов — в том числе и куда более «глубоких», нежели поддерживаемые в головном репозитории. В каждом из них мы увидим единственный подкаталог Everything . А в нём — уже привычные «архитектурные» подкаталоги:

Далее вглубь (или вверх? — зависит от используемой метафоры) — последний уровень вложенности — подкаталоги:

В первом, как легко догадаться, — отладочная информация, которая нам сейчас не интересна. А вот во втором — уже собственно пакеты. В том числе и основной пакет описания репозитория — rpmfusion-free-release . Тот самый, установка которого однозначно приводит к подключению этой «репы». А в соответствующем подкаталоге каталога nonfree аналогичный пакет и будет именоваться соответственно — rpmfusion-nonfree-release .

Структура репозитория RFRemix

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

Он расположен в одноименном каталоге по следующему адресу (насколько я знаю, пока единственному). И структура его следующая: на первом уровне вложенности идут подкаталоги

  • build/ с файлами описания репозиториев,
  • releases/ с образами установочных дисков и LiveCD, и
  • russianfedora/ , содержащий собственно пакеты.

В данный момент нас интересует только последний подкаталог. Он включает три подкаталога:

  • fixes/ , представляющий своего рода дельту между базовыми и дополнительными пакетами оригинальной Fedora, с одной стороны, и RFRemix — с другой;
  • free/ , предназначенный для полностью свободных пакетов проекта Russian Fedora;
  • nonfree/ , предназначенный для пакетов проекта Russian Fedora, распространение которых ограничено законами некоторых стран (но не нашей).

Подробнее о составе всех трёх категорий будет говориться в следующем разделе — пока же нас интересует только физическая структура соответствующих каталогов.

Она идентична: каждый из них включает подкаталоги el/ и fedora/ того же назначения, что и в RPM Fusion. В подкаталоге fedora/ , в свою очередь, выделяются подкатлоги development/ , releases/ и updates/ , а в подкаталоге releases/ — каталоги для номеров главных (мажорных) релизов, в настоящий момент — с 10-го по 15-й.

В каталоге каждого релиза мы видим единственный подкаталог Everything/ , включающий подкаталоги для обеих поддерживаемых архитектур — i386/ и x86_64/ , и подкаталог source/ для пакетов с исходными текстами. Ну и наконец этажом ниже лежат подкаталоги debug/ и os/ понятного (то есть того же, что и в RPM Fusion) назначения.

Дополнительные репозитории

Описанных выше репозиториев большинству пользователей хватит почти на все случаи жизни. Однако в ряде случаев возникает и необходимость в дополнительных пакетах, в официальные «репы» по тем или иным причинам не включённых — возможно, пока не включённых. Типичный на сегодняшний день пример — браузер Chromium: его не найти ни в RPM Fusion, ни в Russian Fedora.

И тут на помощь придёт в первую очередь репозиторий Fedora People — он предназначен именно для пакетов, собираемых независимыми майнтайнерами. По содержанию он не перекрывается с офоциальным и «полуофициальными» репозиториями, однако, насколько мне известно, его пакеты тестируются на совместимость с ними, и потому могут использоваться безбоязненно.

Структура репозитория Fedora People предельно проста: по указанному адресу вы увидите множество каталогов, имена которых повторяют названия содержащихся в них пакетов. Внутри любого из них будет серия подкаталогов для поддерживаемого диапазона релизов — разного в разных случаях. А подкаталог каждого релиза содержит три стандартных подкаталога — i386/ , SRPMS/ и x86_64/ , заключающих в себе файл описания репозитория и собственно файлы пакетов.

В ряде случаев интерес может представлять репозиторий ATrpms . Он содержит многочисленные пакеты мультимедийного содержания, специализированные сборки ядра, изобильные драйвера для видеокарт Nvidia (в том числе для старых моделей, которые уже не найти на официальном сайте фирмы). С полным списком пакетов можно ознакомиться здесь , а здесь — увидеть список поддерживаемых релизов.

Содержание ATrpms сильно пересекается с основными репозиториями — обычно это альтернативные сборки тех же пакетов. Так что гарантировать их полную совместимость с последними нельзя. Впрочем, различная степень надёжности пакетов из ATrpms по указанным адресам помечена наглядно — цветами, расшифрованными в легенде.

В статьях и обзорах, посвящённых Fedora, можно встретить упоминания о многих других дополнительных репозиториях для этого дистрибутива — их список можно видеть, например, в ссылках с того же ATrpms . Однако практически все они потеряли актуальность. Одни (Livna, Freshrpms, Dribble) ныне объединены в составе RPM Fusion. В других содержатся пакеты для весьма старых версий Fedora. Ну а репозиторий Tigro стал основой для Russian Fedora — хотя ленивым обладателям старых версий Fedora он будет полезен и сам по себе.

Логическая организация репозиториев

Физическая структура репозиториев Fedora, особенно головного, выглядит довольно запутанной. К счастью, пользователю, как уже говорилось, практически не приходится иметь с ней дело. В 99 случаях их 100 ему достаточно ориентироваться в логической их организации, которую мы сейчас и рассмотрим.

Классификация программ

Для начала следует сказать, почему слово репозитории ранее было употреблено во множественном числе. А для этого нужно рассмотреть классификацию пакетов, принятую в этом дистрибутиве. Она предельно проста и включает всего две категории.

Первая категория называется free и охватывает программы, распространяемые безоговорочно свободно — то есть под лицензией GPL и, по мнению FSF, стопроцентно с ней совместимыми.

Вторая категория называется nonfree — название не очень удачное, поскольку вызывает ассоциации со всякого рода варезом, контрафактом или необходимостью каких-либо платежей при их использовании. На самом деле это совершенно не так. В категории nonfree объединены исключительно бесплатные (в смысле free beer) и легально распространяемые программы. Однако на распространение их накладываются те или иные ограничения. И потому с точки зрения FSF они не могут называться истинно свободными (в смысле free word).

С одной стороны, в категорию nonfree попадают программы, распространяемые только в бинарном виде — без всяких ограничений, но и без исходных текстов. Примерами таких программ являются фирменные драйвера устройств, например видеокарт и сетевых устройств, или проигрыватель флэш-роликов от фирмы Adobe, браузер Opera, некоторые шрифты и игры.

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

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

Основные репозитории

Для начала рассмотрим основные репозитории, которые автоматически подключаются при установке RFRemix.

Главный, официально поддерживаемый, репозиторий проекта Fedora содержит только пакеты категории free . И поэтому называется просто и незатейливо — fedora , с расшифровкой в виде номера версии и целевой архитектуры, например: Fedora 15 — x86_64.

А вот в составе RPMFusion имеются как полностью свободные, так и «несвободные» пакеты. А потому в нём обособляются два репозитория — rpmfusion-free и rpmfusion-nonfree .

Внутреннее устройство Russian Fedora ещё «богаче» — в нём имеется целых три репозитория:

  • russianfedora-fixes — это пакеты, которые имеются в репозиториях fedora или rpmfusion , однако представленные версиями либо более новыми, либо адаптированными к нашим условиям и кириллическому окружению; пакеты этого репозитория не разделяются на свободные и несвободные;
  • russianfedora-free — полностью свободные пакеты, отсутствующие в репозиториях fedora или rpmfusion ;
  • russianfedora-nonfree — «не совсем свободные», в указанном на прошлой странице смысле, пакеты, также отсутствующие в репозиториях оригинальной Fedora.

Это основная ветка репозиториев для каждого релиза. Она сопровождается несколькими дополнительными, которые заполняются пакетами, обновляемыми в промежутке между релизами:

  • updates — для собственно Fedora;
  • rpmfusion-free-updates — для Rpmfusion-free;
  • rpmfusion-nonfree-updates — для rpmfusion-nonfree;
  • russianfedora-fixes-updates — для Russian Fedora Fixes;
  • russianfedora-free-updates — для Russian Fedora Free;
  • russianfedora-nonfree-updates — для Russian Fedora Nonfree.

Кроме того, каждому из основных репозиториев соответствуют специальные ветки отлаживаемых и тестируемых пакетов: fedora-debuginfo и fedora-updates-testing , соответственно — для основного репозитория и образованные по образу и подобию — для всех остальных.

И, наконец, существует ветка репозиториев rawhide . Она содержит пакеты следующей, разрабатываемой в настоящий момент, версии дистрибутива и, естественно, включает в себя те же самые репозитории, что и в ветках стабиольных релизов: fedora-rawhide , rpmfusion-free-rawhide , rpmfusion-nonfree-rawhide и так далее.

Сказанное выше относилось к репозиториям бинарных пакетов для архитектур i386 и x86_64 . Однако есть ещё и репозитории исходных текстов — fedora-source , rpmfusion-free-source и так далее.

Оставьте комментарий Отменить ответ

Для отправки комментария вам необходимо авторизоваться.

источник