Архів файлів
На перший погляд, програма складається з одного виконуваного файлу: запускаємо файл, отримуємо працюючу програму. Однак під час роботи навіть сама проста програмавикористовує інші файли, що містять різні ресурси: бібліотеки, конфігураційні файли, файли-дірки і навіть запускає інші програми. Щоб програма дійсно запрацювала, необхідно, крім головного файлу, забезпечити наявність у системі всіх потрібних файлівіз ресурсами.
Зрозуміло, що при встановленні або видаленні програми слід подбати і про всі файли, які вона використовує (яких може бути навіть дуже багато). Це – перше завдання пакетування: всі файли, що використовуються програмою, об'єднуються в один файл – архів. Це дозволяє не копіювати при встановленні програми всі файли окремо, а потім не видаляти їх таким же способом, а працювати з усіма даними програми як з єдиним цілим - встановлювати та видаляти один пакет.
Файловий архів. Дерево каталогів представлене у вигляді єдиного файлу, що складається з вмісту всіх файлів у цьому дереві та інформації про ім'я та атрибути кожного файлу.
Немає жорсткої вимоги, щоб один пакет містив лише одну програму. У пакет природно поєднувати такі ресурси, з якими зручно працювати як з єдиним цілим. Це може бути окрема програмаабо набір утиліт (наприклад, coreutils , основні утиліти, успадковані Linux від UNIX ) або модуль з додатковими можливостямипрограми, чи загальні для кількох програм ресурси. У процесі розвитку та/або старіння програмного забезпеченнявиділення деяких завдань в окремий пакет може набувати або втрачати сенс, тому спосіб об'єднання ресурсів у пакети – це не щось раз і назавжди обране: пакети можуть розділятися та зливатися.
Найпростіший і найтрадиційніший для Linux спосіб об'єднати кілька файлів в один – використовувати утиліту tar 1 з'явився набагато раніше Linux та спочатку служив для створення файлових архівів на магнітній стрічці. Звідси і його назва – tape archiver, "архіватор для (магнітних) стрічок". В даний час tar присутній у будь-якій UNIX-подібній системі та дозволяє працювати з файловими архівами на будь-яких носіях.Мефодій, написавши кілька програм та сценаріїв, вирішив зібрати їх в одному файловому архіві, щоб їх зручніше було переносити на всі системи, в яких йому трапляється працювати. Для цього Мефодій створив архів з усім вмістом свого підкаталогу bin/:
Methody@localhost:~ $ tar -cf methody.progs.tar bin/ methody@localhost:~ $ tar -tf methody.progs.tar bin/ bin/loop bin/script bin/to.sort bin/two Приклад 13.1. Створення файлового архіву за допомогою tar
Перший параметр tar складається з двох частин: операція, яку слід зробити над архівом, в даному випадку "c" (create, створити), і ключ "f", який вказує, що архів слід створити у файлі, ім'я файлу архіву - наступний параметр . Ім'я архіву може бути будь-яким, але Гуревич порадив забезпечити його розширенням ".tar", щоб потім не плутатися. Після імені архіву слідують імена файлів та каталогів, які слід запакувати. 2 З кожним зазначеним каталогом працює рекурсивно, тобто запаковує всі файли і підкаталоги, що містяться в ньому.
Щоб перевірити, які файли потрапили до архіву, Мефодій переглянув вміст архіву командою "tar -tf ім'я_архіву" ("t" – переглянути, "f" використовувати файл, вказаний наступним параметром). Тут Мефодій звернув увагу на дві обставини. По-перше, в архіві імена файлів збереглися разом із шляхом. По-друге, всі шляхи, збережені в архіві - відносні.
При розпаковуванні архіву tar файли витягуються разом з шляхом, підкаталоги, що бракують, створюються при необхідності. Усі шляхи tar вважає відносними, починаючи від свого робочого каталогу. Якщо тепер Мефодій розпакує свій архів (командою "tar-xf имя_архива"), то в робочому каталозі буде створено підкаталог "bin/" і в нього будуть записані всі файли з архіву:
Methody@localhost:~ $ tar -xvf methody.progs.tar bin/bin/loop bin/script bin/to.sort bin/two Приклад 13.2. Розпакування архіву
Ключ "v" велить tar бути "балакучим" (verbose), тобто виводити більше діагностичних повідомлень, і завдяки цьому tar при розпакуванні виводить імена (з шляхом) всіх файлів, що записуються. Якщо в робочому каталозі вже є файл, який tar збирається створити під час розпакування, то цей файл буде просто заміненийфайлом із архіву. Так, коли Мефодій розпакував свій "), в системі Мефодія використовується один з найбільш поширених - rpm, тому всі приклади в даній лекції будуть за його участю. Для роботи з пакетами у спеціальному форматі потрібна спеціальна програма-установник, яка так само називається - rpm : вона займається встановленням, видаленням, оновленням та перевіркою пакетів.
Пакет у форматі rpm – це єдиний файл із усіма необхідними даними. Існують певні (хоча й не дуже жорсткі та послідовні) угоди щодо назв файлів-пакетів. Наприклад, rpm -файл, що містить комплект стандартних утиліт coreutils, в системі Мефодія називається coreutils-5.2.1-some5.rpm: спочатку – ім'я пакета, потім через дефіс – службова інформація про номери версій програмного забезпечення та самого пакета.
У цій короткій замітці я хочу розповісти, як дізнатися якому пакету належить файл LinuxМи розглянемо, як вирішити це завдання не тільки в Ubuntu, але і в інших популярних дистрибутивах.
Таке завдання виникає дуже рідко. Наприклад, ви чистите систему, побачили дивний файл, або файл, який займає багато місця і хочете дізнатися якому пакету він належить, і взагалі, чи потрібен він тут. Або інша ситуація ви хочете встановити або видалити програму але не пам'ятайте назву пакета, але знаєте як називається файл, що виконується.
Для отримання такої інформації в Ubuntu є кілька способів. Це стандартна утиліта dpkg, яка працює тільки з існуючими файлами, а також інструмент apt-file, що дозволяє отримати назву програми знаючи ім'я файлу, що виконується. Подібні інструменти існують і для інших дистрибутивів.
Дізнаємось якому пакету належить файл у dpkg
Щоб дізнатися якому пакету належить файл dpkg має опцію -S, щоправда, виведено буде лише ім'я пакета і адресу файла, наприклад:
dpkg -S /usr/bin/cloud
mail.ru-cloud: /usr/bin/cloud
Тепер, якщо хочемо отримати інформацію про пакет, використовуємо опцію -s:
dpkg -s mail.ru-cloud
Або об'їданням ці команди:
dpkg -S /usr/bin/cloud | awk -F: "(print $1)" | xargs dpkg -s
Package: mail.ru-cloud
Status: install ok installed
Priority: extra
Section: net
Installed-Size: 70000
Maintainer: Mail.Ru Group
Architecture: amd64
Version: 15.05.0235-appind
...
Як дізнатися ім'я пакета файлу в apt-file
Утиліта apt-file не є стандартною для системи Ubuntuтому спочатку її потрібно встановити:
sudo apt-get install apt-file
Потім потрібно оновити базу даних програми, при оновленні завантажити близько 30 Мегабайт даних:
sudo apt-file update
Тепер можна використати:
apt-file search /usr/bin/sshd
Дізнаємося якому пакету належить файл у rpm
У системах на базі Red Hat Linux також можна виконати аналогічну дію. Тут замість dpkg використовується консольна утиліта rpm. Для отримання інформації про пакети використовується опція -q, якщо комбінувати її з опцією -f і передати адресу файлу, ми зможемо дізнатися, якому пакету належить файл:
coreutils-8.22-4.1.x86_64
Бажаєте докладнішої інформації про пакет, додайте опцію -i:
rpm -qif /bin/ls
Name: coreutils
Version: 8.22
Release: 4.1
Архітектура: x86_64
Install Date: Чет 29 Жов 2015 22:25:10
Vendor: openSUSE
URL: http://www.gnu.org/software/coreutils/
Summary: GNU Core Utilities
Пакетний менеджер yum, який використовується в системах, заснованих на Red Hat, теж вміє шукати пакети по файлу, для цього є команда whatpovides:
yum whatprovides /bin/ls
Якому пакету належить файл ArchLinux
ArchLinux використовує власний менеджер пакетів, який дуже відрізняється від описаних вище. Але тут також можна зробити те, що нам потрібно. Для цього є опція Qo:
pacman -Qo /usr/bin/pkgfile
/usr/bin/pkgfile is owned by pkgtools 18-1
Але цей спосіб працює тільки для встановлених пакетів, якщо пакет не встановлений можна використовувати утиліту pkgfile. Вона не постачається за замовчуванням, але її можна встановити:
sudo pacman -S pkgtools
Тепер подивимося якому пакету належить /bin/evince:
Тепер ви можете дізнатися, з якого пакету можна отримати потрібну вам програму.
Пошук пакету файлу в Gentoo
Ще один цікавий дистрибутив із своєрідною системою роботи з пакетами. Тут пакети поставляються у вигляді вихідних кодів та скриптів для складання. Знайти пакет по файлу можна за допомогою утиліти equery, передавши їй параметр b. Наприклад:
equery b /usr/bin/qtconfig
x11-libs/qt-qt3support-4.6.2 (/usr/bin/qtconfig)
Такий спосіб працює лише для встановлених пакетів. Через специфіку дистрибутива для не встановлених пакетів способу пошуку не існує.
Висновки
Тепер ви знаєте як зрозуміти, якому пакету належить файл у будь-якому з найпопулярніших дистрибутивів Linux. У всіх дистрибутивах, заснованих на Ubuntu та Debian, працює dpkg, для RPM-based дистрибутивів підходить утиліта rpm. А два інші менш популярні, але дуже цікаві ми розглянули окремо. Якщо у вас залишилися питання, запитуйте у коментарях!
Необхідність встановлення нових програмних пакетів під LINUX виникає у двох основних випадках:
- коли з'являється Нова версіяодного з встановлених пакетів;
- коли виникає необхідність використання якогось пакета, ще встановленого у системі.
У другому випадку це може бути один із пакетів, що є на Вашому настановному дискуале не встановлений у процесі інсталяції. Однак найчастіше нове ПЗ Ви знаходите в , тим більше, що значна частина цього ПЗ безкоштовне або умовно безкоштовне.
Існує дві основні форми поширення ПЗ для LINUX: у вихідних текстах і у вигляді модулів, що виконуються. І в тому і в іншому випадку пакет може поставлятися або у вигляді tar-gz архіву, або у вигляді rpm-пакета.
Найпростіше встановити ПЗ, представлене у вигляді rpm-пакета, що містить файли, що виконуються, цей спосіб і розглянемо першим. Зазначимо лише, що для інсталяції нових пакетів Ви повинні увійти до системи як користувач root.
Програма RPM.
Назва цієї програми (або команди) є абревіатурою Redhat Package Manager. Програма rpm у певному сенсі аналогічна до програм типу setup wizard для MS Windows. Перевагою використання цієї програми в порівнянні з установкою tar-gz архівів є те, що вона автоматично зробить всі необхідні дії щодо встановлення ПЗ: створить необхідні каталоги, розподілить за ними файли, створить посилання. Крім того, вона може бути використана не тільки для встановлення нового пакета, але і для оновлення версій ПЗ, отримання переліків встановленого ПЗ та перевірки установки, а також для деінсталяції окремих пакетів (наприклад, якщо після періоду пробної роботи з програмою Ви вирішили відмовитися від неї) подальшого використання). За допомогою тієї ж програми rpm можна створити пакет формату rpm, однак для початківців краще скористатися готовими rpm-пакетами.
rpm-пакети - це спеціально підготовлені архіви, призначені для обробки програмою rpm. Назва rpm-пакетів закінчується на суфікс.rpm, наприклад xzip-180-1.i386.rpm або xzip-180-1.src.rpm. Як бачите, перед суфіксом. rpm стоїть ще один суфікс. Якщо це .i386 або .i586, то в пакеті знаходяться файли, що виконуються, а якщо цей суфікс.src, - то в пакеті вихідні тексти, які після установки ще треба скомпілювати. Зазвичай і на установочних компакт-дисках і в Інтернет-каталогах rpm-пакети з файлами, що виконуються, розташовуються в каталогах з назвою RPMS, а rpm-пакети з вихідними текстами - в підкаталогах SRPMS.
Ви знайшли і завантажили rpm-архів з версією потрібного Вам пакету. Якщо Ви ставите новий пакет (у Вас не було на комп'ютері попередніх версій цього ПЗ), то для встановлення пакету з цього архіву достатньо перейти в той каталог, де знаходиться архів, і дати команду
rpm -i имя_rpm-архіву
Якщо у Вас було встановлено попередню версію пакета, то в найпростішому випадку треба дати команду наступного формату:
rpm -U --force имя_rpm-архіву
Тут параметр -U говорить програмі, що треба зробити оновлення (upgrade) пакета, а опція --force вимагає безумовно (і без зайвих питань) оновити всі файли, що входять до пакета. Зауважте, що це дуже сильна вимога, і в деяких випадках можливо краще зберегти якісь (наприклад, конфігураційні) файли від попередньої версії. Якщо установка проходить нормально, і ніяких додаткових повідомлень не з'являється, то після завершення роботи програми (після появи запрошення shell) Ви можете скористатися знову встановленим пакетом.
Щоб з'ясувати, які файли встановить той чи інший пакет, потрібно дати команду
rpm -qpl имя_rpm-архіву
А для отримання інформації про пакет – команду
rpm -qpi имя_rpm-архіву
Усього rpm має 16 основних режимів роботи, які має сенс об'єднати у 6 груп (після двокрапки наводиться формат команди для відповідного режиму):
Запити:
Запит: rpm [--query]
Показати теги запитів (Querytags) : rpm [--querytags]
Встановлення та підтримка встановлених пакетів:
Установка: rpm [--install] +
Оновлення: rpm [--freshen|-F]
+
Деінсталяція: rpm [--uninstall|-e]
+
Перевірка: rpm [--verify|-V] +
Підписи (пакети підписуються електронним цифровим підписому форматі
PGP, з метою забезпечення незмінності та збереження авторства
пакетів):
Перевірка підпису: rpm [--verify|-V] +
Перепідписування: rpm [--resign] +
Додавання підпису: rpm [--addsign] +
Робота з базою:
Ініціалізація бази: rpm -i [--initdb]
Rebuild Database: rpm -i [--rebuilddb]
Створення rpm-пакетів:
Створити пакет: rpm [-b|t] +
Перекомпілювати пакет: rpm [--rebuild] +
Build Package від Tarball: rpm [--tarbuild] +
Різне:
Показати конфігурацію програми rpm: rpm [--showrc]
Задати користувачів: rpm [--setperms] +
Задати групи: rpm [--setgids] +
Більше докладний опискоманди rpm Ви можете знайти в RPM-HOWTO, сторінках man та info.
Установка ПЗ з вихідних текстів
У деяких випадках модулі додатків, що виконуються, можуть поставлятися у вигляді tar-gz-архівів або тарбола (.tar.gz, .tgz). Безпосередньо процес інсталяції пакета складається з наступних кроків:
1 розархівувати тарбол:
Створюємо папку, куди розархівуватимемо тарбол,
Mkdir<Имя_папки>
Копіюємо туди тарбол
Cp<исходный_файл> > <назначенная папка>
Безпосередньо розархівуємо до папки:
Tat xfzv<Имя_тарбола>
Розархівація архівів типу tar.gz та tgz
Tat xfjv<Имя_тарбола>
Розархівація архівів типу tar.bz та tbz
файли розархівуються в поточну папку (для роботи з архівами дуже зручно використовувати Midnight Commander – MC – вільний клон NC)
Переходимо до папки з розархівованим тарболом
Cd _Ім'я_папки_
2 конфігуруємо пакет
./configure(У важких випадках потрібно буде в параметрах вказати шляхи для всіх необхідних бібліотек і header-файлів - але на щастя, зазвичай на близьких системах вони лежать одного і сам скрипт configure їх знаходить, також парамети можуть знадобитися, якщо пакет буде розташовуватися не в тому місці , де припускав розробник програми, а будь-якому іншому)
Операційних систем сімейства Linux (називається зазвичай дистрибутивами Linux) дуже багато. Способи встановлення на них теж багато. Різні дистрибутиви підтримують різні способиустановки, та різні формати інсталяційних файлів.
Більшість дистрибутивів Linux підтримують установку з вихідних кодів, які розповсюджуються у вигляді архівів, зазвичай з розширенням tar.gz. У разі встановлення програми з такого архіву програма спочатку компілюється з вихідних кодів. Після цього запускається командний файл, який копіює потрібні файли у встановлені місця. Такий спосіб установки має купу недоліків. Насамперед – абсолютно непотрібний для кінцевого користувача процес компілювання програми. Цей процес займає час, для великих програм – довгий. Після цього залишаються файли з вихідним кодом, які також не потрібні для її використання.
Для вирішення проблем із встановленням програм із вихідних кодів були створені так звані пакетні менеджери - програми для роботи з інсталяційними файлами(пакетами). Пакетні менеджери використовують файли у певному форматі. Використання пакетного менеджера дає багато переваг. Пропадає необхідність компіляції програм із вихідних кодів - і, відповідно, сам вихідний кодстає необов'язковим використання програми. Пакетні менеджери вміють встановлювати програми з репозиторіїв - сховищ пакетів (зокрема через Інтернет). Пакетні менеджери відстежують залежності програм один від одного - тому, якщо при встановленні програми чогось не вистачає, пакетний менеджер повідомить про це, а якщо установка проводиться з Інтернет-репозиторію - ще й запропонує автоматично встановити недостатнє. Також пакетні менеджери відстежують конфлікти пакетів – ситуації, коли одна програма заважає іншій. При встановленні програм із вихідних кодів залежності не охолоджуються, і конфлікти теж. Якщо чогось не вистачає в момент складання програми - складання завершиться з помилкою (можливо, після того, як більша частина складання вже буде виконана). Якщо чогось не вистачає для роботи програми – програма скомпілюється, але не працюватиме (або буде, але неправильно). Те саме буде, якщо є конфлікти.
Один із найпоширеніших форматів інсталяційних пакетів – deb-файли. "deb" - це скорочення від Debian, назви одного з найпопулярніших дистрибутивів Linux, у рамках якого було розроблено цей формат пакетів та пакетний менеджер для нього. Також цей пакет використовується у багатьох дистрибутивах, похідних від Debian - наприклад, Ubuntu та Linux Mint. Програма GUI-deb створена в першу чергу для автоматизації створення deb-файлів, що відображено в її назві.
Інший найпоширеніший формат інсталяційних пакетів - rpm-файли. Цей формат був розроблений компанією Red Hat і використовується в дистрибутиві Red Hat Enterprize Linux, а також похідних від нього та пов'язаних з ним дистрибутивах – Fedora, Cent OS, Mandriva, Alt Linux та багатьох інших. Створення rpm-файлів GUI-deb не підтримується. Пакет у форматі rpm може бути отриманий із пакета у форматі deb за допомогою програми alien. Програма GUI-deb може автоматично запускати alien після складання deb-файлу для отримання пакета у форматі rpm.
Придатна для роботи користувача система складається з безлічі (сот і тисяч) програм та утиліт. У Linux кожен компонент системи представлений у вигляді пакету. Усі операції, пов'язані із зміною складу системи: встановлення, видалення, перевірка, оновлення компонентів, - виробляються над пакетами. В цілому, пакет- цей засіб зробити так, щоб користувач-адміністратор, змінюючи або оновлюючи програмне наповнення системи, працював не з файлами(імена яких йому часом невідомі), а з певними функціональностямисамої системи: наприклад, додавав до неї не «500 файлів», а «WWW-сервер apache».
Архів файлів
На перший погляд, програма складається з одного - виконуваного файлу: запускаємо файл, отримуємо працюючу програму. Однак під час роботи навіть найпростіша програма використовує інші файли, що містять різні ресурси: бібліотеки, конфігураційні файли, файли-дірки і навіть запускає інші програми. Щоб програма дійсно запрацювала, необхідно, крім головного файлу, забезпечити наявність у системі всіх потрібних файлів з ресурсами.
Зрозуміло, що при встановленні або видаленні програми потрібно подбати і про всі використовувані нею файли (яких може бути навіть дуже багато). Це - перше завдання пакетування: всі файли, що використовуються програмою, об'єднуються в один файл - архів. Це дозволяє не копіювати при встановленні програми всі файли окремо, а потім не видаляти їх таким же способом, а працювати з усіма даними програми як з одним цілим - встановлювати і видаляти один пакет.
Файловий архів Дерево каталогів представлене у вигляді єдиного файлу, що складається з вмісту всіх файлів у цьому дереві та інформації про ім'я та атрибути кожного файлу.
Немає жорсткої вимоги, щоб один пакет містив лише одну програму. У пакет природно поєднувати такі ресурси, з якими зручно працювати як з одним цілим. Це може бути окрема програма або набір утиліт (наприклад, coreutils, основні утиліти, успадковані Linux від UNIX) або модуль з додатковими можливостями програми, або загальні для кількох програм ресурси. У процесі розвитку та/або старіння програмного забезпечення виділення деяких завдань в окремий пакет може набувати або втрачати сенс, тому спосіб об'єднання ресурсів у пакети - це не раз і назавжди обране: пакети можуть розділятися і зливатися.
Найпростіший і традиційний для Linux спосіб об'єднати кілька файлів в один - використовувати утиліту tar.
tar з'явився набагато раніше за Linux і спочатку служив для створення файлових архівів на магнітній стрічці. Звідси та його назва - t ape ar chiver, "архіватор для (магнітних) стрічок". В даний час tar присутній у будь-якій UNIX-подібній системі та дозволяє працювати з файловими архівами на будь-яких носіях.
Мефодій, написавши кілька програм та сценаріїв, вирішив зібрати їх в одному файловому архіві, щоб їх зручніше було переносити на всі системи, в яких йому трапляється працювати. Для цього Мефодій створив архів із усім вмістом свого підкаталогу bin/.
Methody@localhost:~ $ tar -cf methody.progs.tar bin/ methody@localhost:~ $ tar -tf methody.progs.tar bin/ bin/loop bin/script bin/to.sort bin/two
Приклад 1. Створення файлового архіву за допомогою tar
Перший параметр tar складається з двох частин: операція, яку слід зробити над архівом, в даному випадку c ( c reate, створити), і ключ "f", який вказує, що архів слід створити у файлі, ім'я файлу архіву - наступний параметр. Ім'я архіву може бути будь-яким, але Гуревич порадив забезпечити його розширенням ".tar", щоб потім не плутатися. Після імені архіву слідують імена файлів та каталогів, які слід запакувати.
З кожним зазначеним каталогом tar працює рекурсивно, тобто запаковує всі файли і підкаталоги, що містяться в ньому.
Щоб перевірити, які файли потрапили в архів, Мефодій переглянув вміст архіву командою « tar -tf ім'я_архіву» (« t » - переглянути, « f » використовувати файл, вказаний наступним параметром). Тут Мефодій звернув увагу на дві обставини. По-перше, в архіві імена файлів збереглися разом із шляхом. По-друге, всі шляхи, збережені в архіві – відносні.
При розпаковуванні архіву tar файли вилучаються разом із шляхом, відсутні підкаталоги створюються за необхідності. Усі шляхи tar вважається відносними від свого робочого каталогу. Якщо тепер Мефодій розпакує свій архів (командою tar xf ім'я_архіву»), то в робочому каталозі буде створено підкаталог «bin/» і в нього будуть записані всі файли з архіву.
Methody@localhost:~ $ tar -xvf methody.progs.tar bin/bin/loop bin/script bin/to.sort bin/two
Приклад 2. Розпакування архіву
Ключ "v" велить tar бути "балакучим" (verbose), тобто виводити більше діагностичних повідомлень, завдяки цьому tar при розпакуванні виводить імена (з шляхом) всіх записуваних файлів. Якщо в робочому каталозі вже є файл, який tar збирається створити під час розпакування, то цей файл буде просто заміненийфайлом із архіву. Так, коли Мефодій розпакував свій архів, підкаталог «bin/» з усім його вмістом замінивсяна підкаталог із архіву. У цій ситуації це не страшно, оскільки в архіві файли такі ж, але якби Мефодій перед розпакуванням змінив якісь зі своїх файлів в «bin/», він втратив би всі зміни.
Формат пакету
Крім зберігання архіву файлів у пакета є й інші завдання (вони обговорюються у двох наступних розділах), тому для пакета в Linux не дуже підходить звичайний файловий архів, на зразок .tar, а потрібен спеціальний формат. Таких форматів у Linux буває кілька (короткий перелік і характеристика - у розділі Package. Установники пакетів), в системі Мефодія використовується один з найбільш поширених - rpm, тому всі приклади в даній лекції будуть за його участю. Для роботи з пакетами у спеціальному форматі потрібна спеціальна програма-установник, яка так само і називається – rpm: вона займається встановленням, видаленням, оновленням та перевіркою пакетів.
Пакет у форматі rpm – це єдиний файл з усіма необхідними даними. Існують певні (хоча і не дуже жорсткі та послідовні) угоди щодо назв файлів-пакетів. Наприклад, rpm-файл, що містить комплект стандартних утиліт coreutils, в системі Мефодія називається coreutils-5.2.1-some5.rpm: спочатку - ім'я пакету, потім через дефіс - службова інформація про номери версій програмного забезпечення та пакета.
Реєстрація в системі
Отже, пакет із компонентом системи - це в першу чергу файловий архів, в якому зберігаються всі необхідні файлиразом із шляхами до них (тобто каталогами). Коли компонентів багато, потрібно забезпечити, щоб у різних пакетах не було файлів з однаковим ім'ямі шляхом, щоб файл, що належить одному пакету, було замінено файлом іншого пакета під час установки. Відстежувати такого роду конфліктипакетів - друге завдання пакетування.
Щоб запобігти конфліктам, в системі повинна зберігатися інформація про всі вже встановлені пакети і файли, що їм належать. Коли точно відомо, які файли належать пакету, можна повністю видалити пакет, не залишивши і не вилучивши нічого зайвого. Такий підхід перешкоджає утворенню в системі «сміття» - марних файлів, що залишилися від віддалених програм- і робить операцію встановлення/видалення пакета повністю оборотною.
Rpm зберігає інформацію про всі встановлені в системі пакети і файли, що належать їм, і може видати цю інформацію за запитом користувача. Почитавши посібник з rpm, Мефодій з'ясував, що список усіх встановлених у системі пакетів (скоріше за все, дуже довгий, у кілька тисяч рядків) можна отримати командою «rpm -qa», список усіх файлів, що належать пакету, командою «rpm -ql ім'я_пакету». Він вирішив перевірити, чи є в його системі вже відомий йому за попередніми лекціями пакет coreutils і дізнатися, які утиліти йому належать:
Methody@localhost:~$rpm -qa | grep coreutils coreutils-5.2.1-some5 methody@localhost:~$rpm -ql coreutils | grep bin /bin/basename /bin/cat /bin/chgrp /bin/chmod
Приклад 3. Які файли належать до пакету?
Мефодій отримав досить довгий список імен файлів, серед яких зустрів багато вже знайомих йому утиліт і деякі незнайомі. Причому запитуючи список файлів, Мефодій використовував лише ім'япакету, без версії- rpm дозволяє звертатися так до будь-якого зі встановлених пакетів2.
Можна виконати і зворотну процедуру – з'ясувати про будь-який файл, якому пакету він належить:
Methody@localhost:~ $ rpm -qf /etc/passwd setup-2.2.5-some1
Приклад 4. Який пакет має файл?
Файли, що належать пакету, можуть бути не лише видалені, а й змінені. Це може бути зроблено свідомо (наприклад, відредаговано конфігураційний файл), у такому разі при оновленні або видаленні пакета змінений файл потрібно зберегти, тому що він містить результат роботи, виконаної адміністратором. Для цього система повинна вміти визначати, що файл, що належить пакету, змінився. Для цього в пакеті повинна зберігатися інформація про всі файли архіву: розмір, атрибути, контрольна сума- у цьому випадку процедура перевірки зможе перевірити відповідність атрибутів файлу в пакеті атрибутам, установленого в системі файлу. Мефодій може перевірити, що змінилося в пакеті командою rpm -V ім'я_пакету ».
Methody@localhost:~ $rpm -V setup S.5....T c /etc/X11/fs/config S.5....T c /etc/exports S.5....T c / etc/fstab S.5....T c /etc/printcap ..?..... c /etc/securetty
Приклад 5. Що змінилося у пакеті?
Мефодій отримав список файлів, що змінилися з моменту встановлення пакета. Мабуть, все це конфігураційні файли, відредаговані адміністратором системи. Мефодій здогадався, що комбінація цифр, літер та точок – це список атрибутів, за якими rpm порівнював встановлені файлиз даними пакета, проте щоб розібратися, що саме означає кожна буква, йому доведеться уважніше читати посібник.
Система Linux розкладається на компоненти без залишку: коженфайл у Linux належить якомусь (і лише одному!) пакету.
Звичайно, крім тих файлів, які створені користувачами.
Це дозволяє звести будь-які зміни у складі системи до операцій над пакетами - від початкової установкидо складних комплексних оновлень. У цьому випадку для всіх змін буде використовуватися та сама програма-установник, наприклад, rpm .
Зміна налаштувань системи
Для повноцінної реєстрації пакета в системі зазвичай недостатньо, щоб система зберігала список файлів, що належать пакету. При встановленні, видаленні або оновленні пакета часто потрібно виконати ряд операцій, щоб оновити відомості про пакет, адаптувати налаштування- як самого пакета до наявних у системі, і навпаки. До того ж, деякі зміни в системі, наприклад, додавання та видалення псевдокористувача, не зводяться до додавання та видалення файлів, а також залежать від поточногостани системи. Виходить, що реєстрація в системі – справа не лише системи, а й самого пакету. Тому в кожному пакеті повинні зберігатися відомості про те, які дії слід виконати в момент різних операцій із ним - у цьому полягає третє завдання пакетування.
Списки необхідних дій представлені у пакеті у вигляді сценаріїв. Ці сценарії прив'язані до процедур встановлення та видалення пакета, причому можуть бути викликані за потребою як до, так і після відповідної процедури. В результаті процедури встановлення та видалення пакета виглядають так:
- виконання попередніх встановлення/видалення сценаріїв;
- копіювання файлів з архіву в систему або видалення файлів із системи
- виконання наступних за встановленням/видаленням сценаріїв.
Methody@localhost:~ $rpm -q --scripts coreutils preinstall scriptlet (за допомогою /bin/sh): # Remove info pages from fileutils, textutils and sh-utils. for f in /usr/share/info/(fileutils,textutils,sh-utils).info*; do [-f "$f"] || continue RPM_INSTALL_ARG1=0 /usr/sbin/uninstall_info "$f" ||: продовження scriptlet (through /bin/sh): /usr/sbin/install_info coreutils.info preuninstall scriptlet (through /bin/sh): /usr/ sbin/uninstall_info coreutils.info
Приклад 6. Перегляд сценаріїв у пакеті
Мефодій з'ясував, що сценарії в пакеті coreutils запускаються перед початком установки (preinstall), після встановлення (postinstall) та перед видаленням (preuninstall), вони виконуються стандартним командним інтерпретатором (/bin/sh). Всі ці сценарії потрібні для того, щоб зареєструвати в системі info встановлену пакетом документацію або видалити цю документацію із системи (командами /usr/sbin/install_info та /usr/sbin/uninstall_info відповідно). Оскільки info будує загальний зміст всієї наявної в системі документації, простого копіюванняфайлів було б недостатньо.
В результаті таких операцій з інтеграції пакета в систему можуть бути змінені або видалені файли, які не належать даному пакету, створені нові файли. Якщо програма, яка міститься в пакеті, користується послугами якоїсь вже встановленої служби (наприклад, syslogd), може знадобитися реєстрація цієї програми в конфігураційних файлах служби. Звісно, зміна «чужих» файлів у процесі встановлення пакета небажана: згодом, видаляючи пакет, потрібно повернути файл у вихідний стан, що завжди можливо (наприклад, після вдумливого редагування адміністратором). Уникнути редагування конфігураційних файлівдозволяє схема”. d», описана в лекції Етапи завантаження системи.
Ціна зручності
Зручність, яку отримує користувач під час роботи з пакетами, досягається не сама собою, а людською працею: пакети повинна створювати людина, її робота називається "супроводжуючий" ("package maintainer" або "packager"). В обов'язки супроводжуючого пакет входить підготовка файлового архіву, необхідних для встановлення та видалення сценаріїв та іншої інформації про пакет та його вміст, та об'єднання їх в одному файлі-пакеті.
Функції створення пакета у форматі rpm також виконує програма rpm .
Дізнатися, хто і коли створив пакет, отримати коротку довідку про програмне забезпечення, яке міститься, можна командою « rpm -qi ім'я_пакету ».
Methody@localhost:~ $ rpm -qi setup Назви: setup Relocations: (no relocateable) Version: 2.2.5 Vendor: Some Linux Team Release: some1 Build Date: Чтв 29 Січ 2004 18:08:05 Install date: Пн 23 2004 15:08:45 Build Host: shogun.somelinux.org Group: Система/Налаштування/Інше Source RPM: setup-2.2.5-some1.src.rpm Size: 39969 License: GPL
Приклад 7. Опис пакету
Потрібно брати до уваги, що будь-який пакет, що містить програмне забезпечення для Linux, не універсальний. Якщо у вас такий пакет, це ще не означає, що його можна встановити у вашій системі. Справа в тому, що різні дистрибутиви Linuxвідрізняються саме тим, яким чином програмне забезпечення організоване в систему(Про дистрибутиви мова піде в лекції). Дистрибутиви можуть відрізнятися розміщенням файлів та процедурами, передбаченими для інтеграції в систему програмного забезпечення, не кажучи вже про те, що у різних дистрибутивах використовується різний формат пакетів. Це означає, що пакет, підготовлений з орієнтацією однією дистрибутив, може бути несумісним з іншим. Щоб у вашому дистрибутиві з'явилася деяка програма, хтось має підготувати та зробити доступним відповідний пакет.
Пакет Ресурси, необхідні для встановлення та інтеграції в систему деякого компонента (архів файлів, до- та післяустановлювальні сценарії, інформація про пакет та його супроводжуючий), об'єднані в одному файлі.
Незважаючи на приватні відмінності, дистрибутиви Linux є варіантами однієї і тієї ж системи, тому в кінцевому підсумку будь-яку програму, що працює в одному дистрибутиві, можна «пристосувати» до іншого. Тільки для цього потрібно мати в своєму розпорядженні вихідними текстамивідповідної програми. Досі йшлося лише про так звані двійкових пакетах, В яких програми містяться у вигляді вже скомпільованих двійкових (виконуваних) файлів, у такому вигляді програма може залежати від деяких властивостей системи та працювати не скрізь. Щоб отримати програму, що працює в системі, потрібно встановити саме двійковий пакет. Однак, пакет може містити і вихідні тексти програм, такі пакети називаються вихідними. Доступність вихідних кодів - обов'язкова умова поширення більшої частини програмного забезпечення для Linux, див. лекцію Політика вільного ліцензування. Історія Linux: від ядра до дистрибутивів. Якщо вийшло так, що ніхто не підготував пакет з потрібною програмою для вашого дистрибутива, у вас є можливість встановити вихідний пакет і скомпілювати програму самостійно.
Чутки про те, що для складання програми з вихідних текстів не обов'язково навіть знати, що таке компілятор, далекі від дійсності.
При успішній компіляції з вихідного пакета виходить відповідний двійковий, який можна встановити в системі.