Pacman управління пакетами в archlinux - наш блогосайт linux і «лірика»

Короткий вступ

Подібно системі apt, яка зародилася в надрах Debian та впровадженої потім ... та куди тільки її не впровадили, - застосування системи pacman далеко виходить за рамки батьківського дистрибутива: pacman успішно прикручується до Slackware - приклад чого показав спочатку Rubix, а потім Frugalware Linux. На Distrowatch я знайшов навіть відомості про те, що цей механізм управління пакетами використовується в Ufficio Zero - італійському дістріубутіве, заснованому на Ubuntu, і використовує, отже, пакети в deb-форматі. Правда, перевірити це мені поки не вдалося - сайт їх виявився на найчистішому мовою Данте і Петрарки, на якому я тільки лаятися можу, а встановлювати його було влом. Може бути, хто з наших романістів може внести ясність?

Проте очевидно, що pacman завоював своє місце під сонцем - і йому в чималому ступені зобов'язаний своєю популярністю Archlinux - дистрибутив, ще недавно широко відомий у вузьких колах власних розробників і нечисленних користувачів.

Pacman - базис пакетного менеджменту

Archlinux - не є в повному розумінні слова дистрибутивом Source Based, подібно Gentoo або, тим більше, Linux from Scratch. Бо основна форма його дистрибуції - все ж у вигляді набору прекомпілірованние пакетів. Видом ці пакети схожі на звичайні архіви * tar.gz:

При найближчому розгляді виявляється, що пакети Archlinux схожі на тарбалли не тільки видом, а й вдачею. Формат їх - простий до межі, це саме чисте за- tar 'енное дерево, стислий gzip' ом, що не містить ніяких інсталяційних скриптів, і взагалі ніякої метаінформації: тільки сам виконуваний бінарник (бінарники), призначений для приміщення в каталог / usr / bin (за винятком тих програм, яким резонно перебувати в / bin. / sbin або / usr / sbin), супроводжуваний в необхідних випадках конфіга (для каталогу / usr / etc) і бібліотеками (для / usr / lib), а також man-документацією .

Засіб для управління цими просто побудованими пакетами також дуже просто і носить назву pacman (від packages manager, треба думати). Формат її виклику такий:

Вказівка дії є обов'язковим, опцій, в відповідність з назвою - опціональним.

Дії, передбачені командою pacman. наступні:

-A. або --add - додавання (тобто установка) пакета в систему;
-U. --upgrade. і -F. --freshen. - оновлення пакета; відмінність між ними в тому, що в другому випадку оновлюється тільки раніше інстальований (за допомогою -A) пакет, в першому ж - установка здійснюється і при відсутності оного;
-S. --sync. - синхронізація локально встановлених пакетів з репозиторієм дистрибутива (ftp.archlinux.org) або його дзеркалами;
-R. --remove. - видалення пакета, що виконується без будь-яких попереджень, разом з усіма його файлами і іншим господарством (за винятком, зрозуміло, призначених для користувача конфігов з каталогу $ HOME);
-Q. --query. - запит інформації про пакет, встановленому або невстановленому;
-V. --version. - висновок номера версії pacman. відомостей про копірайт і ліцензії.

В якості аргументів команди pacman при діях -A. -U і -F повинні виступати повні імена файлів пакетів, виду - pkg_name-version-release.pkg.tar.gz. Якщо пакет розташований в одному з призначених до того місць (про них я скажу трохи пізніше), то досить наведеної форми, в іншому випадку буде потрібно вказівку повного шляху. В одному рядку можна перерахувати кілька пакетів для одноразової установки або оновлення. Дії -Q. -S і -R вимагають тільки вказівки імені пакета, без іншої атрибутики.

Є і ще одна дія - -h. або --help. (Увага - тільки воно і в короткій формі задається в нижньому регістрі), - висновок короткої довідки, конкретно, списку дій. Якщо будь-яка з них приєднати до дії -h. то можна отримати більш докладні відомості про опції, які можуть це дію супроводжувати. Так, команда

дасть список всіх опцій, які доступні при дії --added:

Опції команди pacman досить численні, що компенсується їх звичайної необов'язковістю. Важливими можуть бути -d. --nodeps. скасовує перевірку залежностей, і -f. --force. - примусова установка пакета, а також -r. --root. що пропонує відмінний від умолчальне вихідний каталог (а ним є корінь файлової системи) і вимагає, природно, вказівки шляху (наприклад, / usr / local або / opt. Зазначу ще опцію -c. --cascade. так як застосування її вимагає особливої обережності: вона наказує рекурсивне видалення не тільки зазначеного пакета, але і всіх, пов'язаних з ним залежностями. Звернемо увагу, що опції, на відміну від дій, в короткій формі даються виключно в нижньому регістрі.

