# Воззрения Кота Manual’а. Deb-Пакеты

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

Воззрения кота Manual’а на deb-пакеты

alv

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

Изложение воззрений кота Manual'а на те аспекты работы с deb-пакетами, которые влияют на индивидуализацию системы. Включает в себя пять основных частей и два

приложения. В первом — конспекты по основным командам управления deb-пакетами. Второе

же приложение посвящено описанию утилиты aptitude.

Часть 1. Пакеты

Первая часть будет посвящена общим вопросам. В ней будет говориться о пакетах вообще и

deb-пакетах в особенности. Читатель, знакомый с этими понятиями, может спокойно её

пропустить.

Пакеты, зависимости, библиотеки

Пакеты — это своего рода программные кванты, на которые делится система или дистрибутив.

Это могут быть и простые монофункциональные утилиты (например, строчный текстовый

редактор ed или архиватор tar), более или менее обширные наборы функционально связанных

программ (скажем, coreutils) или составные части огромных программных комплексов

(примером чему — рабочая среда Cinnamon, которая будет предметом специального

рассмотрения).

Термин пакет (английское package) употребляется в двух смыслах: как авторский набор

исходных текстов, созданный разработчиком программы, и как комплект скомпилированных из

него исполняемых программ и всех их служебных файлов, собранный майнтайнерами

дистрибутива или вообще третьими лицами. Пакеты в первом смысле называются исходниками

или вообще «сырцами» (от английского Source), во втором — бинарниками. В этом manual'е

речь пойдёт почти исключительно о пакетах во втором понимании этого термина.

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

говорят о системах rpm based или deb based. Но даже если они собраны в одном формате

(например, rpm или deb), бинарные пакеты из разных дистрибутивов далеко не всегда

совместимы в рамках одной системы. Впрочем, к формату deb, который здесь рассматривается, это относится в наименьшей степени: например, пакеты для всех дистрибутивов семейства

Ubuntu сохраняют почти полную бинарную совместимость внутри него, а иногда — с пакетами

прародительского Debian’а и его прямых клонов.

Ключевым для бинарных, или дистрибутивных, пакетов является понятие зависимостей. Суть

его в том, что пакет packagename1 для сборки, установки и (или) функционирования требует

наличия в системе пакета packagename2, тот, в свою очередь, может потребовать пакета

packagename3, и так далее.

Различаются зависимости «жёсткие» и «мягкие». Удовлетворение первых абсолютно

необходимо для сборки и функционирования данного пакета. Так, практически любая

программа использует главную системную библиотеку glibc, любое приложение для системы

X — одну из главных Иксовых библиотек, xlib или xcb, любая интегрированная рабочая среда

— одно из двух основных семейств высокоуровневых библиотек, Qt/KDE или Gtk.

«Мягкие» зависимости данного пакета не критичны для его функционирования —

удовлетворение их лишь добавляет ему дополнительные функции (например, печати и

сканирования для офисных и графических приложений) или возможности (скажем, доступ к

файлам данных определённых форматов для той же графики или мультимедиа).

В deb-формате бинарных пакетов предусмотрено более дробное разделение «мягких»

зависимостей, но об этом подробнее будет говориться чуть позже. А пока замечу, что часто

приходится учитывать и так называемые конфликтующие зависимости — то есть

альтернативные по назначению пакеты, не способные ужиться в одной системе.

Понятие зависимостей пронизывает насквозь UNIX-совместимые системы, и особенно важно

для свободных их представителей. Ибо традиционная модель разработки UNIX-программ (то, что задумчиво именуют UNIX Way) характеризуется ярко выраженным стремлением не

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

велосипеды. Ведь все программы, вне зависимости от их назначения, неизбежно должны

выполнять некоторые однотипные действия, как то: открыть файл, записать его, вывести на

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

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

заново.

Вот их, как правило, поддаваясь смертному греху лености, и не программируют «с нуля». А

объединяют соответствующие директивы в отдельные программные комплексы, именуемые

библиотеками (libraries). Сами по себе они к автономному исполнению не предназначены.

Однако любая программа, при необходимости совершить одно из типовых действий, вызывает

из такой библиотеки некий фрагмент кода, содержащий требуемую последовательность

директив.

Библиотеки обычно привязаны к определённым языкам программирования, синтаксису

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

употребимым в UNIX-системах и их приложениях является язык C, то его функции и требуются

чаще всего. Они собираются в главную системную библиотеку, которая почти во всех

дистрибутивах Linux именуется glibc.

Однако главной системной библиотекой список не исчерпывается. В UNIX-подобных системах

при создании пользовательских интерфейсов используются библиотеки свойств терминала

(например, ncurces) для консольных программ и библиотеки, описывающие процедуры

отрисовки окон и управления ими — для графических программ системы X, библиотеки

интерфейсных элементов и графических примитивов более высокого уровня (Motif, Qt, Gtk), библиотеки описания графических и мультимедийных форматов файлов и тому подобные

«сборники». Иными словами, существует тенденция к вынесению в разделяемые библиотеки

всех повторяющихся действий и элементов, какие только возможно.

Если библиотек, используемых в программах для консольного режима, не так много, они

достаточно универсальны и легко поддаются учёту, то с библиотеками для обеспечения

графического режима существенно сложнее. Даже простое перечисление их заняло бы немало

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

среды (они же именуются десктопами, DE) и их штатные приложения.

Большая часть распространённых десктопов использует библиоотеки Gtk 3-й и, реже, 2-й

верси. В их числе Cinnamon, LXDE, MATE, Xfce, Unity и, наконец, GNOME 3 (далее именуемый

просто GNOME, поскольку вторая ветка этой среды вымерла соответственно. К ним же

примыкает). Последний десктоп для своей работы требует также собственных библиотек

GNOMElibc.

На библиотеке Qt основана среда KDE, которая также не живёт без собственных библиотек из

набора KDELibs. Чистая Qt используется в настоящее время только в десктопе LXQt. Однако в

будущем ожидается переход на эту библиотеку десктопа Budgie. Также на Qt основана среда

Unity 8, в том числе и её десктопный вариант, который, правда, пока назвать работоспособным

язык не поворачивается.

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

библиотеками в единый, самодостаточный пакет. Таковы системы Snap (изначально созданная

для Ubuntu, но ныне способная работать и в более иных дистрибутивах) и от рождения кросс-

дистрибутивная система Flatpak. Однако ни та, ни другая всенародного признания пока не

получили, так что речи о них в этом Manual'е не будет.

Формат deb-пакетов

Формат пакетов deb был разработан ещё в прошлом тысячелетии для дистрибутива Debian и

унаследован от него Ubuntu, во многом предопределив успех последней. А вслед за ней — и

удачливость многих её клонов. Почему deb-формату и следует уделить некоторое внимание.

Пакет deb-формата — архивный файл (собранный утилитой архивирования ar), включающий

три компонента. Первый — это файлик debian-binary, не содержащий ничего, кроме номера

версии deb-формата (в данный момент — 2.0).

Второй файл носит имя data.tar.xz и, как легко догадаться, представляет собой tar-архив, сжатый утилитой xz. Содержимое архива — скомпилированные исполняемые бинарники и

необходимые им для работы компоненты (библиотеки, конфиги, документация и так далее).

Иными словами, все компоненты, которые при установке пакета будут инкорпорированы в

файловую иерархию целевой системы.

Третий файл именуется control.tar.gz и представляет собой архив файлов, содержащих

всякого рода метаинформацию — описание пакета, его зависимости, классификационную

принадлежность, приоритет и так далее (файл control), контрольные суммы всех

исполняемых бинаников (файл md5sums), сценарии, выполняемые при установке и удалении

пакета (preinst, postinst, prerm и postrm).

Зависимости в терминах deb-пакетов имеют несколько градаций: обязательные (depends), рекомендуемые (recommends), предлагаемые (suggests), конфликтующие (conflicts).

Первая градация — это обычные «жёсткие» зависимости, без удовлетворения которых пакет

либо не будет работать, либо вообще не установится. С градацией последней тоже понятно —

это, так сказать, анти-зависимости.

Ну а зависимости рекомендуемые и предлагаемые — это две разновидности «мягких»

зависимостей. Разница между ними в том, что рекомендуемые пакеты обеспечивают

«зависимому» пакету дополнительные функции (например, поддержку мыши в консольных

приложениях), а пакеты предлагаемые предоставляют дополнительные возможности, вполне

вероятно, полезные, но не жизненно необходимые (например, документацию, в том числе на

не-английских языках).

То есть первая категория «мягких» зависимостей как бы более нужная, нежели вторая.

Впрочем, таково субъективное мнение майнтайнера конкретного пакета — вполне возможно, что у применителя будет по этому поводу мнение более иное. И потому и пакетный менеджер

apt, и его графическая «морда» Synaptic, устанавливающие зависимости автоматически, в в

большинстве deb based дистрибутивов по умолчанию не делают этого ни для рекомендуемых, ни, тем более, для предлагаемых пакетов, а лишь выводят их список, дабы применитель сам

принял решение по данному вопросу.

Кроме того, спецификой deb-пакетов является ещё и существование так называех пред-

зависимостей (pre-depends) — при их нарушении установка пакета даже не может начаться, ибо их наличия требует пре-инсталляционный сценарий «зависящего» пакета. Впрочем, с

точки зрения пользователя они немногим отличаются от обычных зависимостей типа depends.

Кроме зависимостей, для пакетов deb-формата важно также понятие их приоритета. Оно

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

важный (important), также оказывающиеся практически необходимыми, стандартный, то есть

имеющийся практически в любой полнофункциональной Linux-системе, дополнительный

(optional) — тут уж степень важности каждый должен решать для себя.

Как это принято в мире Open Source, все бинарные пакеты (и пакеты deb-формата тут не

исключение) сопровождаются исходными текстами, доступными из соответствующего

репозитория дистрибутива. И здесь deb-формат проявляет свою специфику: каждый пакет в

исходниках обычно включает три файла — packagename.orig.tar.gz, packagename.dsc и

packagename.diff.gz.

Первый — самый обычный тарбалл исходных текстов авторского пакета, что подчеркивается

словом orig в его имени: формат архива, имя и система нумерации версий также совпадают с

таковыми авторского пакета. Файл packagename.dsc содержит в себе всю метаинформацию, необходимую для правильного построения из него бинарного deb-пакета. А

packagename.diff.gz — это те изменения исходного кода, которые вносятся для адаптации

пакета непосредственно к данному дистрибутиву. Если таких изменений не потребовалось (или

если пакет писался именно для данного дистрибутива), он может и отсутствовать.

Статус пакетов

В системах пакетного менеджмента deb based дистрибутивов, в том числе и в Mint, пакеты

объединяются в категории, секции и группы. Список категорий включает следующие пункты: Установленные пакеты — очевидно из названия;

Обновляемые пакеты — установленные пакеты, для которых в репозитории доступны

более новые версии;

New Packages — пакеты, добавленные в локальный кэш после последней его очистки; Неустановленные пакеты — пакеты, отсутствующие в системе, но доступные из

репозиториев;

Виртуальные пакеты — не существующие пакеты, указывающие на другие пакеты, которые нужно использовать для тех или иных задач;

Задачи (Tasks) — группы пакетов (метапакеты), которые предоставляют лёгкий способ

выбора заранее сформированного набора пакетов под определённую цель.

В секции пакеты группируются по назначению: программы для администрирования, базовые

пакеты, текстовые редакторы, и так далее.

Группы представляют собой разделы официального репозитория. В дистрибутивах, основанных

на Ubuntu, они таковы: main, restricted, universe, multiverse, о чём речь пойдёт позднее.

Каждый пакет в терминологии имеет основной статус, обозначаемый строчной литерой; в их

число входят:

i (от install) — установленный пакет;

p (от purge) — пакет не установленный или деинсталлированный «вчистую» (то есть с

удалением его конфигурационных файлов);

c (от clean) — пакет, деинсталлированный с сохранением конфигурационных файлов; v (от virtual) — виртуальный пакет.

Кроме того, пакеты могут иметь один из следующих дополнительных статусов, хотя это и не

обязательно:

A (от Auto) — установленный автоматически, как зависимость другого пакета; пакеты, не

имеющие статуса A, считаются установленными вручную;

h (от hold) — пакет с фиксированной версией (то есть не подверженный апгрейду); u (от unpacked) — пакет распакованный, но не установленный; H — «недоустановленный» пакет;

C — пакет установленный, но не настроенный;

B — «сломанный» пакет, то есть установленный с нарушением зависимостей.

Обращаю особое внимание на пакеты, имеющие статус A: они устанавливаются вместе со

своими зависимостями и могут быть удалены только вместе с ними. Правда, как мы увидим

дальше, статус установленного пакета может быть изменён, и тогда он станет доступным для

индивидуального удаления.

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

формат, сводятся к изменению их статуса. И делается это с помощью инструментов текстового

режима (утилиты dpkg, gdebi, apt) или их графических фронт-эндов («морды» для Gdebi, Qapt, Synaptic).

Средства для работы с пакетами

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

оболочки для них;

менеджеры пакетов;

их графические фронт-энды;

центры приложений.

Первая группа — это низкоуровневые утилиты для работы с единичными пакетами: их

установки, удаления, etc. В нашем случае эту роль выполняет семейство утилит dpkg.

Отслеживание зависимостей здесь выполняется на уровне удовлетворения или

неудовлетворения, попыток автоматического разрешения зависимостей не предпринимается.

Оболочки для установщиков пакетов выполняют те же самые функции, что и они сами,

посредством как прямых команд (утилита gdebi), так и средствами графического интерфейса.

К числу последних принадлежат Gdebi (использующая Gtk), Gdebi-kde (для одноимённой

среды), Qapt, основанная на библиотеке Qt. Сдежует заметить, что все эти оболочки не только

отслеживают выполнение или нарушение зависимостей, но и предпринимают попытки их

разрешения, более или менее успешные, в зависимости от обстоятельств.

Менеджеры пакетов работают уже не с единичными пакетами, а с их репозиториями. И, кроме

перечисленных функций, их непременной обязанностью является не только отслеживание

зависимостей, но и их автоматическое, по возможности, разрешение. В большинстве deb based дистрибутивов эту роль выполняет семейство утилит APT, из которых наиглавнейшей нынче

является одноимённая утилита — apt.

Четвёртая группа — графические фронт-энды для менеджеров пакетов. Нынче она

представлена программой Synaptic; её аналог для среды KDE, Muon, назвать вполне

функциональной нельзя.

Что же касается пятой группы — это самые высокоуровневые программы, в которых прозрачно

для применителя интегрированы функции поиска пакетов в Сети, подключения к содержащим

их репозиториями и собственно пакетный менеджмент. Название её заимствовано от Центра

приложений Ubuntu — первого представителя этой группы. Хотя в некоторых случаях

программы этой группы могут оказаться полезными, автору этих строк они представляются

избыточными, и речи о них в данном Manual'е не будет. Остальные же инструменты работы с

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

Часть 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.

Часть 3. Репозитории

Поскольку пакетные менеджеры, которым будут посвящены части четвёртая и пятая, работают

не с единичными пакетами, как описанные в прошлой части установщики, а с их

репозиториями, они предваряются описанием воззрений кота Manual'а на официальные и

неофициальные репозитории дистрибутивов семейства Ubuntu, а также на методы их

использования.

Репозитории

Пакеты, входящие в дистрибутив (или, если угодно, образующие дистрибутив), валяются не

абы как — они организованы в репозитории. Что это такое?

В переводе на русский язык слово репозиторий означает «хранилище» — и именно его

