RPM: керівництво до використання
У цій статті зроблена спроба розглянути такі теми, як формат команд утиліти rpm, формат пакету і spec-файлу, послідовність складання пакетів і т.д.
[Влад Горелецкій (gorelets AT rambler.ru)]
RPM - Red Hat Package Manager, система управління програмним забезпеченням, що живе і розвивається в надрах Red Hat. Має місце також рекурсивне визначення RPM в стилі GNU is not UNIX - RPM Package Manager. Якщо вибрати цей варіант, слід було б написати: «живе і розвивається в надрах Open Source». Загалом, кому що подобається. Якщо ж зачепити формальну сторону, RPM ліцензований під GPL v.2.
Наш інтерес до цієї системи обумовлений існуванням безлічі rpm-based дистрибутивів, тобто дистрибутивів, які є колекціями rpm-пакетів, пов'язаних повинні суперечити одна одній залежностями і забезпечених необхідними механізмами установки-супроводу. Серед дистриб'юторів rpm-based операційних систем - гранди осестроенія, такі, як сама Red Hat, Suse (нині підрозділ Novell), Mandrake і безліч інших проектів, і довгоживучих, і одноденок.
І в складі дистрибутивів і у вигляді окремих розробок є велика кількість графічних утиліт-фронтендів до rpm. В силу приховування, як це нерідко буває, деяких особливостей роботи системи пакетування цими утилітами, ми їх розглядати не будемо. Крім того, в переважній більшості ситуацій робота в консолі щодо rpm-пакетів значно простіше і прозоріше (за винятком складних поєднань залежностей різних версій одних програм від інших).
У цій статті зроблена спроба розглянути такі важливі теми, як формат команд утиліти rpm, формат пакету і spec-файлу, послідовність складання пакетів і практично зовсім не порушена архітектура RPM, так як адміністраторам ці подробиці не важливі, а розробники в основному використовують інтерфейси начебто бібліотеки librpm. Тому в кращих традиціях відсилаємо «цікавляться знати», як це влаштовано всередині, до вихідного коду.
Для дослідження rpm (НЕ RPM) з інструментів потрібно Midnight Commander. Чесно кажучи, важко уявити собі розробника rpm-пакетів, який не користується mc. Про причини цього поговоримо далі. З додаткових умов слід назвати кілька вільного часу і терпіння.
Всі приклади запускалися на ОС Suse Linux 10.0.
Поверхневий погляд.
Оскільки rpm позбавляє користувача від необхідності тримати всі подробиці про встановлений в операційній системі ПО, повинен бути механізм, який виконує ці функції всередині пакетного менеджера. І він є: це база даних rpm. У версіях молодше v.4 движок бази статично збирався в складі пакету, v.4 використовує зовнішню BDB (Berkeley Data Base). Утиліта має високорівнева командний інтерфейс, що дозволяє виробляти запити до бази про встановлені пакетах і їх залежностях.
Отже, приступимо до прикладів. Утиліта rpm може працювати в різних режимах, режими задаються значенням основного ключа команди. Крім того, є ряд опцій, що діють в будь-яких режимах.
Для установки пакета використовується такий формат команди:
# Rpm -i <имя пакета>
І тут ми стикаємося з першим незручністю, так як ім'я пакета має наводиться повністю, разом з усіма його версіями і номерами збірок. Справа в тому, що утиліта просто шукає по зазначеному шляху файл з таким ім'ям, тому ім'я має збігатися в точності. Наприклад, в моїй системі для установки mc доведеться сказати наступне (передбачається наявність прав суперкористувача):
# Rpm -i / шлях до сховища / mc-4.6.1-5.i586.rpm
А ось для того, щоб видалити пакет, можна вказати в якості імені пакета просто mc, так як в цьому випадку утиліта вже звертається до бази даних пакетів:
Для роботи в режимі апгрейда пакетів використовується ключ -U. Якщо потрібно встановити пакет певної версії, не обов'язково з'ясовувати, чи є попередні версії пакету в системі, досить використовувати -U. Наявні версії утиліта освіжить, а в разі відсутності пакета - встановить його. Тому найбільш стандартним вважається варіант команди установки, подібний наступного:
# Rpm -Uhv / шлях до сховища / mc-4.6.1-5.i586.rpm
або з мережевого сховища:
# Rpm -Uhv ftp: // ivanov: [email protected]: 7020 / шлях до сховища / mc-4.6.1-5.i586 .rpm
Ще два цікавих режими: верифікація і режим запитів. Для оцінки можливостей верифікації встановлених пакетів зробимо наступний експеримент: пошкодимо файл якогось пакета і перевіримо його за допомогою rpm.
Наприклад, майже завжди в списку команд каталогу / bin першим йде виконуваний файл arch. Ця утиліта виводить інформацію про процесорної архітектурі системи на стандартний висновок. Щоб дізнатися, зі складу якого пакета цей файл, скористаємося режимом запиту, в якому rpm запускається за допомогою ключа -q. Опція -f запитає, до якого пакунку відноситься дане зображення:
Тепер створимо резервну копію програми, а потім додамо в файл один символ:
# Cp / bin / arch / bin / arch_back
# Echo "1" >> / bin / arch
Після чого механізм верифікації пакету повинен нам повідомити про існуючі проблеми:
# Rpm -V util-linux-2.12q-26
У рядку виведення перед назвою файлу пакета з'являються якісь символи (якщо верифікація успішна і пошкоджень немає, висновку не буде), які вказують на характер несправностей. В даному випадку s означає зміну розміру файлу, 5 - порушення сигнатури md5 файлу, T - зміна часу останньої модифікації (тобто часу копіювання файлу в систему в нашому випадку).
Відновимо файл і знову проведемо перевірку:
# Mv / bin / arch_back / bin / arch
# Rpm -V util-linux-2.12q-26
і побачимо, що все у нас добре, крім часу останньої модифікації файлу / bin / arch, яке буде відповідати часу зворотного копіювання. Така інформація допомагає адміністратору виявити деякі проблеми і пакети - кандидати на переустановку.
Розширені можливості.
Крім режимів роботи, утиліта rpm має безліч опцій, одні з яких прив'язані до певного режиму, інші мають сенс в декількох режимах, або у всіх. Кілька прикладів часто використовуваних опцій.
У режимах установки-видалення досить часто виникає необхідність скористатися опціями --nodeps або --force. Перша дозволяє встановити (видалити) пакет незалежно від того, задовольняються чи все його залежності, друга - встановити пакет навіть в тому випадку, якщо в системі є файли більш свіжих версій. Певний інтерес представляють опції --aid, яка автоматично задовольнить виникають залежно та --test, яка і означає тестування операцій, тобто весь висновок про виникаючі проблеми буде здійснено, але реальних операцій не проводиться. Дуже зручно моделювати поломку системи в результаті яких-небудь дій.
Велику колекцію можливостей надають опції режиму запитів. Про пакеті і його файлах можна отримати практично будь-яку інформацію, починаючи з короткої довідки про пакет (поєднання ключів -qi) і списку файлів пакета (-ql) і закінчуючи значенням деяких службових полів бінарного заголовка пакета. Ці можливості реалізуються або за допомогою відповідних ключів-фільтрів, або за допомогою опції --queryformat, яка дозволяє вивести тільки замовлені службові поля. Наприклад, команда
# Rpm -q --queryformat% <имя пакета>
виведе опис пакета, а команда
# Rpm -q --queryformat% <имя пакета>
- назва дистрибутива, в складі якого знаходиться пакет. Причому заміна -q на -qp дозволить ту ж саму інформацію отримати від rpm-файлу не встановленого в систему пакета. Можна отримати список тільки конфігураційних файлів пакета, або тільки файлів документації, або тільки файлів, що містять в імені регулярний вираз, тобто в принципі що завгодно.
Дуже часто (лінь - двигун прогресу) використовуються запити, висновок яких перенаправляється в зовнішні фільтри. Так, запит про всіх встановлених файлах, перенаправлений в grep, допоможе знайти пакет із заданим ім'ям, або з ім'ям, що містить задану послідовність символів. команда
# Rpm -qa | grep mc
виведе список пакетів, в іменах яких зустрічається поєднання mc, а команда
# Rpm -qa | grep ^ mc
список пакунків, чиї починаються на mc.
За браком місця ми не обговорюємо такі екзотичні, але важливі для розробника опції, як, наприклад, --showrc, яка дозволяє вивести вміст файлів скриптів і макросів з файлів rpmrc і macros на стандартний висновок або в файл, і багато інших. Слід зауважити, що rpm забезпечений докладною документацією man.
Що всередині.
Кілька слів про те, що відбувається в процесі установки і видалення пакета. Як уже зазначалося, rpm автоматизує рутинні операції. При установці (видаленні) пакетів будь-які, як завгодно складні дії з налаштування встановлених пакетів, або видаленні слідів діяльності пакетів видаляються, можна помістити в скрипти. Залежно від положення цих скриптів в канонічній послідовності дій, наприклад, по установці пакета, ці скрипти називаються преінсталляціоннимі або постінсталляціоннимі. Стандартна послідовність операцій, ініціалізіруемих rpm при установці пакету, така:
перевіряються можливі конфлікти (найбільш частий варіант конфлікту - в системі встановлений однойменний пакет більш свіжої версії);
обробляються конфігураційні файли;
копіюються бінарні файли в потрібні каталоги;
виконуються постінсталляціонние скрипти;
оновлюється база даних пакетів.
Формат rpm-пакету.
Формат пакета складається з бінарного заголовка і cpio-архіву, який містить бінарні файли в такому дереві каталогів, в якому вони будуть знаходиться в системі після установки пакета. Файловий менеджер mc розуміє безліч всяких архівів, і в тому числі - упаковку rpm. Якщо в панелі mc виділити rpm-пакет і натиснути введення, ми побачимо псевдофайловую систему, що складається з наступних компонентів: каталогу INFO, архіву CONTENTS.cpio, того самого, що містить бінарні файли, файлу HEADER і псевдоскріптов INSTALL і UPGRADE. В каталозі INFO містяться файли, імена яких відповідають іменам полів spec-файлу, вміст - значенням полів. Файл HEADER - по суті те ж саме, тільки в одному файлі. Посилання INSTALL і UPGRADE відповідають командам rpm -ih <имя пакета> і rpm -Uh <имя пакета>. Тобто, якщо на них натиснути, ці дії і відбудуться.
У реальному форматі ніякої файлової системи немає. Просто mc вміє по-своєму інтерпретувати бінарний заголовок пакета, за що його розробникам великий респект.
При бажанні можна виділити cpio-архів з усього пакета. Для цього існує утиліта rpm2cpio.
Зберемо пакет.
У rpm версії v.4 режим збірки пакета оформлений у вигляді окремої утиліти - rpmbuild. Скористаємося найефективнішим методом вивчення технології, тобто, зберемо модельний rpm-пакет. Немає і питання, що повинна робити програма, яку ми спакуємо в rpm. Вона повинна говорити: «Hello, world!»!
У rpm-based дистрибутивах існує спеціальне дерево каталогів, призначене виключно для збирання пакетів. Воно лежить в / usr / src (в Suse Linux - в / usr / src / packages) і містить каталоги BUILD, RPMS, SOURCES, SPECS, SRPMS. Призначені вони відповідно для зберігання тимчасових каталогів збірки, зібраних бінарних rpm, вихідного коду, зберігання файлів специфікації, зібраних src.rpm-пакетів. Src.rpm містять вихідний код і spec-файли і призначені для пересборки на цільових машинах з метою кращої адаптації до архітектури і системному оточенню цих машин. Для збірки нам буде потрібно вихідний код програми, який традиційно упаковується в tar.gz або в tar.bz2 і spec-файл. Spec-файл для rpm приблизно те ж, що Makefile для утиліти make. Це докладний сценарій того, що повинно відбуватися при складанні з усіма необхідними визначеннями і службовими полями. Отже, за справу.
int main (int argc, char ** argv)
Не забудемо порожній рядок в кінці файлу. Запакуємо вихідний код в tar.gz (команду віддаємо, перебуваючи в каталозі / usr / src / packages / SOURCES):
# Tar cvfz ./hi-0.1.tar.gz ./hi.c
Summary: Вітаю утиліта.