Следующий шаг на пути к применению Cintu — это доукомплектация системы прикладными пакетами. А возможно, и полная перекомплектация её — ведь приложения Малой редакции пподбирались, исходя из наших с Мануалом предпочтений, которые не обязаны совпадать с предпочтениями применителей. И потому Глава 7 будет посвящена главному средству управления пакетами — утилите apt.

Вступление

Утилита apt в её современном виде (начиная с версии 1.6) перекрывает 90% всего, что может потребоваться применителю в этом благородном деле. А с сопутствующими утилитами apt-mark и apt-file — и все 146%. Она подробно описана в «Воззрениях кота Мануала». И здесь о ней будет говориться только применительно к системе Cintu

Пакеты — это своего рода программные кванты, на которые делится система или дистрибутив. Это могут быть и простые монофункциональные утилиты (например, строчный текстовый редактор ed или архиватор tar), более или менее обширные наборы функционально связанных программ (скажем, coreutils) или составные части огромных программных комплексов (примером чему — рабочая среда Cinnamon). В Cintu, как и в её родительской системе Ubuntu (и прародительской — в Debian’е) используются пакеты deb-формата (за подробностями — к коту Мануалу).

Ключевым для пакетов является понятие зависимостей. Суть его в том, что пакет packagename1 для сборки, установки и (или) функционирования требует наличия в системе пакета packagename2, тот, в свою очередь, может потребовать пакета packagename3, и так далее.

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

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

То есть первая категория «мягких» зависимостей как бы более нужная, нежели вторая. И потому в современной версии утилиты apt рекомендуемые пакеты по умолчанию устанавливаются точно так же, как и пакеты depends. Впрочем, как будет показано в дальнейшем, это можно изменить либо опциями команды apt, либо её настройками. Нужно ли это делать — другой вопрос.

Предлагаемые пакеты утилитой apt автоматически не устанавливаются — выводится лишь их список, дабы применитель сам принял решение по данному вопросу. Опять же теоретически и это изменяемо — предлагаемые пакеты тоже можно включить как depends, дабы они устанавливались автоматически. Но вот этого, пожалуй, делать не нужно — кроме, возможно, единичных случаев.

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

Кроме зависимостей, для пакетов deb-формата важно также понятие их приоритета. Оно отражает степень необходимости пакета для функционирования системы, например: обязательный (required), без которого работа системы невозможна, основной (base) и важный (important), также оказывающиеся практически необходимыми, стандартный, то есть имеющийся практически в любой полнофункциональной Linux-системе, дополнительный (optional) — тут уж степень важности каждый должен решать для себя.

Классификация пакетов

В системах пакетного менеджмента deb based дистрибутивов (в том числе и в Cintu) пакеты объединяются в категории, секции и группы. Список категорий включает следующие пункты:

• Установленные пакеты — очевидно из названия;
• Обновляемые пакеты — установленные пакеты, для которых в репозитории доступны более новые версии;
• New Packages — пакеты, добавленные в локальный кэш после последней его очистки;
• Неустановленные пакеты — пакеты, отсутствующие в системе, но доступные из репозиториев;
• Виртуальные пакеты — не существующие пакеты, указывающие на другие пакеты, которые нужно использовать для тех или иных задач;
• Задачи (Tasks) — группы пакетов (метапакеты), которые предоставляют лёгкий способ выбора заранее сформированного набора пакетов под определённую цель.

Задержимся на различии между двумя последними категориями — понимание этого момента весьма важно. Виртуальные пакеты на самом деле пакетами не являются — им не соответствуют никакие реально существующие deb-файлы, которые можно было бы скачать. Они являются только средством идентификации реальных пакетов на основании общих, логических критериев — предоставляемого сервиса, совместимости со стандартной программой или ранее созданным пакетом и т.д.

Примерами виртуальных пакетов являются www-browser, x-display-manager или x-terminal-emulator. Полный список виртуальных пакетов можно видеть здесь.

Метапакеты, в отличие от пакетов виртуальных — настоящие пакеты, то есть реально существующие deb-файлы. Однако их содержимое — лишь список пакетов, предназначенных для достижения той или иной цели. Например, метапакет ubuntu-minimal содержит список пакетов, обеспечивающих базовый функционал системы любой системы на основе Ubuntu, а в метапакете geany-gtk3-plugins содержится полный список плагинов для текстового редактора Geany.

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

Группы представляют собой разделы официального репозитория. В дистрибутивах, основанных на Ubuntu, они таковы: main, restricted, universe, multiverse, о чём речь пойдёт позднее.

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

Статус — очень важное понятие в терминологии deb-пакетов. Во-первых, каждый пакет имеет основной статус, обозначаемый строчной литерой. В их число входят:

i (от install) — установленный пакет;
p (от purge) — пакет не установленный или деинсталлированный «вчистую» (то есть с удалением его конфигурационных файлов);
c (от clean) — пакет, деинсталлированный с сохранением конфигурационных файлов;
v (от virtual) — виртуальный пакет, этот статус присваивается пакетам одноимённой категории.

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

A (от Auto) — установленный автоматически, как зависимость другого пакета; пакеты, не имеющие статуса A, считаются установленными вручную;
h (от hold) — пакет с фиксированной версией (то есть не подверженный апгрейду);
u (от unpacked) — пакет распакованный, но не установленный;
H — «недоустановленный» пакет;
C — пакет установленный, но не настроенный;
B — «сломанный» пакет, то есть установленный с нарушением зависимостей.

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

В сущности, все действия по управлению пакетами в дистрибутивах, использующих deb-формат, сводятся к определению их текущего статуса и его изменению. До недавнего времени для этого требовался ряд инструментов CLI (утилиты dpkg, gdebi-core, apt-cache и apt-get) и/или их графические фронт-энды («морды» для Gdebi, Qapt, Synaptic). Однако ныне, как уже говорилось, практически все необходимые действия можно выполнить с помощью универсальной утилиты apt: она является и менеджером пакетов, работающим с удалёнными репозиториями, и полностью перекрывает функционал локальных установщиков пакетов.

Репозитории

Утилита apt предназначена в первую очередь для работы с репозиториями. И потому её рассмотрение начнём с обзора официальных и неофициальных репозиторинв дистрибутивов семейства Ubuntu, а также методов их использования.

Что такое репозитории

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

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

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

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

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

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

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