Нарешті, сама цікава опція - -u. --sysupgrade. Використовувана разом в діями -U або, ще краще, -S. вона забезпечує тотальне оновлення всієї системи:

Очевидно, що в цьому випадку потрібне підключення до Мережі для синхронізації з репозиторіями Archlinux.

Для ознайомлення з іншими опціями пропонується звернутися до тітки Мане - man pacman.

Налаштування pacman

Вище я побіжно обмовився, що для спрощення установки пакетів їх слід розмістити у належному місці. А місце це визначається у файлі конфігурації pacman - /etc/pacman.conf.

Як і всі а Archlinux, файл цей влаштований дуже просто і складається з двох секцій - загальних налаштувань установки пакетів і списку репозиторіїв оних. До загальних налаштувань відносяться:

якої визначається список пакетів, які не торкаються при тотальному оновленні за допомогою pacman -Su;

що містить список файлів, які не повинні записуватись за жодних установках і оновлення пакетів (в тому числі і при тотальному апдейте); за замовчуванням тут, крім зазначених, перераховані всі основні загальносистемні конфіги типу etc / fstab. etc / rc.conf. etc / rc.local. і т.д.;

шлях до бази даних пакетів (за замовчуванням - / var / lib / pacman);

відключення пасивного режиму ftp-з'єднання (за замовчуванням використовується саме він - і це, товариші, правильно в більшості випадків).

У списку репозиторіїв Arch'а зазначено головного ftp-сервер проекту

і все його дзеркала. Списки можна задати окремо для поточної гілки, стабільної, включити в нього репозиторії неофіційних пакетів. Нарешті, можна задати і локальний репозиторій пакетів, наприклад:

Саме перебування пакета в одному з репозиторіїв, перерахованих у файлі /etc/pacman.conf. позбавляє від необхідності вказувати повний шлях до файлу пакета, про що говорилося раніше. Зрозуміло, що установка пакета з ftp-сервера вимагає підключення до Мережі. Локальний ж репозиторій, куди можна розмістити пакети, викачані завчасно, позбавляє від цієї необхідності.

проблема залежностей

Установка пакетів за допомогою pacman відбувається фантастично швидко. Що, загалом-то, зрозуміло: адже pacman просто розпаковує архів пакету і записує його прекомпілірованние компоненти куди слід. Оскільки ніякої метаінформації в пакеті не міститься, то і відстеження залежностей як би не відбувається.

Проте контроль залежностей в системі управління пакетам Archlinux існує. Ця функція покладена на зовнішню (по відношенню до кожного пакету) базу даних, розташовану в каталозі / var / lib / pacman /. Вона включає в себе два підкаталогу - / var / lib / pacman / current / і / var / lib / pacman / local. У першому - база всіх пакетів, охоплених дистрибутивом Arch Linux (вірніше, офіційної його частиною). Вона утворена каталогами виду pkg-ver-rel (наприклад, bash-2.05b-6 - приводяться нижче приклади ставляться до цього пакету), в кожному з яких є по два файли: desc - короткий опис пакету в формі

і depends - список пакетів, з якими даний пов'язаний залежностями, а також, можливо, конфліктуючих пакетів:

У каталозі / var / lib / pacman / local /. як випливає з його назви, міститься база пакетів, встановлених на даній машині. Він утворений так само, як і / var / lib / pacman / current /. проте в каталозі кожного пакета - вже по три файли: desc. depends і files.

Опис пакета в файлі desc включає, крім короткої інформації (аналогічної опису з current), також дати побудови і установки пакета, ім'я збирача (для офіційної частини їм виступає узагальнений archlinux), і сумарний розмір:

У файлі depends. крім списку пакетів, від яких залежить даний, наведений і список пакетів, які залежать від нього:

Нарешті, files - це просто список всіх компонентів пакета із зазначенням шляхів, за якими вони розміщуються при інсталяції:

В необхідних випадках тут же можна виявити і список файлів, підданих зміни при установці пакету (в першу чергу це відноситься до загальносистемних конфігам), із зазначенням вихідних контрольних сум:

Ця інформація знадобиться при видаленні пакета командою pacman -R - для відновлення первозданної конфігурації системи (саме завдяки їй pacman здатний до «чистої» деінсталяції пакетів).