рекомендуют употреблять языковые пуристы. Однако, как это обычно бывает по жизни, в

народе утвердилось иное их именование — repo или, говоря по нашему, по бразильскому

кириллическому, «репы». Почему во множественном числе — станет понятно из дальнейшего

рассказа.

Сам по себе репозиторий действительно можно в первом приближении определить как место

хранения пакетов, специально собранных для данного дистрибутива, к которому возможен

свободный (мы ведь ведём речь только о свободных системах, верно?) доступ.

Однако доступности сервера, хранящего пакеты, недостаточно, чтобы носить высокое

званиезвание репозитория. Пакеты в репозитории должны быть структурированы по

определённым, присущим данному дистрибутиву, принципам. Система хранения пакетов

должна обеспечивать их пополнение, обновление, а главное — поддержку целостности и

непротиворечивости пакетов в отношении зависимостей, причём для всех поддерживаемых на

текущий момент версий дистрибутива.

Иными словами, пакеты в репозитории должны сопровождаться базами данных — теми

самыми, которые используются системой управления пакетами данного дистрибутива.

Кроме того, весьма желательно, чтобы репозиторий зеркалировался на нескольких

независимых серверах — по вполне понятным причинам. Правда, это не является

непременным требованием. Тем не менее, наличие зеркал — одно из оснований для

употребления слова репозитории во множественном числе.

В последние годы получила распространение точка зрения, что право на гордое имя

настоящего дистрибутива даёт только собственный репозиторий пакетов, при его отсутствии

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

Автор этих строк и сам активно поддерживает озвученный взгляд. Почему до сих пор так и не

набрался наглости величать нашу Cintu дистрибутивом. Ибо она основывается, с одной

стороны, на официвальных репозиториях проекта Ubuntu, с другой — на нескольких PPA-

репозиториях с Launchpad'а, которые и будут последовательно рассмотрены в ближайших

разделах.

Устройство репозиториев Ubuntu

Официальные репозитории Ubuntu располагаются по адресу: archive.ubuntu.com/ubuntu. Это —

«головное» хранилище пакетов, имеющее многочисленные региональные зеркала, принадлежность которых к стране указывается стандартным двухсимвольным префиксом, например ru.archive.ubuntu.com/ubuntu/ — российское зеркало.

Проще всего с устройством репозиториев с точки зрения применителя можно ознакомиться

просмотром их списка в файле /etc/apt/sources.list, который создаётся автоматически

при инсталляции. В Ubuntu и любом её «чистом» (не обязательно официальном) клоне, в том

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

в обязательном порядке содержит следующие строки:

deb http://ru.archive.ubuntu.com/ubuntu/ xenial main restricted deb http://ru.archive.ubuntu.com/ubuntu/ xenial universe

deb http://ru.archive.ubuntu.com/ubuntu/ xenial multiverse

Здесь первый компонент в каждой строке, deb, означает, что речь идёт о бинарных пакетах

(про пакеты с исходниками я скажу чуть позже). Далее следует «базовый» URL репозитория, соответствующий тому зеркалу сервера, которое было выбрано при установке системы — в

наших условиях оно будет или российским (как в примере), или официальным

http://archive.ubuntu.com/ubuntu/. Последнее отнюдь не является показателем русофобии —

известны прецеденты, когда обновления ысех зеркал существенно запаздывали супротив

официоза.

Далее указывается кодовое имя релиза (в примере — xenial) и его отдельных веток, коими по

умолчанию будут:

просто xenial — в неё входят собственно пакеты дистрибутива; xenial-updates — «обычные» обновления пакетов, связанные со сменой версий, сборок

и исправлением ошибок;

xenial-security — как нетрудно догадаться, обновления, латающие «дыры» в

безопасности системы.

Кроме того, каждом релизе Ubuntu имеются ещё две ветки — в 16.04 они носят имена xenial-backport и xenial-proposed: обе они содержат обновлённые версии некоторых пакетов из

последующих релизов, первая — уже офциально «утверждённые», вторая — проходящие

«обкатку».

Для подключения ветки с backport'ированными пакетами при установке любого «чистого»

клона Ubuntu нужно отметить соответствующую опцию, что в Cintu и авторских редакциях

Neon'а сделано по умолчанию. Ветку xenial-proposed можно (если нужно — а иногда такая

необходимость возникает) подключить только вручную, внеся в файл /etc/apt/sources.list такую строку:

deb http://ru.archive.ubuntu.com/ubuntu/ xenial-proposed main restricted universe multiverse Наконец, в то же файле /etc/apt/sources.list есть и такая строка:

# deb-src http://archive.canonical.com/ubuntu xenial partner Это репозиторий для пакетов, в том числе и коммерческих, разрабатываемых партнёрами

фирмы Canonical. Как можно видеть, по умолчанию после стандартной утсановки она

закомментирована. Я, кажется, никогда ничего из этого репозитория не устанавливал, и

потому и в Cintu, и в Neon'е он онтлючён. Для включения с него надо снять символ

комментария.

Далее в каждой втеке репозиториев идёт перечень категорий пакетов. Их четыре: main — полностью свободные пакеты, официально поддерживаемые разработчиками

Ubuntu;

restricted — пакеты, также официально поддерживаемые дистрибутивом, но не вполне

свободные;

universe — полностью свободные программы, официально дистрибутивом не

поддерживаемые и развивающиеся силами независимых разработчиков; multiverse — пакеты, аналогично universe официально не поддерживаемые и, подобно

restricted, не вполне свободные.

«Не вполне свобода» пакетов из категорий restricted и multiverse выражается в

ограничениях на их распространение (например, мультимедиа-кодеки, использующие

алгоритмы, патентованные в отдельных странах) или могут распространяться только в

бинарном виде (например, фирменные драйверы для видеокарт).

До сих пор речь шла о репозиториях бинарных пакетов. Однако существуют и параллельные им

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

первичной установке системы, чего нет ни в Cintu, ни в Neon'е. Так что если исходники

потребуются — надо снять символы комментария со строк

# deb-src http://ru.archive.ubuntu.com/ubuntu/ xenial main restricted И им подобных.

PPA-репозитории

Кроме официального репозитория, для Ubuntu существует централизованное хранилище

репозиториев дополнительных, объединяемых понятием PPA — Personal Packages Archive, то

есть входящих в персональный архив пакетов, пополняемый сторонними разработчиками и

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

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

очередь появляются как бинарники в PPA-репозиториях Ubuntu.

Для доступа к PPA-репозиториям фирмой Canonical разработан специальный онлайновый

инструмент — Launchpad, размещённый на одноимённом сайте. Это — не открытая и не

свободная система. Более того, она имеет и платную версию, предназначенную для

разработчиков коммерческих пакетов. Однако нас, как применителей, это не касаются.

Описания подлючённых PPA-репозиториев даются в отдельных файлах каталога

/etc/apt/sources.list.d/, называемых в соответсвие с ppa-именем пакета и суффиксом

*.list. Откуда оно берётся, будет сказано позднее. А пока — как оно выглядит.

Большинство пакетов в PPA-репозиториях собирается и поддерживается майнтайнерами-

индивидуалами, и потому здесь нередко можно видеть их имена, фамилии или ники. В других

случаях это просто имя пакета, часто с отражением статуса разработки. Репозиторий может

включать несколько связанных друг с другом пакетов — и тогда может называться по главному

из них.

Возможны и более причудливые имена, например, ppa:mystic-mirage/komodo-edit —

репозиторий текстового редактора Komodo Edit. Важно, что они в обязательном порядке

включают «префикс» ppa:, который в имени соответствующего list-файла отбрасывается. Зато

завершается последний обязательным компонентом — именем релиза. Например, для Komodo Edit имя list-файла, соответствующего релизу 16.04 — mystic-mirage-ubuntu-komodo-edit-xenial.list.

Внутри такого файла — обычно две строки. Например, для пакета komodo-edit они будут

такими:

deb http://ppa.launchpad.net/mystic-mirage/komodo-edit/ubuntu xenial main deb-src http://ppa.launchpad.net/mystic-mirage/komodo-edit/ubuntu xenial main То есть в одном файле описывается и репозиторий бинарников, и репозиторий исходников.

Если последний отсутствует — соответствующей строки не будет. Впрочем, в PPA-

репозиториях пакетов без исходников не водится. А вот среди «не вполне свободного» софта

встречаются, примером чему — браузер Vivaldi: файл vivaldi.list выглядит следующим

образом:

deb http://repo.vivaldi.com/stable/deb/ stable main

Однако случаи, когда приходится искать пакеты за пределами PPA-репозиториев, достаточно

редки. Ибо в них, как в Греции есть всё — и ещё немного больше, чем всё. Правда, чтобюы

воспользоваться этим «греческим сокровищем», PPA-репозитории нужно подключить, о чём

будет говориться в следующем разделе.

Подключение PPA-репозиториев

Подключение PPA-репозиториев во всех «чистых» клонах семейства Ubutnu можно выполнить

разными способами. Первый из них — «ручной», о котором я скажу в конце этого раздела.

Ничего принципиально сложного в еём нет, однако и прибегать к нему приходится редко. Ибо

в Ubuntu и её клонах имеется специальная утилита add-apt-repository — сценарий на

Python'е, автоматизирующий данный процесс. Иногда в сети можно встретить для него

имяapt-add-repository, но это не более чем символическая ссылка на реальный скрипт.

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

$ sudo add-apt-repository [ppa-name]

где [ppa-name] — так называемое PPA-имя, которое только и требуется знать для нужного

репозитория. Как его определить?

Можно, конечно, походить по форумам Ubuntu’йской тематики, можно сделать запрос к Гоше

или Яше, указав имя искомого пакета, можно… да много чего можно сделать, чтобы по

прошествии изрядного или ещё большего времени получить нужный результат. А можно,

действуя методично и планомерно, прибегнуть к универсальному способу, который и

описывается ниже.

Первый шаг — заход на Launchpad.net. Далее в поле поиска следует набрать имя требующегося

пакета или его фрагмент, например, systemback:

Далее в списке выдачи результатов нужно отыскать нужную строку — Systemback: Kendek (почему, будет сказано в соответствующем трактате)

Теперь — по ссылке, и прочитать раздельчик, озаглавленный Adding this PPA to your system, где искомое ppa-имя будет выделено полужирным шрифтом: Его и следует подставить в качестве аргумента команды:

$ sudo add-apt-repository ppa:nemh/systemback

Дабы развеять все сомнения, можно пройти по ссылке Read about installing. Появится

всплывающее окошко, в котором процедура добавления PPA-репозитория будет описана

подробно, с иллюстрациями:

После выполнив предыдущей команды нужно ни в коем случае не забыть проделать процедуру

апдейта, о чём, впрочем, есть напомингание на странице:

$ sudo apt update

Теперь можно устанавливать пакеты из новообретённого репозитория. А ознакомиться со

списком оных можно сразу. Правда, в данном примере — всего один пакет, но зато для всех

актуальных релизов, включая и нужный нам Xenial:

Впрочем, как было сказано в начале раздела, можно обойдясь без команды add-apt-repository: отыскав нужный репозиторий (пусть для разнообразия это будет PPA Цветко

Цветкова с пакетами Cinnamon 3.2 для релиза Xenial), развернуть строку Technical details about this PPA:

Строки из поля ниже просто копируются в новый текстовый файл, создаваемый в каталоге

/etc/apt/sources.list.d под именем tsvetko_tsvetkov-ubuntu-cinnamon-3-2-xenial.list. После чего следует добавить gpg-ключ — это символы после слеша в строке

Signing key:. Что делается тремя командами:

$ sudo gpg --keyserver keyserver.ubuntu.com --recv DA2717C1

$ sudo gpg --export --armor DA2717C1 > /tmp/public.key

$ sudo sudo apt-key add public.key

Две последние команды можно совместить в одном конвейере:

$ sudo sudo gpg --export --armor DA2717C1 | apt-key add --

И теперь остаётся только не забыть про обновление локального кеша: $ sudo apt update

Не правда ли, любой из предложенных способов проще, чем беготня по форумам и блогам? Да

и Гошу с Яшей не стоит беспокоить по пустякам.

Редко, но бывает так, что приходится устанавливать пакеты из какого-либо иного источника, нежели PPA-репозитории. Но в этом случае грамотно сделанный пакет при установке сам

добавляет свой репозиторий в общий список — так, например, происходит при установке

браузеров Vivaldi и Opera. Либо, на худой конец, сопровождается сведениями о том, как это

сделать самостоятельно (пример чему будет приведён в трактате про Virtualbox). Если ни того, ни другого не имеет места быть — возникает вопрос: а стоит ли связываться с таким пакетом?

Часть 4. Инструментарий apt

Современные версии утилиты apt практически полностью вобрали в себя функционал команд

apt-get и apt-cache. Что, однако, не отражено ни в её официальной документации, ни в

сторонних сетевых источниках (русскоязычных — точно). Поэтому в четвёртой части трактата

про deb-пакеты излагаются воззрений кота Manual'а на ныншние её возможности, а также на

некоторые дополнительные утилиты семейства APT.

Вступление

Набор APT (Advanced Packaging Tools) — это программный комплекс, охватывающий все

стороны управления пакетами, вплоть до их построения из исходных текстов. Он включает в

себя десятки самостоятельных пакетов, объединяющих бессчётное количество отдельных

утилит.

Однако по умолчанию при стандартной инсталляции из этого богачества во всех известных

мне клонах Ubuntu устанавливается только собственно пакет apt с его зависимостями

(libapt, apt-utils) и пара-тройка пакетов служебных (типа apt-transport). Правда, в

отдельных редакциях Cintu «из коробки» установлены и некоторые другие пакеты этого

семейства.

Так что далее будут рассмотрены утилиты эпонимического пакета apt, а под занавес также

утилита apt-file из одноимённого пакета. Именно они наиболее востребованы в реальной

работе с пакетами.

Список утилит пакета apt можно получить различными способами, например, командой

$ dpkg -c apt_[1.4-beta4]version]ubuntu1_amd64.deb G '/usr/bin/'

И выглядеть он будет, если отбросить «лишнюю» информацию, таким образом:

/usr/bin/apt

/usr/bin/apt-cache

/usr/bin/apt-cdrom

/usr/bin/apt-config

/usr/bin/apt-get

/usr/bin/apt-key

/usr/bin/apt-mark

Впрочем, в данном случае проще воспользоваться графическим фронт-эндом Synaptic (о которо

будет говориться в части 5), которая выдаст такую картинку: И по поводу этого списка надо сказать несколько слов, ибо во многих сетевых материалах до

сих пор с упорством, заслуживающим лучшего применения, предлагается по старинке

использовать утилиты apt-cache для получения информации и пакетах и apt-get — для

манипуляций с оными (установки, удаления, обновления).

Это позорно и преступно, как говаривал лирический герой Венички Ерофеева. Ибо вот уже

почти три года, с 1 апреля 2014, существует универсальная эпонимическая утилита apt. И уже

более года, с выхода версии 1.2.X (которая включена в Ubuntu 16.04 и во все её клоны), её

функционал практически полностью перекрывает интегрированные возможности утилит apt-cache и apt-get. А в использовании она проще этой «сладкой парочки» уже хотя бы тем, что

она одна и короткая. Кроме того, у неё есть и некоторые дополнительные функции.Так что

далее будет говориться только об apt из одноимённого пакета.

Отступление. Утилиту apt из одноимённого пакета, имеющего место быть во всех deb based системах, не следует путать с утилитой того же имени из дистрибутивов проекта

Mint — Linux Mint и LMDE. Последняя возникла задолго до появления в инструментарии APT

