Linux Mint и его Cinnamon. Очерки применителя. Часть 6

Алексей Федорчук 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.

Разумеется, успешной установка пакета будет только при соблюдении следующих условий:

  1. физическом наличии его в пределах досягаемости с локальной машины (на подключенной файловой системе, смонтированном компакт-диске или ином носителе);
  2. знании точного пути (path2) к нужному файлу пакета (имя его, кстати, должно быть указано полностью);
  3. отсутствии неудовлетворенных зависимостей.

Из первого условия следует, что 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. Что представит такую картинку:

gdebi_01

Самая ценная информация здесь — это список файлов, входящих в состав пакета. В отличие от Synaptic’а, о котором речь пойдёт со временем, GDebi выводит его даже для не установленных пакетов:

gdebi_02

В случае, если в пакете всё устраивает, он устанавливается нажатием одноимённой кнопки, что сначала потребует авторизации, а затем незамедлительно начинается установка:

gdebi_03

Проверка зависимостей, естественно, осуществляется как и в dpkg — на уровне удовлетворённости или неудовлетворённости. В последнем случае выводится сообщение о том, какие пакеты следует установить для их разрешения. По завершении установки картинка становится такой:

gdebi_04

Удаление пакета выполняется тем же образом: авторизация и собственно удаление:

gdebi_05

И завершается возвращением исходной картинки. Если от удаляемого пакета зависит какой-либо другой, то опять же последует сообщение об ошибке:

gdebi_06

Никаких преимуществ против консольного бак-энда, то есть собственно 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_001

Которая эту самую суперсилу и вызовет вот в таком виде:

рис 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 — излишне усложнёнными.

Оглавление

Оставить комментарий

Перейти к верхней панели