Воззрения кота Manual’а: apt и сородичи

Воззрения кота Manual’а: apt и сородичи

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

Содержание

Введение

Управление пакетами (их установка, обновление, удаление) — одна из тех административных задач, которые чаще всего приходится выполнять применителю. Как неоднократно говорилось на этих страницах, вся базовая часть Cintu, без всяких изменений, унаследована от Ubuntu. В том числе и средства управления пакетами. И потому всё сказанное в данных «Воззрениях», применимо к любому клону материнской системы. А многое — и к deb based дистрибутивам вообще.

Общее вступление

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

Этим, кстати, грешат и не столь давние Воззрения кота Мануала: в них можно найти сведения и об установщиках пакетов, и об aptitude, и о различных графических «мордах». Разумеется, знание о факте существования команды dpkg, утилиты Gdebi или оболочки Synaptic не повредит применителю. Однако необходимости прибегать к ним нынче практически нет.

На самом деле 99% всех задач по управлению пакетами нынче решается с помощью универсальной утилиты apt. Правда, как решаются — материалов не много даже на английском, не помогает в данном случае и тётя Маня. Самую подробную информацию по возможностям apt я обнаружил на сайте Computer Hope, однако и в нём имеются прорехи: соответствующий раздел датируется концом декабря 2017 года — и успел несколько устареть.

Ибо для того, чтобы быть «всеохватной», утилита должна иметь версию, начиная с 1.6. Именно она входит в Ubuntu 18.04 Bionic, которая по выходе релиза обрела статус «долгоиграющей». На него и будет ориентироваться всё дальнейшее изложение.

Для борьбы с оставшимся одним процентом задач достаточно помнить о команде apt-mark и пакете apt-file. Воззрения кота Мануала на них, вместе с утилитой apt, и будут темой настоящего очерка. В приложении к которому будет приведён краткий конспект по их использованию.

Особенности данных «Воззрений»

Первая (и главная) особенность данных «Воззрений» — та, что кот Мануал сосредоточил своё внимание исключительно на утилите apt. Не размениваясь на прочие средства работы с deb-пакетами — тем более, что необходимости в их использовании нынче в обыденной работе практически не возникает. Остальные особенности вытекают из главной.

Как уже говорилось, актуальных материалов по утилите apt мало, а русскоязычных — крайне мало. Поэтому кот Мануал попытался осветить функционал её максимально подробно, опираясь на аналогичные функции утилит apt-get и apt-cache, проверяя соответствие экспериментально. И это — вторая особенность его «Воззрений».

Внимание Мануала привлекли те функции apt‘а, о которых, по словам Кристофера Робина, известного, люди почему-то не любят говорить вслух. Среди них — фильтрация результатов поиска пакетов, возможность их локальной установки, делающая излишней обращение к низкоуровневой команде dpkg -i, инверсия действия между субкомандой install и пары remove и purge. Инверсия эта часто описывалась применительно к утилите apt-get, а о том, что она работает и в современном apt, нынче просто забыли. Совместное описание этих функций можно считать третьей особенностью его «Воззрений».

Рассмотрены Мануалом и вопросы автодополнения субкоманд утилиты apt и их аргументов применительно к умолчальному шеллу Cintu — Zsh. Вероятно, большая часть этих автодополнений (если не все из них) работают и в Bash, однако здесь вам не там, и имеется своя специфика. Описание которой является четвёртой особенностью данного материала.

Наконец, пятая особенность «Воззрений» — совместно с утилитой apt описаны и утилиты apt-mark и apt-file, дополняющие её функционал.

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

Пакеты

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

О пакетах вообще

Термин пакет (английское package) употребляется в двух смыслах: как авторский набор исходных текстов, созданный разработчиком программы, и как комплект скомпилированных из него исполняемых программ и всех их служебных файлов, собранный майнтайнерами дистрибутива или вообще третьими лицами. Пакеты в первом смысле называются исходниками или вообще «сырцами» (от английского Source), во втором — бинарниками. В этом Мануале речь пойдёт в основном о пакетах во втором понимании этого термина.

Бинарные пакеты специфичны для семейств некогда родственных дистрибутивов, почему часто говорят о системах rpm based или deb based. Но даже если они собраны в одном формате (например, rpm или deb), бинарные пакеты из разных дистрибутивов далеко не всегда совместимы в рамках одной системы. Впрочем, к формату deb, который здесь рассматривается, это относится в наименьшей степени: например, пакеты для всех дистрибутивов семейства Ubuntu сохраняют почти полную бинарную совместимость внутри него, а иногда — с пакетами прародительского Debian’а и его прямых клонов.

Формат 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).

Как это принято в мире Open Source, все бинарные пакеты (и пакеты deb-формата тут не исключение) сопровождаются исходными текстами, доступными из соответствующего репозитория дистрибутива. И здесь deb-формат проявляет свою специфику: каждый пакет в исходниках обычно включает три файла — packagename.orig.tar.gz, packagename.dsc и packagename.diff.gz.

