Немає перевірених версій цієї сторінки; ймовірно, її ще не перевіряли на відповідність правилам проекту.

RPM (англ. Red Hat Package Manager — менеджер пакунків Red Hat[2] або RPM Package Manager — RPM — менеджер пакунків) — позначає дві речі: формат пакунків програмного забезпечення і програму, створену для управління цими пакунками. Програма дозволяє встановлювати, видаляти і оновлювати програмне забезпечення. Формат RPM заснований на форматі, розробленому LSB.

RPM Package Manager
Типменеджер пакунків
АвториMarc Ewingd[1], Erik W. Troand[1] і Red Hat
РозробникRed Hat
Операційна системаLinux
Мова програмуванняC
ЛіцензіяGNU General Public License
Репозиторійgithub.com/rpm-software-management/rpm
Вебсайтrpm.org

Спочатку розроблений компанією Red Hat для Red Hat Linux, RPM став використовуватися в багатьох дистрибутивах GNU/Linux і був портований на інші операційні системи: Novell NetWare (з версії 6.5 SP3), IBM AIX (з версії 5) та інші.

Сьогодні «RPM Package Manager» використовується як рекурсивний акронім.

Проєкт RPM 4 (rpm.org [Архівовано 15 червня 2018 у Wayback Machine.]) розвивається компанією Red Hat і використовується в таких дистрибутивах, як RHEL, Fedora, SUSE Linux, openSUSE, Mageia, ALT Linux і MeeGo. RPM 4 не слід плутати з проєктом RPM 5 (rpm5.org), який ніяк не пов'язаний з RPM 4 і з 2007 року розвивається паралельно іншою командою розробників. З дистрибутивів, що перейшли на RPM 5, можна відмітити Unity Linux, OpenEmbedded, ArkLinux і Mandriva Linux.

Назви пакунків

ред.

Кожен пакунок RPM має назву, яка складається з декількох частин:

  • Назва програми
  • Версія програми
  • Номер релізу (кількість разів перезбірки програми однієї і тієї ж версії). Також часто використовується для позначення дистрибутиву, під який зібраний цей пакунок, наприклад mdv (Mandriva Linux) або fc4 (Fedora Core 4).
  • Архітектура, під яку зібраний пакунок (i386, ppc і т. д.)

Зібраний пакунок зазвичай має такий формат назви:

<назва>-<версія>-<реліз>.<архітектура>.rpm

Наприклад:

nano-0.98-2.i386.rpm

Іноді в пакунок входять початкові коди. Такі пакунки не містять інформації про архітектуру, вона замінюється на src. Наприклад:

libgnomeuimm2.0-2.0.0-3.src.rpm

Бібліотеки найчастіше розповсюджуються в двох окремих пакунках. Перший містить зібраний код, другий (зазвичай до нього додають -devel) містить заголовні файли і інші файли, необхідні розробникам. Необхідно стежити за тим, щоб версії цих двох пакунків збігалися, інакше бібліотеки можуть працювати некоректно. Пакунки з розширенням noarch.rpm не залежать від конкретної архітектури комп'ютера. Зазвичай вони містять графіку і тексти, що використовують інші програми.

Структура пакунків RPM

ред.

Пакунок записується у двійковому форматі і складається з чотирьох розділів:[2]

  • початкова ідентифікація пакунка як RPM файла, що містить також деякі застарілі заголовки.
  • Підпис, який може використовуватися для впевненості в цілісності та/або автентичності.
  • Заголовок містить метадані:
    • назва, версія, реліз пакунка
    • архітектура
    • залежності які потребує пакет
    • залежності які надає, задовільняє, для встановлення інших пакетів
    • група пакетів
    • інформація про збірку, з яких вихідних файлів, коли та на якому хості було зібрано пакет
    • список файлів
    • короткий опис, URL та опис пакунку
    • журнал змін
  • Файловий архів cpio який стиснений за допомогою gzip, bzip2 або lzma. Формат RPM 5.0 підтримує архіватор xar.
  • Архів також має скрипти, які виконуються під час встановлення, видалення пакунків.

Переваги і недоліки RPM

ред.

Переваги RPM над іншими засобами управління і установкою програмного забезпечення:

  • Легкість видалення і оновлення програм
  • Популярність: дуже багато програм збираються саме в RPM, тому немає необхідності збирати програму з вихідних кодів
  • «Неінтерактивна установка»: легко автоматизувати процес установки/оновлення/видалення
  • Перевірка цілісності пакунків за допомогою контрольних сум і GPG-підписів
  • DeltaRPM, аналог patch, що дозволяє відновити встановлене програмне забезпечення з мінімальними витратами на трафік
  • Можливість акумуляції досвіду складальників в spec-файлі
  • Відносна компактність spec-файлів за рахунок використання макросів

