Воззрения кота Manual’а. Deb-пакеты. Часть 2. Установщики пакетов

Алексей Федорчук

Во второй части трактата про deb-пакеты излагаются воззрений кота Manual’а на их установщики: утилиту dpkg и её фронт-энды, такие, как текстовая утилита gdebi, графические «морды» для KDE и Gtk-based сред, а также примкнувшую к ним утилиту Qapt.

Установщик пакетов dpkg

Утилиты семейства dpkg, предназначенные для работы с единичными deb-пакетами, были исторически первым средством автоматического развертывания пакетов, учитывающим их зависимости. Они лежат в фундаменте всех надстраивающих их систем управления пакетами (apt, Synaptic, etc.). В ряде случаев dpkg оказывается наиболее простым средством для установки или удаления пакета, а также получения информации о нем.

Семейство dpkg включает в себя около 25 отдельных утилит — полный их список можно просмотреть таким образом:

    $ ls /usr/sbin/dpkg* /usr/bin/dpkg*

Наиболее употребимы из них — собственно dpkg (средство для установки и удаления программ) и dpkg-query (инструмент создания запросов к базе данных deb-пакетов). Кроме того, весьма важна программа
dpkg-reconfigure, предназначенная для настройки установленных пакетов. Однако речь о ней аойдёт в другом Manual’е.

А сейчас для начала рассмотрим установку пакетов. Итак, если нам необходимо установить единичный пакет, поступаем так:

    $ sudo dpkg -i path2/packagename.deb

И дело в шляпе — через считанные мгновения пакет packagename.deb будет установлен: это обеспечивает опция -i (от install) вслед за командой dpkg. Дабы в дальнейшем не повторяться, замечу, что все действия по установке и удалению пакетов требуют полномочий администратора, приобретаемых временно командой sudo.

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

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

Из первого условия следует, что dpkg удобно использовать при доустановке компонентов с инсталляционного CD/DVD (или при установке заблаговременно скачанных пакетов). Второе условие самоочевидно. Ну а третье также выполнимо без особого труда: в случае нарушения зависимостей dpkg выдаст сообщение об ошибке с полным перечнем того, что нужно установить для устранения этого, причём в списке будут перечислены только обязательные зависимости. И достаточно все необходимые пакеты поместить в командную строку для того, чтобы они были установлены единой операцией (если, конечно, все эти пакеты имеются в наличии).

Другое часто требующееся применение команды dpkg — удаление ненужных пакетов. Это делается двояко: команда

    $ sudo dpkg -r packagename

удалит пакет, но сохранит настроечные его файлы, а команда

    $ sudo dpkg -P packagename

произведет полную очистку системы от всех компонентов пакета (кроме конфигурационных файлов в домашнем каталоге пользователя — от них в любом случае придется избавляться вручную). Правда, только если он не связан зависимостями с другими пакетами — в этом случае последует сообщение о невозможности удаления пакета и выведен список его зависимостей, этому препятствующих.

Обратим внимание — в аргументах обеих команд фигурирует уже не полное имя пакета, а только его базовая часть. Это распространяется на все случаи использования dpkg (и других команд ее семейства), когда речь идет об уже установленных пакетах.

Следующая сфера деятельности команд семейства dpkg — получение информации о пакетах (поскольку оно никак не влияет на систему, необходимости в правах администратора тут не возникает). И здесь первое дело — это получение списка пакетов, установленных в системе:

    $ dpkg -l

До появления интегрированной утилиты apt приведённая команда была чуть ли не единственным способом получения списка установленных пакетов. Или, по крайней мере, самым простым.

Для отдельных уже установленных пакетов информацию о них проще всего получить с помощью команды dpkg-query, требующей указания какого-либо из операторов действия и имени пакета в качестве аргумента. Операторы действия команды dpkg-query можно вывести так:

    $ dpkg-query --help

Одним из главных операторов здесь является -s или --status — вывод детального статуса пакета, включающий:

• имя пакета, собственно статус (установлен ли он) и приоритет;
• секция репозитория, к которой пакета относится (например, editors — для текстовых редакторов);
• размер пакета в установленном виде;
• имя майнтайнера, архитектура, для которой пакет собран, и номер версии;
• описание зависимостей и конфликтов;
• краткое (в один абзац) описание пакета.

Оператор -l или --list — тоже своего рода описание статуса, но в табличной форме, включающее сведения о том, установлен ли пакет, нуждается ли он в обновлении, нет ли ошибок в его настройке, и так далее. Этот же опреатор без указания аргумента выведет послный список пакетов, установленных в системе, аналогично команде dpkg -l.

Оператор -W или --show обеспечит просто вывод номера версии в форме:

    $ dpkg-query -W nano
    nano	2.5.3-2

Весьма полезен оператор -L или --listfiles — он позволяет полный список файлов, относящихся к данному пакету:

Обратная процедура, то есть поиск пакета, к которому относится файл, указанный в качестве аргумента, выполняется с помощью оператора -S или --search. Впрочем, для этой цели больше подходит утилита apt-file, до которой речь дойдёт со временем.

И вообще, все сказанное об информации по пакетам, относится к пакетам уже установленным. Для получения же сведений о неустановленных пакетах удобнее использовать утилиту gdebi, о которой будет говориться в следующем разделе.

Утилита gdebi…

Утилита gdebi, подобно dpkg, предназначена для установки единичных deb-пакетов, работает в текстовом режиме, однако обладает некоторыми дополнительными функциями. Она запускается одноимённой командой, которая без аргумента выведет справку по собственному использованию:

$ gdebi
Usage: использование: gdebi [опции] имя_файла
Для отображения графической версии запустите gdebi-gtk
  Options:
    --version             show program's version number and exit
    -h, --help            show this help message and exit
    -n, --non-interactive
                          Запустить неинтерактивно (опасно!)
    -o APT_OPTS, --option=APT_OPTS
                          Установить опцию конфигурации APT
    -q, --quiet           Не отображать информацию о ходе выполнения
    --apt-line            Только эмулировать и вывести строку, совместимую с apt-get в stderr
    --root=ROOTDIR        Использовать альтернативную корневую папку

Без указания опций, с именем файла deb-пакета в качестве аргумента команды и при наличии административных привилегий, её запуски приведёт сначала к выводу списка необходимых зависимостей, а затем, после соответствующего подстверждения, к установке и пакета, и его зависимостей, если те имеются в подключённых репозиториях. Указание опции -n, как следует из приведённой справки, избавит и от просмотра зависимостей, и от подтверждения установки.

Весьма полезной опцией утилиты gdebi мне показалась опция --apt-line, дающая только имитацию установки пакета (очевидно, что права администратора при этом не требуются):

Что полезно при определении зависимостей неизвестного пакета и для проверки его «устанавливаемости».

… и её «морды»

Текстовая gdebi (которая, кстати, входит в пакет gdebi-core) имеет два графических фронт-энда (которые в народе именуются «мордами») — Gdebi, использующую библиотеку Gtk, и Gdebi-KDE, основанную на понятно чём.

Утилита Gdebi по умолчанию устанавливается в больщихстве Grk-based клонов Ubuntu (вместе со своим бэк-эндом, разумеется). Имеется она и в Cintu — здесь её можно запустить из секции Администрирование главного меню Cinnamon, где она фигурирует под длинным именем Программа установки пакетов Gdebi. Однако по умолчанию её предлагается открыть при щелчке на любом имени файла deb-пакета в локальной файловой системе. Более того, то же самое предлагается, если щёлкнуть на ссылке на deb-пакет на удалённом ресурсе в браузере:

Можно видеть, что при этом она сообщает и о недостающих зависимостях, список которых якобы можно просмотреть, нажав кнопку Подробности. Потому что в появляющейся панели на самом деле мало чего видно:

И еслизнакомство с зависимостями пакета на самом деле важно, то приходится обращаться к текстовой утилите gdebi, о которой только что говорилось. Впрочем, на установке пакетов это не сказывается — они обычно благшополучно иснталлируются по нажатии на кнопку Установить пакет, хотя в некоторых случаях — только со второго раза.

Утилита Gdebi-KDE, как и её бэк-энд, пакет gdebi-core, отсуствует, например, в референсной редакции KDE из дистрибутива KDE Neon, хотя и имеется в официальном репозитории Ubuntu. Так что её легко установить командоы

    $ sudo apt install gdebi-kde

После чего в контекстное меню при ПКМ на имени deb-пакета добавится соответствующий пункт:

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

Некоторые подробности о нём:

И список входящих в него файлов:

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

Причём, в отличие от Gdebi, список зависимостей выглядит вполне по человечьи.

Утилита Qapt

Графическая утилита Qapt используется в KDE Neon в качестве умолчального установщика пакетов. В отличие от утилит семейства Gdebi, она представляет собой графический фпонт-энд не непосрдественно к dpkg, а к утилите apt. Однако её целесообразно рассмотреть в этой части, поскольку и внешне, и функционально она подобна Gdebi-KDE.

Как можно догадаться по названию, интерфейс Qapt основан на библиотеке Qt. Тем не менее, нет никаких препятсвий для её использования и в Gtk-средах, например, в Cintu. Для чего нужно только установить соответствующий пакет из официального репозитория Ubuntu:

    $ sudo apt install qapt-deb-installer

Все необходимые зависимости (их оказывается не так много) будут вытянуты автоматически. И теперь после скачивания из сети deb-пакета (или при щелчке на имени соответствующего файла, уже имеющегося локально) само собой будет появляться окно, похожее на таковое установщика GDebi-KDE:

Как и в предыдущем случае, окно это имеет вкладки, содержащие дополнительную информацию о пакете, как то — номер версии, размер после установки и другие мелочи:

А главное — список файлов, входящих в состав пакета:

Кнопка же Подробности при наличии дополнительных пакетов, установка которых требуется для разрешения зависимостей, выводит сведения о них в «человечьем» виде (а не в том «бесчеловечном», который обеспечивает GDebi последних версий):

Ознакомившись со всем этим хозяйством, можно нажать кнопку Установить пакет в главном окне и ввести пароль для получения прав администратора:

А затем в терминальном окне можно понаблюдать за ходом установки пакета. И, убедившись, что процесс завершился благополучно, закрыть окно:

Заключение

Таким образом, функционал Qapt и GDebi-KDE практически идентичен: установка локально скачанного пакета вместе с разрешением его зависимостей, если таковое требуется. И если соответствующие пакеты имеются в подключённых репозиториях, разумеется.

Основанная на Gtk «морда» GDebi выполняет то же самое. Однако утилита Qapt оформлена гораздо приятней (как, впрочем, и GDebi-KDE). А главное, позволяет получить гораздо больше сведений о предполагаемом объекте установки. В том числе — о его составе до того, как пакет будет реально установлен.

А посокльку, как уже было сказано, Qapt прекрасно работает в среде Cinnamon, и при этом тянет за собой минимум «чуждых» ей зависимостей, в будущих сборках Cintu именно она будет использоваться в качестве установщика пакетов по умолчанию.

[Общее содержание]