Первый — самый обычный тарбалл исходных текстов авторского пакета, что подчеркивается словом orig в его имени: формат архива, имя и система нумерации версий также совпадают с таковыми авторского пакета. Файл packagename.dsc содержит в себе всю метаинформацию, необходимую для правильного построения из него бинарного deb-пакета. А packagename.diff.gz — это те изменения исходного кода, которые вносятся для адаптации пакета непосредственно к данному дистрибутиву. Если таких изменений не потребовалось (или если пакет писался именно для данного дистрибутива), он может и отсутствовать.

Зависимости

Ключевым для бинарных, или дистрибутивных, пакетов является понятие зависимостей. Суть его в том, что пакет 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 и авторских редакциях Neon’а сделано по умолчанию:

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-src 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:bluesabre/geany-gtk3 — репозиторий текстового редактора Geany, собранного на базе Gtk3. Важно, что они в обязательном порядке включают «префикс» ppa:, который в имени соответствующего list-файла отбрасывается. Зато завершается последний обязательным компонентом — именем релиза. Например, для указанной сборки Geany имя list-файла, соответствующего релизу 17.10 — bluesabre-ubuntu-geany-gtk3-artful.list (версии для 18.04 на момент сочинения этих строк нет).

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

deb http://ppa.launchpad.net/bluesabre/geany-gtk3/ubuntu bionic main
# deb-src http://ppa.launchpad.net/bluesabre/geany-gtk3/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

Впрочем, к Cintu (и всем остальным Ubuntu’идам) это не относится.

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

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

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

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

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

И в списке выдачи результатов нужно отыскать нужную строку — например, соответствующую репозиторию Gwendal LE BIHAN и проследовать по ссылке:

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

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

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

$ sudo add-apt-repository ppa:gwendal-lebihan-dev/cinnamon-nightly

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

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

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

$ sudo apt update

В версии apt 1.6 необходимости в этом нет: апдейт кеша произойдёт автоматически. Правда, это касается Cintu с её оболочкой Zsh по умолчанию. При использовании Bash’а, как говорят на форуме Matuntu, апдейт происходит только при указании опции -y.

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

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. Либо, на худой конец, сопровождается сведениями о том, как это сделать самостоятельно (пример чему приведён в трактате про Virtualbox). Если ни того, ни другого не имеет места быть — возникает вопрос: а стоит ли связываться с таким пакетом?

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

Как говори лось ранее, последняя версия утилиты apt (начиная с 1.6) практически полностью вобрала в себя функционал команд dpkg, apt-get и apt-cache, а также aptitude. Что, однако, почти не отражено в её официальной документации, и уж совсем — в сторонних сетевых источниках (русскоязычных — точно). Поэтому в четвёртой части трактата про deb-пакеты излагаются воззрений кота Manual’а на ныншние её возможности, а также на некоторые дополнительные утилиты семейства APT.

Вступление

Набор APT (Advanced Packaging Tools) — это программный комплекс, охватывающий все стороны управления пакетами, вплоть до их построения из исходных текстов. Он включает в себя десятки самостоятельных пакетов, объединяющих бессчётное количество отдельных утилит.

Общий обзор

Однако по умолчанию при стандартной инсталляции из этого богачества во всех известных мне клонах Ubuntu устанавливается только собственно пакет apt с его зависимостями (libapt, apt-utils) и пара-тройка пакетов служебных (типа apt-transport). Кроме того, в отдельных редакциях Cintu «из коробки» установлены и некоторые другие пакеты этого семейства, например, apt-file (почти всегда, если я про него не забыл) и apt-build (если он для чего-нибудь понадобился).

Так что далее будут рассмотрены утилиты эпонимического пакета 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 из одноимённого пакета, имеющего место быть во всех 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 18.04 (и всех дистрибутивах на основе Bionic’а) она будет такой:

$ apt --version
apt 1.6.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 nem

и нажать клавишу табулятора, то, во первых, имя пакета развернётся до последнего «безальтернативного» символа, а во-вторых, далее имена пакета можно выбирать либо перебором, либо, как определено в настройках оболочки 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.94) будет следующим:

cinnamon:
  Установлен: 3.6.7-20180322040144-bionic
  Кандидат:   3.6.7-20180409040158-bionic
  Таблица версий:
     3.6.7-20180409040158-bionic 500
        500 http://ppa.launchpad.net/gwendal-lebihan-dev/cinnamon-nightly/ubuntu bionic/main amd64 Packages
 *** 3.6.7-20180322040144-bionic 100
        100 /var/lib/dpkg/status
     3.6.7-8 500
        500 http://ru.archive.ubuntu.com/ubuntu bionic/universe amd64 Packages

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

