Citkit, 30 января 2007 г
Первая версия настоящей статьи была опубликована в журнале LinuxFormat #9(83), 2006, с. 38-39. Ныне вашему вниманию предлагается вторая версия, несколько переработанная и существенно (более чем вдвое) расширенная.
Кроме этого, в журнале Linuxformat #5(79), 2006, с 68-71, была опубликована статья Тихона Тарнавского "Aptitude - превосходная степень apt", подвигшая меня на сочинение настоящего опуса. Тем не менее, по содержанию эти статьи практически не пересекаются.
Одна из отличительных особенностей дистрибутивов семейства Debian - разнообразие средств управления пакетами. Среди них:
- семейство утилит dpkg, предназначенных для манипуляций с единичными deb-пакетами (установки, удаления, реконфигурирования, получения информации, и так далее);
- dselect - интерактивная оболочка над dpkg, обладающая функциями контроля зависимостей;
- семейство утилит apt, запускаемых из командной строки и обеспечивающее полный набор средств управления пакетами;
- программа aptitude - мощное средство контроля над пакетами, работающее как в командном, так и интерактивном режиме;
- synaptic - графическая надстройка для управления deb-пакетами с интерфейсом, основанным на библиотеке Gtk;
- adept - аналогичная предыдущей надстройка, интерфейс которой базируется на библиотеках Qt и kdelibs;
- gnome-apt - также графическая надстройка для управления пакетами, функционирующая в среде GNOME.
Семейство утилит dpkg не обладает способностью контролировать зависимости пакетов - при нарушении оных они прекращают работу с выводом соответствующих сообщений. И, потому, хотя в ряде случаев утилиты эти оказываются удобными, а то и просто незаменимыми (например, dpkg-reconfigure для настройки пакета), использование их ныне ограничено. Интерактивная же надстройка над ними, dselect, в настоящее время практически вышла из употребления - ее функции с успехом перекрываются aptitude.
Графические утилиты управления пакетами, как легко догадаться, оказываются привязанными к определенным наборам графических библиотек (synaptic), а то и к конкретным интегрированным средам (adept и gnome-apt), и потому могут использоваться только в соответствующем окружении.
Таким образом, двумя по настоящему универсальными инструментами пакетного менеджмента оказываются утилиты семейства apt и программа aptitude. В Сети часто можно встретить мнение, что вторая выступает в качестве фронт-энда по отношению к apt-утилитам. Однако насколько можно установить из рассмотрения их зависимостей, это не совсем так: aptitude - независимая от apt программа, просто она основывается на том же наборе библиотек libapt. Так что теоретически говоря, их можно было бы использовать и порознь. Другое дело, что в составе базовой системы Debian и всех его дериватов в обязательном порядке присутствуют и пакет apt (один из многих, входящих в это семейство), и пакет aptitude.
Полный набор утилит apt обеспечивает весь мыслимый комплекс действий с пакетами - от установки единичного пакета с отслеживанием всех его зависимостей (apt-get) до полной пересборки системы из исходников, подобно тому, как это делается в дистрибутивах Source Based. И потому в ряде случаев оказывается незаменимым. Впрочем, основные особенности apt были описаны ранее, и даже составлен подробный FAQ по его использованию.
Программа aptitude не столь универсальна по своему назначению. Функции ее сводятся к установке и удалению пакетов и получению информации о них. Однако и то, и другое она делает не просто хорошо, а очень хорошо. А уж в отслеживании зависимостей и разрешении связанных с ними коллизий, особенно в нетривиальных случаях, она не имеет себе равных. И потому разработчиками Debian она рекомендуется ныне в качестве основного средства для управления пакетами. В документации к дистрибутивам семейства Ubuntu внимание на ней не столь акцентируется - там отдается предпочтение либо традиционному apt, либо графическим утилитам Synaptic или Adept (в зависимости от рабочей среды). Однако и убунтийцам использование aptitude никак не возбраняется.
Программа aptitude работает в текстовом режиме и предполагает два метода использования – интерактивный, через основанный на ncurces интерфейс, и командный - непосредственно из строки шелла.
Тут я должен изложить свое сугубое ИМХО. На мой взгляд, интерактивный режим aptitude требуется в двух случаях:
- на стадии начальной установки системы, например, если в ходе инсталляции ограничиться лишь базовыми компонентами, а такие вещи, как Иксы, десктоп и так далее, устанавливать после выполнения апгрейда базы;
- после массового удаления пакетов, на предмет выявления "осиротевших" их зависимостей, и вообще в нештатных ситуациях.
Для обычной же жизнедеятельности - поиска нужных пакетов, получения информации о них, установки и удаления - aptitude проще использовать в режиме командной строки.
Командный метод использования aptitude не будет непривычен тому, кто знаком с утилитами apt-get и apt-cache: конструкция ее директив предполагает наличие оператора и, для некоторых из последних, также аргумента - имени пакета или ключевого слова.
Особенности aptitude в сравнении с утилитами apt проще всего рассмотреть на примере конкретных командных директив.
Резонные люди обычно начинают работу с пакетами поиском нужного для установки пакета. В случае с aptitude это делается так:
$ aptitude search keyword
ответом на что будет список всех пакетов, в названии или описании которых имеется указанное ключевое слово, с краткой характеристикой. Почти как в apt, но вывод aptitude содержит информацию о текущем состоянии пакета. Например, в одной из предыдущих заметок мы использовали aptitude для поиска драйверов nvidia, после чего успешно их установили. То есть поиск по ключевому слову nvidia:
$ aptitude search nvidia
даст примерно следующую картину:
i nvidia-glx - NVIDIA binary XFree86 4.x/X.Org driver
p nvidia-glx-dev - NVIDIA binary XFree86 4.x/X.Org driver de
p nvidia-glx-legacy - NVIDIA binary XFree86 4.x/X.Org 'legacy'
p nvidia-glx-legacy-dev - NVIDIA binary XFree86 4.x/X.Org 'legacy'
v nvidia-kernel-1.0.7184 -
v nvidia-kernel-1.0.8774 -
v nvidia-kernel-1.0.9629 -
v nvidia-kernel-1.0.9631 -
i A nvidia-kernel-common - NVIDIA binary kernel module common files
i nvidia-kernel-source - NVIDIA binary kernel module source
p nvidia-legacy-kernel-source - NVIDIA binary 'legacy' kernel module sour
p nvidia-settings - Tool of configuring the NVIDIA graphics d
p nvidia-xconfig - The NVIDIA X Configuration Tool
Очень похоже на вывод команды
$ apt-cache search nvidia
не так ли? Отличие - в крайней левой колонке, уже за наличие которой aptitude можно предпочесть apt-утилита. Литеры, в ней стоящие, маркируют статус пакета - основной (левый символ) и, возможно, дополнительный (второй символ). Значения основного статуса следующие:
- i (от installed) - пакет установлен в системе:
- p (от purge) - пакет не был установлен или был удален "вчистую" (как - будет говориться далее);
- c (от clean) - пакет, удаленный с сохранением конфигурационных файлов;
- v (от virtual) - т.н. виртуальные пакеты, то есть просто списки реальных пакетов, один из которых будет использоваться в той или иной ситуации.
Дополнительный статус пакета может принимать такие значения:
- A (от Auto) - пакет был установлен не самостоятельно, а автоматически, как зависимость другого пакета;
- h (от hold) - для пакета зафиксирована его текущая версия, то есть он не будет обновляться при выполнении операторов upgrade и dist-upgrade (см. ниже);
- u (от unpacked) - пакет был получен, распакован, но не инкорпорирован в файловую систему и не сконфигурирован;
- C (от half-Configured) - пакет, установка которого оборвалась на стадии конфигурирования;
- H (от Half-installed) - пакет, установка которого оборвалась на стадии инсталляции;
- B (от Broken) - т.н. "сломанные" пакеты - то есть содержащие ошибки внутри себя или утратившие свои зависимости.
Обращаем особое внимание на пакеты, имеющие дополнительный статус A: именно его наличие позволит нам в дальнейшем эффективно выполнять "чистку" системы.
Следующий этап применения aptitude - получение информации о тех пакетах, которые можно заподозрить в полезности. Этой цели служит оператор show, требующий аргумента в виде имени пакета. Так, в ходе поиска драйвера нам потребовалось получить подробную информацию о ряде пакетов, например:
$ aptitude show nvidia-kernel-source
выведет примерно следующие данные:
- Package: nvidia-kernel-source - имя пакета;
- State: installed - установлен ли пакет, как в данном примере, или нет (not installed);
- Automatically installed: no - установлен ли пакет автоматически, как зависимость другого пакета (A) или самостоятельно (как в данном примере);
- Version: 1.0.9631+2.6.20.1-6 - номер версии и сборки;
- Priority: необязательный - приоритет;
- Section: multiverse/misc - категория (main, restrited и так далее, см. заметку о репозиториях) и секция;
- Maintainer: Ubuntu Kernel Team - майнтайнер дистрибутивного пакета;
- Uncompressed Size: 1978k - объем в распакованном виде;
- Depends: debhelper (> 4.0.0), make, sed (> 3.0), dpatch (>= 2.0.0) - жесткие, то есть обязательные, зависимости;
- Recommends: nvidia-glx (>= 1.0.9631), kernel-package (>= 8.082), devscripts - настоятельно рекомендуемые "мягкие" зависимости;
- Suggest - "мягкие" зависимости, предлагаемые в меру настойчиво (в примере отсутствуют);
- Conflicts: nvidia-kernel-src -конфликтующие пакеты;
- Replaces: nvidia-kernel-src - пакеты, которые будут заменены данным пакетом;
- Description: описание пакета, обычно в один абзац.
Очевидно, что все операторы команды aptitude, служащие получению информации о пакетах, могут выполняться от лица обычного пользователя. Следующие же операторы требуют уже привилегий администратора - то есть должны запускаться от лица root-оператора или, как это принято в дистрибутивах семейства Ubuntu, их следует временно получить посредством команды sudo.
Установка выбранных пакетов осуществляется посредством оператора install, требующем в качестве аргумента имени пакета:
$ sudo aptitude install pkg_name
При этом происходит просмотр репозиториев, перечисленных в соответствующем конфигурационном файле (файл этот - то же, что и для утилит семейства apt, то есть /etc/apt/source.list; о его настройке будет говориться в одной из ближайших заметок), и, при необходимости, скачивание deb-пакета из Сети, помещение его в локальный кэш пакетов (каталог /var/cache/apt/archives), распаковка архива, инкорпорация его компонентов в файловую систему и, при необходимости, выполнение действий по настройке, автоматически или, если требуется, в интерактивном режиме.
При разрыве связи во время скачивания пакета его уже полученный фрагмент помещается в каталог /var/cache/apt/archives/partial/, и повторение процедуры install продолжает докачку с места обрыва.
Оператор install команды aptitude, в отличие от одноименного из apt-get, получает из репозитория, помещает в локальный кэш, устанавливает и настраивает не только "жесткие" зависимости пакета (собственно depends), но и часть "мягких" (те, что относятся к категории recommends). На усмотрение пользователя остается только установка "мягких" зависимостей из категории suggest (то есть "предложений" оператора show). Хотя, как мы увидим далее, такое положение можно изменить.
Установка версий пакетов осуществляется в соответствие с описанием их локального кэша. Каковой время от времени (а также после подключения дополнительных репозиториев) нуждается в обновлении. Это осуществляется посредством оператора update, в аргументах не нуждающегося.
Пакет, «испорченный» по какой-либо причине (например, неаккуратным вмешательством в конфигурационные файлы) можно «починить». Команда
$ sudo aptitude reinstall pkg_name
вернет его в первозданное состояние.
Установленные пакеты, оказавшиеся не нужными, могут быть удалены. Директива
$ sudo aptitude remove pkg_name
удалит указанный в качестве аргумента пакет с сохранением его конфигурационных файлов. Именно такая ситуация и маркируется литерой c в выводе команды aptitude search. Полная же очистка системы от всех следов пакета достигается оператором purge:
$ sudo aptitude purge pkg_name
В этом случае пакет в выводе команды aptitude search маркируется литерой p, то есть становится неотличимым от пакета, которого в системе никогда не было. Однако оператор purge не удаляет конфигурационные файлы пакета из домашнего каталога пользователя - это придется проделать самостоятельно.
Можно удалить сразу несколько пакетов. Для этого не всегда нужно перечислять их в качестве аргументов оператора remove или purge. В некоторых случаях можно прибегнуть к удалению по маске, то есть к конструкции типа
$ aptitude purge ’~nvidia’
В данном примере будут бесследно удалены все пакеты, имеющие компонент nvidia в своем имени.
Важно, что оба оператора удаления - и remove, и purge, - деинсталлируют не только пакет, указанный в качестве аргумента, но и все те, которые были установлены автоматически в качестве его зависимостей - разумеется, только в том случае, если в системе не осталось других программ, которые от них зависят. Уже одно это является веским аргументом в пользу предпочтения aptitude перед классическими инструментами apt.
Программа aptitude позволяет выполнить и тотальное обновление системы - этой цели служат операторы upgrade и dist-upgrade. Как и в apt-get, первый обновит все установленные пакеты в том случае, если это не влечет за собой новых, противоречащих наличным, зависимостей. Оператор же dist-upgrade выполнит принудительное обновление системы. В обоих случаях удалению подвергнутся также автоматически установленные пакеты, от которых больше ничего не зависит.
Важно, что пакеты, имеющие статус h (то есть фиксированной версии), не подвергнутся обновлению ни при выполнении оператора upgrade, ни при dist-upgrade. Фиксация же версии выполняется посредством оператора hold, аргументом которого выступает имя пакета. Снять фиксацию версии можно с помощью оператора keep и того же аргумента.
Как и при выполнении оператора install, процедуры upgrade и dist-upgrade безболезненно переживают разрыв связи (или, например, прерывание по нажатию клавишной комбинации Control+C): повторный их запуск возобновляет установку с момента прерывания.
Позволяет aptitude избавиться и от промежуточных продуктов собственной жизнедеятельности - скачанных из Сети deb-архивов; для этого предназначены операторы clean и autoclean. Первый просто удалит из локального кэша все deb-пакеты, скачанные в процессе действия программы aptitude, то есть очистит каталог /var/cache/apt/archives. Оператор же autoclean удалит deb-файлы только тех пакетов, которые ныне не установлены в системе (то есть устаревшие - при регулярном употреблении операторов update, upgrade и dist-upgrade их может накопиться изрядное количество).
И, наконец, еще пара операторов, не имеющих аналогов в инструментарии apt: markauto и unmarkauto. Первый помечает пакет или их группу как установленные автоматически в качестве зависимостей. Так, командой
$ sudo aptitude markauto ’~slibs’
в качестве автоматически установленных (статус A) будут помечены все пакеты с компонентом libs в имени - то есть практически все библиотеки. Следствием чего явится автоматическое удаление неиспользуемых библиотек после деинсталляции последнего зависимого от них пакета.
Если же для некоторых библиотек это по каким-либо причинам нежелательно, их можно "размаркировать" командой
$ sudo aptitude unmarkauto pkg_name
переведя таким образом в категорию пакетов, установленных собственноручно. И, следовательно, могущих быть удаленными только явным образом.
Кроме операторов, командная директива aptitude предусматривает использование опций. Они весьма многочисленны, но не обязательны, и потому я остановлюсь только на самых, с моей точки зрения, интересных и полезных. Более подробные сведения об опциях можно получить посредством
$ man 8 aptitude
Ранее уже говорилось, что по умолчанию при использовании aptitude с любыми операторами инсталляции устанавливаемый пакет тянет за собой не только "жесткие", обязательные, зависимости, но и изрядную часть "мягких" - тех, которые майнтайнер пакета посчитал нужным включить в категорию recommends. Что не всегда желательно.
Избежать принудительного выполнения "рекомендаций" можно с помощью опции -R, данной в командной директиве установки конкретного пакета. Если же игнорирование "рекомендаций" требуется всегда - это можно будет запечатлеть в конфигурационном файле. Как именно - будет сказано чуть ниже. Пока же допустим, что мы уже изменили умолчальное поведение aptitude - теперь операторы инсталляции учитывают только "жесткие" (depends) зависимости.
Однако для некоторых пакетов все же желательно установить все рекомендуемые зависимости - например, в случае малознакомых пакетов, с которыми просто лень разбираться. В этом случае можно прибегнуть к опции -r (--with-recommends), которая инвертирует действие опции -R - то есть заставит установить все рекомендуемые зависимости.
Должен предупредить: применение опции -R к установленной системе Ubuntu/Kubuntu требует осторожности. Базовая ее инсталляция осуществляется по принципу "плюс recommends". И применение к ней aptitude -R делает как бы "ненужными" многие пакеты. Одни из них - действительно (на мой взгляд) лишние. Однако в "черный список" могут попасть и нужные пакеты, вплоть до метапакета, определяющего среду дистрибутива - ubuntu-desktop, kubuntu-desktop или xubuntu-desktop (для дистрибутивов Ubuntu, Kubuntu и Xubuntu, соответственно). Удаление же их повлечет деинсталляцию всех компонентов соответствующих рабочих сред.
Так что перед тем, как нажать
Хотите продолжить? [Y/n/?]
внимательно прочтите весь предшествующий ему вывод. Впрочем, привычка читать вывод перед тем, как "давить батоны", не будет лишней при работе с любой программой...
Тем не менее, вполне возможно, что по разрешении указанных противоречий, опцию -R все же захочется сделать умолчальной. Для этого нужно внести изменения в конфигурационные файлы aptitude. Вообще-то aptitude обращается к тем же конфигам, что и apt (/etc/apt/sources.list, /etc/apt/apt.conf),однако имеет и собственный - ~/.aptitude/config. По умолчанию он пуст, но может быть отредактирован по потребностям. В частности, для придания опции -R статуса по умолчанию, в этот файл следует внести такую строку:
aptitude::Recommends-Important "false";
К слову сказать, можно, напротив, сделать так, чтобы при установке пакета автоматически инсталлировались также и "предлагаемые" (suggest) зависимости. Это достигается строкой
aptitude::Suggests-Important "true";
Вообще-то опций конфигурирования для aptitude предусмотрено великое множество - и многие из них применимы не только к командному, но и к интерактивному режиму, позволяя настроить внешний вид интерфейса и многое другое. Ознакомиться с полным набором опций конфигурирования aptitude и их умолчальными значениями можно в официальной документации - она включена в состав дистрибутива и находится в каталоге /usr/share/doc/aptitude/html/{lang}/. Здесь под {lang} подразумевается язык документа - кроме английской (en) версии, в репозитории Ubuntu существуют переводы его на французский, финский и чешский языки; кстати, в репозитории Debian русской версии этого документа также не обнаруживается. А текущие настройки можно посмотреть в файле /usr/share/aptitude/aptitude-defaults.
В общем, после знакомства с aptitude можно сделать вывод, что она предоставляет все возможности, обеспечиваемые утилитами apt-get и apt-cache плюс ряд дополнительных, подчас неоценимых, удобств, позволяющих, в частности, содержать пакетное хозяйство в стерильной чистоте. И потому использование ее в командном режиме предпочтительно перед указанными средствами комплекта apt.
Правда, тут я хотел бы отметить: совместное использование aptitude и apt видится мне нежелательным. То есть, по завершении настройки aptitude и приведении пакетного хозяйства с соответствие с ними к командам apt-get и apt-cache лучше не прибегать. Команда же apt-cache будет выдавать информацию в соответствие с настройками aptitude, а не умолчаниями apt – в частности, зависимости в выводе apt-cache show будут показываться так, как они описаны в файле ~/.aptitude/conf.
Что же до интерактивного режима aptitude, требующего запоминания многочисленных горячих клавиш, то его повседневное использование - сугубо на любителя. Однако в некоторых случаях - например, при чистке системы от секционных групп пакетов - он оказывается незаменимым. И именно в этом аспекте будет рассмотрен в следующей заметке.
В заключение я хотел бы выразить признательность Тихону Тарнавскому, благодаря которому я преодолел скептическое отношение к этой замечательной программе.
Сообщения