Мы с котом Мануалом и сами активно поддерживаем озвученный взгляд. Почему до сих пор так и не набрался наглости величать нашу Cintu дистрибутивом. Ибо она основывается, с одной стороны, на официальных репозиториях проекта Ubuntu, с другой — на нескольких PPA-репозиториях с Launchpad’а, которые и будут последовательно рассмотрены в ближайших разделах.

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

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

Проще всего с устройством репозиториев с точки зрения применителя можно ознакомиться просмотром их списка в файле /etc/apt/sources.list, который создаётся автоматически при инсталляции. В Ubuntu и любом её «чистом» (не обязательно официальном) клоне, в том числе и в Cintu, при согласии с предлагаемыми в ходе стандартной установки умолчаниями он в обязательном порядке содержит следующие строки (не считая закомментированных):

deb http://ru.archive.ubuntu.com/ubuntu/ bionic main restricted
deb http://ru.archive.ubuntu.com/ubuntu/ bionic universe
deb http://ru.archive.ubuntu.com/ubuntu/ bionic multiverse
deb http://ru.archive.ubuntu.com/ubuntu/ bionic-updates main restricted
deb http://ru.archive.ubuntu.com/ubuntu/ bionic-updates universe
deb http://ru.archive.ubuntu.com/ubuntu/ bionic-updates multiverse
deb http://security.ubuntu.com/ubuntu bionic-security main restricted
deb http://security.ubuntu.com/ubuntu bionic-security universe
deb http://security.ubuntu.com/ubuntu bionic-security multiverse

Здесь первый компонент в каждой строке, deb, означает, что речь идёт о бинарных пакетах (про пакеты с исходниками я скажу чуть позже). Далее следует «базовый» URL репозитория, соответствующий тому зеркалу сервера, которое было выбрано при установке системы — в наших условиях оно будет или российским (как в примере), или официальным http://archive.ubuntu.com/ubuntu/. Последнее отнюдь не является показателем русофобии — известны прецеденты, когда обновления всех зеркал насколько запаздывали супротив официоза.

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

• просто bionic — в неё входят собственно пакеты дистрибутива;
• bionic-updates — «обычные» обновления пакетов, связанные со сменой версий, сборок и исправлением ошибок;
• bionic-security — как нетрудно догадаться, обновления, латающие «дыры» в безопасности системы.

Кроме того, каждом релизе Ubuntu имеются ещё две ветки — они носят имена bionic-backport и bionic-proposed: обе они содержат обновлённые версии некоторых пакетов из последующих релизов, первая — уже официально «утверждённые», вторая — проходящие «обкатку». Кстати, пакеты из второй ветки не обязательно попадут в первую.

Для подключения ветки с backport’ированными пакетами при установке любого «чистого» клона Ubuntu нужно отметить соответствующую опцию, что в Cintu сделано по умолчанию:

deb http://ru.archive.ubuntu.com/ubuntu/ bionic-backports main restricted universe multiverse

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

deb http://ru.archive.ubuntu.com/ubuntu/ bionic-proposed main restricted universe multiverse

Наконец, в то же файле /etc/apt/sources.list есть и такая строка:

# deb http://archive.canonical.com/ubuntu bionic partner

Это репозиторий для пакетов, в том числе и коммерческих, разрабатываемых партнёрами фирмы Canonical. Как можно видеть, по умолчанию после стандартной установки она закомментирована. Для включения с этой строки надо снять символ комментария.

Далее в каждой ветке репозиториев идёт перечень категорий пакетов. Их четыре:

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

«Не вполне свобода» пакетов из категорий restricted и multiverse выражается в ограничениях на их распространение (например, мультимедиа-кодеки, использующие алгоритмы, патентованные в отдельных странах), или могут распространяться только в бинарном виде (например, фирменные драйверы для видеокарт).

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

# 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:, который в имени соответствующего list-файла отбрасывается. Зато завершается последний обязательным компонентом — кодовым именем релиза. Например, для текущего релиза 18.04 имя имя list-файлабудет завершаться компонентом bionic.

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

deb http://ppa.launchpad.net/embrosyn/cinnamon/ubuntu bionic main
# deb-src http://ppa.launchpad.net/embrosyn/cinnamon/ubuntu bionic 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, но это не более чем символическая ссылка на реальный скрипт.

Как ни странно, утилита add-apt-repository не входит в базовый комплект ubuntu-minimal и по умолчанию не устанавливается, например, при минимальной установке с mini.iso. В этом случае перед её использованием надо установить пакет, её содержащий:

$ sudo apt install software-properties-common

Впрочем, мы это проделали в Главе 2.

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

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

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

Можно, конечно, походить по форумам Ubuntu’йской тематики, можно сделать запрос к Гоше или Яше, указав имя искомого пакета, можно… да много чего можно сделать, чтобы по прошествии изрядного или ещё большего времени получить нужный результат. А можно, действуя методично и планомерно, прибегнуть к универсальному способу, который и описывается ниже.

Первый шаг — заход на Launchpad.net. Далее в поле поиска следует набрать имя требующегося пакета или его фрагмент. Затем — в списке выдачи результатов отыскать нужную строку. и проследовать по ссылке. Там для начала нужно убедиться, что в искомом репозитории имеются пакеты для требуемого релиза Ubuntu, например, для Bionic’а, выбрав соответствующее имя из выпадающего меню:

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

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

$ sudo add-apt-repository [ppa:имя]

Дабы развеять все сомнения относительно правильности этого шага, можно предварительно пройти по ссылке Read about installing. Появится всплывающее окошко, в котором процедура добавления PPA-репозитория будет описана подробно, с иллюстрациями.

После запуска указанной команды будет запрошено подтверждение её исполнения — здесь достаточно нажать Enter. Дабы избежать этой тяжкой работы, можно запустить команду с опцией -y.

После выполнения команды раньше (в apt 1.5.X и более старых) требовалось обновить локальный кеш пакетов:

$ sudo apt update

В версии apt 1.6 необходимости в этом нет: апдейт кеша произойдёт автоматически. Теперь можно устанавливать пакеты из новообретённого репозитория.

PPA вручную