утилиты apt. И представляет она собой набор скриптов на Python'е, интегрирующих

возможности команд apt-get, apt-cache, dpkg и даже aptitude. Она входит в пакет

mintsystem и устанавливается в каталог /usr/local/bin (подробности — в книге про

Linux Mint и его Cinnamon. Теоретически apt для Mint можно прикрутить и к «чистым»

клонам Ubuntu (и автор этих строк предпринимал такие попытки ). Однако нынче это

занятие потеряло смысл, так как нативный apt из современных версий пакета apt по

функционалу сравнялся со своим предтечей из Mint'а.

К слову сказать, определить версию apt можно с помощью этой самой утилиты. И в момент

сочинения этих строк в Cintu (как и в других регулярно обновляемых клонах Ubuntu 16.04) она

будет такой:

$ apt --version

apt 1.2.19 (amd64)

В Ubuntu Yakkety версия apt нынче 1.3.3, а в Zesty — даже 1.4beta, которая, вероятно, обретёт

статус стабильной к выходу релиза.

Так что пакет apt во всех актуальных и грядущих релизах Ubuntu и её клонов содержит уже

полнофункциональную версию одноимённой утилиты. Правда, каждый запуск её

сопровождается предупреждением, оказывающим на некоторых граждан устрашающее

действие:

WARNING: apt does not have a stable CLI interface.

Use with caution in scripts.

Однако предупреждение это по части стабильности давно уже силы не имеет. Что же до

использования утилиты apt в скриптах, то исчерпывающее разъяснение по сему поводу можно

получить, если запустит её без субкоманды, опций и аргументов, в «голом» виде: $ apt

apt 1.2.19 (amd64)

Использование: apt [параметры] команда

apt — менеджер пакетов с интерфейсом командной строки,

предоставляет команды для поиска и управления,

а также запросов информации о пакетах.

Он выполняет те же задачи, что и специализированные инструменты APT, например apt-get и

apt-cache,

но содержит параметры, которые больше подходят для интерактивного использования по

умолчанию.

...

Из чего следует, что apt не хуже пары apt-cache и apt-get в скриптах, а лучше их в

интерактивном режиме. Что предваряется шаблоном использования этой утилиты. О котором

надо сказать несколько слов.

Утилита apt имеет свои собственным внутренние команды, именуемые также операторами или

субкомандами (я буду придерживаться последнего термина, как наименее неопределённого).

Субкоманды эти определяют, что же должна делать утилита. Которая имеет и опции, уточняющие условия действия.

Перечень субкоманд даётся в выводе «голой» команды apt, где сопроводжается краткими

пояснениями — в локализованной версии послендние также даются на русском языке. Однако

это — тот самый случай, когда глазам своим верить не следует. Ибо в этом списке будт далеко

не все субкоманды, поддерживаемые современными (от 1.2.X и выше) версиями утилиты.

Не следует принимать на веру и то, о чём поведает тётя Маня в ответ на команду

$ man apt

Полного списка субкоманд и опций здесь мы также не увидим. Их придётся выковыривать из

man (8) apt-get и man (8) apt-cache. Ибо, как уже было сказано, нынешние версии apt практически полностю вобрали в себя их функционал.

Насколько я знаю, полного описания возможностей утилиты apt в сети на русскоя языке не

существует, да и на английском такого мне не попадалось. И поэтому в двух следующих

разделах предлагается описание функционала этой утилиты, который показался мне наиболее

востребованным или интересным.

Как говорилось в части первой настоящего трактата, вся работа с deb-пакетами сводится к

определению их текущего статуса (то есть получению информации о пакетах) и его изменению

(установке, удалению, обновлению). Субкоманды для решения первой задачи будут описаны в

ближайшем разделе, второй — в следующем за ним.

Субкоманды определения статуса

Поскольку субкоманды определения статуса, то есть просто получения информации о пакетах, не приводят ни к каким изменениям в системе, для их выполнения достаточно прав обычного

пользователя. Они выполняют большинство самых частых действий, для которых

предназначается утилита apt-cache.

Здесь на первом месте надо поставить субкоманду list, не требующую аргументов. В своей

элементаhной форме

$ apt list

она вывовдит полный список пакетов, установленных в системе и доступных в подключённых

репозиториях. Для каждого пакета, кроме имени, указывается codename релиза и его ветки, номер версии и целевая архитектура:

0ad/xenial 0.0.20-1 amd64

0ad-data/xenial,xenial 0.0.20-1 all

Выводится также основной статус пакета:

accountsservice/xenial-updates,now 0.6.40-2ubuntu11.3 amd64 [установлен]

И, если есть, два дополнительных — автоматичкий:

acl/xenial,now 2.2.52-3 amd64 [установлен, автоматически]

М локальный:

hunspell-ru-aot/now 0.4.0-2 all [установлен, локальный]

Последний присваивается пакетам, которые устанавливались не из репозитория, а «в лоб», с

помощью одного из установщиков пакетов. Локально установленные пакеты, тем не менее, попадают в базу оных, и далее с ними можно обращаться средствами apt.

Субкоманда три опции:

--all-versions, применяемую по умолчанию — она-то и обеспечивает вывод всех

наличных и доступных пакетов;

--installed, которая выводит только установленные пакеты (вручную, автоматически и

локально);

--upgradeable, выводящая список пакетов, для которых доступны обновления, её имеет

смысл выполнить после команды apt update, о которой будет говориться в следующем

разделе.

Надо отметить, что субкоманда list не имеет аналогов в утилите apt-cache, но близка по

смыслу команде dpkg -l, хотя и отличается от неё формой вывода.

Вывод субкоманды list можно фильтровать для поисков нужного пакета (например, с

помощью утилиты grep). Однако проще и эффективней искать пакеты посредством

специальной субкоманды search, в качестве аргумента которой выступает «базовое имя»

пакета или его «шаблон». Например, команда

$ apt search systemback

выведет сведения не только об одноимённом пакете:

systemback/xenial,now 1.8.402~ubuntu16.04.1 amd64 [установлен]

Simple system backup and restore application with extra features но и обо всех, с ним связанных:

libsystemback/xenial,now 1.8.402~ubuntu16.04.1 amd64 [установлен, автоматически]

Systemback shared library

и так далее. По умолчанию поиск последовательности символов, заданной в качестве

аргумента, производится не только в именах пакетов, но и в их опиисаниях. Поэтому, например, вывод команды

$ apt search apt

будети неприлично длинным, и содержащим немало мусора, так что потребует фильтрации. О

чём будет расскзано в воззрениях кота Manual'а на командную оболочку Zsh.

Для получения подробной информации об определённом пакете используется субкоманда

show. И здесь в качестве аргумента нужно указывать именно «базовое имя» пакета. Например, команда:

$ apt show systemback

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

после инсталляции, а также описание. Но самой важной частью этой метаинформации

являются списки «жёстких» записимостей пакета (Depends), его рекомендаций (Recommends), предложений (Suggests), а также всяческих «помех» (Conflicts, Breaks, Replaces).

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

Первая из них выводит «прямой» список список зависимостей, рекомендаций, предложений и

помех:

$ apt depends apt

И выглядит он так:

А вот субкоманда rdepends выводит список пакетов, которые зависят от данного, рекомендуют

или предлагают его. Что, например, команда

$ apt rdepends zsh

Выведет в таком виде:

И последняя из «информационных» субкоманд первостепенной важности — policy. Она

позволяет определить приоритетность установки разных версий одного пакета. Что особенно

существенно в том случае, если эти версии содержатся в разных репозиториях, например, в

официальном и каком-либо из PPA. Так, вывод команды

$ apt policy cinnamon

в последней сборке Cintu будет следующим: cinnamon:

Установлен: 3.2.7+xenial

Кандидат: 3.2.7+xenial

Таблица версий:

*** 3.2.7+xenial 500

500 http://ppa.launchpad.net/tsvetko.tsvetkov/cinnamon-3-2/ubuntu xenial/main amd64 Packages 100 /var/lib/dpkg/status

2.8.6-1ubuntu1 500

500 http://ru.archive.ubuntu.com/ubuntu xenial/universe amd64 Packages Что показывает приоритетность пакетов Cinnamon из репозитория Tsvetko относительно

официального. А заодно демонстрирует, насколько последний в плане поддержки этой среды

отстаёт от острия прогресса.

Правда, использовать субкоманду policy имеет смысл не после установки спорного в

отношении версии пакета, а до. Дабы удостовериться, что установлена будет нужная его

версия и из подходящего источника. А иногда — что вместо нужного пакета не инсталлируется

одноимённый, но совершенного иного назначения.

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

примером является ситуация с дисплейным менеджером MDM. Его нет ни в официальном

репозитории Ubuntu, ни в большинстве PPA-сборок, кроме репозиториев Гвендаля и Цветко.

Зато в официальном репозитории есть пакет mdm (Middleman System), представляющий собой

набор утилит, помогающих одновременно выполнять команды из shell-скриптов. И во время

своих первых экспериментов по сборке базовой Ubuntu со средой Cinnamon я однажды

установил его вместо M Display Manager'а (именно так расшифровывается аббревиатура MDM).

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

приглашения к авторизации в «голой» консоли.

Так что с тех пор при сборке Cintu я перед установкой MDM (а жэто один из финальных

аккордов процесса) обязательно даю команду

$ apt policy mdm

и внимательно смотрю на её вывод:

$ apt policy mdm

mdm:

Установлен: 2.0.17+xenial

Кандидат: 2.0.17+xenial

Таблица версий:

*** 2.0.17+xenial 500

500 http://ppa.launchpad.net/tsvetko.tsvetkov/cinnamon-3-2/ubuntu xenial/main amd64 Packages 100 /var/lib/dpkg/status

0.1.3-2.1build1 500

500 http://ru.archive.ubuntu.com/ubuntu xenial/universe amd64 Packages Чтобы убедится в том, что это нога у кого надо нога установится тот MDM, который мне нужен.

Интермедия о праве root'а

Субкоманды, предназначенные для изменения статусов пакета, как основных, так и

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

командную конструкцию, изменяющую статус пакета, например:

$ sudo apt install [packagename]

Далее в примерах она будет опускаться, и причин тому две. Первая — очевида: банальная лень

набирать одно и то же.

Вторая причина более существенная: если предполагается вводить много команд от лица

администратора (то есть больше двух — а это обычное дело при подключении PPA-

репозиториев, периодическом обновлении системы и просто при массовой установке и

удалении пакетов), то права его лучше заполучить на неопределённый срок. Что можно

сделать двумя способами. Первый из которых — команда

$ sudo -i

После её выполнении происходит переход в каталог /root, смена регистрационного shell'а на

root'овый и считывание его конфигурационных файлов. То есть это полный аналог команды su

- в системах с активзивированным аккаунтом администратора.

Второй способ — команда

$ sudo -s

Она также даёт пользователю все административные привилегии, однако он сохраняет свою

регистрационную командную оболочку со всеми её настройками. Сохраняется также и

текущий каталог пользователя.

Вид приглашения командной строки изменяется при любом способе получения прав

администратора. Как именно — зависит от конкретных настроек, о которых сейчас говорить

неуместно. А далее в тексте команды, требующие root'овых привилегий, будут предваряться

символом «решётки» — #, чтобы отличать их от пользовательских команд, символизируемым

нашим баксом животворящим — $.

Выбор способа — дело вкуса и привычки. Я практически всегда использую второй, и

рекомендую его применителя системы Cintu (и авторских сборок на базе Neon'а). Ибо и там, и

там по умолчанию для обычного пользователя в качестве login shell используется командная

оболочка Zsh (к которой я привык), тогда как для виртуального root'а в этой роли сохраняется

Bash (который я не люблю и знаю плохо).

Дополнительный плюс второго способа в том, что команды, введённые от лица

администратора, сохраняются в пользовательском ~/.zhistfile, и при необходимости их

можно легко просмотреть, «не прикидываясь root'ом» для этой нехитрой операции. Что, возможно, плохо с точки зрения безопасности. Однако весьма полезно при сочинении

материалов вроде этого.

Вне зависимости от способа обретения прав админисратора, выход из такого псевдо-root'ового

сеанса осуществляется командой

# exit

Которую нужно не забыть выполнить сразу, как только отпадёт необходимость в

административных привилегиях.

Субкоманды изменения статуса

Теперь, вооружившись знаниями о способах получения прав администратора, можно

приступить к рассмотрению субкоманд, изменяющих статус пакета. И самая частая процедура

здесь — изменение статуса «не установленный» на «установленный». Или, попросту говоря, инсталляция пакета, которая обеспечивается субкомандой install с именем пакета (или

именами пакетов — их может быть сколько угодно). Например, команда

# apt install apt-dpkg-ref

установит пакет указанного имени, который содержит краткую справку по опциям утилит

семейств APT и dpkg в различных форматах (HTML, PDF, TeX, etc.).

Установка пакета apt-dpkg-ref начнётся сразу, без запроса подтверждения, потому как в

стандартно установленной системе он не имеет неудовлетворённых записимостей. Если же

таковые обнаружатся — будет выведен их список, сопровождаемый запросом на

подтверждение установки оных вместе с целевым пакетом (или отказа от неё для них для всех).

Например, в mini-редакции Cintu установка пакета Qapt, описанного в части третьей, можно

выполнить командой

# apt install qapt-deb-installer

И вывод её будет выглядеть так:

Избавиться от этого можно (если нужно — точнее, не нужно) с помощью опции -y (или --yes)

— она вызовет немедленную инсталляцию пакета и всех его зависимостей без всяких списков и

подтверждений. Которая, кстати, применима во всех случаях запросов подтверждения, и, как

легко догадаться, означает согласие с ними.

По умолчанию в список зависимостей (Depends) устанавливаемого пакета включаются и его

рекомендации (Recommens), которые при согласии также будут установлены автоматически, все «гуртом». Если это почему-либо нежелательно, следует прибегнуть к опции --no-install-recommends. И тогда повторение предыдущей команды в форме

# apt install qapt-deb-installer --no-install-recommends

Даст перечень рекомендаций отдельно:

При желании здесь можно прервать процесс, и действительно нужные пакеты из числа

рекомендуемых добавить в приведённую выше строку, или же установить отдельной командой.

Предложения пакета (Suggests) в состав зависимостей по умолчанию не включаются, но

присутствуют в в выводе субкоманды install отдельно. Если возникает желание установить

их все вместе в рекомендациями — его легко удовлетворить с помощью опции --install-suggests. С её использованием вывод всё той же команды на установку пакета Qapt будет

таким:

И здесь остаётся заметить только, что умолчальное отношение утилиты apt к зависимостям, рекомендациям и предложениям можно изменить. Но об этом я напишу когда-нибудь в другой

раз, потому как тема эта далеко выходит за рамки воззрений кота Manual'а.

Если в качестве аргумента субкоманды install подставить имя уже установленного пакета —

последует отказ с обяснением причины. Например, в Cintu в ответ на команду

# apt install zsh

будет сказано, что

Уже установлен пакет zsh самой новой версии (5.1.1-1ubuntu2).

Тем не менее, иногда возникает необходимость переустановить запоротый пакет (почему —

говорить сейчас не место и не время) при неизменности его версии в репозитории. И на сей

предмет у субкоманды install существует специальная опция --reinstall, которая и

обеспечивает переустановку. Но — только пакета, указанного в качестве аргумента, его

установленных зависмостей она не затрагивает.

Другое дело, если версия пакета в репозитории изменилась: на этот случай существует

субкоманда upgrade. Но она затрагивает не только «подкомандный» пакет, и потому речь о

ней пойдёт чуть позже.

А сейчас время вспомнить, что иногда пакет хочется не установить сразу, а сначала

посмотреть, «что у него внутре». Для чего файл пакета нужно скачать на локальную машину.

И на этот предмет существует специальная субкоманда — download. Она, единственная из все

в этом разделе, не требует прав администратора. Точнее, может потребовать, но не

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

$ apt download packagename

имеет право на запись в него — никакие root'овые привилегии ему не нужны.

Пакеты по жизни приходится не только устанавливать, но иногда и удалять. Этой цели служат

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

имена — как и в случае с установкой пакетов, аргументов может быть сколько угодно.

Первая из них — remove: она удаляет все файлы пакета, за исключением его общесистемных

конфигов, которые находятся в каталоге /etc и (или) в его подкаталогах. После этого пакет

приобретает основной статус c (см. часть 1).

Вторая субкоманда для удаления пакетов — purge. Она полностью вычищает все входящие в

них файлы, включая и конфигурационные. После её применения пакет обретает основной

статус p — такой же, как у тех, что никогда в данной системе не устанавливались. Правда, эта

субкоманда не затрагивает конфигов в домашнем каталоге пользователя — дабы полностью

порвать с проклятым прошлым, их придётся удалить вручную.

Обе субкоманды, даже не имея никаких зависимостей, по умолчанию требуют подтверждения, прежде чем выполнить своё «чёрное» (или, напротив, «благородное») дело. Избавиться от

которого можно, опять-таки, с помощью опции -y.

Если же пакет имеет зависимые от него пакеты — перед согласием с его удалением будет

выведен их список. С ним надо ознакомиться очень внимательно, ибо его составляющие будут

также автоматически удалены вместе с целевым пакетом. Что может серьёзно сказаться на

работоспособности системы — вплоть до поного её разрушения.

Старожилы Ubuntu (и некоторых других дистрибутивов) помнят времена, когда удаление

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

инсталляции её, получали статус A, то есть автоматически установленных.

Сейчас до таких крайностей, к счастью, дело не доходит. Однако от внимательного чтения

вывода автоматически удаляемых пакетов это не избавляет. Во-избежание, как сказал некогда

один восточный мудрец.

А вот «прямые» зависимости удаляемого пакета, то есть, что были установлены для

обеспечения его работоспособности, ни remove, ни purge не затрагивают. Однако, если от

таких пакетов более не зависит ни один другой пакет в системе — список таких «осиротелых»

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

избавления от них — дать от лица администратора команду

# apt autoremove

Которая в своём выводе повторит список пакетов, обречённых на автоматическое заклание, и

предложит согласиться с их удалением.

Кроме установки и удаления, пакеты нуждаются также в обновлении. Этот процесс начинается

с такой команды:

# apt update

Она устанавливает соединение со всеми репозиториями, перечисленными в файле

/etc/apt/sources.list и файлах внутри каталога /etc/apt/sources.list.d, и приведет

локальный кэш пакетов в соответствие с их версиями на серверах. Субкоманду update следует

применять также после каждого изменения списков репозиториев — как при их добавлении, так и при удалении.

Теперь можно приступить к собственно обновлению системы, для чего послужит команда

# apt upgrade

сравнит версии установленных пакетов с обновленным их кэшем, выявит все компоненты, нуждающиеся в обновлении, скачает соответствующие их версии из сети и заменит ими

пакеты устаревшие. В случае, если новые версии повлекут за собой и новые зависимости, по

сравнению с имевшимися ранее, — они также будут скачаны и установлены. Но перед этим

будет выведен полный список пакетов, нуждающихся в обновлении, число файлов, который

предстоит скачать из сети, и их суммарный объем, значение, на которое возрастет занятое

дисковое пространство в результате всех этих действий, и последует запрос на подтверждение

операции.

Надо заметить, что в некоторых случаях upgrade не сможет выполнить обновление каких-то

пакетов, о чем честно и сообщит перед запросом на подтверждение операции. Причины этому

могут быть разные — например, конфликт новых зависимостей пакетов с каким-либо наличным

софтом. На сей случай мы располагаем более радикальным средством — субкомандой full-upgrade. Именно к нему следует прибегнуть, если мы обновляем старую версию дистрибутива

до нового релиза (и в некоторых других случаях):

# apt full-upgrade

Эта команда просто тотально перепишет все наличные пакеты их обновленными версиями,

одновременно разрешая и новые их зависимости (вплоть до удаления старых конфликтующих

пакетов). Правда, и тут возможны коллизии типа описанной выше, но в большинстве случаев

их можно проигнорировать — они, скорее всего, рассосутся при следующем апдейте и

апгрейде.

Если нет — следует вспомнить об опции --fix-broken, применимой также к субкомандам

upgrade и install (с которой она аргументов не требует). И во всех этих случаях она будет

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

Правда, иногда разрешение противоречий в системе может привести к сносу половины оной —

и потому вывод любой субкоманды с опцией --fix-broken требует особо внимательного

прочтения. Благо, нынче при использовании Ubuntu'идов в штатном (не экспериментальном) режиме к ней прибегать не приходится никогда.

Наконец, последнее слово о субкомандах, требующих административных привилегий. И

установка единичных пакетов, и обновление системы любого рода начинаются со скачивания

из сети файлов пакетов. Которые по умолчанию помещвются в каталог

/var/cache/apt/archives (а файлы пакетов, скачивание которых по каким-то причинам

оборвалось — в каталог /var/cache/apt/archives/partial). И со временем их там

скачивается прилично количество (а иногда просто неприличное). А вот понадобиться эти

файлы пакетов могут только в единичных случаях, да и тогда их проще скачать заново, нежели

отыскать.

Так что избавление от «продуктов жизнедеятельности» применителя любого дистрибутива —

задача если не архиважнейшая, то весьма важная. И в deb based системах она решается

субкомандами clean и autoclean, не требующими аргументов. Первая просто тупо очищает

каталоги, указанные в предыдущем абзаце.

Вторая делает то же самое — но только в отношении пакетов и ихъ версий, более недоступных

в подключённых репозиторях, сохраняя файлы пакетов актуальных. Впрочем, большого

практического смысла в субкоманде autoclean я не вижу.

А вот команду apt clean надо выполнять решулярно. Как и использовать предварительно

такие субкоманды утилиты apt, как update, upgrade и autoremove.

Интермедия об aptitude

Полноты картины следует сказать, что в deb based системах существует ещё один

«продвинутый» менеджер пакетов — программа aptitude. По своим возможностям она

примерно соответствует как паре утилит apt-get и apt-cache, так и утилите apt в

современном её исполнении. Однако предоставляет и некоторые дополнительные функции, до

недавнего времени бывшие уникальными.

Тем не менее, нынче aptitude категорически не рекомендуется к использованию во всех

дистрибутивах семейства Ubuntu и отсутствует в стандартной базовой инсталляции. Кажется, анналогично её положение и в соббственно Debian'е. Причин тому две. Первая — программа

эта давно не развивается, и в ней накопилось достаточно большое количество ошибок, которые

проявляются при разрешении зависимостей.

Вторая же причина — фнкционал aptitude, который некогда был уникальным, ныне почти

полностью перекрывается apt'ом в советании с дополнительными утилитами apt-mark и apt-file, которые будут описаны в следующих разделах.

Тем не менее, утилита aptitude входит в состав ряда клонов Debian. И потому, полноты

картины ради, будет описана в одном из приложений к данному трактату.

Утилита apt-mark

В в утилите apt не предусмотрено простых средств для массового изменения вторичных

статусов пакетов, вроде автоматически установленных или зафиксированных — одна из задач, с которыми хорошо справлялась aptitude, ныне, как уже было сказано, исключённая из рядов

КПСС Core System в Debian’е и Ubuntu. Однако на смену ей ghbikf утилита apt-mark — один из

компонентов пакета apt.

Утилита apt-mark предназначена во-первых, для выявления пакетов, имеющих вторичный

статус установленных вручную или автоматически, пакетов зафиксированных, то есть не

подлежащих обновлению при обновлении, а во-вторых — для изменения этих статусов. Первой

цели служат субкоманды:

showauto, которая выводит список автоматически установленных пакетов; showmanual, делающая то же самое для пакетов, установленных вручную; showhold, выводящая список пакетов с зафиксированными версиями.

Ясно, что все они могут быть выполнены с правами обычного пользователя.

Для изменения статуса с автоматического на «ручной» предназначена субкоманда manual, тогда как субкомандакоманда auto выполняет обратную процедуру. Субкоманда hold фиксирует версию пакета, а unhold — снимает фиксацию. Не менее очевидно, что все они

требуют привилегий администратора.

«Изменяющие» субкоманды могут иметь произвольное число аргументов, что позволяет

выполнять массовое манипулирование пакетами. Это особенно актуально для пакетов, установленных автоматически не как зависимости, а в составе метапакетов, в том числе и при

первичной инсталляции системы. То есть сначала список всех таких пакетов выводится

командой

$ apt-mark showauto | grep [pattern]

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

# apt-mark manual *

После чего они при необходимости могут быть удалены независимо и от включавшего их

метапакета, и от других его компонентов.

Впрочем, в современных версиях Ubuntu и сородичей это не так востребовано, как некогда

(когда, впрочем, утилиты apt-mark ещё не было в природе). Старожилы-убунтийцы помнят

времена, когда удаление какого-нибудь безобидного тамильского шрифта приводило к сносу

всех компонентов метапакета ubuntu-desktop или аналогичного.

Ныне пакеты, установленные при первичной инсталляции в рамках крупных базовых задач

(tasks), маркируются как имеющие статус «ручных», и могут быть удалены без малейшего

вреда для системы. Но в ряде частных случаев субкоманда manual оказывается

востребованной.

А вот про пару hold и unhold можно сказать определённо: она нужна редко, но крепко.

Например, для фиксирования версии ядра — если не собственноручно собранного, то хорошо

подобранного. Или позарез нужного пакета одного из старых релизов, который в релизах более

новых капитально поломали, а то и вообще забросили. Или… да мало ли таких случаев в

жизни, которые требуют исключения из правил?

Утилита apt-file

При работе с пакетами довольно часто возникает задача — определить, какие же файлы входят

в состав того или иного пакета. В deb based системах обычно предлагается решать её или с

помощью самого низкоуровнего средства — утилиты dpkg, или, напротив, посредством

графического фронт-энда для управления пакетами, Synaptic’а. Оба они с этим делом

справляются, при условии, что «препарируемый» пакет, как минимум, скачан на локальную

машину, а при использовании Synaptic’а — ещё и установлен в системе.

Однако нередко состав пакета и хочется посмотреть для того, чтобы решить, стоит ли его

скачивать, а тем более — устанавливать. И тут на помощь приходит утилита apt-file. Она

входит в состав одноимённого пакета, который в базовой инсталляции с mini.iso отсутствует

— здесь его потребуется установить самостоятельно:

# sudo apt install apt-file

После этого первым делом надо запустить команду

$ apt-file update

которая скачает Contents-файлы всех репозиториев, описанных в файле

/etc/apt/sources.list и поместит их в каталог ~/.cache/apt-file примерно в таком

виде:

ru.archive.ubuntu.com_ubuntu_dists_xenial-backports_Contents-amd64.gz ru.archive.ubuntu.com_ubuntu_dists_xenial_Contents-amd64.gz ru.archive.ubuntu.com_ubuntu_dists_xenial-updates_Contents-amd64.gz security.ubuntu.com_ubuntu_dists_xenial-security_Contents-amd64.gz Это — та база, с которой в дальнейшем будет работать утилита apt-file. Очевидно, что

процедуру её апдейта не худо повторять после подключения каждого дополнительного

репозитория. Правда, репозитории, не содержащие Contents-файла (а таковых большинство

среди мелких PPA-репозиториев), всё равно будут проигнорированы.

Для определения состава пакета служит субкоманда list или её псевдоним show. В качестве

аргумента указывается так называемый шаблон (pattern), который может принимать несколько

значений, в том числе и просто имя пакета, например:

$ apt-file list apt-file

apt-file: /etc/apt/apt-file.conf

apt-file: /etc/bash_completion.d/apt-file

apt-file: /usr/bin/apt-file

apt-file: /usr/bin/diffindex-download

apt-file: /usr/bin/diffindex-rred

apt-file: /usr/share/apt-file/apt-file-update.update-notifier apt-file: /usr/share/apt-file/do-apt-file-update

apt-file: /usr/share/apt-file/is-cache-empty

apt-file: /usr/share/doc/apt-file/README

apt-file: /usr/share/doc/apt-file/changelog.gz

apt-file: /usr/share/doc/apt-file/copyright

apt-file: /usr/share/man/man1/apt-file.1.gz

apt-file: /usr/share/man/man1/diffindex-download.1.gz

apt-file: /usr/share/man/man1/diffindex-rred.1.gz

А вот в случае с пакетом apt вывод той же команды будет жутковатым, потому что в команде

$ apt-file list apt

последовательность apt будет воспринята как шаблон, который можно расширить не только до

apt-build или synaptic, но даже до adapter. Для предотвращения этого безобразия

предусмотрена опция --fixed-string, или просто -F, запрещающая развёртывание шаблона.

То есть команда

$ apt-file -F list apt

обеспечит вывод списка файлов только пакета apt и никакого другого. Если отфильтровать его

сквозь grep по ключевому слову, например, bin, можно поимённо узнать все входящие в него

утилиты, для чего ранее была использована команда dpkg:

apt: /usr/bin/apt

apt: /usr/bin/apt-cache

apt: /usr/bin/apt-cdrom

apt: /usr/bin/apt-config

apt: /usr/bin/apt-get

apt: /usr/bin/apt-key

apt: /usr/bin/apt-mark

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

именем. Это можно сделать с помощью утилиты dpkg:

$ dpkg -S filename

Но, опять-таки, только в случае, что искомый пакет установлен в системе. Однако в том-то и

дело, что обычно как раз для отыскания пакета не установленного — такая ситуация будет

описана в трактате о Cintu. И её решение задачи — использование apt-file с субкомандой

search (или её псевдонимом find):

$ apt-file -l find add-apt-repository

software-properties-common

Обращаю внимание на опцию -l: как явствует из её «длинного» имени, --package-only, она

обеспечивает присутствие в выводе только имеми пакета, без неё вывод был бы перегружен

лишней информацией вроде полных путей к исполняемому файлу, man-странице и вообще

всему, что совпадает с шаблоном аргумента.

Утилита apt-file имеет и другие опции, среди которых:

--ignore-case (сокращённо -i), предписывающая игнорировать регистр символов;

--regexp, она же -x, позволяющая использовать в шаблоне регулярные выражения;

-- обозначающая конец опций; она необходима, если шаблон начинается с дефиса.

За остальными опциями — как обычно, к тёте Мане. От которой можно узнать и о последней

внутренней команде apt-file, purge, действие которой противоположно update — она

удаляет локальные Contents-файлы, что может потребоваться при переключении на другие

репозитории.

В приведённом ранее выводе команды

$ apt-file list apt-file

можно видеть, что в пакет apt-file входит ещё две утилиты — diffindex-download и

diffindex-rred. Они выступают в качестве средств обеспечения «титульной» утилиты, позволяя при последующих апдейтах скачивать лишь патчи Contents-файлов и совмещать их с

локальными.

Часть 5. Synaptic

Система управления пакетами Synaptic — интегрирующий графический фронт-энд для

нескольких утилит семейства APT, обычно используемых для работы с пакетами deb-формата, а

в некоторых дистрибутивах — и с пакетами rpm.

Введение

Как ни странно, Synaptic появился не в Debian, и вообще не в deb based системах: первые его

версии были созданы в бразильском дистрибутиве Connectiva — том самом, разработчики

которого впервые прикрутили apt для управления rpm-пакетами, назвав это дело apt-rpm.

Создателем Synaptic’а был Альфредо Кодзима (Alfredo Kojima), а позднее им занимался Густаво

Нимейер (Gustavo Niemeyer), оба являвшиеся тогда, на рубеже тысячелетий, сотрудниками

фирмы Connectiva. И исключительно фронт-эндом к apt-rpm и выступал Synaptic в начальную

пору своей жизни.

После покупки Connectiva фирмой Mandrakesof (в январе 2005 года) связка apt-rpm и Synaptic была благополучно похерена в недрах объединённой Mandriva — в пользу собственных

инструментов, urpmi и rpmdrake. Однако сама идея оказалась очень продуктивной — и ещё в

2001 году Михаэль Фогт (Michael Vogt) «дебианизировал» Synaptic, приспособив его для работы

с собственно deb-пакетами. Хотя Фогт и по сей день является основным майнтайнером

upstream-версии пакета, среди пользователей Debian’а, насколько мне известно, он широкого

распространения не получил — предпочтение здесь отдавалось сначала aptitude, а затем и

поныне — собственно apt-утилитам.

Звёздный час Synaptic’а наступил с появлением в октябре 2004 года первой версии Ubuntu.

Будучи основанным на библиотеке Gtk, он сразу и гармонично вписался в тогдашнее GNOME-

окружение этого дистрибутива. И с темх пор в ряде случаев Synaptic оказывается самым

эффективным средством для работы с пакетами.

Обзор

Как только что говорилось, Synaptic — это интегрирующая надстройка над утилитами

семейства apt, а потому предоставляет все функции, обеспечиваемые утилитами apt-get и

apt-cache, а также и ряд дополнительных. В их числе:

поиск пакетов в репозиториях с определением их состояния и статуса; их установку и обновление с автоматическим разрешением зависимостей; удаление пакетов, в том числе и включая их зависимости;

обновление базы данных пакетов из репозитория;

тотальное обновление системы.

Кроме того, Synaptic включает средства настройки — в частности, доступа к репозиториям. В

Mint для этой цели вызывается собственная утилита smintsource.

Штатный способ запуска Synaptic’а выполняется через главное меню, папример, в Cintu nfr: Администрирование -> Менеджер пакетов Synaptic или панели фаворитов: Очевидно, что установка и удаление пакетов потребует прав администратора, запрос на

получение каковых (посредством механизма sudo, то есть с вводом пользовательского пароля) и последует после вызова Synaptic’а через меню:

Если отказаться от ввода пароля, то Synaptic таким способом запущен не будет. Однако его

таки можно запустить и от лица обычного пользователя — из командной строки терминала или

минитерминала прямой командой:

$ synaptic

В этом случае появится такое предупреждение:

Из которого явствует, что запущенный в пользовательском режиме Synaptic можно

использовать для поиска пакетов и получения информации о них, но не для манипуляций с

пакетами — соответствующие пункты меню или пиктограммы панели просто не будут

активизированы.

Так что нормальный режим работы Synaptic’а — административный. И после ввода пароля

пользователя можно будет видеть окно примерно такого вида:

Как явствует из скриншота, в окне Synaptic’а мы имеем следующие основные элементы

интерфейса:

строку меню;

панель инструментальных кнопок;

два главных фрейма — список разделов репозитория и список пакетов выбранного

раздела (по умолчанию показываются все пакеты);

фрейм с кнопками выбора критериев для вывода пакетов;

фрейм свойств конкретного пакета.

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

предыдущем скриншоте. Но заполняется контентом при свершении выбора: в правом нижнем

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

соответствующего пакета (буде таковой существует и имеет смысл): А при правом клике на имени пакета появляется контекстное меню:

Здесь-то, в пункте Свойства, и содержится информация о пакете. Во-первых, общие сведения о

нём:

Далее — перечень зависимостей:

В следующей вкладке — список установленных файлов и путей к ним, доступный только для

установленных пакетов:

Перечень версий, доступных в подключённыхрепозиториях:

И последнее — описание пакета

Теперь рассмотрим критерии вывода пакетов. С группировкой пакетов по разделам всё более-

менее ясно, тем более, что названия разделов почти все даны в русском переводе, а те

немногие, что оставлены в оригинале (например, World Wide Web), и без перевода понятны:

Следующий критерий отбора — по состоянию пакетов. После нажатия соответствующей

кнопки в левом главном фрейме выводится список категорий, зависящий от текущего

состояния системы, например, в таком виде:

Происхождение пакетов фиксирует принадлежность пакетов к разделу официального

репозитория или тому-или иному PPA-репозиторию:

В числе специальных фильтров — списки пакетов, для которых доступны обновления, списки

неустановленных рекомендаций для инсталлированных пакетов, и так далее: Название кнопки Результаты поиска говорит само за себя:

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

на него внимательно, то слева можно увидеть две колонки пиктограмм. В первой из них

отмечается текущее сосотяние пакета — установлен ли он, отмечен для установки или

удаления, и так далее.

Наличие пиктограммы во второй колонке означает, что пакет поддерживается в офицальном

репозитории, отсутствие — происхождение его из какого-либюо стороннего источника

(например, из некоего PPA-репазитория). Полную расшифровку значений пиктограмм можно

получить через систему встроенной помощи: меню Справка -> Описание значков:

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

Отметить для повторной установки — то есть реинсталляции, аналог команды apt reinstall;

Отметить для удаления — удаление данного пакета с сохранением его конфигов, аналог команды apt remove;

Отметить для полного удаления — удаление данного пакета вместе с его конфигами, но не затрагивая зависимостей, аналог команды apt purge;

Свойства — его мы уже рассмотрели.

Кроме того, из того же контекстного меню можно отметить для установки рекомендации и

предложения данного пакета:

Для пакета не установленного по умолчанию доступны два пункта — Отметить для

установки (аналог команды apt install) и всё те же Свойства. Активизация пунктов

Отметить для установки… рекомендуемые и предлагаемые пакеты зависит от общих

настроек Synaptic’а, к которым мы со временем вернёмся.

Подчеркну, что все отметки через контекстное меню не влекут за собой немедленной

установки, обновления или удаления пакетов — эти действия будут выполнены только после

надатия кнопки Применить.

Теперь двинемся вверх по основным элементам интерфейса главного окна Synaptic’а. Как уже

говорилось, выше двух главных фреймов обнаруживается инструментальная панель, а на ней

кнопки. Первой из них идёт кнопка Обновить — это ни что иное, как перечитывание базы

репозиториев пакетов, тех, которые были определены в настройках (о чем будет говориться

далее).

То есть, по простому, происходит выполнение команды apt update, замаскиврованное

графическим интерфейсом. И за ходом процесса можно наблюдать воочию:

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

как обновляемые. А для претворения обновлений в в действительность предназначена

следующая кнопка, Применить — предложение выполнить над пакетами, отмеченными для

установки, обновления или удаления, соответствующие действия.

Кнопка Свойства вызывает ту же самую панель, что и одноимённый пункт контекстного

меню.

О поиске через инструментальную панель стоит поговорить отдельно. Потому что систем

поиска там… не сказать чтобы совсем две, но уж полторы точно. Во-первых, это поле

Быстрый поиск, которое как раз и есть «в половинных», потому что имеется дялеко не во

всех сборках Synaptic'а.

Однако там, где оно имеется — предназначено для наращиваемого поиска в списке правого

главного фрейма в соответствие с разделами, выбранными во фрейме левом. То есть, если в

последнем выбрать раздел Все, а в поле ввести gnu, мы получим список всех пакетов, содержащих эти символы в имени, в резюме или в описании:

Если же мы укажем точное (или предполагаемое) имя пакета (например, gnumeric), то

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

имени этого пакета, ни в его кратком описании слова «gnumeric» мы не увидим. Потому что

это пример поиска в полных описаниях — тех самых, которые выводятся в нижнем правом

фрейме (или в закладке Общие панели Свойства).

А вот кнопка Найти имеет место быть во всех сборках Sypatic'а. И она как раз и позволяет

варьировать область поиска и его критерии:

По умолчанию поиск проводится в именах пакетов и их описаниях. Однако область поиска

можно ограничить только именами. Кроме того, поиск можно выполнять по имени

майнтайнера пакета, номеру версии, зависимостям или предложениям: Наконец, самый верхний интерфейсный элемент окна — строка главного меню. Однако на как

раз на меню мы останавливаться не будем: смысл его пунктов в общих чертах понятен из

названий, И к тому же по большей части они дублируются меню контекстным и кнопками

инструментальной панели. Так что скажу-ка я лучше пару слов о настройке Synaptic’а.

Настройка

Как легко догадаться, за настройки Synaptic’а отвечает одноимённый пункт главного меню, содержащий подпункты:

Параметры;

Репозитории;

Фильтры;

Установить внутренний параметр;

Панель инструментов.

Рассмотрим их последовательно.

Пункт Параметры (или Preferences) вызывает панель со множеством вкладок, позволяющих

настроить общее поведение Synaptic’а:

Основное;

Столбцы и шрифты;

Цвета;

Файлы;

Сеть;

Дистрибутив.

Вкладка Основное, кроме внешнего вида (включение или выключение чекбокса о показе

информации в главном окне), позволяет установить ряд очень важных параметров:

Например, Подтверждать изменения, которые могут подействовать на другие пакеты —

разумеется, лучше держать эту опцию включённой, как оно и есть по умолчанию.

Важно также определиться с опцией Рассматривать рекомендуемые пакеты как

зависимости, то есть считать их обязательными к установке. По умолчанию она включена, что совпадает с умолчальной конфигурацией утилиты apt, (как и в обычном apt. Так что если

использовать apt и Sinaptic попеременно, лучше эту опцию не трогать — или изменить её и

там, и там, во избежание путаницы.

Выпадающее меню Удаление пакетов определяет, удалять ли их полностью (аналогично

команде apt purge), что установлено по умолчанию, или сохранять конфигурационные файлы

(как при команде apt remove).

Меню пункта Обновить систему позволяет установить, использовать ли по умолчанию

стандартное обновление, интеллектуальное (то есть с попыткой разрешения противоречий

зависимостей) или выбирать метод обновления по запросу. Последнее время проблем с

интеллектуальным обновлением, вроде, не отмечалось, так что можно остановиться на этом

методе (тем более что он установлен по умолчанию).

В выпадающем меню Обновление устаревших сведений о пакетах можно выбрать пункты

— Всегда спрашивать, Автоматически или Игнорировать. Представляется, что первая, умолчальная, будет лучшим выбором.

Во вкладке Столбцы и шрифты, во-первых, определяется набор колонок вывода информации

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

для Synaptic’а.

Смысл установок во вкладке Цвета вполне очевиден:

Во вкладке Файлы определяется, надо ли хранить в локальном кэше скачанные файлы

пакетов, сохранять ли историю установок, а также задаётся время хранения файлов истории.

Имеется и кнопка для принудительной очистки каталога /var/cache/apt/archives:

Во вкладке Сеть при необходимости можно задать адреса прокси-серверов http и ftp, буде

таковые используются:

И, наконец, во вкладке Дистрибутив указывается режим обновления дистрибутива в рамках

текущей версии — по умолчанию отмечен пункт Предпочитать версии из:, и в выпдающем

меню выбран пункт текущего релиза (в данном случае — xenial):

Далее в меню Настройки идёт пункт Репозитории. Выбрав его, можно, во-первых

просмотреть список всех подключённых репозиториев, в том числе и неактивированных, и при

необходимости — активировать что-либо из последних:

Репозитории из списка можно удалить совсем (с помощью кнопки Delete). А можно

ограничиться их временной деактивацией — и в ряде случае это имеет резоны

Далее, с помощью кнопки New можно подключить какую-либо ветвь официального

репозитория, указав его тип (бинарный или исходник) и просто заполнив соответствующие

поля — в примере их значения даны для ветки proposed:

Кстати, ветка proposed — как раз пример одного из тех репозиториев, которые в обыденной

жизни лучше держать в неактивном состоянии. Потому что иногда пакеты из него

действительно нужны. Но их нахождение там — всегда явление временное: после тестирования

они либо переходят в одну из основных веток, либо исключаются.

Тем же образом можно добавлять и PPA-репозитории. В примере ниже это проделано для

репозитория Цветко Цветкова, содержащего актуальную (на момент сочинения этих строк) версию Cinnamon 3.2. Обращаю внимание, что в поле URL заносится http-адрес репозитория, а

не его PPA-имя, как при использовании команды add-apt-repository: После довавления любого репозитория следует предложение обновить локальный кеш пакетов, не соглашаться с которым нет никаких резонов:

Смысл пункта Фильтры поиска (вспомним, что они фигурируют у нас среди кнопок левого

нижнего фрейма главного окна Synaptic’а) в том, чтобы включить (или выключить) те или иные

критерии поиска:

В пункте Установить внутренний параметр можно задать некие переменные для Synaptic’а, и определить их значения. Впрочем, необходимости в этом я до сих пор не испытывал, и

потому говорить не буду.

Ну а с пунктом Панель инструментов всё проще некуда — здесь устанавливается вид её

кнопок: в виде только значков, только текста или их комбинации; можно также скрыть

инструментальную панель вообще:

На этом настройки Synaptic’а можно считать законченными. Как, впрочем, и вообще разговор

о нём. А уж чем пользоваться на предмет управления пакетами, утилитой ли командной строки

apt сотоварищи, или графической оболочкой Synaptic — следует решать по ситуации.

Приложение 1. Конспекты

В приложениях к Воззрениям кота Manual'а на deb-пакеты собраны материалы двух категорий.

Первая — конспекты. В части 4 вскользь был упомянут пакет apt-dpkg-ref. Автором его

является Мэттью Дэниш (Matthew Danish), и представляет он собой краткую справку по

опциям и субкомандам утилит dpkg и APT. На английском, разумеется, языке, зато во

всякоразных форматах.

Основываясь на этой идее, я сгруппировал в приложении 1 конспекты по установщикам

пакетов — утилитам CLI dpkg (на русском языке) и gdebi и по утилите apt в её современном

исполнении.

Вторая группа приложений — описание утилиты aptitude в двух режимах её работы —

интерактивном и командном. Оно вынесено за пределы основного материал потому, что, как

уже говорилось, утилита эта нынче не особенно рекомендуется к использованию. Но, тем не

менее, в ряде клонов Debian'а она сохраняется в установке по умолчанию, и может быть

полезной. Кроме того — кто знает? Может она когда-нибудь и получит дальнейшее развитие.

Если нет — исторического интереса она не потеряет точно.

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

Краткая справка по опциям утилиты [code]dpkg[/code]:

dpkg -i [package.deb] — установка пакета, предварительно скачанного на локальную

машину;

dpkg -c [package.deb] вывод списка файлов, входящих в данный пакет;

dpkg -L [package] вывод списка файлов установленного пакета; dpkg -I [package.deb] вывод информации о данном пакете;

dpkg -s [package] вывод информации об устанолвенном пакете; dpkg -r [package] удаление установленного пакета с сохранением конфигов; dpkg -P [package] полное удаление пакета, включая конфиги;

dpkg -S [file] поиск установленных пакетов в базе данных, содержащих указанный

файл.

Краткая справка по утилите gdebi

Формат команды:

# gdebi [опции] [package.deb]

Опции:

-n, --non-interactive — неинтерактивный режим (без подтверждения действий);

-q, --quiet — подавление вывода информации о ходе выполнения;

--apt-line — эмуляция установки пакета с выводом списка его зависимостей.

Утилита apt

Конспект по субкомандам и опциям утилиты apt разделяется на три группы. В первой —

субкоманды для получения информации самой утилите и справки о ней. Во второй —

субкоманды для получения инфрормации о пакетах. Субкоманды первой и второй групп могут

запускаться от лица обычного пользователя. В третьей группе — субкоманды, связанные с

манипуляцией пакетами, и потому требующие привилегий администратора.

Об apt

apt help — вывод справки (то же — по «голой» команде apt);

apt --version — номер версии пакета apt.

Информационные субкоманды и их опции

apt list --all-versions (или без опций) — вывод списка всех пакетов в

подключённых репозиториях, с опцией --installed — только установленных, с опцией

--upgradeable — пакетов, для которых доступны обновления;

apt search [шаблон] — поиск пакетов по имени и шаблону в описаниях; apt show package — вывод информации о пакете;

apt depends package — вывод списка зависимостей пакета;

apt rdepends package — вывод списка зависимых пакетов;

apt policy package — вывод списка доутпных версий пакета с указанием приоритета

при установке.

Модифицирующие субкоманды и их опции

apt install package[s] — установка пакета (пакетов); с опцийе --no-install-recommends — установка без рекомендаций, с опцией --install-suggests — установка

вместе с предложениями; с опцией --fix-broken — попытка исправления «сломанных»

зависимостей (применимо также к субкомандам upgrade и full-upgrade (ни в одном

случае результат не гарантирован).

apt download package — скачивание пакета в текущий каталог без его установки

(можно запускать от имени обычного пользователя, если тот имеет право записи в

последний);

apt update — обновление кеша пакетов;

apt upgrade — обновление всех установленных пакетов;

apt full-upgrade — глобальное обновление системы;

apt remove package[s] — удаление пакета (пакетов) с сохранением конфигов; apt purge package[s] — «чистое» удаление пакета (пакетов);

apt autoremove — удаление «осиротелых» зависимостей;

apt clean — удаление скачанных файлов пакетов.

3. Утилита apt-mark

Субкоманды утилиты apt-mark, подобно таковым apt, служат, во-первых, для определения

вторичного статуса пакетов, что не требует прав суперпользователя. В во-вторых, для

изменения оного — и в этом случае должны запускаться с правами администратора.

Субкоманды определения статуса

apt-mark showauto — вывод списка автоматически установленных пакетов; apt-mark showmanual — вывод списка пакетов, установленных вручную; apt-mark showhold — вывод списка пакетов с зафиксированными версиями.

Субкоманды изменения статуса

apt-mark manual package[s] — изменение статуса с «автоматически установленный»

на «установленный вручную»;

apt-mark auto package[s] — изменение статуса с «установленный вручную» на

«установлен автоматически»;

apt-mark hold package[s] — фиксация версии пакета (пакетов); apt-mark unhold package[s]

— снаяти фиксации версий.

Утилита apt-file

Утилита apt-file служит для определения состава пакета, во-первых, и для поиска пакетов, содержащих определённый файл, во вторых. Ни в том, ни в другом случае изменений в системе

она не вызывает, и потому запускается от имени обычного пользователя.

Установка

Утилита apt-file может отсуствовать в стандартной инсталляции конкретного дистрибутива.

Установить её можно так:

# apt install apt-file

Субкоманды

apt-file update — создание и обновление базы Contents-файлов подключённых

репозиториев; должна быть выполнена перед первым запуском и в дальнейшем

повторяться при изменении списка подключённых репозиториев; apt-file list|show [шаблон] — вывод списка файлов пакетов, совпадающих с

шаблоном; с опцией --fixed-string, или -F, запрещающей развёртывание шаблона, последний воспринимается как точное имя пакета;

apt-file search|find [шаблон] — поиск пакетов, содержащих файлы, совпадающие

с шаблоном; с опцией --package-only, или -l, вывод ограничивается базовым именем

пакета;

apt-file purge — очистка кеша Contents-файлов.

Опции

Некоторые опции применимы ко всем субкомандам, требующим аргументов:

--ignore-case, или -i — игнорирование региста символов в шаблонах;

--regexp, или -x — использование в шаблонах регулярных выражений;

-- конец опций; необходимо, если шаблон начинается с дефиса.

Приложение 2. Утилита aptitude

Программа aptitude — пакетный менеджер, функционально примерно соответствующий как

паре утилит apt-get и apt-cache, так и утилите apt. Однако по сравнению с обоими

инструментами управления пакетами она предоставляет некоторые дополнительные

возможности.

Общее вступление

Программа aptitude ныне не очень настойчиво рекомендуется к применению в Debian'е и

совсем не рекомендуется — в дистрибутивах семейства Ubuntu. Однако воззерния кота

Manual'а в отношении её заслуживают места хотя бы в приложениях к основному материалу.

Во-первых, полноты картины радди, а во-вторых — потому, что она по прежнему используется в

ряде «чистых» клонов Debian'а, например, в MX Linux.

Программа aptitude была создана в 1999 году Дэниелом Барроузом (Daniel Burrows) в

качестве замены dselect — архаичной и неудобной в использовании надстройки над

утилитами семейства dpkg. Впервые она была включена в Debian 2.2 (так называемый potato), и с тех пор утвердилась в этом дистрибутиве в качестве штатного средства управления

пакетами.

Существует мнение, что aptitude выступает в качестве фронт-энда по отношению к утилитам

семейства APT. Однако это не совсем так: aptitude и APT независимы друг от друга, но

основаны на одном и том же наборе библиотек libapt.

Программа aptitude представлена во всех deb based дистрибутивах. Она рекомендуется к

употребелнию в собственно Debian'е, а в ткаих его клонах, как Siduction и Aptosid выступает

пакетным менеджером по умолчанию. Теоретически работает она и в Ubuntu со всеми его

производными, и почти всегда присутствует в установке по умолчанию. Однако здесь главным

средством управления пакетами в командной строке является семейство утилит APT И на

практике оказывается, что совместное использование apt и aptitude не целесообразно. И

потому резонные люди не рекомендуют применение последней в системах, основанных на

Ubuntu, в том числе и в Linux Mint. Именно поэтому о ней не говорилось в книге, посвящённой

этому дистрибутиву. А вот в LMDE, базовая часть которой целиком заимствована из Debian'а,

никаких препятствий к применению aptitude не просматривается. Хотя, честно говоря, имея

в руках Mint-реализацию утилиты apt, я ни разху не ощутил потребности в ней.

Как известно, полный набор утилит семейства APT обеспечивает весь мыслимый комплекс

действий с пакетами — от установки единичного пакета с отслеживанием всех его

зависимостей до полной пересборки системы из исходников, подобно тому, как это делается в

дистрибутивах Source Based.

Программа aptitude не столь универсальна по своему назначению. Функции ее сводятся к

установке и удалению пакетов и получению информации о них. Однако и то, и другое она

делает не просто хорошо, а очень хорошо. Она хорошо показывает себя в отслеживании

зависимостей и разрешении связанных с ними коллизий, в том числе и в нетривиальных

случаях. А главная её сила — в гемоглобине возможностях поиска пакетов по шаблонам —

здесь она просто не имеет себе равных.

Программа aptitude работает в текстовом режиме и предполагает два метода использования

– интерактивный, через основанный на ncurces интерфейс, и командный - непосредственно из

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

него мы и начнём.

Интерактивный режим

Основное применение aptitude в интерактивном режиме — установка системы с помощью так

называемого алтернативного инсталлятора, применяемого в Ubuntu Server, Lubuntu и при

установке с mini.iso

Обзор интерфейса

Для запуска aptitude в интерактивном режиме достаточно дать одноименную команду без

опций, операторов и аргументов. Причем для ознакомления с возможностями программы это

можно сделать и от лица обычного пользователя — во избежание случайных ошибок. Когда же

потребуется выполнить реальные действия над пакетами — пароль администратора будет

запрошен.

После запуска aptitude перед нами предстает ее интерактивный текстовый интерфейс, основанный на библиотеке ncurses. Рабочее пространство программы разбито по умолчанию

на три части: вверху — строка меню и краткая справка по наиболее употребимые горячим

клавишам, в середине — разворачиваемый список категорий, внизу — поле описания пакетов.

Доступ к пунктам меню, развертывание списков и тому подобные манипуляции

осуществляются с клавиатуры. Однако, если aptitude собрана с поддержкой gpm (а в LMDE

так оно и есть, ножно только не забыть установить соответствующий пакет), то те же действия

можно выполнять и посредством мыши. Причем при запуске её в окне иксового терминала

работает и колесо прокрутки, правда, довольно странно, построчно.

Организация главного меню интерактивной aptitude, как мы скоро убедимся, не являет собой

торжества логики. Активизация выполняется по комбинации клавиш Control+T, после чего в

нём можно видеть следующие пункты:

Действия (Actions) — выполнение действий, "заказанных" в пункте Пакет; Откат (Undo) — отмена выполненных действий;

Пакет (Package) — "заказ" действий с пакетами для выполнения в пункте Действия; Решатель (Resolver) — здесь решаются проблемы с зависимостями; Поиск (Search) — предлагается догадаться самим; Параметры (Options) настройка интерфейса, работы с зависимостями и кое-какие

прочие;

Окна (Views) — открытие и закрытие новых "окон" (которые правильней назвать

вкладками);

Справка (Help) — она же Помощь.

При правильной локализации интерфейс программы почти полностью русскоязычный. Если

это почему-либо раздражает, то запустить aptitude можно таким образом: $ LANG="POSIX" aptitude

Перемещение по пунктам — стрелками управления курсором или мышью, деактивизация меню

— клавишей Escape.

Логику создателей интерактивного меню aptitude понять довольно сложно, поэтому мы

будем рассматривать его не в установленном ими порядке, а в том, в каком задействуются на

практике.

А на практике работу aptitude надо начинать с её настройки (что верно и для подавляющего

большинства программ), для чего предназначен пункт Параметры. Однако как раз это дело

мы оставим напоследок — после обзора остальных пунктов меню, иначе непонятно будет, что

тут настраивать.

Так что в реальности для знакомства с возможностями программы первым нам потребуется

пункт Пакет, в котором пакеты отмечаются для того, чтобы в дальнейшем с ними выполнить

заказанные действия с помощью подпунктов одноимённого пункта меню. Смысл большинства

подпунктов пункта Пакет вполне очевиден:

Тем не менее, пробежимся по ним беглой рысью.

в пунктах Установить (Install), Удалить (Remove) и Удалить полностью (Purge) отмечаются пакеты, предназначенные для установки, удаления с сохранением конфигов

и удаления "вчистую", соответственно;

пункты Оставить (Keep) и Удержать (Hold)-- фиксирую версии пакетов при единичном

ближайшем апгрейд и навеки (или до принудительной отмены фиксации); пункты Отметить как установленные автоматически и Отметить как

установленные вручную принудительно задают пакетам соответствующий статус, вне

зависимости от того, как они были установлены на самом деле.

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

потому для предназначения пакетов к установке или удалению достаточно прав пользователя.

Но фиксация версий и изменение дополнительного статуса вносят изменение в локальный кэш

пакетов, что требует прав администратора, о чём и выводится соответствующее

предупреждение.

Так что, закончив развлекуху с предопределением судьбы пакетов, самое время отправиться в

пункт Действия главного меню. Где мы видим следующую картину: Назначение подпункта Установить/удалить пакеты очевидно — это реальное выполнение

соответствующих действий над отмеченными в пункте Пакет пакетами. А также приводит к

исполнению всх прочих заказов.

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

помечает в локальном кэше пакеты, для которых доступны обновления; само по себе

обновление будет выполнено при переходе к первому подпункту.

Подпункт Забыть о новых пакетах заставляет не учитывать категорию New Packages. А

Очистить кэш пакетов приводит к удалению файлов пакетов, скачанных в процессе

жизнедеятельности aptitude, находящихся в каталоге /var/cache/apt/archives/.

Действие подпункта Очистить устаревшие файлы сходно, но он вызывает удаление файлов, соответствующих только пакетам устаревших версий.

Подпункт Играть в сапёра позволяет убить время в ожидании скачивания и установки

пакетов.

Наконец, Стать суперпользователем именно это и означает, если aptitude была запущена

от пользователя обычного. Все пункты из меню Действия требуют прав администратора

(кроме игры в сапёра — это баловство доступно и простому юзеру). Так что в этом пункте будет

выведено приглашение sudo ввести пароль пользователя:

[sudo] password for alv:

Права администратора можно получить и иным путём — выбором одного из действий в этом

пункте, что вызовет предложение Стать суперпользователем: И при согласии опять же последует приглашение sudo:

Мы рассмотрели два наиболее востребованных пункта главного меню, остальные затронем уж

совсем вкратце и по порядку.

Смысл пункта Откат понятен скорее по английски (Undo) — не ожидайте от его выбора каких-

либо денег.

Пункт меню Решатель вызывает у меня некоторое недоверие, я им никогда не пользовался, и

потому изучение его возможностей оставляю на усмотрение заинтересованных лиц.

В пункте Поиск, как легко догадаться, осуществляется поиск пакетов вперед и назад, причём

по умолчанию инкрементно:

Здесь же, через подпункт Найти неработоспособные можно отыскать и так называемые

"сломанные пакеты" — на скриншоте они выделены кумачом: Приведённый пример взят из моей самосборной Pure Betsy, и таких кумачовых строк в

довольно много. Они не означают, что в моей системе что-то неправильно: они вызваны

удалением ряда метапакетов, которые мне по жизни не нужны, и жить это не мешает ни в

малейшей степени.

Пункты меню Окна позволяют создавать несколько вкладок разного назначения, например, для списка пакетов, их категорий, рекомендаций и так далее. Разумеется, в каждый момент

можно видеть только что-то одно, но между этими списками легко переключаться в любом

направлении:

Некоторые вкладки возникают как бы самопроизвольно. Так, при обращении к пункту

Параметры, доступный для настройки их список выводится в новой вкладке. Открытие

каждого подпункта меню Справка также создаёт отдельную вкладку. И подчас нужно

довольно долго переключаться между открытыми вкладками, чтобы добраться, наконец, до

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

клавишами (см. далее). Или — мышью через собственно tab-подобные вкладки.

Пункт Справка очень важен: в нем можно не только получить краткие подсказки по статусу

пакетов, доступным действиям, горячим клавишам, но и прочитать весьма подробное

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

задаваемых вопросов.

Перемещению по меню стрелками управления курсором или мыши, что не всегда оказывается

быстро, есть альтернатива — использование горячих клавиш.

Горячие клавиши

Практически все действия, доступные через главное меню aptitude, могут быть выполнены и

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

предпочтительным. Полный комментированный (на русском языке) список хоткеев можно

посмотреть через пункт Справка -> Справка: Правда, список этот совершенно не структурирован, и потому воспринимается тяжко. Так что

я позволю себе ограничиться краткой шпаргалкой для наиболее употребимых из горячих

клавиш, зато сгруппировав их по назначению.

Хоткеи для отметки

+ — отметить пакет для установки (или снять фиксацию версии);

- — отметить пакет для удаления с сохранением конфигов; _ — отметить пакет для удаления "вчистую";

: — зафиксировать версию пакета для ближайшего обновления;

= — зафиксировать текущую версию пакета навеки (или до снятия фиксации); M — отметить пакет как установленный автоматически;

m — отметить пакет как установленный вручную.

Хоткеи для действий

g — выполнение заказанных действий над отмеченными пакетами; на самом деле по

первому нажатию клавиши " g" только выводится список "заказанных" пакетов; сами по

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

U — обновление локального кэша пакетов;

V — отметка обновляемых;

f — забыть о новых пакетах;

q — выход из aptitude или её Справки.

Хоткеи для поиска

/ — прямой поиск;

\ — обратный поиск;

n — повторный прямой поиск;

N — повторный обратный поиск;

b — поиск "сломанных" пакетов.

Хоткеи для вкладок

F6 — переключение на следующую вкладку;

F7 — переключение на предыдущую вкладку;

q — закрытие вкладки.

Кроме того, не вредно помнить, что комбинация клавиш Control+T активизирует меню, комбинация Control+U отменяет последнее действие, а горячая клавиша ? вызывает ту

справку, которая внутри пункта Справка.

Настройка интерфейса

Кое-какие вещи в умолчальном интерфейсе интерактивной aptitude могут показаться

непривычными и (или) неудобными. Честно говоря, автору этих строк в ней кажется

непривычным и неудобным почти всё. Но его примирение с этой программой обусловлено, во-

первых, удобством её командной ипостаси (о чём речь впереди) и, во-вторых, тем, что

некоторые возможности настройки интерфейса таки имеют место быть.

Как нетрудно догадаться, они выполняются через главное меню: Параметры -> Предпочтения, после чего в новой вкладке выводится список доступных для изменения

параметров, объединённых в три секции:

Настройки интерфейса;

Работа с зависимостями;

Разное.

В настоящий момент нас будет интересовать только первая секция, касающаяся интерфейса.

Как можно видеть из следующего скриншота, тут всё довольно просто, потому что каждый

настраиваемый параметр прокомментирован, причём при нашей умолчальной локали — по

русски:

Так что я вкратце изложу свои соображения по поводу включения или выключения отдельных

пунктов. Разумеется, всё сказанное ниже — не более чем ИМХО.

Показывать некоторые из доступных команд вверху экрана — по первости лучше

оставить в умолчальном (то есть включённом) состоянии; но при регулярном

использовании интерактивной aptitude надобность в этой подсказке быстро исчезает; Скрывать строку меню, когда она не используется — эту опцию (по умолчанию она

отключена) я включил бы сразу, ибо действия через меню, как уже говорилось, довольно

медленны; да и при необходимости вызвать его всегда можно комбинацией клавиш

Control+T;

По возможности использовать строку ввода внизу экрана — при включении этой

опции строка ввода будет расположена внизу экрана, в выключенном состоянии (по

умолчанию) ввод будет показан в виде всплывающего диалогового окна; дело вкуса, для

меня удобнее первый вариант;

Показывать результаты частичного поиска (инкрементный поиск) —

единственным аргументом против этой опции (включённой по умолчанию) может быть

только ну исключительная слабость машины;

Завершать работу программы при закрытии последнего окна — учитывая

следующий пункт, ничему не мешает;

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

есть При возникновении ошибки;

Использовать индикатор скачивания «status-line» для всех скачиваний — по

умолчанию выключено, но мне кажется удобным;

Показывать область информации по умолчанию — включено по умолчанию, и

лучше оставить по крайней мере до окончания настроек зависимостей, а там — как

больше понравится; я оставляю;

Показывать закладки для доступных окон — безусловно, лучше оставить

включённым, ибо наглядно и проще переключаться;

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

Перейти к следующему элементу после изменения состояния пакета — по

умолчанию по выполнении действия с пакетом происходит возврат к исходному списку

категорий, если включить эту опцию — к следующему пакету из списка; в чем

необходимости не вижу, поскольку с пакетами редко приходится работать по их порядку

в списках;

Автоматически показывать причину неработоспособности пакетов — при

включении (как по умолчанию) для "сломанных" пакетов в области информации будут

показаны зависимости, которые не могут быть удовлетворены;

При запуске показывать список пакетов вместо стандартного дерева —

включение опции выводит при запуске программы "плоский" список всех пакетов в

алфавитном порядке, без всякого структурирования, что мне кажется неудобным.

Остальные пункты секции настройки интерфейса касаются методов группировки экрана

пакетов, формата представления окон пакетов, строки состояния и заголовка. Через

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

aptitude, куда и я пошлю любознательных читателей (сам, каюсь, этих разделов руководства

не читал за неактуальностью).

Настройки интерфейса интерактивной aptitude выполняются от лица обычного пользователя

и, соответственно, имеют силу только в его сеансе, ибо отражены в файле

~/.aptitude/config — обычном текстовом файле, доступном и для прямого редактирования.

aptitude и зависимости

Настройка работы с зависимостями в aptitude не обязана сводиться к установке

соответствующих параметров интерактивного меню, но может потребовать и правки

конфигурационного файлв. Который. напомню, называется ~/.aptitude/config и по

умолчанию выглядит так:

aptitude "";

aptitude::Ignore-Recommends-Important "true";

aptitude::Keep-Unused-Pattern "";

aptitude::Delete-Unused-Pattern "";

(END)

То есть — почти никак: все умолчальные параметры считываются сначала из файла

/usr/share/aptitude/aptitude-defaults, а затем из конфиголв в каталоге

/etc/apt/apt.conf.d. Из всего, что имеет отношение к зависимостям, можно видеть только

строку игнорирования рекомендаций. Так что продолжим наши развлечения с зависимостями, перейдя к соответствующей секции:

Здесь всё происходит точно так же, как и при настройке интерфейса: каждая опция

прокомментирована, и остаётся только решить, нужна ли она именно вам.

Для первых двух опций, Автоматически разрешать зависимости выбираемого пакета и

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

пакетов) утрачивает смысл.

А вот с опцией Автоматически устанавливать рекомендуемые пакеты возможны

варианты. Дело в том, что обычно используемая в Ubuntu для установки пакетов утилита apt-get, в отличие от aptitude, рекомендованные пакеты по умолчанию не устанавливает. И для

приведения работы этих программ в соответствие друг с другом есть резон отключить эту

опцию. В этом случае в конфиг aptitude добавится такая строка: Apt::Install-Recommends "false";

С другой стороны, для графических фронт-эндов к APT, таких, как Symantic и Muon Package Manager, напротив, рекомендованные зависимости устанавливают. Подозреваю, что и Центр

приложений ведёт себя аналогично. Так что может понадобиться вернуть умолчальное

значение. В этом случае та же строка приобтетёт вид:

Apt::Install-Recommends "true";

В общем, тут следует принимать волевое решение в соответствие со своими наклонностями. И

при этом не следует забывать, что каково бы ни было значение этой опции в конфиге, при

установке единичного пакета оно всегда может быть инвертировано опциями кмоандной

строки, о чём будет сказано на соответствующей странице.

Возможно, что читатель, помимо рекомендованных зависимостей, пожелает по умолчанию

устанавливать также и предлагаемые. Сделать это через интерактивное меню нельзя, но легко

решается добавлением в ~/.aptitude/config одной строки:

$ echo 'Apt::Install-Suggests "true";' >> .aptitude/config

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

нужны, лучше устанавливать в индивидуальном порядке.

Опция Автоматически удалять неиспользуемые пакеты включена по умолчанию — и, полагаю, таковой должна и оставаться, иначе система будет захламлена неиспользуемыми

библиотеками и тому подобным мусором.

Что же до пункта Пакеты, которые никогда не будут автоматически удалены, то, как

нетрудно понять, он содержит список шаблонов имён пакетов, "неудаляемых" при установке

новых их версий. По умолчанию в этот список включены маски имён образов ядра и его

модулей:

^linux-image.*$ | ^linux-restricted-modules.*$ | ^linux-ubuntu-modules.*$

И трогать их не надо. А вот чем дополнить список — решать пользователю (при условии, что он

знает, что делает).

Опция Позволить разрешение зависимостей не обращая внимание на фиксации и

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

некоторых пакетов и запрещается их обновление, чтобы это отменять.

Вообще-то опций конфигурирования для aptitude предусмотрено великое множество.

Ознакомиться с полным их набором и их умолчальными значениями можно, прочитав файл

/usr/share/aptitude/README. Это английская версия, существуют пего переводы на ряд

других языков, русского среди которых нет.

А теперь, покончив со вторым пунктом, который про свободу Африке зависимости, пора

завершить тему частью Разное. Где тоже не так много опций: И включение/отключение их сугубо субъективно. Разве что опцию Автоматически

обновлять установленные пакеты я бы однозначно оставил в умолчальном (то есть

отключённом) состоянии. Ну и изменять URL для скачивания списков изменений я бы тоже

поостерёгся. Да, Показать, что будет сделано, перед тем как делать — часто раздражает.

Но даёт некоторую паузу во времени — чтобы последний раз подумать перед сносом всей

системы.

Командный режим

Как можно было видеть из обзора интерактивной aptitude, эта программа предоставляет

очень широкие возможности по управлению пакетами. Что, однако, компенсируется — да

простят меня её поклонники — неудобством и крайней нелогичностью интерфейса. Это если не

говорить о визуальной заторможенности даже на современных машинах. И потому aptitude гораздо эффективней использовать в командном режиме — если уж использовать вообще.

Введение

Командный метод использования aptitude не будет непривычен тому, кто знаком с утилитами

apt-get и apt-cache. Конструкция ее директив предполагает наличие оператора и, обычно, также аргумента — имени пакета, шаблона имени, ключевого слова или фильтра. Кроме того, операторы могут предваряться специфичными для них опциями.

Командные директивы с использованием основных операторов можно сгруппировать

следующим образом:

директивы поиска;

директивы вывода информации;

директивы манипуляции с пакетами;

директивы манипуляции со статусом;

директивы обновления системы;

директивы "очистки";

разные разности.

Очевидно, что все операторы команды aptitude, служащие для получения информации о

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

страницах это символизируется использованием $ в качестве приглашения командной строки.

Операторы, вносящие изменения в систему, требуют привилегий администратора — и их

желательно временно получить посредством команды sudo aptitude ... для выполнения

единичной директивы или sudo -s на неопределённый срок. Использование sudo -i, меняющей всё пользовательское окружение, не рекомендуется, так как настройки aptitude делаются в аккаунте обычного пользователя.

Особенности aptitude проще всего рассмотреть на примере конкретных командных директив.

После чего можно будет провести сравнение с другими пакетными менеджерами. Я

ограничусь примерами, которые кажутся мне (на основе собственного опыта) наиболее

частыми. Больше подробностей по использованию aptitude можно найти в официальном

руководстве, написанном её создателем — Дэниелом Барроузом. Оно имеет версии на

нескольких языках, среди которых русского опять не обнаруживается.

Поиск пакетов

Резонные люди обычно начинают работу с пакетами поиском нужного для установки пакета. В

случае с aptitude это делается так:

$ aptitude search keyword

ответом на что будет список всех пакетов, в названии которых имеется указанное ключевое

слово — по умолчанию aptitude не ищет заданное слово в описаниях пакетов. В отличие от

apt, вывод aptitude содержит также информацию о статусах пакета — основном и, если

имеется, дополнительном. Так, поиск по ключевому слову aptitude: $ aptitude search aptitude

даст примерно следующий вывод:

i A aptitude — средство управления пакетами с текстовым интерфейсом

p aptitude:i386 — средство управления пакетами с текстовым интерфейсом

i A aptitude-common — не зависящие от архитектуры файлы для менеджера пакетов aptitude p aptitude-dbg — отладочные символы для менеджера пакетов aptitude p aptitude-dbg:i386 — отладочные символы для менеджера пакетов aptitude v aptitude-doc -

p aptitude-doc-cs — Руководство по консольному менеджеру пакетов aptitude на чешском языке

p aptitude-doc-en — руководство на английском языке для aptitude p aptitude-doc-es — Руководство по консольному менеджеру пакетов aptitude на испанском

языке

p aptitude-doc-fi — Руководство по консольному менеджеру пакетов aptitude на финском языке

p aptitude-doc-fr — Руководство по консольному менеджеру пакетов aptitude на французском

языке

p aptitude-doc-it — Italian manual for aptitude, a terminal-based package manager p aptitude-doc-ja — Руководство по консольному менеджеру пакетов aptitude на японском языке

Вместо ключевого слова оператору search в качестве аргумента можно задать фильтр. Он

предваряется символом тильды ~. В качестве фильтра можно задать условия поиска, например, в именах пакетов:

$ aptitude search ~naptitude

Что эквивалентно приведённой выше умолчальной форме директивы. А для поиска в описаниях

пакетов можно использовать такую конструкцию:

$ aptitude search '~daptitude'

Что даст куда более длинный вывод:

p apt-cacher — кеширующий прокси-сервер для работы с репозиторями пакетов Debian p apticron — Simple tool to mail about pending package updates i A aptitude — средство управления пакетами с текстовым интерфейсом

p aptitude:i386 — средство управления пакетами с текстовым интерфейсом

i A aptitude-common — не зависящие от архитектуры файлы для менеджера пакетов aptitude p aptitude-dbg — отладочные символы для менеджера пакетов aptitude p aptitude-dbg:i386 — отладочные символы для менеджера пакетов aptitude p aptitude-doc-cs — Руководство по консольному менеджеру пакетов aptitude на чешском языке

p aptitude-doc-en — руководство на английском языке для aptitude p aptitude-doc-es — Руководство по консольному менеджеру пакетов aptitude на испанском

языке

p aptitude-doc-fi — Руководство по консольному менеджеру пакетов aptitude на финском языке

p aptitude-doc-fr — Руководство по консольному менеджеру пакетов aptitude на французском

языке

p aptitude-doc-it — Italian manual for aptitude, a terminal-based package manager p aptitude-doc-ja — Руководство по консольному менеджеру пакетов aptitude на японском языке

p cron-apt — автоматическое обновление пакетов с помощью apt-get p cupt — alternative front-end for dpkg — console interface p cupt:i386 — alternative front-end for dpkg — console interface p dselect — утилита для управления пакетами Debian

p dselect:i386 — утилита для управления пакетами Debian

p gbrainy — brain teaser game and trainer to have fun and to keep your brain trained p libcwidget-dev — high-level terminal interface library for C++ (development files) p libcwidget-dev:i386 — high-level terminal interface library for C++ (development files) p pkgsync — automated package list

Можно также выбирать пакеты, входящие в определённые секции (~sname) или (задачи

~tname). Например, директива

$ aptitude search '~sgnome'

выберет все пакеты, входящие в секцию gnome, а конструкция

$ aptitude search '~tubuntu-desktop'

выведет список пакетов, составляющих задачу ubuntu-desktop.

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

в строгие кавычки, как в приведённых примерах. В используемой по умолчанию в Ubuntu оболочке bash в большинстве случаев можно обойтись без них. Хотя и вреда от кавычек не

будет ни малейшего.

Литеры, используемые для фильтров, легко запомнить, если осознать простую их мнемонику: n — от name,

d — от description,

s — от section,

t — от task,

m — от maintainer.

Ключевое слово после литеры — это просто последовательность символов, поэтому на запрос

вида

$ aptitude search 'napt'

последует вывод из длинного списка пакетов, не обязательно имеющих отношение к утилитам

семейства APT. Чтобы избежать этого, можно прибегнуть к регулярным выражениям, таким

же, как используются, например, в утилите grep. Так, директива

$ aptitude search 'n^apt'

отфильтрует только пакеты, начинающиеся с apt.

В директивах поиска можно использовать и логические операторы. Так, команда

$ aptitude search '~n^apt' '~n^dpkg'

выловит пакеты, имеющие отношение к apt и dpkg — логический оператор И подразумевается

по умолчанию. Конструкция вида

$ aptitude search '~n^apt|~n^dpkg'

свяжет аргументы оператора поиска логическим ИЛИ. А вот в команде

$ aptitude search '~n^apt!~n^aptitude'

символ восклицательного знака означает логическое отрицание: в её выводе будут

присутствовать пакеты, начинающиеся на apt, за исключением пакетов, содержащих в своем

имени aptitude в начальной позиции.

Пакеты можно также фильтровать по их статусу. Так, команда

$ aptitude search '~i'

выведет список всех инсталлированных пакетов, а команда

$ aptitude search '~U'

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

Запросы по ключевой последовательности символов можно комбинировать с запросами по

статусу. Так, команда

$ aptitude search '~i~naptitude'

i A aptitude — средство управления пакетами с текстовым интерфейсом

i A aptitude-common — не зависящие от архитектуры файлы для менеджера пакетов aptitude из всего множества пакетов, имеющих отношение к aptitude, выберет только установленные

в системе. А команда

$ aptitude search '~i~tubuntu-desktop'

проделает то же самое для пакетов, установленных в составе соответствующего метапакета.

Здесь я привёл лишь некоторые примеры запросов на поиск пакетов, которые использую более-

менее регулярно. А вообще-то эта тема лимитируется только потребностями и фантазией.

Информация о пакетах

Следующий этап применения aptitude — получение информации о тех пакетах, которые

можно заподозрить в полезности. Этой цели служит оператор show, требующий аргумента в

виде имени пакета. Например, информация о самом пакете aptitude выглядит так: $ aptitude show aptitude

Пакет: aptitude

Состояние: установлен

Автоматически установлен: да

Версия: 0.6.8.1-2ubuntu2

Приоритет: необязательный

Раздел: admin

Сопровождающий: Ubuntu Developers

Архитектура: amd64

Размер в распакованном виде: 4 855 k

Зависимости: aptitude-common (= 0.6.8.1-2ubuntu2), libapt-pkg4.12 (>= 0.9.3), libboost-iostreams1.49.0 (>= 1.49.0-1), libc6 (>= 2.14), libcwidget3, libept1.4.12 (>= 1.0.9), libgcc1 (>= 1:4.1.1), libncursesw5 (>= 5.6+20070908), libsigc++-2.0-0c2a (>= 2.0.2), libsqlite3-0 (>=

3.6.5), libstdc++6 (>= 4.6), libtinfo5, libxapian22

Рекомендует: sensible-utils, apt-xapian-index, libparse-debianchangelog-perl Предлагает: aptitude-doc-en | aptitude-doc, tasksel, debtags Конфликтует: ia32-apt-get (< 22), ia32-apt-get (< 22), aptitude Описание: средство управления пакетами с текстовым интерфейсом

aptitude — утилита для управления пакетами со множеством полезных функций, в том числе: mutt-подобный синтаксис для удобного поиска пакетов, отложенное

выполнение запрошенных пользователем действий (как у dselect), получение и вывод на экран

списка изменений для большинства пакетов и параметры

командной строки как у apt-get.

Также aptitude занимает немного места и следит за чистотой системы, удаляя ненужные более

вспомогательные пакеты.

Сайт: http://aptitude.alioth.debian.org/

Здесь мало чего заслуживает комментирования. Разве что хотел бы обратить внимание на

пункт Зависимости: в их списке можно увидеть libapt, но самого apt'а не найти. Это —

свидетельство того, что aptitude не является фронт-эндом для последнего, о чём уже

упоминалось в прошлом очерке.

Оператор show показывает, от каких пакетов зависит тот, что указан в качестве её аргумента.

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

помощью оператора why. Например, директива

$ aptitude why aptitude

покажет, для каких пакетов зависимостью является пакет aptitude i tasksel Зависит aptitude (>= 0.2.15-1)

А оператор why-not, напротив, выведет список пакетов, которые с данным сосуществовать не

могут по тем или ниным причинам:

$ aptitude why-not aptitudep

B dpackage:i386 Предоставляет dpackage

pB dpackage:i386 Предлагает apt:i386

pB apt:i386 Предлагает aptitude:i386 | synaptic:i386 | wajig:i386

p aptitude:i386 Конфликтует aptitude

Установка и удаление пакетов

Установка выбранных пакетов осуществляется посредством оператора install, требующем в

качестве аргумента имени пакета:

# aptitude install package_name

При этом последовательно будут выполнены следующие действия:

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

/etc/apt/source.list, и PPA-репозиториев, которым соответствуют файлы в каталоге

/etc/apt/sources.list.d (файлы эти — те же, что и для утилит семейства APT); скачивание deb-пакета из Сети, помещение его в локальный кэш пакетов (в каталог

/var/cache/apt/archives);

распаковка архива, инкорпорация его компонентов в файловую систему и, при

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

При разрыве связи во время скачивания пакета его уже полученный фрагмент помещается в

каталог /var/cache/apt/archives/partial/, и повторение процедуры install продолжает

докачку с места обрыва.

Оператор install команды aptitude, в отличие от одноименного из apt-get, по умолчанию

получает из репозитория, помещает в локальный кэш, устанавливает и настраивает не только

"жесткие" зависимости пакета (собственно depends), но и часть "мягких" (те, что относятся к

категории recommends). На усмотрение пользователя остается только установка "мягких"

зависимостей из категории suggests. Хотя, такое положение можно изменить — или

соответствующими настройками, или, как мы увидим далее, опциями командной строки.

Установка версий пакетов осуществляется в соответствие с описанием их локального кэша.

Каковой время от времени (а также после подключения дополнительных репозиториев) нуждается в обновлении. Это осуществляется посредством оператора update, в аргументах не

нуждающегося.

Пакет, «испорченный» по какой-либо причине (например, неаккуратным вмешательством в

конфигурационные файлы) можно «починить». Команда

# aptitude reinstall package_name

вернет его в первозданное состояние.

Установленные пакеты, оказавшиеся не нужными, могут быть удалены. Директива

# aptitude remove package_name

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

Именно таким пакетам присваивается статус c, что маркируется соответствующей литерой в

выводе команды aptitude search. Полная же очистка системы от всех следов пакета

достигается применением оператора purge:

# sudo aptitude purge package_name

В этом случае пакет в выводе команды aptitude search маркируется литерой p, то есть

становится неотличимым от пакета, которого в системе никогда не было. Однако оператор

purge не удаляет конфигурационные файлы пакета из домашнего каталога пользователя — это

придется проделать самостоятельно.

Можно удалить сразу несколько пакетов. Для этого не всегда нужно перечислять их в качестве

аргументов оператора remove или purge. В некоторых случаях можно прибегнуть к удалению

по маске, то есть к конструкции типа

# aptitude purge ’~nzsh’

В данном примере будут бесследно удалены все пакеты, имеющие компонент zsh в своем

имени.

По умолчанию оба оператора удаления — и remove, и purge, — деинсталлируют не только

пакет, указанный в качестве аргумента, но и все те, которые были установлены автоматически

в качестве его зависимостей — разумеется, только в том случае, если в системе не осталось

других программ, которые их используют.

Ранее говорилось о возможности инверсии умолчального отношения к рекомендованным

зависимостям. Так, избежать принудительного выполнения "рекомендаций" можно с помощью

опции -R (или --without-recommends), данной в командной директиве установки

конкретного пакета. Напротив, если игнорирование "рекомендаций" запечатлено в

конфигурационном файле как умолчальное, установить их для отдельного пакета можно, прибегнутв к опции -r (--with-recommends), которая инвертирует действие опции -R, то есть

заставит установить все рекомендуемые зависимости.

Должен предупредить: применение опции -R к установленной системе Ubuntu требует

осторожности. Базовая ее инсталляция осуществляется по принципу "плюс recommends". И

применение к ней aptitude -R делает как бы "ненужными" многие пакеты. Так что перед

тем, как нажать Enter в ответ на предложение

Хотите продолжить? [Y/n/?]

внимательно прочтите весь предшествующий ему вывод. Впрочем, привычка читать вывод

перед тем, как "давить батоны", не будет лишней при работе с любой программой...

Командная aptitude: изменения статуса пакетов

На странице про интерактивную aptitude говорилось о возможности изменения статуса

пакетов через её меню. Однако и в командном режиме это делается ничуть не сложнее. Так, перманентно зафиксировать версию пакета (пакетов) можно с помощью директивы

# aptitude hold package_name

Это придаст перечисленным статус h, в результате чего они будут игронироваться при

тотальном обновлении системы. Обратная процедура, то есть снятие фиксации версии, выполняется командой

# aptitude unhold package_name

Если версия пакета должна быть зафиксирована только на одну, ближайшую, операцию

обновления, надо прибегнуть к директиве

# aptitude keep package_name

Для изменения дополнительного статуса A, очень важного при управлении пакетами, используется пара операторов markauto и unmarkauto. Первый помечает именованный пакет

или их группу по шаблону как установленные автоматически в качестве зависимостей. Так, командой

# aptitude markauto ’~slibs’

в качестве автоматически установленных (статус A) будут помечены все пакеты из секции libs

— то есть практически все библиотеки. Следствием чего явится автоматическое удаление

неиспользуемых библиотек после деинсталляции последнего зависимого от них пакета.

Если же для некоторых библиотек это по каким-либо причинам нежелательно, их можно

"размаркировать" (то есть снять дополнительный статус A) командой

# aptitude unmarkauto package_name

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

Обращаю внимание на символ # в приведённых примерах: он подчёрикает, что все операции по

изменению статуса пакетов требуют прав root'а, так как связаны с изменением локального

кеша.

Командная aptitude: обновление системы

Программа aptitude позволяет выполнить и тотальное обновление системы, причём в двух

различных режимах safe-upgrade и full-upgrade. Правда, оба они начинаются с

обновления локального кэша, то есть выполнения директивы

# aptitude update

После чего можно переходить собственно к обновлению. И для начала — в его "безопасном"

варианте, то есть в режиме

# aptitude safe-upgrade

Без указания аргумента (или аргументов) эта директива обновит все установленные пакеты на

новые их версии, доступные в репозитории. Но только в том случае, если это не повлечёт за

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

зависимостей, уже имеющихся. Если то или другое явление имеет место быть — нас об этом

проинформируют, но сама процедура обновления выполнена не будет. И тогда можно будет

прибегнуть к директиве

# aptitude full-upgrade

Она выполнит принудительное обновление системы, то есть: для всех обновляемых пакетов при

необходимости установит новые пакеты-записимости и удалит старые.

В двух словах: safe-upgrade обновит все пакеты системы, если это не потребует изменения

их "списочного состава", full-upgrade приведёт последний в соответствие с новыми

реалиями.

Если в качестве аргументов любого из операторов указать список пакетов, то, как легко

догадаться, обновлению подвергнутся только в нём поименованные — при тех же условиях.

Важно, что пакеты, имеющие статус h (то есть с зафиксированной версией), не подвергнутся

обновлению ни при выполнении оператора safe-upgrade, ни при dist-upgrade.

Как и при выполнении оператора install, процедуры safe-upgrade и full-upgrade безболезненно переживают разрыв связи (или, например, прерывание по нажатию клавишной

комбинации Control+C): повторный их запуск возобновляет установку с момента прерывания.

Очистка системы

Как уже говорилось на одной из предыдущих страниц, установка пакетов начинается с их

скачивания из сети и помещения в каталог /var/cache/apt/archives. И сами собой они

оттуда не удаляются, зазря занимая место на диске. Хотя в большинстве случаев ни для чего

уже не нужны никому (за исключением некоторых специальных случаев): при необходимости

переустановки пакета обычно его проще скачать заново, и часто уже обновлённый.

Разумеется, при наличии нормального подключения к сети — но в ином случае применение

Ubuntu не целесообразно вообще, лучше поискать дистрибутив, не столь ориентированный на

онлайн.

То же самое бедствие, только в ещё больших масштабах, имеет место быть при регулярном

обновлении системы — в этом случае в означенном каталоге скапливаются просто

геологические напластования разных версий одних и тех же пакетов.

Благо, aptitude позволяет избавиться и от промежуточных продуктов собственной

жизнедеятельности. Для начала — deb-файлов тех пакетов, которые ныне не установлены в

системе (то есть устаревших версий — при регулярном употреблении операторов safe-upgrade и full-upgrade их накапливается изрядное количество). Делается это так:

# aptitude autoclean

Если deb-файлы устаревших версий пакетов не нужны заведомо, то те, что соответствуют

версиям актуальным, теоретически могут пригодиться — например, для переноса

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

тоже предусмотрена специальная директива:

# aptitude clean

Которая полностью очистит каталог /var/cache/apt/archives.

Разные разности

Командная aptitude «умеет много гитик», с которыми можно ознакомиться в документации к

этой программе. И рассмотрение которых я оставляю заинтересованным лицам. Здесь же

хотелось бы упомянуть одно одной из таких «гитик» — возможности тэгирования пакетов. То

есть присвоения некоему их набору пользорвательского тэга (user-tag) с произвольным

именем. Это можно сделать при установке пакетов:

# aptitude install --add-user-tag myset [package list]

То есть присвоить указанный тэг набору своих любимых приложений. А можно проделать это в

любой момент времени после установки пакетов с помощью конструкции вида:

# aptitude add-user-tag myset geany pidgin abiword gnumeric И в дальнейшем использовать этот тэг для поиска:

$ aptitude search '?user-tag(myset)'

избирательного обновления

# aptitude safe-upgrade '?user-tag(myset)'

и прочих манипуляций. При наличии некоторой толики фантазии механизму тэгирования

пакетов можно придумать немало применений.

Если необходимость в тэгировании пакетов отпала, тэги легко ликвидировать такой командой:

# aptitude remove-user-tag tag_name

В общем, после знакомства с aptitude можно сделать вывод, что она предоставляет все

возможности, обеспечиваемые утилитами apt-get и apt-cache плюс ряд дополнительных, подчас неоценимых, удобств. И потому использование ее в командном режиме, казалось бы, предпочтительно перед указанными средствами комплекта APT. Однако реалзизация apt для

Mint обеспечивает практически тот же функционал — за исключением разве что, сложного

поиска по шаблонам. Однако читатель сам сможет сделать заключение: использовать ему

aptitude или нет.

Document Outline

Воззрения кота Manual’а на deb-пакеты

Часть 1. Пакеты

Пакеты, зависимости, библиотеки

Формат deb-пакетов

Статус пакетов

Средства для работы с пакетами

Часть 2. Установщики пакетов

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

Утилита gdebi…

… и её «морды»

Утилита Qapt

Заключение

Часть 3. Репозитории

Репозитории

Устройство репозиториев Ubuntu

PPA-репозитории

Подключение PPA-репозиториев

Часть 4. Инструментарий apt

Вступление

Субкоманды определения статуса

Интермедия о праве root'а

Субкоманды изменения статуса

Интермедия об aptitude

Утилита apt-mark

Утилита apt-file

Часть 5. Synaptic

Введение

Обзор

Настройка

Приложение 1. Конспекты

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

Утилита apt

Об apt

Информационные субкоманды и их опции

Модифицирующие субкоманды и их опции

3. Утилита apt-mark

Субкоманды определения статуса

Субкоманды изменения статуса

Утилита apt-file

Установка

Субкоманды

Опции

Приложение 2. Утилита aptitude

Общее вступление

Интерактивный режим

Обзор интерфейса

Горячие клавиши

Настройка интерфейса

aptitude и зависимости

Командный режим

Введение

Поиск пакетов

Информация о пакетах

Установка и удаление пакетов

Командная aptitude: изменения статуса пакетов

Командная aptitude: обновление системы

Очистка системы

Разные разности