Алексей Федорчук aka Alv
Работа с пакетами. Введение
Работа с пакетами предполагает следующие действия — их установку с занесением в локальную базу данных, отслеживание зависимостей (и иногда их разрешение) обновление, удаление, получение информации о пакетах, иногда конфигурирование. Инструментарий для работы с пакетами можно разделить на четыре группы:
- установщики пакетов;
- оболочки для них;
- менеджеры пакетов;
- их графические фронт-энды;
- центры приложений.
Первая группа — это низкоуровневые утилиты для работы с единичными пакетами: их установки, удаления, etc. В нашем случае эту роль выполняет семейство утилит dpkg. Отслеживание зависимостей здесь выполняется на уровне удовлетворения или неудовлетворения, попыток автоматического разрешения зависимостей не предпринимается. Семейство это не уникально для Mint, а присутствует во всех дистрибутивах, использующих deb-формат пакетов.
Оболочки для установщиков пакетов выполняют те же самые функции, что и они сами, но посредством не прямых команд, а графического интерфейса. В Mint такой оболочкой для dpkg является Gdebi.
Менеджеры пакетов работают уже не с единичными пакетами, а с их репозиториями. И, кроме перечисленных функций, их непременной обязанностью является не только отслеживание зависимостей, но и их автоматическое, по возможности, разрешение. В Mint, как и в большинстве deb based дистрибутивов, эту роль выполняет семейство утилит APT, ныне главным образом в лице интегрированной команды apt.
Четвёртая группа — графические фронт-энды для менеджеров пакетов. В Mint она представлена программой Synaptic.
Что же касается пятой группы — это самые высокоуровневые программы, в которых прозрачно для применителя интегрированы функции поиска пакетов в Сети, доступа к содержащим их репозиториями и собственно пакетный менеджмент. Название её заимствовано от Центра приложений Ubuntu — первого представителя этой группы. В Mint её аналогом выступает Менеджер программ, о котором говорилось в очерке про фирменные утилиты этого дистрибутива. Остальные же инструменты работы с пакетами будут рассмотрены в ближайших очерках.
Установка пакетов
Установщик пакетов dpkg
Утилиты семейства dpkg, предназначенные для работы с единичными deb-пакетами, были исторически первым средством автоматического развертывания пакетов, учитывающим их зависимости. Они лежат в фундаменте всех надстраивающих их систем (apt, synaptic, mintinstall. В ряде случаев dpkg оказывается наиболее простым средством для установки или удаления пакета, а также получения информации о нем. Кроме того, одна из утилит семейства, dpkg-reconfigure, с которой мы сталкивались во время доводки текстовой консоли, оказывается незаменимой при настройке пакетов установленных.
Вообще, возможности утилит семейства (см. man (1) dpkg) очень широки, и потому заслуживают рассмотрения, хотя бы в минимально необходимом для применителя объеме. Наиболее употребимы из них — следующие:
- собственно
dpkg— средство для установки и удаления программ; dpkg-query— инструмент создания запросов к базе данных deb-пакетов;dpkg-reconfigure— программа для настройки установленных пакетов.
А вообще это семейство включает в себя около 25 утилит — полный их список можно просмотреть таким образом:
ls /usr/sbin/dpkg* /usr/bin/dpkg* -1 | wc
Утилиты эти входят в состав пакетов dpkg и dpkg-dev; первый, предназначенный для основных действий с бинарными пакетами, устанавливается по умолчанию в ходе первичной инсталляции; второй же, включающий утилиты для манипуляции с пакетами исходников, должен быть установлен дополнительно (или устанавливается как зависимость, например, при инсталляции пакета apt-build).
Для начала рассмотрим установку пакетов. Итак, если нам необходимо установить единичный пакет, поступаем так:
$ dpkg -i path2/packagename.deb
и дело в шляпе — через считанные мгновения пакет packagename.deb будет установлен: это обеспечивает опция -i (от install) вслед за командой dpkg. Дабы в дальнейшем не повторяться, замечу, что все действия по установке и удалению пакетов требуют полномочий администратора, приобретаемых временно командой sudo.
Разумеется, успешной установка пакета будет только при соблюдении следующих условий:
- физическом наличии его в пределах досягаемости с локальной машины (на подключенной файловой системе, смонтированном компакт-диске или ином носителе);
- знании точного пути (
path2) к нужному файлу пакета (имя его, кстати, должно быть указано полностью); - отсутствии неудовлетворенных зависимостей.
Из первого условия следует, что dpkg удобно использовать при доустановке компонентов с инсталляционного CD/DVD (или установке заблаговременно скачанных пакетов). Второе условие самоочевидно. Ну а третье также выполнимо без особого труда: в случае нарушения зависимостей dpkg выдаст сообщение об ошибке с полным перечнем того, что нужно установить для ее устранения, причем в списке будут перечислены только обязательные зависимости. И достаточно все необходимые пакеты поместить в командную строку:
$ sudo dpkg -i path2/packagename1.deb … path2/packagename#.deb
для того, чтобы они были установлены единой операцией (если, конечно, все эти пакеты имеются в наличии).
Другое часто требующееся применение команды dpkg — удаление ненужных пакетов. Это делается двояко: команда
$ sudo dpkg -r packagename
удалит пакет, но сохранит настроечные его файлы, а команда
$ sudo dpkg -P packagename
произведет полную очистку системы от всех компонентов пакета (кроме конфигурационных файлов в домашнем каталоге пользователя — от них в любом случае придется избавляться вручную). Правда, только если он не связан зависимостями с другими пакетами — в этом случае последует сообщение о невозможности удаления пакета и выведен список его зависимостей, этому препятствующих.
Обратим внимание — в аргументах обеих команд фигурирует уже не полное имя пакета, а только его значимая часть. Это распространяется на все случаи использования dpkg (и других команд ее семейства), когда речь идет об уже установленных пакетах.
Следующая сфера деятельности команд семейства dpkg — получение информации о пакетах. И здесь первое дело — это получение списка пакетов, установленных в системе:
$ dpkg -l
Что в моей системе даёт примерно такой вывод:
ii accountsservice 0.6.35-0ubuntu7.1 amd64 query and manipulate user account information ii acl 2.2.52-1 amd64 Access control list utilities … ii zsh 5.0.2-3ubunt amd64 shell with lots of features ii zsh-common 5.0.2-3ubunt all architecture independent files for Z ii zsh-doc 5.0.2-3ubunt all zsh documentation - info/HTML format ii zsh-lovers 0.8.3-0ubunt all tips, tricks and examples for the zs
До появления интегрированной утилиты apt команда dpkg -l была чуть ли не единственным способом получения списка установленных пакетов. Или, по крайней мере, самым простым.
Для уже установленных пакетов информацию о них проще всего получить с помощью команды dpkg-query, требующей указания какого-либо из операторов действия и имени пакета в качестве аргумента. Операторы действия команды dpkg-query можно вывести так (поскольку получение информации о пакетах никак не влияет на систему в целом, необходимости в правах администратора тут не возникает):
$ dpkg-query --help
Они следующие:
-sили--status— вывод детального статуса пакета, включающий:- имя пакета, собственно статус (установлен ли он) и приоритет;
- секция репозитория, к которой пакета относится (например,
editors— для текстовых редакторов); - размер пакета в установленном виде;
- имя майнтайнера, архитектура, для которой пакет собран, и номер версии;
- описание зависимостей и конфликтов;
- краткое (в один абзац) описание пакета.
-pили--print-avail— практически то же самое, но в форме, приспособленной для печати;-lили--list— тоже своего рода описание статуса, включающее сведения о том, установлен ли пакет, нуждается ли он в обновлении, нет ли ошибок в его настройке, и так далее;-Wили--show— просто вывод номера версии в форме:$ dpkg-query -W nano nano 1.3.8-2
-Lили--listfiles— полный список файлов, относящихся к данному пакету, в форме:/. /etc /etc/nanorc /usr /usr/share /usr/share/doc /usr/share/doc/nano …
и так далее (пример для текстового редактора nano);
-Sили--search— поиск пакета, к которому относится некий файл, указанный в качестве аргумента; может выполнить и обратную задачу — поиск всех файлов, принадлежащих данному пакету, вывод в этом случае оказывается аналогичнымdpkg-query -L.
Повторю, что все сказанное о информации по пакетам, относится к пакетам уже установленным. Для получения же сведений о неустановленных пакетах удобнее использовать графическую оболочку GDebi, о которой будет говориться в следующем разделе.
Еще одна важная задача утилит dpkg — выполнение настройки отдельных, уже установленных, пакетов. Предназначенная для этого команда так и называется — dpkg-reconfigure, и запускается таким образом:
$ sudo dpkg-reconfigure packagename
После этого вызывается диалоговая программа конфигурации — debconf, и ответы на серию более или менее тривиальных вопросов позволяют добиться желаемого результата. Каковы эти вопросы — зависит от настраиваемой программы. В частности, ранее dpkg-reconfigure была использована для настройки экранных шрифтов в консоли.
Установщик пакетов GDebi
GDebi представляет собой графический фронт-энд для утилиты dpkg. Она разработана фирмой Canonical специально для Ubuntu и потому, естественно, имеется и в Mint (о котором далее и пойдёт речь). Запустить GDebi можно из секции Администрирование главного меню Cinnamon — но тогда придётся обратиться к пункту File -> Open её меню, и потом долго рыскать по файловому древу в поисках нужного имени. Так что более простой способ её запуска — клик на имени deb-файла в файловом менеджере Nemo. Что представит такую картинку:
Самая ценная информация здесь — это список файлов, входящих в состав пакета. В отличие от Synaptic’а, о котором речь пойдёт со временем, GDebi выводит его даже для не установленных пакетов:
В случае, если в пакете всё устраивает, он устанавливается нажатием одноимённой кнопки, что сначала потребует авторизации, а затем незамедлительно начинается установка:
Проверка зависимостей, естественно, осуществляется как и в dpkg — на уровне удовлетворённости или неудовлетворённости. В последнем случае выводится сообщение о том, какие пакеты следует установить для их разрешения. По завершении установки картинка становится такой:
Удаление пакета выполняется тем же образом: авторизация и собственно удаление:
И завершается возвращением исходной картинки. Если от удаляемого пакета зависит какой-либо другой, то опять же последует сообщение об ошибке:
Никаких преимуществ против консольного бак-энда, то есть собственно dpkg, я в GDebi не усмотрел — кроме разве что наглядности. Для установки большого количества пакетов она оказалась неудобной из-за необходимости авторизоваться на каждый такой чих — при использовании dpkg это можно решить один раз командой
$ sudo -i
А самая востребованная сфера применения GDebi — установка единичного, не отягощённого завимисостями, пакета на предмет «поиграться и стереть». Но в этом отношении ей нет равных…
Утилита apt
Этот очерк посвящается Mint-спецфичному средству управления пакетами — утилите apt. Которую не следует путать ни а одноимённым пакетом, имеющимся во всех deb based дистрибутивах, ни с входящей в него с недавних пор командой apt — как будет показано далее, это очень много больших разниц. Ибо Mint’овская
Утилита apt: введение
Основным средством управления пакетами во всех дистрибутивах deb based в настоящее время являются утилиты семейства Apt. Ранее наряду с ними широко применялась утилита aptitude, используемая в некоторых дистрибутивах и по сей день (а также обычно устанавливаемая по умолчанию). Однако она давно не развивается, и постепенно становится достоянием истории, особенно в Mint — причины чего скоро станут ясны.
До недавнего времени самыми востребованными прменителем утилитами семейства были apt-cache и apt-get, предназначенные для получения информации о пакетах и манипулирования оными, соответственно. Именно их использование подразумевается в большинстве примеров работы с пакетами, которые можно найти в Сети.
Но в апреле 2014 года разработчики проекта Debian выпустили релиз пакета Apt 1.0, в состав которого вошла одноимённая утилита apt, частично перекрывающая функционал их обеих. Она была немедленно освоена во всех deb based дистрибутивах, хотя никто не запрещает по прежнему использовать apt-cache и apt-get, тем более что возможности их гораздо шире, нежели может предложить apt.
В Mint также имеется пакет apt, включающий утилиты apt-cache, apt-get и даже та самая новая apt. Однако в этом дистрибутиве используется собственная реализация утилиты apt, которая включает не только все возможности старых утилит, но и многие функции командного режима aptitude, ряд возможностей низкоуровневой команды dpkg, а также собственные дополнительные фичи. Именно эта, Mint-спецфичная утилита apt, и будет героиней настоящего очерка.
Для начала надо разобраться со всеми многочисленными apt‘ами, в частности, двумя одноимёнными утилитами одного практически назначения. Как различать их между собой?
В отличие от утилиты apt из пакета того же имени, наша героиня входит в состав пакета mintsystem, в чём мы скоро убедимся с помощью её самой. А пока определим путь к её исполняемому файлу командой which:
$ which apt /usr/local/bin/apt
Путь же к утилите apt из пакета apt — такой:
$ ls /usr/bin/apt
В том, что это абсолютно разные исполняемые файлы, легко убедиться, сравнив их идентификаторы (так называемые inode):
$ ls -i /usr/bin/apt 4058 /usr/bin/apt* $ ls -i /usr/local/bin/apt 139077 /usr/local/bin/apt*
Если набрать в командной строке apt без указания пути, то всегда будет запущена вторая команда. Как они не путаются между собой? Благодаря определению переменной PATH в общесистемном конфиге /etc/login.defs, значения которой можно посомотреть таким образом:
$=> echo $PATH /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
То есть команда apt сначала ищется в каталоге /usr/local/bin, где благополучно находится и запускается. Для запуска же «двойника» требуется указание полного пути:
$ /usr/bin/apt
Впрочем, во избежание путаницы, о «двойнике» лучше просто забыть — тем более, что наша героиня далеко превосходит его по функционалу.
И так, утилита apt запускается просто одноимённой командой, сопровождаемой субкомандами, определяяющими цель операции, и аргументами, в качестве которых выступают имена пакетов, хотя некоторые субкоманды аргументов не требуют.
Разумеется, имеются у команды apt и опции, из которой в обыденной жизни достаточно одной — --help или -h, после которой не требуется ни субкоманд, ни аргументов — она выведет краткую (но, тем не менее, в большинстве случаев достаточную) справку по использованию утилиты:
$ apt --help
apt
Usage: apt command [options]
apt help command [options]
Commands:
autoclean - Erase old downloaded archive files
…
upgrade - Perform a safe upgrade
version - Show the installed version of a package
This apt has Super Cow Powers
Впрочем, и в опции --help нет необходимости: тот же результат достигается, если дать команду apt без опций и аргументов.
Кстати, последняя строка вывода apt --help, утверждающая о наличии в данной версии apt некоей коровьей суперсилы, может вызвать вызвать надежды на нечто необыкновенное. Надежды эти легко претворить в жизнь командой:
Которая эту самую суперсилу и вызовет вот в таком виде:
рис apt-moo
Кроме опции --help, утилита apt имеет и субкоманду help, аргументом которой выступает любая из прочих субкоманд. Впрочем, она ориентирована исключительно на тех, кто привык к старым утилитам apt-cache, apt-get и aptitude, ибо вывод её выглядит следующим образом:
$ apt help search "apt search" is equivalent to "aptitude search"
Или:
$ apt help install "apt install" is equivalent to "sudo apt-get install"
В системе можно найти и стандартную страницу от тёти Мани — man (8) apt. Однако толку от неё не много: она относится не к нашей утилите apt, а к своей тёзке из более иных deb based дистрибутивов, таких, как Ubuntu и сородичи. Так что полагаться надо не на неё, а на экранную подсказку. А за деталями, касающимися отдельных функций, обращаться к man (8) apt-cache и man (8) apt-get — как я уже говорил, наша утилита практически полностью перекрывает функционал их обеих
Субкоманды утилиты apt разделяются на две группы, служащие различным целям — получению информации о пакетах, для которых достаточно прав обычного пользователя, и манипулированию ими, что требует прав администратора. Однако обратим внимание на второй пример использования субкоманды help. Он показывает, что утилита apt позволяет не утруждать себя воспоминаниями о необходимости ввода команды sudo: при указании любой её субкоманды, связанной с манипулированием пакетами и потому требующей прав администратора, запрос пароля последует автоматически:
$ apt install geany [sudo] password for alv:
Кстати говоря, это — уникальная особенность Mint’овского apt, «обычный» apt для манипуляций с пакетами обязательно должен в явном виде предваряться командой sudo.
Тем не менее, хотя «правовые» группы субкоманд утилиты apt скрыты от применителя, субкоманды эти целесообразно рассмотреть в соответствие с ними. А поскольку, прежде чем манипулировать пакетами, желательно иметь о них какие-никакие сведения, начать имеет смысл с «информационной» группы.
Утилита apt: «информационные» субкоманды
Первая операция, с которой сталкивается применитель при работе с пакетами — поиск нужного пакета. Этой цели служит субкоманда search с указанием в качестве аргумента ключевого слова, которым может быть имя пакета или его фрагмент, а также слово из краткого описания пакета. Выводом будет список подходящим пакетов, сопровождаемый тем самым кратким описанием. Например, для пакета zsh это выглядит так:
$ apt search zsh … p fizsh - Friendly Interactive ZSHell i zsh - командная оболочка с большим набором возмо p zsh:i386 - командная оболочка с большим набором возмо … i zsh-doc - Документация к zsh - формат info/HTML i zsh-lovers - Полезные советы и примеры для zsh p zsh-static - shell with lots of features (static link) p zsh-static:i386 - shell with lots of features (static link) p zshdb - отладчик сценариев оболочки Zsh
Обращаю внимание — в выводе, кроме всего прочего, содержится информация о состоянии пакета: i — установленный, p — не установленный или «чисто» удалённый, c — удалённый с сохранением конфигов (в чём разница — расскажу позднее). Этой мелочи так не хватало в старом apt-cache search — она, в частности, позволяет вывести список всех установленных пакетов с помощью такой конструкции:
$ apt search * | grep \^i … i libindicator7 - panel indicator applet - shared library i A libintl-perl - Uniforum message translations system compa i liblockfile-bin - механизм блокирования на основе lock-файло i A libmusicbrainz3-6 - library to access the MusicBrainz.org data i libnotify-bin - отправка уведомлений рабочего стола службе …
В некоторых строках во второй колонке можно видеть символ A. Он показывает, что данный пакет был установлен автоматически, как зависимость какого-либо другого пакета.
Поиск пакетов происходит не в мировом масштабе, а только в подключённых репозиториях, как официальных, так и дополнительных. Причём иногда он может вывести пакеты если не с одинаковыми, то с похожими именами из разных источников. Так. у меня в системе установлена Opera 26.0 из репозитория разработчиков. И этот же пакет, версии 12.16, имеется в extra-репозитории Mint. И потому вывод команды
$ apt search opera
будет таким:
p opera - Fast and secure web browser and Internet s p opera:i386 - Fast and secure web browser and Internet s c opera-beta - Fast and secure web browser p opera-developer - Fast and secure web browser p opera-next - Fast and secure web browser and Internet s p opera-next:i386 - Fast and secure web browser and Internet s i opera-stable - Fast and secure web browser
Как тут определить, кто есть who? В данном случае (в том числе и) этой цели послужит субкоманда show: с именем пакета в аргументе она выведет подробные сведения о пакете. Для просто opera они будут выглядеть так:
$ apt show opera Пакет: opera Состояние: не установлен Версия: 12.16.1860-1linuxmint Приоритет: необязательный Раздел: non-free/web …
А для opera-stable — иначе:
$ apt show opera-stable Новый: да Состояние: установлен Автоматически установлен: нет Версия: 26.0.1656.60 Приоритет: необязательный Раздел: non-free/web …
В выводе субкоманды show имеется и другая информация — о жёстких и некоторых прочих зависимостях, конфликтующих пакетах, и так далее, а также описание пакета, более подробное, чем резюме. Важно, что вся она доступна как для установленных пакетов, так и для пакетов, имеющихся в репозиториях, но не установленных.
Очень часто возникает задача определения состава пакета — входящих в него файлов и путей к ним. Она решается с помощью субкоманды content. Например, для пакета zsh это будет выглядеть так:
$ apt content zsh [~] /. /bin /bin/zsh5 /usr /usr/lib /usr/lib/x86_64-linux-gnu /usr/lib/x86_64-linux-gnu/zsh …
Иногда требуется и решение обратной задачи — определения, в какой пакет входит некий — файл исполняемый бинарник или, чаще, библиотека. На сей предмет существует субкоманда contains. Именно с её помощью мы сейчас и определим, в состав какого пакета входит сама утилита apt. Однако если сделать это прямо в лоб, командой
$ apt contains apt
на выходе будет несколько экранов пакетов и файлов, содержащих последовательность символов apt в своём имени. Поэтому конкретизируем запрос, вспомнив полный путь к исполняемому её файлу и
И теперь подставим вывод её как аргумент предыдущей команды:
$ apt contains /usr/local/bin/apt mintsystem: /usr/local/bin/apt
Что и убеждает нас, что утилита apt в ходит в состав пакета mintsystem. А не одноимённого ей, как можно было бы ожидать — хотя и он в системе имеется, включая в себя, в частности, утилиты apt-cache и apt-get.
Обе последние субкоманды, и content, и contains, работают только для установленных пакетов.
А вообще-то для определения зависимостей существует специальная пара субкоманд — depends и rdepends. Первая выводит полный список зависимостей пакета, который задан в качестве её аргумента, например:
$ apt depends zsh
zsh
Зависит: libc6
Зависит: libcap2
Зависит: libtinfo5
Зависит: zsh-common
ПредЗависит: dpkg
dpkg:i386
Предлагает: zsh-doc
Рекомендует: libncursesw5
Рекомендует: libpcre3
Конфликтует: zsh:i386
Вторая же выведет список «обратных» зависимостей, в том числе и пакетов
$ apt rdepends zsh zsh Reverse Depends: zsh:i386 zshdb zsh-static zsh-beta zomg zec shellex shell-fm flowscan fizsh |draai autojump zsh-dbg zsh-common zsh-common zsh-common
Таким образом, можно видеть, что по части получения информации о пакетах Mint’овская утилита apt далеко превосходит как свой прототип, так и apt-cache, соответствуя скорее возможностям командной aptitude. Единственное, о чём можно пожалеть — так это об отсутствии субкоманды list, выводящей списки доступных, установленных и обновляемых пакетов. Но, как говорил Кот Бегемот, нет в жизни совершенства. Тем более что, как было показано, эту задачу таки можно решить средствами нашей apt. Да и dpkg -l пока не отменили.
Утилита apt: «манипуляционные» субкоманды
После того как нужный пакет был обнаружен с помощью субкоманды search, и его нужность была подтверждена просмотром вывода субкоманды show, его остаётся только установить — для этого предназначена субкоманда install, воспинимающая в качестве аргемента имя пакета, например:
$ apt install pepperflashplugin-nonfree
Напоминаю, что предварять эту директиву командой sudo нет необходимости — пароль будет запрошен автоматически. После чего, если пакет не связан никакими зависимостями, установка его начнётся немедленно. В противном же случае будет выведен список всех пакетов, которые он тянет за собой, с указанием объёма, и последует запрос, продолжать ли это дело. Ответ про умолчанию — Да, то есть при согласии достаточно просто нажать Enter. Однако, прежде чем это делать, со списком зависимостей желательно всё-таки ознакомиться.
По умолчанию apt install устанавливает только жёсткие зависимости, зависимости рекомендуемые и предлагаемые будут просто перечисленны.
Субкоманда install предназначена для установки пакетов из репозиториев, как удалённых, так и локальных. Однако локально пакеты могут быть установлены и другим способом — субкомандой deb. В отличие от субкоманды install, она в качестве аргумента требует не имени пакета, а полного имени его файла, при необходимости, с указанием пути. Например, так
$ apt deb path2/Yandex.deb
будет установлена бета-версия яндексового браузера для Linux. Разумеется, файл Yandex.deb предварительно должен быть скачан. Как любезно сообщит нам команда
$ apt help deb
команда apt deb эквивалентна команде sudo dpkg -i.
В случае, если в системе установлена более старая версия запрашиваемого пакета, обе субкоманды, и install, и deb, выполнят его обновление. А вот установить повторно ту же версию, что имеется, первая субкоманда откажется. А ведь такая необходимость время от времени возникает — например, если пакет был безнадёжно испорчен в ходе нездоровых экспериметов. Правда, это можно сделать с помощью субкоманды deb — если соответствующий файл сохранился в кеше. Если же перед тем выполнялась субкоманда clean (см. далее), кеш очистившая напрочь, на помощь придёт субкоманда reinstall, использование которой очевидно — она требует в качестве аргумента имени установленного пакета.
Пакеты требуется не только устанавливать и обновлять, но иногда и удалять. Для этого предназначены две субкоманды — remove и purge, аргументами которых, очевидно, служат имена пакетов, подлежащих изничтожению. Разница между ними в том, что первая удаляет только основные файлы пакета, не затрагивая его общесистемных конфигов, вторая же расправляется также и с ними. В выводе субкоманды search, как говорилось в предыдущем разделе, это выражается в изменении состояния — c в первом случае и p — во втором. Впрочем, пользовательские конфиги, то есть dot-файлы из каталога ~/, и во втором случае нужно (если нужно) будет удалять руками.
При использовании обеих субкоманд удаления следует внимательно читать их вывод, прежде чем нажимать Enter для подтверждения серъёзности своих намерений: обе они автоматически удаляют пакеты, которые зависят от удаляемого, что далеко не всегда можно приветствовать.
А вот чего ни remove, ни purge не удаляют автоматически — так это пакеты, от которых зависит удаляемый, даже если они уже больше никем не используются. Однако они честно предупреждают о таких «сиротах», предлагая для их удаления выполнить субкоманду autoremove. Особенно актуальна она после удаления пакетов другим, не очень известным, способом, непосредственно из главного меню Cinnamon, о чём будет сказано позже.
Перед установкой пакетов из репозитория они предварительно скачиваются и помещаются в каталог /var/cache/apt/archives/, где со временем их скапливается преизрядное количество, и далеко не всегда эти пакеты потребуются в дальнейшем (точнее, почти всегда не потребуются). Для избавления от таких «отходов производства» существуют субкоманды autoclean и clean. Первая удаляет из кеша только пакеты устаревших версий, сохраняя те, версии которых установлены в системе. Вторая же полностью очищает каталог /var/cache/apt/archives/.
Сказанное выше касалось единичных пакетов или их серий — любая из перечисленных субкоманд принимает любое количество аргументов. Однако в утилите apt предусмотрены и субкоманды для тотального обновления системы. Однако, прежде чем выполнить любую из них, необходимо провести обновление локального кеша пакетов, то есть получить списки новых и обновлённых пакетов. Делается это субкомандой update:
$ apt update
Её же в обязательном порядке следует выполнять после каждого изменения в репозиториях — подключения новых или отключения имевшихся. К слову сказать, теоретически для редактирования списков репозиториев предназначена субкоманда sources. Однако практически в Mint она бесполезна, так как вызывает текстовый редактор по умолчанию (nano) для редактирования /etc/apt/sources.list. В нашем же дистрибутиве этот файл содержит только репозиторий локального оптического диска, а все реальные репозитории описываются в файлах каталога /etc/apt/sources.list.d.
Однако вернёмся к тотальному обновлению. Для этого существует субкоманда upgrade, которая выявит все пакеты, для которых в репозиториях доступны более свежие версии, выведет их список, объём для скачивания и прирост объёма занятого дискового пространства после выполнения процедуры, а также запросит подтвержения:
$ apt upgrade Чтение списков пакетов… Готово Построение дерева зависимостей Чтение информации о состоянии… Готово Расчёт обновлений…Готово Пакеты, которые будут обновлены: gir1.2-gudev-1.0 libegl1-mesa libegl1-mesa-drivers libgbm1 … обновлено 35, установлено 0 новых пакетов, для удаления отмечено 0 пакетов, и 0 пакетов не обновлено. Необходимо скачать 36,3 MБ архивов. После данной операции, объём занятого дискового пространства возрастёт на 124 kB. Хотите продолжить? [Д/н]
В ходе выполнения upgrade обновляются по возможности все пакеты, за исключением тех, для которых обновление потребует, для разрешения зависимостей, доустановки новых пакетов или удаления существующих; для них сохраняются текущие версии. Так что это не совсем тотальное обновление системы.
По настоящему тотально действует субкоманда dist-upgrade: она не только обновляет все пакеты, для которых обновления доступны, но может доустанавливать новые пакеты и удалять существующие, если это необходимо для разрешения зависимостей. Эта субкоманда применяется при смене релиза. В очерке о репозиториях говорилось, что для перехода с Qiana на Rebecca достаточно прописать одноимённые репозитории в файлах их описаний — после чего дать команду
$ apt dist-upgrade
Всё сказанное выше в этом разделе относилось к бинарным пакетам. Однако в утилите apt предусмотрены и средства для работы с пакетами исходных текстов. Так, с помощью субкоманды source можно просто скачать пакет, указанный в качестве её аргумента — разумеется, для этого должен быть подключён репозиторий исходников. Субкоманда build (эквивалент sudo dpkg-buildpackage) выполнит построение бинарного пакета. А субкоманда build-dep ограничится конфигурированием необходимых для этого зависимостей. Применить первые две субкоманды у меня случая не было, так что говорить о них не буду. А вот build-dep предлагается запомнить — эта субкоманда понадобится нам в очерке о включении поддержки ZFS.
Можно видеть, что и по части манипулирования пакетами возможности утилиты apt широки и многогранны. То есть это действительно универсальное средство управления пакетами, в обыденной жизни способное почти всегда заменить все прочие — от низкоуровневой dpkg (за исключением dpkg-reconfigure) до графического front-end’а — Synaptic’а. Ибо не уступает последнему в наглядности вывода информации о пакетах (на мой взгляд, так даже превосходит), позволяя манипулировать оными проще и быстрее. Рядом с Mint’овским apt тёзка из Debian/Ubuntu выглядит довольно слабым, а традиционные apt-cache и apt-get — излишне усложнёнными.