# apt install cinnamon

Правда, в момент сочинения первой редакции этих строк версии Cinnamon для систем на базе Bionic'а в обоих источниках сравнялись. Однако, как обычно, ко времени релиза Ubuntu 18.04 вышла очередная версия Cinnamon (3.8 — на этот раз даже с опережением графика). Которая немедленно появилась в репозитории Гвендаля, но, скорее всего, никогда не появится в официальном.

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

Последний случай, как ни странно, встречается в реальности, самым курьёзным чему примером является ситуация с дисплейным менеджером MDM. Его нет ни в официальном репозитории Ubuntu, ни в большинстве PPA-сборок, кроме репозитория Гвендаля.

Зато в официальном репозитории есть пакет mdm (Middleman System), представляющий собой набор утилит, помогающих одновременно выполнять команды из shell-скриптов. И во время своих первых экспериментов по сборке базовой Ubuntu со средой Cinnamon я однажды установил его вместо M Display Manager'а (именно так расшифровывается аббревиатура MDM). И потом некоторое время недоумевал, почему после рестарта системы я не вижу ничего, кроме приглашения к авторизации в «голой» консоли.

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

$ apt policy mdm

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

mdm:
  Установлен: 2.0.19-20180322000310-bionic
  Кандидат:   2.0.19-20180409000201-bionic
  Таблица версий:
     2.0.19-20180409000201-bionic 500
        500 http://ppa.launchpad.net/gwendal-lebihan-dev/cinnamon-nightly/ubuntu bionic/main amd64 Packages
 *** 2.0.19-20180322000310-bionic 100
        100 /var/lib/dpkg/status
     0.1.3-2.1build2 500
        500 http://ru.archive.ubuntu.com/ubuntu bionic/universe amd64 Packages

Чтобы убедится в том, что это нога у кого надо нога установится тот MDM, который мне нужен.

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

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

Интермедия о праве 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), однако не для того релиза, который нам нужен, хотя и работоспособен в нашем. Например, ни в одном репозитории нам не найти очень нужного (для нас) пакета nemo-terminal для актуальной версии Cinnamon 3.6 и будущей 18.04, однако в PPA-репозитории Embrosin'а он имеется для релиза 17.10 — остаётся его только заполучить.

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

Переходим по ссылке и фильтруем базар по имени пакета и кодовому имени самого «юного» релиза:

После чего «разворачиваем» содержимое пакет, в котором отыскиваем нужный файл — в данном случае nemo-terminal_3.6.0-1~artful0_amd64.deb, он-то и подлежит скачиванию:

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

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

# apt install path2/nemo-terminal_3.6.0-1_artful0_amd64.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. А в произвольной системе Ubuntu based её тоже можно установить из официального репозитория:

# apt install alien

Утилита 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.2-5ubuntu1.2).

Тем не менее, иногда возникает необходимость переустановить запоротый пакет при неизменности его версии в репозитории. И на сей предмет у субкоманды 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 я не вижу.

Интермедия об ucaresystem-core

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

Шелчок на указанной пиктограмме откроет окно терминала (XTerm) и панель для ввода пароля с целью получения прав root'а:

После чего в течении 5 секунд скрипт ucaresystem-core будет запущен, отработает свою программу и, выдав сообщение о необходимости перезагрузки (в случае обновления ядра, например)

прекратит свою работу — терминальное окно при этом закроется автоматически.

Немного о настройке 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-файлов и совмещать их с локальными.

Приложение. Конспект команд

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

Утилита 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 — использование в шаблонах регулярных выражений;
  • -- конец опций; необходимо, если шаблон начинается с дефиса.
image_pdfPDF

2 thoughts on “Воззрения кота Manual’а: apt и сородичи

  1. Ссылка на список виртуальных пакетов не работает. Однако можно посмотреть их через aptitude:
    ★ $ aptitude search ‘?virtual’ ★
    См. https://askubuntu.com/questions/1122264/where-can-i-obtain-a-list-of-all-virtual-packages-provided-by-a-ubuntu-distribut
    Кроме того в aptitude есть поиск по ключевым словам(а чем иным являются виртуальные пакеты?).
    В Cintu пакет aptitude не установлен.

  2. Верная ссылка для перечня виртуальных пакетов теперь:
    https://www.debian.org/doc/packaging-manuals/virtual-package-names-list.yaml
    Что касается просмотра в APT виртуальных пакетов, то с версии 2.0(2020 г.)
    apt-у подбросили дров из aptitude и он тоже может искать виртуальные пакеты:
    $ apt search ?virtual
    или
    $ apt search ~v
    Выводятся десятки тысяч строк, в то время как в перечне Dedebian их около 150.
    См. apt-patterns :
    https://manpages.ubuntu.com/manpages/jammy/man7/apt-patterns.7.html

Добавить комментарий