Основні недоліки

ред.
  • Незавершена і застаріла документація (або англомовна чернетка)
  • Збірка пакунка з вихідних кодів зазвичай вимагає великих знань
  • Залежності. RPM не займається задоволенням залежностей. Цю проблему вирішують менеджери yum, urpmi, yast, zypper в залежності від диструбутива.
  • Макропакунки між дистрибутивами можуть істотно розрізнятися
  • Іноді відбувається несумісність версій пакунків при пошуку залежностей (найчастіше це відбувається тоді, коли відбувається спроба встановити пакунок від іншого дистрибутиву, наприклад від Fedora Core до Mandriva)
  • Неможливо розпакувати звичайним ПЗ (в порівнянні з deb (Debian) або tgz (Slackware)). Для цього існує скрипт rpm2cpio.sh [Архівовано 6 березня 2012 у Wayback Machine.] (він розпаковує пакунок за допомогою od, expr, dd і gunzip, а не однією командою)

Створення пакунку

ред.

Для створення пакунку потрібний spec-файл. Це звичайний текстовой файл, має суфікс .spec і містить в собі назву пакунку, версію, номер реліза, інструкції по збірці і установці пакунку і список змін. За наявності spec-файла пакунок створюється командою rpmbuild

Дуже короткий курс молодого бійця можна знайти тут; з англомовних керівництв можна рекомендувати хоч і старе, але багато в чому (особливо по частині макросів) актуальне Maximum RPM [Архівовано 16 травня 2008 у Wayback Machine.] і чернетка його оновленої версії — RPM Guide.

Приклади використання

ред.

маніпуляції з пакунками

ред.
  • rpm -i package-1.2.3-1.el9.x86_64.rpm — встановлення пакунка.
  • rpm -U package-1.2.3-2.el9.x86_64.rpm — за наявності встановленого пакунка package відбудеться його оновлення, за відсутності — встановлення.
  • rpm -e package — видалення пакунка

запити до бази RPM

ред.
  • rpm -qa — (--all) виведення переліку всіх встановлених пакунків
  • rpm -ql package — виведення переліку всіх встановлених файлів пакунка package
  • rpm -qf /path/to/file — виведення пакунка, якому належить файл /path/to/file
  • rpm -qa --queryformat '%010{SIZE}\t%{NAME}-%{VERSION}-%{RELEASE}\n' — використання визначеного формату запиту при виводі списку всіх встановлених пакунків: розмір файла пакета, назва пакета, версія, реліз.
  • rpm --verify package — проведення перевірки (аудіта) пакунка package. Виявляє файли що стали відсутні або змінені після встановлення пакунка.

База даних RPM

ред.

База даних RPM представляє собою набір баз Berkeley DB, який ведеться в теці /var/lib/rpm. В них ведеться інформаця про те, які пакет встановлювались, оновлювались, їх залежності, які файли були встановлені операційну систему, їх метадані при встановленні тощо.

При встановленні або видалені програм, rpm перевіряє наявність необхідних залежностей, причому перевіряє не наявність файлів на файловій системі, а наявність саме в цій базі. Залежності іноді собою представляють не тільки файл, а абстрактну сутність, бібліотеку яка

В набір утілит rpm входить функціонал аудиту, який дозволяє перевірити наявність або відсутність файлів які були встановлені в пакеті, їх контрольну суму а також встановлені права.

База даних не має вбудованих механізмів журналювання, тому може постраждати від переривання процесу встановлення/видалення пакетів, помилок, нестачі вільного місця на файловій системі. Це призводить до неконсистентного стану бази, в такому випадку її можна відновити за допомогою rpm --rebuilddb.

При повній втраті бази, її можна відновити з наявних пакунків, з них можна отримати інформацію якою база повинна бути наповнена, в емулювати встановлення без перезапису файлів, а лише записи в базу rpm -ivh --justdb за списком пакунків.

Дистрибутиви Linux

ред.

Список деяких найвідоміших дистрибутивів Linux, заснованих на RPM:

Виноски

ред.
  1. а б в http://rpm5.org/roadmap.php
  2. а б Maximum RPM: Taking the Red Hat Package Manager to the Limit. Архів оригіналу за 5 липня 2008. Процитовано 17 липня 2008. [Архівовано 2008-07-05 у Wayback Machine.]

Посилання

ред.

Дивись також

ред.
  NODES
Done 1