Зі структури бази пакетів легко зрозуміти принцип контролю залежностей в Archlinux: при установці нового пакету програма pacman спочатку перевіряє каталог / var / lib / pacman / current / на предмет виявлення його залежностей, а потім - каталог / var / lib / pacman / local / на предмет того, чи встановлені пакети, від яких залежить даний. Якщо все в порядку - пакет успішно встановлюється. Якщо ж ні - видається список імен відсутніх пакетів (в порядку, якому вони повинні інсталюватися) і робота pacman 'а завершується повідомленням про помилку. Ніяких спроб вирішити порушення залежностей автоматично він не робить, залишаючи це на частку користувача.

Так що при установці пакету, залежно для якого не виконані, користувач, отримавши відповідний список, повинен самостійно встановити всі відсутні компоненти. Причому з кожним з них можливе повторення історії - тобто порушення залежностей, які повинні вирішуватися вручну.

Така система може здатися не дуже зручною. Хоча це набагато краще, ніж класичний rpm. де при порушенні залежностей видається що-небудь типу недостачі бібліотеки імя_рек.so.1 - і давай обчислюй, до складу якого пакета вона входить. У Archlinux же висновок команди pacman виглядає приблизно наступним чином:

після чого відсутні пакети (разом з необхідним) легко встановити однією командою.

Руки проти автоматики

Проте, в порівнянні з такими як-би «просунутими» системами управління пакетами, як apt або навіть yum. pacman виглядає досить примітивно. Однак це а) не так (бо він не більше ніж додаток до ABS), і б) має свої переваги.

Про ABS мова попереду, а ось про переваги «ручного» підходу pacman (в CRUX прийнята приблизно така ж система, та й pkg-tools з Slackware не сильно від них відрізняється) перед системами типу apt я хотів би поговорити докладніше на увазі їх не повною очевидності .

Однак згадаємо, що залежно пакетів бувають двох родів: обов'язкові, або жорсткі, і не обов'язкові, так би мовити, «м'які». Перші - об'єктивна реальність, яка визначає неодмінність їх виконання: ніяку програму неможливо змусити працювати без glibc (про статичної лінковке тут не говоримо), ніяке X-програма не буде функціонувати без xlib. жодна KDE-софтіна не встане без Qt і kdelibs.

«М'які» ж залежності до виконання не обов'язкові, так як лише забезпечують пакету деякі додаткові функції, корисні, некорисні, а то й відверто шкідливі - причому поняття користі і шкоди тут відверто суб'єктивні. Так, більшість збирачів links або mc вважають неодмінною умовою їх юзабільний підтримку gpm. мені ж використання миші як вказівного пристрою в цих додатках представляється однозначно шкідливим. Я вже не кажу про те, що дозвіл необов'язкових залежностей призводить до захаращення файлової системи компонентами, про які користувач часом не має ні найменшого уявлення (та й мати не бажає).

Так ось, в Archlinux користувач, отримавши попередження про те, що потрібний йому пакет вимагає того-то і того-то, при мінімальному досвіді (і деякому поданні про залежності) може визначити, чи належать нав'язувані йому залежності до числа «жорстких», об'єктивних , або «м'яких», обумовлених суб'єктивними уявленнями збирача пакета. І в другому випадку - усвідомлено зробити вибір:

простоти заради погодитися зі зробленим йому пропозицією (що, правда, призведе до захаращення системи),
відмовитися від задоволення залежностей за допомогою опції nodeps (в цьому випадку є певний ризик того, що пакет не буде функціонувати належним чином - втім, для «м'яких» залежностей ризик цей не дуже великий),
або просто плюнути і зібрати необхідний пакет з початкових кодів вручну - тільки з тими with / without і enable / disable. які йому дійсно потрібні.

Звичайно, ручна збірка теж має свої мінуси. Встановлені крім системи пакетів програми не потраплять в базу даних. І відповідно, якщо в подальшому доведеться встановлювати пакети, що залежать від такого «самосборніка», через систему pacman 'а, то він не буде виявлений останнім.

Втім, якщо розглядати Archlinux як фундамент для побудови власної системи, обмежившись лише компонентами base і все інше збираючи вручну - такий шлях цілком прийнятний. Якщо все ж орієнтуватися на змішане його використання - критично важливі компоненти збираються вручну, всі інші - встановлюються з прекомпілірованние пакетів, - то вихід все одно залишається. Оскільки база даних, яка використовується pacman 'ом, дуже проста, ніхто не забороняє внести в неї відомості про «самозбірних» пакеті вручну (правда, тут немає такого засобу автоматизації цього процесу, як inject в Gentoo).

Втім, все сказане про залежності відноситься тільки до випадку установки пакетів з локального носія. І якщо користуватися репозиторіями пакетів з ftp-сервера проекту або його дзеркал - сили не має. Тому що, як уже було сказано, проста команда pacman -Su виконає повне оновлення системи з дозволом всіх залежностей