Как было сказано ранее, при подключении PPA-репозитория можно обойтись без команды add-apt-repository — например, если забылось про включающий её пакет. Для этого, отыскав нужное «хренилище» (пусть для разнообразия это будет “Utappia” team, содержащее очень важную для нас утилиту ucaresystem-core, разворачиваем строку Technical details about this PPA. И просто копируем строки в рамке в новый текстовый файл, создаваемый в каталоге /etc/apt/sources.list.d под именем utappia-ubuntu-stable-bjonic.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. Либо, на худой конец, сопровождается сведениями о том, как это сделать самостоятельно. Если ни того, ни другого не имеет места быть — возникает вопрос: а стоит ли связываться с таким пакетом?

Собственно про apt

Как говорилось ранее, последняя версия утилиты apt (начиная с 1.6) практически полностью вобрала в себя функционал команд dpkg, apt-get и apt-cache, а также aptitude. Далее будут рассмотрены утилиты эпонимического пакета apt, а под занавес также утилита apt-file из одноимённого пакета. Именно они наиболее востребованы в реальной работе с пакетами.

Общий обзор

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

$ apt-file list apt 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

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

Это позорно и преступно, как говаривал лирический герой Венички Ерофеева. Ибо вот уже четыре года, с 1 апреля 2014, существует универсальная эпонимическая утилита apt. С момента выхода версии 1.2.X её функционал практически полностью перекрывает интегрированные возможности утилит apt-cache и apt-get. А в использовании она проще этой «сладкой парочки» уже хотя бы тем, что она одна и короткая. Кроме того, у неё есть и некоторые дополнительные функции, в том числе и появившиеся в версии 1.6.

К слову сказать, определить версию apt можно с помощью её самой. В Cintu 18.04 (и всех дистрибутивах на основе Bionic’а) она будет такой:

$ apt --version
apt 1.6.3ubuntu0.1 (amd64)

Так что пакет apt в текущем релизе Cintu содержит уже полнофункциональную версию одноимённой утилиты. Правда, в некоторых случаях при запуске её появляется предупреждение, оказывающие на некоторых граждан устрашающее действие:

    
	WARNING: apt does not have a stable CLI interface.
    Use with caution in scripts.

Однако предупреждение это по части стабильности давно уже силы не имеет. Что же до использования утилиты apt в скриптах, то исчерпывающее разъяснение по сему поводу можно получить, если запустит её без субкоманды, опций и аргументов, в «голом» виде:

apt — менеджер пакетов с интерфейсом командной строки, предоставляет команды
для поиска и управления, а также запросов информации о пакетах.
Он выполняет те же задачи, что и специализированные инструменты APT,
например apt-get и apt-cache, но содержит параметры, которые больше
подходят для интерактивного использования по умолчанию.

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

Субкоманды apt

Указанное сообщение предваряется шаблоном использования этой утилиты:

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

Из этого шаблона видно, что утилита apt имеет свои собственным внутренние команды, именуемые также операторами или субкомандами. Далее мы будем придерживаться последнего термина, как наименее неопределённого. Субкоманды эти определяют, что же должна делать утилита. Параметры же, именуемые также опциями (мы с Мануалом предпочитаем последний термин), уточняют условия действия субкоманд (или утилиты apt в целом).

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

Основные команды:
  list - показать список пакетов из указанных имён пакетов
  search - искать в описаниях пакетов
  show - показать дополнительные данные о пакете
  install - установить пакеты
  remove - удалить пакеты
  autoremove - автоматически удалить все неиспользуемые пакеты
  update - обновить список доступных пакетов
  upgrade - обновить систему, устанавливая/обновляя пакеты
  full-upgrade - обновить систему, удаляя/устанавливая/обновляя пакеты
  edit-sources - редактировать файл с источниками пакетов

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

Не следует в данном случае ожидать много и тёти Мани в ответ на команду

$ man apt

Там, конечно, с информацией будет чуть побогаче, но полного списка субкоманд и опций утилиты apt она нам тоже не выдаст даже под пыткой. Недостающее придётся выковыривать из man apt-get и man apt-cache. Однако кое-чего не обнаружится и там. Ибо, как уже было сказано, последняя версия apt не только полностью вобрала в себя их функционал, но кое в чём и превзошла его.

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

Автодополнение в apt

Каждый применитель, хоть чуть-чуть поработавший в CLI, знает, насколько упрощает жизнь в командной строке автодополнение команд и их аргументов по нажатию клавиши Tab. Работает эта штука и для команды apt — причём и для её субкоманд, и для их аргументов, то есть имён пакетов. Хотя в обоих случаях с некоторыми ограничениями.

Автодополнение имён субкоманд работает почти для всех из них. Так, «аббревиатура» apt se по нажатии табулятора будет развёрнута до apt search, apt sh — до apt show, apt in — до apt install, и так далее. Хотя некоторые субкоманды (например, policy или clean), «автодополняться» категорически не желают. Возможно, временно: с каждой новой версией apt число субкоманд, поддерживающих автодополнение, растёт.

К слову — глобальные псевдонимы для субкоманд утилиты apt, о которых будет со временем говорить в Главе о Zsh, по возможности придумывались так, чтобы они могли быть развёрнуты до полной формы. Почему — будет сказано чуть позже.

Однако есть четыре часто используемые субкоманды — забегая вперёд, скажу, что это show (подробная информация о пакете), install (установка пакетов), remove и purge («грязное» и «чистое» удаление, соответственно). И для них автодополнение работает не только для имён субкоманд, но и их аргументов — в этом качестве выступают имена пакетов. Так, если набрать в CLI команду

# apt show nemo

и нажать клавишу табулятора, то, во первых, имя пакета развернётся до последнего «безальтернативного» символа, а во-вторых, далее имена пакета можно выбирать либо перебором, либо, как определено в настройках оболочки Zsh в Cintu, выбирать из списка:

Обращаем внимание, что в списке выбора присутствуют как установленные пакеты (например, nemo), так и те, которых в системе отродясь не было (скажем, nemo-keyboard). Однако информация будет выведена не только для любого установленного, но и для отсутствующего пакета.

Аналогично происходит и для субкоманды install: нажатие клавиши табуляции выводит список всех пакетов, имена которых совпадают с шаблоном, независимо от их текущего статуса. Например, в выводе для шаблона cinn можно видеть и отсутствующий пакет cinnamon-settings-daemon-dev:

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

А вот для субкоманд remove и purge при автодополнении выводятся только имена установленных пакетов. Например, для шаблона cinn список этот выглядит так:

Остаётся добавить, что автодополнение имён пакетов не работает при использовании «коротких» имён субкоманд, обеспечиваемых средствами оболочки Zsh. И потому применитель поставлен перед тяжким выбором: набрать ли в командной строке in и вставить щелчком средней кнопки мыши имя пакета, вытащенного из поиска? Или, напротив, развернуть субкоманду до install и выбрать то же имя из вывода по Tab? Впрочем, мы с Мануалом верим, что с этой трудной задачей наши читатели справятся применительно ситуации.

Определение статуса

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

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

На первое место среди «статусных» субкоманд надо поставить субкоманду list, не требующую аргументов. В своей элементарной форме

$ apt list

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

0ad/bionic 0.0.20-1 amd64
0ad-data/bionic,bionic 0.0.20-1 all
...

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

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

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

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

М локальный:

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

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

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

• --all-versions, применяемую по умолчанию — она-то и обеспечивает вывод всех наличных и доступных пакетов;
• --installed, которая выводит только установленные пакеты (вручную, автоматически и локально);
• --upgradeable, выводящая список пакетов, для которых доступны обновления, её имеет смысл выполнить после команды apt update, о которой будет говориться в следующем разделе.

Надо отметить, что субкоманда list не имеет аналогов в утилите apt-cache, но близка по смыслу команде dpkg -l, хотя и отличается от неё формой вывода.

Поиск пакетов…

Вывод субкоманды list можно фильтровать для поисков нужного пакета (например, с помощью утилиты grep). Однако проще и эффективней искать пакеты посредством специальной субкоманды search, в качестве аргумента которой выступает «базовое имя» пакета или его «шаблон». Например, команда

$ apt search systemback

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

systemback/yakkety,now 1.8.402~ubuntu16.04.1 amd64 [установлен]
	Simple system backup and restore application with extra features

но и обо всех, с ним связанных:

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

и так далее.

… и фильтрация его результатов

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

$ apt search apt

будет неприлично длинным, и содержащим немало мусора. Однако его можно существенно сократить, используя опцию -n (или --names-only). Например, если стоит задача отыскать все плагины к файловому менеджеру Nemo, команда

$ apt search nemo -n

выведет список только тех пакетов, содержащих последовательность nemo в их именах. Однако в этом списке обнаружатся, скажем, и такая строка, к файловому менеджеру нашему отношения не имеющая:

ttf-denemo/bionic,bionic 2.2.0-1 all
  music notation symbol fonts for denemo

Однако круг поисков может быть ещё более сужен такой командой:

$ apt search '^nemo' -n

И вот в её выводе ничего, кроме самого Nemo

nemo/bionic 3.8.2-1~bionic0 amd64  [установлен, автоматически]
  Файловый менеджер и графическая оболочка для Cinnamon

и искомых плагинов, уже точно не окажется:

nemo-data/now 3.8.2-1~bionic0 all [установлен, локальный]
  data files for nemo
...
nemo-seahorse/now 3.8.2-1~bionic0 amd64 [установлен, локальный]
  seahorse plugins and utilities for encryption

nemo-terminal/now 3.8.2-1~bionic0 amd64 [установлен, локальный]
  Nemo extension to enable an embedded terminal

Кроме того, фильтрацию результатов поиска можно выполнить средствами кмоандной оболочки Zsh, о чём будет рассказано в воззрениях кота Manual’а на соответствующий предмет.

Информация о пакете

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

$ apt show systemback 

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

Package: systemback
Version: 1.8.402~ubuntu16.10.1
Priority: optional
Section: admin
Maintainer: Kende Krisztián 
Installed-Size: 1 403 kB
Depends: libc6 (>= 2.14), libqt5core5a (>= 5.5.0), libqt5gui5 (>= 5.0.2) | libqt5gui5-gles (>= 5.0.2), libqt5widgets5 (>= 5.2.0), libstdc++6 (>= 4.1.1), libsystemback (= 1.8.402~ubuntu16.10.1), libx11-6, casper | live-boot, dosfstools, fonts-freefont-ttf | ttf-freefont, genisoimage, squashfs-tools, syslinux, syslinux (<< 3:5) | isolinux (>> 3:6), syslinux (<< 3:5) | syslinux-common (>> 3:6), syslinux (<< 3:5) | syslinux-utils (>> 3:6), systemback-efiboot-amd64 (= 1.8.402~ubuntu16.10.1), systemback-scheduler (= 1.8.402~ubuntu16.10.1), upstart | sysvinit (>= 2.88) | systemd, xterm, zenity | kde-baseapps-bin | kdebase-bin
Recommends: grub2-common, grub-efi-amd64-bin, grub-pc-bin, lupin-casper, systemback-cli (= 1.8.402~ubuntu16.10.1), systemback-locales (= 1.8.402~ubuntu16.10.1), ttf-ubuntu-font-family
Suggests: btrfs-tools, jfsutils, reiserfsprogs, xfsprogs, unionfs-fuse
Conflicts: live-config, live-config-systemd
Breaks: systemback-gui-common (<< 1.0.0)
Replaces: systemback-gui-common (<< 1.0.0)
Download-Size: 855 kB
APT-Manual-Installed: yes
APT-Sources: http://ppa.launchpad.net/nemh/systemback/ubuntu yakkety/main amd64 Packages
Description: Simple system backup and restore application with extra features
 Systemback makes it easy to create backups of the system and the users
 configuration files. In case of problems you can easily restore the previous
 state of the system. There are extra features like system copying, system
 installation and Live system creation.
 .
 This package contain a Qt5 graphical user interface for Systemback.

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

Просмотр зависимостей

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

$ apt depends apt

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

apt
  Зависит: adduser
 |Зависит: gpgv
    gpgv:i386
 |Зависит: gpgv2
  Зависит: gpgv1
    gpgv1:i386
  Зависит: ubuntu-keyring
  Зависит: libapt-pkg5.0 (>= 1.6~beta1)
  Зависит: libc6 (>= 2.15)
  Зависит: libgcc1 (>= 1:3.0)
  Зависит: libgnutls30 (>= 3.5.6)
  Зависит: libseccomp2 (>= 1.0.1)
  Зависит: libstdc++6 (>= 5.2)
  Ломает: apt-transport-https (<< 1.5~alpha4~)
  Ломает: apt-utils (<< 1.3~exp2~)
  Ломает: aptitude (<< 0.8.10)
  Рекомендует: ca-certificates
  Предлагает: apt-doc
 |Предлагает: aptitude
    aptitude:i386
 |Предлагает: synaptic
  Предлагает: wajig
  Предлагает: dpkg-dev (>= 1.17.2)
 |Предлагает: gnupg
    gnupg:i386
 |Предлагает: gnupg2
  Предлагает: gnupg1
    gnupg1:i386
  Предлагает: powermgmt-base
  Заменяет: apt-transport-https (<< 1.5~alpha4~)
  Заменяет: apt-utils (<< 1.3~exp2~)

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

$ apt rdepends zsh

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

zsh
Reverse Depends:
  Конфликтует: usrmerge (<< 5.2-4~)
  Заменяет: zsh-common (<= 5.0.2-1)
  Рекомендует: zsh-common
  Зависит: zshdb
  Зависит: zsh-theme-powerlevel9k
  Улучшает: zsh-syntax-highlighting
  Зависит: zsh-syntax-highlighting
  Зависит: zsh-static
  Улучшает: zsh-antigen
  Зависит: zsh-antigen
  Зависит: zplug (>= 4.3.9)
  Зависит: zomg
  Зависит: zec
  Зависит: fizsh (>= 4.3.9)
  Зависит: tomb
  Рекомендует: staden-common
  Зависит: shellex
  Улучшает: powerline
  Рекомендует: libpetsc3.7.7-dev
  Рекомендует: libpetsc3.7.7-dbg
  Рекомендует: libpetsc-complex-3.7.7-dev
  Рекомендует: libpetsc-complex-3.7.7-dbg
  Зависит: libodb-api-bin
  Зависит: libncarg-dev
 |Зависит: libeccodes-tools
  Зависит: flowscan
  Заменяет: zsh-common (<= 5.0.2-1)
  Зависит: ecflow-server
  Зависит: draai
  Улучшает: autojump
  Рекомендует: zsh-common

Приоритет версий

И последняя из «информационных» субкоманд первостепенной важности — policy. Она позволяет определить приоритетность установки разных версий одного пакета. Что особенно существенно в том случае, если эти версии содержатся в разных репозиториях, например, в официальном и каком-либо из PPA. Так, вывод команды

$ apt policy cinnamon

в последней сборке Cintu (на базе 18.04) будет следующим:

cinnamon:
  Установлен: 3.8.7-1~bionic0
  Кандидат:   3.8.7-1~bionic0
  Таблица версий:
 *** 3.8.7-1~bionic0 500
        500 http://ppa.launchpad.net/embrosyn/cinnamon/ubuntu bionic/main amd64 Packages
        100 /var/lib/dpkg/status
     3.6.7-8ubuntu1 500
        500 http://archive.ubuntu.com/ubuntu bionic/universe amd64 Packages

Он показывает приоритетность пакетов Cinnamon из репозитория Embrosyn'а относительно официального. И, следовательно, именно первые и будут установлены (вместе со всеми своими зависимостями из того же источника) командой

# apt install cinnamon

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

Изменение статуса пакетов

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

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

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

$ sudo apt install [packagename]

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

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

$ sudo -i

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

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

$ sudo -s

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

Вид приглашения командной строки изменяется при любом способе получения прав администратора. Как именно — зависит от конкретных настроек, о которых сейчас говорить неуместно. А далее в тексте команды, требующие root'овых привилегий, будут предваряться символом «решётки» — #, чтобы отличать их от пользовательских команд, символизируемым баксом нашим животворящим — $.

Выбор способа — дело вкуса и привычки. Мы с Мануалом практически всегда используем второй, и рекомендую его применителям системы Cintu. И в последних сборках Cintu мы, по настоянию кота, и для исполняющего обязанности root'а в качестве пользовательской оболочки назначили Zsh. Так что настройки шелла в любом случае будут одинаковы. Однако при втором способе получения административных привилегий команды, введённые от лица администратора, сохраняются в пользовательском ~/.zhistfile. И при необходимости их можно легко просмотреть, «не прикидываясь root'ом» для этой нехитрой операции. Что, возможно, плохо с точки зрения безопасности. Однако весьма полезно при сочинении материалов вроде этого.

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

# exit

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

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

Установка пакетов

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

# apt install apt-dpkg-ref

установит пакет указанного имени, который содержит краткую справку по опциям утилит семейств APT и dpkg в различных форматах (HTML, PDF, TeX, etc.).

Установка пакета apt-dpkg-ref начнётся сразу, без запроса подтверждения, потому как в стандартно установленной системе он не имеет неудовлетворённых зависимостей. Если же таковые обнаружатся — будет выведен их список, сопровождаемый запросом на подтверждение установки оных вместе с целевым пакетом (или отказа от установки для них для всех). Например, это последует при попытке установить пакет apt-build:

# apt install apt-build

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

Для подтверждения установки достаточно нажать клавишу Enter — согласие с запросом предполагается по умолчанию. Тем не менее, и от этой сложной операции можно избавиться, с помощью опции -y (или --yes). Так что та же команда в форме

# apt install apt-build -y

вызовет немедленную инсталляцию пакета и всех его зависимостей без всяких списков и подтверждений. Кстати, опция -y применима ко всем субкомандам утилиты apt, когда требуется запрос на подтверждение действий, и, как легко догадаться, означает согласие с ними. К слову сказать, существует и обратная опция, --assume-no — она, напротив, предписывает отвечать на любой запрос отрицательно.

По умолчанию в список зависимостей (Depends) устанавливаемого пакета включаются и его рекомендации (Recommedsns), которые при согласии также будут установлены автоматически, все «гуртом». Однако, если обойтись без опции -y, то на стадии подтверждения можно прервать процесс, проанализировать список рекомендаций и действительно нужные пакеты из их числа рекомендуемых добавить в строку повторения команды установки пакета — но уже в другой форме, без рекомендованных пакетов.

А чтобы обойтись без автоматической установки зависимостей, следует прибегнуть к опции --no-install-recommends. И с ней вывод команды будет много короче:

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

Предложения пакета (Suggests) в состав зависимостей по умолчанию не включаются, но присутствуют в выводе субкоманды install отдельно. Если возникает желание установить их все вместе с рекомендациями — его легко удовлетворить с помощью опции --install-suggests. Однако с её использованием вывод команды

# apt install qapt-deb-installer --install-suggests

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

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

Локальная установка

В прошлом подразделе речь шла об установке пакетов из удалённых репозиториев, ибо утилита apt — это в первую очередь менеджер пакетов, именно для этого и предназначенный. Однако, начиная с версии 1.6.X (той самой, что включена в Cintu 18.04), он вполне может работать и как установщик локально размещённых пакетов, подобно команде dpkg -i, утилите gdebi-core или её «морде» Gdebi. Подобно двум последним, при нарушении зависимостей он не только сообщает об этом, как dpkg, но и (обычно) успешно их разрешает — разумеется, если требуемые пакеты находятся в подключённых репозиториях.

Необходимость локальной установки возникает в трёх случаях. Первый — когда пакет хочется не установить сразу, а сначала посмотреть, «что у него внутре». Для чего файл пакета нужно скачать на локальную машину. И на этот предмет существует специальная субкоманда — download. Она, единственная из все в этом разделе, не требует прав администратора. Точнее, может потребовать, но не обязательно. Ибо скачивание файла пакета происходит в текущий на данный момент каталог, и если пользователь, запустивший команду

$ apt download packagename

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

Второй случай — когда нужный пакет имеется в репозитории (например, в PPA), однако не для того релиза, который нам нужен, хотя и работоспособен в нашем.
Делается это в общем случае так. Заходим в нужный нам PPA-репозиторий и находим там слова View package details.

Переходим по ссылке и фильтруем базар по имени пакета и кодовому имени самого «юного» релиза. После чего «разворачиваем» содержимое пакет, в котором отыскиваем нужный deb-файл, который и подлежит скачиванию.

Наконец, третий случай — если нужный пакет в существующих репозиториях просто отсутствует, но в принципе доступен в виде файла deb-формата, скачанного из сети или изготовленного своими руками, например, с помощью утилиты alien. Именно такая ситуация возникает при установке пакета hunspell-ru-aot — единственного русскоязычного словаря проверки орфографии с обязательной поддержкой буквы Ё.

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

# apt install path2/hunspell-ru-aot_0.4.0-2_all.deb

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

# apt install ./hunspell-ru-aot_0.4.0-2_all.deb

Причём автодополнение работать не будет — и имя файла, и путь к нему надо набрать руками. Или — скопировать через «мышиный» буфер. За исключением этого маленького неудобства, установка локального файла через apt ничуть не сложнее, чем через dpkg или gdebi.

Интермедия про alien

Утилита alien была написана в незапамятные времена и специально предназначена для конвертации бинарных пакетов, собранных для разных дистрибутивов, из одного формата в другой. По умолчанию этим другим форматом был (и остаётся) deb, однако поддерживаются также rpm, tgzиз Slackware (и абстрактный tar.gz — тоже), slp из Stampede (был некогда такой дистрибутив Linux'а, в своё время — самый фронтирный) и pkg из Solaris.

Утилита alien входит во все актуальные сборки Cintu, во всех остальных Ubuntu'идах её легко установить из официального репозитория:

# apt install alien

Целевым форматом по умолчанию в alien, как только что было сказано, выступает deb, прочие задаются соответствующими опциями, на которых я останавливаться не буду (заинтересованным предлагаю обратиться к тёте Мане — man alien). Конвертация в deb-пакет из любого другого формата требует прав администратора. Однако пользоваться на предмет их обретения командой sudo здесь не желательно (хотя и не запрещается): после этого сгенерённый файл *.deb будет принадлежать root'у, со всеми вытекающими из этого неудобствами. Так что проще воспользоваться утилитой fakeroot, которая также имеется во всех редакциях Cintu.

Утилита fakeroot после запуска (кстати, не требующего ввода пароля) создаёт «псевдоадминистративное окружение». Как и sudo, её можно использовать двояко. Во-первых, дать команду

$ fakeroot

после которой последует две жалобы на «несекьюрность» текущего каталога (в обоих случаях надо отвечать согласием, то есть y), после чего в приглашении командной строки вместо пользователя можно увидеть «администратора». То есть в Cintu по умолчанию это будет выглядеть так:

[alv]=$ fakeroot
zsh compinit: insecure directories, run compaudit for list.
Ignore insecure directories and continue [y] or abort compinit [n]? y
zsh compinit: insecure directories, run compaudit for list.
Ignore insecure directories and continue [y] or abort compinit [n]? y
[root]=$

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

[root]=$ echo $USER
alv

Теперь можно дать команду конвертации, например, такую:

[root]=$ alien thessalonica-theano-otf-fonts-2.0-19.77.noarch.rpm

Которая завершится сообщением:

thessalonica-theano-otf-fonts-2.0-19.77.noarch.deb generated

При необходимости команду можно повторить для следующего файла, или задать сразу несколько аргументов, в том числе и по маске. А по окончании всей процедуры конвертации — вернуться в нормальную пользовательскую среду командой exit. И убедиться, что владельцем конвертированного файла будет не root, как в случае применения sudo, а пользователь:

[alv]=$ ls -l adobe-sourcecodepro-fonts_2.010-23.5_all.deb
-rw-r--r-- 1 alv alv 1297642 сен 20 22:27 adobe-sourcecodepro-fonts_2.010-23.5_all.deb

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

[alv]=$ fakeroot alien micro-d41f0bb_amd64.tar.gz
micro-d41f0bb-amd64_1-2_all.deb generated

И результат будет тем же самым:

[alv]=$ ls -l micro-d41f0bb-amd64_1-2_all.deb
-rw-r--r-- 1 alv alv 2173384 сен 20 22:35 micro-d41f0bb-amd64_1-2_all.deb

Внимательный читатель обратил внимание, что в списке поддерживаемых утилитой alien форматов нет tar.xz (txz), а утилита xz нынче часто используется для компрессии тарбаллов. И действительно, напрямую конвертировать файл с таким суффиксом не удастся:

[alv]=$ fakeroot alien otf-bitter-1-2-any.pkg.tar.xz
Unknown type of package, otf-bitter-1-2-any.pkg.tar.xz.

Однако тут помогает нехитрая уловка — банальное переименование tar.xz в tar.gz, поскольку alien сам непосредственно распаковкой и упаковкой архивов не занимается.

И действительно, если выполнить такую операцию:

[alv]=$ cp otf-bitter-1-2-any.pkg.tar.xz otf-bitter-1-2-any.pkg.tar.gz

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

[alv]=$ fakeroot alien otf-bitter-1-2-any.pkg.tar.gz
otf-bitter-1_2-2_all.deb generated

Команду alien можно применять не только к пакетам какого-либо дистрибутива, но и к абстрактным тарбаллам — выше это было проделано для редактора micro.

Более того, alien работает даже с самосборными тарбаллами. Например, шрифта Monofur в виде пакета не найти, наверное, ни в одном дистрибутиве. Он доступен в виде zip-архива в одной из шрифтовых коллекций. Его можно распаковать, входящие файлы распихать по нужным подкаталогам (собственно шрифты monof55.ttf и monof56.ttf — в usr/share/fonts/truetype, текст лицензии monof_tt.txt в usr/share/licenses), а из родительского каталога сделать архив monofur-otf_1-1_all.tar.gz и подсунуть его в качестве аргумента команды alien. С генерацией deb-пакета на выходе. Да, это не эстетично идеологично, зато «дёшево, надёжно и практично».

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

Переустановка и обновление

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

# apt install zsh

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

Уже установлен пакет zsh самой новой версии (5.4.2-3ubuntu3).

Тем не менее, иногда возникает необходимость переустановить запоротый пакет при неизменности его версии в репозитории. И на сей предмет у субкоманды install существует специальная опция --reinstall, которая и обеспечивает переустановку. Но — только пакета, указанного в качестве аргумента, его установленных зависимостей она не затрагивает.

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

# apt upgrade pkg_name

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

Удаление пакетов

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

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

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

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

Если же пакет имеет зависимые от него пакеты — перед согласием с его удалением будет выведен их список. С ним надо ознакомиться очень внимательно, ибо его составляющие будут также автоматически удалены вместе с целевым пакетом. Что может серьёзно сказаться на работоспособности системы — вплоть до полного её разрушения.

Старожилы Ubuntu (и её производных) помнят времена, когда удаление какого-нибудь шрифта для письменности теллугу (очень в наших широтах востребованного) приводило к сносу почти всей системы. Ибо все пакеты, устанавливавшиеся при первичной инсталляции её, получали статус A, то есть автоматически установленных. Потому как устанавливались они как части метапакета типа ubuntu-desktop.

Сейчас до таких крайностей, к счастью, дело не доходит — пакеты, установленные как компоненты метапакетов, не получают обычно (хотя и не всегда) статуса A, то есть считаются установленными вручную. Однако от внимательного чтения вывода автоматически удаляемых пакетов это не избавляет. Во-избежание, как сказал некогда один восточный мудрец.

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

Установка и обновление: инверсия действий

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

# apt install leafpad-

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

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

# apt purge leafpad+

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

# apt install xed leafpad-

Установит текстовый редактор Xed вместо Leafpad'а. А конструкция

# apt purge xed+ leafpad

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

Обновление системы

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

# apt update

Она устанавливает соединение со всеми репозиториями, перечисленными в файле /etc/apt/sources.list и файлах внутри каталога /etc/apt/sources.list.d, и приведёт локальный кэш пакетов в соответствие с их версиями на серверах. Что завершится выводом примерно такого сообщения:

Может быть обновлено 16 пакетов. Запустите «apt list --upgradable» для их показа.

Выполнив указанную команду, можно ознакомиться со списком потенциально обновляемых пакетов. Субкоманду update следует применять также после каждого изменения списков репозиториев — как при их добавлении, так и при удалении. Впрочем, как было сказано в разделе про PPA-репозитории, при добавлении последних команда обновления локального кеша пакетов обычно вызывается автоматически.

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

# apt upgrade

Она сравнит версии установленных пакетов с обновлённым их кэшем, выявит все компоненты, нуждающиеся в обновлении, скачает соответствующие их версии из сети и заменит ими пакеты устаревшие. В случае, если новые версии повлекут за собой и новые зависимости, по сравнению с имевшимися ранее, — они также будут скачаны и установлены. Но перед этим будет выведен полный список пакетов, нуждающихся в обновлении, число файлов, который предстоит скачать из сети, и их суммарный объем, значение, на которое возрастёт занятое дисковое пространство в результате всех этих действий, и последует запрос на подтверждение операции:

Пакеты, которые будут обновлены:
  falkon gir1.2-packagekitglib-1.0 libmysqlclient20 libpackagekit-glib2-18 libperl5.26 libruby2.3 libssl1.0.0
  openssl packagekit packagekit-tools perl perl-base perl-modules-5.26 ruby2.3 snapd vivaldi-stable
Обновлено 16 пакетов, установлено 0 новых пакетов, для удаления отмечено 0 пакетов, и 0 пакетов не обновлено.
Необходимо скачать 55,8 MB/79,8 MB архивов.
После данной операции, объём занятого дискового пространства возрастёт на 2 725 kB.

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

# apt full-upgrade

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

Если нет — следует вспомнить об опции --fix-broken, применимой также к субкомандам upgrade и install (с которой она аргументов не требует). И во всех этих случаях она будет пытаться скорректировать систему так, чтобы противоречивых зависимостей в них не осталось. Правда, иногда разрешение противоречий в системе может привести к сносу половины оной — и потому вывод любой субкоманды с опцией --fix-broken требует особо внимательного прочтения. Благо, нынче при использовании Ubuntu'идов в штатном (не экспериментальном) режиме к ней прибегать не приходится (почти) никогда.

Очистка системы

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

# apt autoremove

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

И установка единичных пакетов, и обновление системы любого рода начинаются со скачивания из сети файлов пакетов. Которые по умолчанию помещаются в каталог /var/cache/apt/archives (а файлы пакетов, скачивание которых по каким-то причинам оборвалось — в каталог /var/cache/apt/archives/partial). И со временем их там скачивается приличное количество (а иногда просто неприличное). А вот понадобиться эти файлы пакетов могут только в единичных случаях, да и тогда их проще скачать заново, нежели отыскать.

Так что избавление от «продуктов жизнедеятельности» применителя любого дистрибутива — задача если не архиважнейшая, то весьма важная. И в deb based системах она решается субкомандами clean и autoclean, не требующими аргументов. Первая просто тупо очищает каталоги, указанные в предыдущем абзаце.

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

А вот команду apt clean надо выполнять регулярно. Как и использовать предварительно такие субкоманды утилиты apt, как update, upgrade и autoremove. И потому возникает естественное желание как-то автоматизировать этот процесс. Один из способов для этого — утилита ucaresystem-core, рассмотренная в соответствующем разделе Главы 5-й.

Немного о настройке apt'а

Теоретически настройки apt'а описываются в файле /etc/apt/apt.conf. Однако нынче такого файла в свежеустановленной системе нет. Конечно, ничто не запрещает его создать — однако сейчас идеологически правильным считается записывать настройки в файлики каталога /etc/apt/apt.conf.d/. Мы с Мануалом этим не занимаемся, потому как умолчальные настройки полагаем разумными, и потом мало чего можем сказать по этому поводу. Единственный спорный момент здесь — отношение его к рекомендациям как к зависимостям. Если это почему либо не нравится — рекомендуется создать файл типа /etc/apt/apt.conf.d/99norecommends (имя файла произвольное) и внести в него такие строки:

APT::Install-Recommends "0";
APT::Install-Suggests "0";

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

Сопутствующие утилиты

Утилита apt обеспечивает почти всё необходимое для управления пакетами. Но — всё же не всё. И потому — «чего не хватит в доме — сколько хочешь в гастрономе». То есть — в утилитах apt-mark и apt-file.

Утилита apt-mark

В в утилите apt не предусмотрено простых средств для массового изменения вторичных статусов пакетов, вроде автоматически установленных или зафиксированных — одна из задач, с которыми хорошо справлялась aptitude, ныне, исключённая из рядов КПСС Core System в Debian’е и Ubuntu. Однако на смену ей пришла утилита 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-файлов и совмещать их с локальными.

Qaptt — графический установщик пакетов

Как было покащано выше, утилита apt прекрасно справляется с локальной установкой пакетов, однако требует их предварительного скачивания и запуска субкоманды install с нетривиальным аргументом. И потому были придуманы графические фронт-энды, упрощающие данную процедуру — они осуществляют запуск установки одним щелчком на имени deb-файла, как локального, так и удалённого.

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

$ sudo apt install qapt-deb-installer

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

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

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

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

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

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

Графический менеджер пакетов Synaptic

Система управления пакетами Synaptic — интегрирующий графический фронт-энд для нескольких утилит семейства APT, обычно используемых для работы с пакетами deb-формата. Она предоставляет все функции, обеспечиваемые утилитами apt-get и apt-cache, а также и ряд дополнительных. В их числе:

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

Кроме того, Synaptic включает средства настройки — в частности, доступа к репозиториям.

Штатный способ запуска Synaptic’а выполняется через главное меню: Администрирование -> Менеджер пакетов Synaptic, или из панели фаворитов:

Очевидно, что установка и удаление пакетов потребует прав администратора, запрос на получение каковых (посредством механизма sudo, то есть с вводом пользовательского пароля) и последует после вызова 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» мы не увидим. Потому что это пример поиска в полных описаниях — тех самых, которые выводятся в нижнем правом фрейме (или в закладке Общие панели Свойства).

А вот кнопка Найти имеет место быть во всех сборках Sypaptic'а. И она как раз и позволяет варьировать область поиска и его критерии:

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

Наконец, самый верхний интерфейсный элемент окна — строка главного меню. Однако на как раз на меню мы останавливаться не будем: смысл его пунктов в общих чертах понятен из названий, И к тому же по большей части они дублируются меню контекстным и кнопками инструментальной панели. Так что скажу-ка я лучше пару слов о настройке Synaptic’а.

Настройка

Как легко догадаться, за настройки Synaptic’а отвечает одноимённый пункт главного меню, содержащий подпункты:

• Параметры;
• Репозитории;
• Фильтры;
• Установить внутренний параметр;
• Панель инструментов.

Рассмотрим их последовательно.

Пункт Параметры (или Preferences) вызывает панель со множеством вкладок, позволяющих настроить общее поведение Synaptic’а:

• Основное;
• Столбцы и шрифты;
• Цвета;
• Файлы;
• Сеть;
• Дистрибутив.

Вкладка Основное, кроме внешнего вида (включение или выключение чекбокса о показе информации в главном окне), позволяет установить ряд очень важных параметров:

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

Важно также определиться с опцией Рассматривать рекомендуемые пакеты как зависимости, то есть считать их обязательными к установке. По умолчанию она включена, что совпадает с умолчальной конфигурацией утилиты apt. Так что если использовать apt и Sinaptic попеременно, лучше эту опцию не трогать — или изменить её и там, и там, во избежание путаницы.

Выпадающее меню Удаление пакетов определяет, удалять ли их полностью (аналогично команде apt purge), что установлено по умолчанию, или сохранять конфигурационные файлы (как при команде apt remove).

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

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

Во вкладке Столбцы и шрифты, во-первых, определяется набор колонок вывода информации о пакетах и их порядок. А во-вторых, указывается, использовать ли общесистемные шрифты, заданные глобально для всех приложений рабочей среды, или задать собственные, специально для Synaptic’а.

Смысл установок во вкладке Цвета вполне очевиден:

Во вкладке Файлы определяется, надо ли хранить в локальном кэше скачанные файлы пакетов, сохранять ли историю установок, а также задаётся время хранения файлов истории. Имеется и кнопка для принудительной очистки каталога /var/cache/apt/archives.

Во вкладке Сеть при необходимости можно задать адреса прокси-серверов http и ftp, буде таковые используются.

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

Далее в меню Настройки идёт пункт Репозитории. Выбрав его, можно, во-первых просмотреть список всех подключённых репозиториев, в том числе и неактивированных, и при необходимости — активировать что-либо из последних:

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

Далее, с помощью кнопки New можно подключить какую-либо ветвь официального репозитория, указав его тип (бинарный или исходник) и просто заполнив соответствующие поля — в примере их значения даны для ветки proposed:

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

Тем же образом можно добавлять и PPA-репозитории. В примере ниже это проделано для репозитория Liquorix, содержащего свежие версии ядра. Обращаю внимание, что в поле URL заносится http-адрес репозитория, а не его PPA-имя, как при использовании команды add-apt-repository:

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

Смысл пункта Фильтры поиска (вспомним, что они фигурируют у нас среди кнопок левого нижнего фрейма главного окна Synaptic’а) в том, чтобы включить (или выключить) те или иные критерии поиска:

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

Ну а с пунктом Панель инструментов всё проще некуда — здесь устанавливается вид её кнопок: в виде только значков, только текста или их комбинации; можно также скрыть инструментальную панель вообще:

На этом настройки Synaptic’а можно считать законченными. Как, впрочем, и вообще разговор о нём. А уж чем пользоваться на предмет управления пакетами, утилитой ли командной строки apt сотоварищи, или графической оболочкой Synaptic — следует решать по ситуации.