Воззрения кота Мануала: apt для Mint

Воззрения кота Мануала: apt для Mint

В данном очерке кот Мануал излагает свои воззрения на особенности программы apt в реализации для дистрибутива Linux Mint и её отличия от эпонимической утилиты apt, входящей в семейство утилит APT, общее для всех deb based дистрибутивов.

Краткое вступление

Программу apt в реализации для Mint не следует путать с одноимённой же утилитой, входящей в состав всех deb based дистрибутивов (в том числе и в Mint). Поэтому в настоящем руководстве кот Мануал будет назвать первую сценарием apt (а далее будет показано, что это действительно сценарий на языке Python) или, при отсутствии разноченией, просто apt. За второй же он закрепил имя — утилита apt.

Надо сказать, что многие применители Mint (не только совсем начинающие), и особенно пользователи Linux вообще, судя по сайтам, блогам и форумам соответствующей тематики, иногда даже не подозревают о существовании сценария apt для Mint и его отличиях от одноимённой утилиты, хотя и используют его постоянно. Причём механически применяют рецепты для чистой Ubuntu и её прямых клонов, на которые так богаты указанные ресурсы.

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

Это и побудило кота Мануала, известного своим альтруизмом, изложить свои воззрения на сценарий apt и приёмы управления пакетами с его помощью. Причём его воззрения распространяются не только на все редакции Linux Mint, но и LMDE (Linux Mint Debian Edition), основанный, как легко догадаться не на Ubuntu, а на Debian’е послелней стабильной ветки.

Немного истории

В своих Воззрениях на утилиту aptкот Мануал пишет, что ныне с ёё помощью можно решить 99% всех задач по управлению пакетами в deb based дистрибутивах. Но так было не всегда.Утилита apt была представлена миру 1 апредля 2014 года. А до того для выпоролнения всех работ по управлению пакетами требовался комплекс отдельных утилит. В первую очередь это были apt-get (для установки пакетов) и apt-cache (для получения информации об оных). Кроме того, в ряде случаев приходилось прибегать к низкоуровневой утилите dpkg. А некоторые задачи можно было решить только с помощью aptitude.

Для упрощения жизни пользователя вскоре просле создания дистрибутива Mint (2006 год) была разработана программа apt — копирайт на неё, принадлежащий Клементу Лефевру, датируется 2008 годом. Напоминаю, что никакой такой утилиты apt из одноименного пакета APT, общего для всех deb basd систем, ещё и в проекте не было. В результате сценариий apt позвроляет выполнить все действия над пакетами, в том числе недоступные, без привлечения сторонних команд утилите apt.

Общее описание

Программа apt для Mint входит в состав пакета mintsystem. Она представляет собой сценарий на языке Python, в чём легко убедиться такой командой:

$ head -1 /usr/local/bin/apt
#!/usr/bin/python3

Сценарий apt для Mint’а интегрирует все средства управления пакетами deb based систем — apt-get и apt-cache, dpkg и aptitude. Он также позволяет фиксацию версий пакетов и снятие оной, выполняет определение принадлежности файла пакету и, напротив, пофайлового состава пакета — в пакете APT они требуют отдельных команд apt-mark и apt-file, соответственно.

В отличие от стандартной утилиты apt, располагающейся в каталоге /usr/bin, сценарий apt для Mint инсталлируется в каталог /usr/local/bin, что можно определить такой командой:

$ which apt
/usr/local/bin/apt

Так что при вводе в командной строке apt без указания пути вызывается именно она, что поскольку стандартные значения переменной PATH определены в общесистемном конфиге /etc/login.defs таким образом:

$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin...

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

$ /usr/bin/apt list --upgradeable

Это чуть ли не единственная функция стандартного инструментария утилиты apt, в явном виде отсутствующая в сценарии apt для Mint. Однако, как мы увидим позднее, и эта опция здесь доступна.

Сценарий apt — не единственный компонент пакета mintsystem. Кроме него, этот пакет включает ещё пять программ, которые также располагаются в каталоге /usr/local/bin/search:

gnome-help*  highlight-mint*  mint-sha256sum*  search*  yelp*

Подобно apt, это также сценарии на языке Python (gnome-help и yelp) или shell=скрипты (остальные три). Впрочем, к управлению пакетами некоторое отношение имеет только скрипт mint-sha256sum, предназначенный для проверки целостности пакетов путём подстёта подсчёта их контрольных сумм по алгоритму SHA256. Так, эта команда выведет контрольную сумму для пакета google-earth

Впрочем, скрипт search может быть полезен сам себе,вне связи с пакетным менеджментом. Формат её вызова таков:

$ search for [искомый фрагмент] in [каталог для поиска]

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

Применение

Сценарий apt запускается одноимённой командой CLI с указанием внутренней команды, определяющей цель действия и, в большинстве случаев, аргумента (аргументов), в качестве которых выступает имя пакетов (или имена — их может быть сколько угодно):

$ apt command pkgname1 … pkgname#

Некоторые часто используемые внутренние команды apt аргументов не требуют.

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

$ apt

или командой

$ apt help

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

apt
Usage: apt command [options]
       apt help command [options]

Commands:
  add-repository   - Add entries to apt sources.list
  autoclean        - Erase old downloaded archive files
  autoremove       - Remove automatically all unused packages
  build            - Build binary or source packages from sources
  build-dep        - Configure build-dependencies for source packages
  changelog        - View a package's changelog
  check            - Verify that there are no broken dependencies
  clean            - Erase downloaded archive files
  contains         - List packages containing a file
  content          - List files contained in a package
  deb              - Install a .deb package
  depends          - Show raw dependency information for a package
  dist-upgrade     - Upgrade the system by removing/installing/upgrading packages
  download         - Download the .deb file for a package
  edit-sources     - Edit /etc/apt/sources.list with your preferred text editor
  dselect-upgrade  - Follow dselect selections
  full-upgrade     - Same as 'dist-upgrade'
  held             - List all held packages
  help             - Show help for a command
  hold             - Hold a package
  install          - Install/upgrade packages
  list             - List packages based on package names
  policy           - Show policy settings
  purge            - Remove packages and their configuration files
  recommends       - List missing recommended packages for a particular package
  rdepends         - Show reverse dependency information for a package
  reinstall        - Download and (possibly) reinstall a currently installed package
  remove           - Remove packages
  search           - Search for a package by name and/or expression
  show             - Display detailed information about a package
  showhold         - Same as 'held'
  showsrc          - Display all the source package records that match the given package name
  source           - Download source archives
  sources          - Same as 'edit-sources'
  unhold           - Unhold a package
  update           - Download lists of new/upgradable packages
  upgrade          - Perform a safe upgrade
  version          - Show the installed version of a package

Здесь для начала следует сказать о внутренней команде help. Данная без аргументов, она, как мы только что видели, выведет список внутренних команд сценария apt. При указании аргумента — любой из внутренних команд — будут выведены её эквиваленты для apt-cache, apt-get, apt-mark, aptitude или dpkg. Например:

$ apt help search
«apt search» is equivalent to «aptitude -w 123 search»
$ apt help install
«apt install» is equivalent to «sudo apt-get install»
$ apt help deb
«apt deb» is equivalent to «sudo dpkg -i»
...

И так далее.

Команда apt search субкоманда — единственный способ получения информации о работе сценария apt в Mint’е: никакой иной доекментации на него в природе не существует.

Конечно, каждому применителю, достаточно знакомому со стандартным инструментарием любых deb base систем (например, в объёме соответствующего раздела Воззрений кота Мануала), догадаться о назначении внутренних команд сценария apt по выводу субкоманды help с соответствующим аргументом легко.

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

  • поиска пакетов и получения информации о ниж;
  • установки и удаления отдельных бинарных пакетов;
  • общего обновления системы.

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

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

$ apt install shutter
[sudo] password for alv:

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

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

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

$ apt list

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

0ad/bionic 0.0.22-4 amd64
0ad-data/bionic,bionic 0.0.22-1 all
0ad-data-common/bionic,bionic 0.0.22-1 all
...
zyne/bionic,bionic 0.1.2-2 all
zziplib-bin/bionic-updates,bionic-security 0.13.62-3.1ubuntu0.18.04.1 amd64
zzuf/bionic 0.15-1 amd64

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

$ apt list --installed

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

$ apt search geany

отыщет одноимённый пакет для установки этого текстового редактора (называемого, однако, «Небольшой и быстрой IDE») и все его плагины (на сегодняшний день общим числом более сорока):

p   geany                                      - Небольшая и быстрая IDE                             
...
p   geany-plugins                              - Набор плагинов для Geany                            
p   geany-plugins-common                       - Набор плагинов для Geany (переводы)

Важное отличие сценария apt от аналогов утилит семейства APT в том, что в его выводе в первой колонке можно видеть основной статус пакета (i — установленный, p — не установленный или «чисто» удалённый, v — виртуальный, и так далее). А при наличии у пакета дополнительного статуса он отображается во второй колонке. Например, A — автоматически установленный, h — с фиксированной версией, и так далее. Это позволяет весьма дробно отфильтровать пакеты по их статусу, скажем, с помощью утилиты grep.

Возможности стандартной утилиты apt в отношении фильтрации по статусу более ограничены: в выводе её помечаютс пакетыя инсталлированные ([установлен]), все прочие же не помеченные никак. А в выводе apt-cache search на статус пакетоыв нет даже намёка.

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

$ apt version cinnamon
4.4.8+tricia

Массу подробностей о пакете можно узнать с помощью внутренней команды show. Например, команда

$ apt show geany

выведет следующие сведения:

Package: geany
Version: 1.32-2
Priority: optional
Section: universe/devel
Origin: Ubuntu
Maintainer: Ubuntu Developers 
Original-Maintainer: Geany Packaging Team 
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Installed-Size: 3 088 kB
Provides: geany-abi-18176, geany-api-235
Depends: libatk1.0-0 (>= 1.12.4), libc6 (>= 2.15), libcairo2 (>= 1.8.0), libgcc1 (>= 1:3.0), libgdk-pixbuf2.0-0 (>= 2.22.0), libglib2.0-0 (>= 2.41.1), libgtk-3-0 (>= 3.21.5), libpango-1.0-0 (>= 1.20.0), libpangocairo-1.0-0 (>= 1.14.0), libstdc++6 (>= 5.2), geany-common (= 1.32-2)
Suggests: libvte9, doc-base
Breaks: geany-plugins-common (<< 0.21)
Homepage: http://www.geany.org
Download-Size: 1 033 kB
APT-Sources: http://archive.ubuntu.com/ubuntu bionic/universe amd64 Packages
Description: Небольшая и быстрая IDE
 Geany — нетребовательная к ресурсам интегрированная среда разработки
 программ, маленькая и быстрая, с небольшим количеством зависимостей от
 других пакетов. использует только GTK2, поэтому для запуска Geany
 необходимы только runtime-библиотеки GTK2.
 .
 The basic features of Geany are:
  - syntax highlighting
  - code completion
  - auto completion of constructs like if, for and while, XML and HTML
  - call tips
  - folding
  - many supported filetypes like C, Java, PHP, HTML, Python, Perl, Pascal
  - symbol lists
  - embedded terminal emulation

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

$ apt depends geany                         
geany
  Зависит: libatk1.0-0
  Зависит: libc6
  Зависит: libcairo2
  Зависит: libgcc1
  Зависит: libgdk-pixbuf2.0-0
  Зависит: libglib2.0-0
  Зависит: libgtk-3-0
  Зависит: libpango-1.0-0
  Зависит: libpangocairo-1.0-0
  Зависит: libstdc++6
  Зависит: geany-common
  Ломает: geany-plugins-common
  Предлагает: libvte9
  Предлагает: doc-base

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

$ apt rdepends geany      
geany
Reverse Depends:
  geany-plugins-common
  geany-common
  ...
 |deb-gview
  games-c++-dev

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

Все приведённые выше внутренние команды дают информацию как об установленных пакетах, так и о пакетах, доступных в подключённых репозиториях. А вот внутренние команды contains и content работают только для установленных пакетов. Первая позволяет определить, к какому пакету принадлежит данный файл — именно таким способом нами была определена принадлежность сценария apt:

$ apt contains /usr/local/bin/apt
mintsystem: /usr/local/bin/apt

$ apt contains /usr/local/bin/apt

А внутренняя команда content выводит список всех файлов пакета с указанием их положения в файловой иерархии:

$ apt content mintsystem
/.
/etc
/etc/apt
/etc/apt/apt.conf.d
/etc/apt/apt.conf.d/90mintsystem
/etc/apt/preferences.d
/etc/apt/preferences.d/official-extra-repositories.pref
/etc/bash_completion.d
/etc/bash_completion.d/apt-linux-mint
/etc/init.d
/etc/init.d/mintsystem
/etc/sudoers.d
/etc/sudoers.d/0pwfeedback
/lib
/lib/systemd
/lib/systemd/system
/lib/systemd/system/mintsystem.service
/usr
/usr/bin
/usr/bin/check_signals
/usr/bin/dns-fix
/usr/bin/mint-drivers
/usr/bin/rtfm
/usr/lib
/usr/lib/linuxmint
/usr/lib/linuxmint/mintsystem
/usr/lib/linuxmint/mintsystem/mint-adjust.py
/usr/lib/linuxmint/mintsystem/mint-apt-download.py
/usr/lib/linuxmint/mintsystem/mint-apt-recommends.py
/usr/local
/usr/local/bin
/usr/local/bin/apt
/usr/local/bin/highlight-mint
/usr/local/bin/mint-sha256sum
/usr/local/bin/search
/usr/share
/usr/share/doc
/usr/share/doc/mintsystem
/usr/share/doc/mintsystem/changelog.gz
/usr/share/doc/mintsystem/copyright
/usr/share/glib-2.0
/usr/share/glib-2.0/schemas
/usr/share/glib-2.0/schemas/com.linuxmint.gschema.xml
/usr/share/lintian
/usr/share/lintian/overrides
/usr/share/lintian/overrides/mintsystem
/usr/share/linuxmint
/usr/share/linuxmint/adjustments
/usr/share/linuxmint/adjustments/15-mintsystem.menu
/usr/share/linuxmint/adjustments/15-mintsystem.overwrite
/usr/share/linuxmint/adjustments/README
/usr/share/linuxmint/mintsystem
/usr/share/linuxmint/mintsystem/apt
/usr/share/linuxmint/mintsystem/apt/official-package-repositories.pref
/usr/share/linuxmint/mintsystem/templates
/usr/share/linuxmint/mintsystem/templates/resolv.conf
/usr/share/man
/usr/share/man/man1
/usr/share/man/man1/rtfm.1.gz
/usr/share/nemo
/usr/share/nemo/actions
/usr/share/nemo/actions/mint-sha256sum.nemo_action

Наконец, последняя из «информационных» внутренних команд — policy. Она используется для определения приоритета версий одного и того же пакета, доступного из разных репозиториев, например, базового репозитория Ubuntu, официального репозитория Mint'а и (или) PPA. Такая ситуация имеет место быть, например, для пакетов среды Cinnamon (из репозиториев Ubuntu и Mint'а) или для скриншоттера Shutter (из Ubuntu и PPA). В первом случае вывод будет такой:

$ apt policy cinnamon 
cinnamon:
  Установлен: 4.4.8+tricia
  Кандидат:   4.4.8+tricia
  Таблица версий:
 *** 4.4.8+tricia 500
        500 http://packages.linuxmint.com tricia/backport amd64 Packages
        100 /var/lib/dpkg/status
     3.6.7-8ubuntu1 500
        500 http://archive.ubuntu.com/ubuntu bionic/universe amd64 Packages

А для Shutter'а — такой:;

$ apt policy shutter 
shutter:
  Установлен: 0.94.3-1~0linuxuprising1~bionic2
  Кандидат:   0.94.3-1~0linuxuprising1~bionic2
  Таблица версий:
 *** 0.94.3-1~0linuxuprising1~bionic2 500
        500 http://ppa.launchpad.net/linuxuprising/shutter/ubuntu bionic/main amd64 Packages
        500 http://ppa.launchpad.net/linuxuprising/shutter/ubuntu bionic/main i386 Packages
        100 /var/lib/dpkg/status
     0.94-1 500
        500 http://archive.ubuntu.com/ubuntu bionic/universe amd64 Packages
        500 http://archive.ubuntu.com/ubuntu bionic/universe i386 Packages

В обоих случаях первым идёт пакет из репозитория с более высоким приоритетом, то есть из Mint'овского или PPA, но не из Ubuntu'вского.

Манипуляции с пакетами

Главное действие в отношении пакетов, которые были сочтены полезными по результатам рассмотрения «информационных» внутренних команд — их установка. А основным инструментом установки является внутренняя команда install. В качестве аргументов она принимает имена пакетов — те самые, которые были найдены командой apt search и в полезности которых можно было убедиться командой apt show. Например, для установки чрезвычайно полезного текстового редактора Geany следует дать команду

$ apt install geany

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

[sudo] password for alv:

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

Чтение списков пакетов… Готово
Построение дерева зависимостей       
Чтение информации о состоянии… Готово
Следующие пакеты устанавливались автоматически и больше не требуются:
  libfluidsynth1 libmikmod3 libsdl-mixer1.2
Для их удаления используйте «sudo apt autoremove».
Будут установлены следующие дополнительные пакеты:
  geany-common
Предлагаемые пакеты:
  libvte9
Следующие НОВЫЕ пакеты будут установлены:
  geany geany-common
Обновлено 0 пакетов, установлено 2 новых пакетов, для удаления отмечено 0 пакетов, и 7 пакетов не обновлено.
Необходимо скачать 2 849 kB архивов.
После данной операции объём занятого дискового пространства возрастёт на 11,1 MB..
После данной операции объём занятого дискового пространства возрастёт на 11,1 MB.
Хотите продолжить? [Д/н]

Согласие предполагается по умолчанию, так что тут достаточно нажать Enter. После чего начинается скачивание пакетов из содержащего их репозитория, распаковка и инкорпорация компонентов в файловую иерархию, а также регистрация в базе данных и включение, если требуется, исполняемого файла в главное меню (для Geany — в секцимю Прграммирование, так как эта программа позиционируется её авторами как IDE — Integrated Development Environment, то есть интегрированная среда разработки). Основной статус пакета geany изменится на «установленный»:

apt search geany | head -n 1 
i   geany                           - Небольшая и быстрая IDE

А пакет geany-common приобретёт ещё и статус автоматически установленного:

apt search geany-common | head -n 1
i A geany-common                    - Небольшая и быстрая IDE — общие файлы

Если в системе уже был установлен данный пакет более старой версии — он будет обновлён. А вот переустановить пакет той же версии (например, если он был безнадёжно испорчен в ходе экспериментов) команда install откажется, сообщив, что

Уже установлен пакет geany самой новой версии (1.32-2).

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

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

$ apt deb hunspell-ru-aot_0.4.0-2_all.deb

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

Как показывает следующий вывод

$ apt help deb
"apt deb " is equivalent to "sudo dpkg -i "

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

В отличие от внутренней команды install, команда deb не только обновит пакет до более новой версии, но и переустановит его версию текущую.

Установленные пакеты иногда требуется и удалять. Этой цели в сценарии apt для Mint служат две внутренние команды — remove и purge, аргументами которых служат, очевидно, имена удаляемых пакетов. Первая удаляет файлы пакета, но сохраняет его общесистемные конфиги, вторая — удаляет также и их (не затрагивая, однако, конфиги в домашнем каталоге пользователя). Различие между ними отражается в основном статусе удалённого пакета — в первом случае его значение будет c, во втором — p, как и у пакетов, которые никогда не устанавливались.

И remove, и purge автоматически удаляют все зависимые пакеты, список их выводится после ввода пользовательского пароля:

$ apt purge libreoffice-impress
[sudo] пароль для alv:    
Чтение списков пакетов… Готово
Построение дерева зависимостей       
Чтение информации о состоянии… Готово
Следующие пакеты устанавливались автоматически и больше не требуются:
  libfluidsynth1 libmikmod3 libsdl-mixer1.2
Для их удаления используйте «sudo apt autoremove».
Следующие пакеты будут УДАЛЕНЫ:
  libreoffice-impress* libreoffice-ogltrans*
Обновлено 0 пакетов, установлено 0 новых пакетов, для удаления отмечено 2 пакетов, и 7 пакетов не обновлено.
После данной операции объём занятого дискового пространства уменьшится на 4 194 kB.
Хотите продолжить? [Д/н]

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

Пакеты, от которых зависит удаляемый, автоматически не удаляются ни remove, ни purge. В этом случае apt предлагает воспользоваться внутренней командой autoremove для очистки системы от «осиротелых» зависимостей:

$ apt autoremove

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

$ apt check

Что при хорошем раскладе после ввода пароля должно дать такой результата:

Чтение списков пакетов… Готово
Построение дерева зависимостей       
Чтение информации о состоянии… Готово

А при плохом… плохого у нас до сих пор не было.

Перед установкой пакетов из репозитория они предварительно скачиваются и помещаются в каталог /var/cache/apt/archives/. Со временем файлов пакетов накапливается много, а нужны они бывают только в исключительных случаях. Для избавления от них существуют в сценарии apt для Mint предусмотрены команды autoclean и clean. Первая удаляет из кеша только пакеты устаревших версий, сохраняя те, версии которых установлены в системе. Вторая же полностью очищает каталог /var/cache/apt/archives/.

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

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

$ apt update

Эту команду в обязательном порядке следует выполнять после каждого изменения в репозиториях — подключения новых или отключения имевшихся. Теоретически для редактирования списков .репозиториев в сценарии apt для Mint предназначена команда ources. Однако практически она бесполезна, так как вызывает текстовый редактор по умолчанию для редактирования /etc/apt/sources.list. В нашем же дистрибутиве этот файл содержит только репозиторий локального оптического диска, а все реально подключённые репозитории описываются в файлах каталога /etc/apt/sources.list.d.

Кстати, в сценарии apt предусмотрена и внутренняя команда для подключения сторонних PPA-репозиториев — add-repository. В качестве аргумента её используется т.н. PPA-адрес. Например, перед установкой обновлённого Shutter'а надо выполнить такую команду:

$ apt add-repository ppa:linuxuprising/shutter

А затем надо выполнить обновление локального кеша пакетов, как было описано выше.

Для обновления всех, по возможности, пакетов установленной системы в сценарии apt для Mint существует внутренняя команда upgrade. Она выявит все пакеты, для которых в репозиториях доступны более свежие версии, выведет их список, объём для скачивания и прирост объёма занятого дискового пространства после выполнения процедуры, а также запросит подтвержения:

$ apt upgrade
Чтение списков пакетов… Готово
Построение дерева зависимостей       
Чтение информации о состоянии… Готово
Расчёт обновлений… Готово
Следующие пакеты будут обновлены:
  firefox firefox-locale-en firefox-locale-ru gir1.2-networkmanager-1.0
  gir1.2-nm-1.0 libnm-glib4 libnm-util2 libnm0 network-manager
  network-manager-config-connectivity-ubuntu
Обновлено 10 пакетов, установлено 0 новых пакетов, для удаления отмечено 0 пакетов, и 0 пакетов не обновлено.
Необходимо скачать 55,6 MB архивов.
После данной операции объём занятого дискового пространства возрастёт на 572 kB.
Хотите продолжить? [Д/н]

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

При использовании команды upgrade следует учитывать, что она обновляет в том числе и те компоненты, которые по умолчанию были заблокированы для обновления через фирменный инструмент mintupdate — правда, ныне, по причине внедрения TimeShift, в свежеинсталлированной системе по умолчанию таких нет. Если же такие пакеты сохранились от прежних версий (а это были ядро и всё, что с ним связано, glibc, и ещё некоторые), или TimeShift не используется (как это имеет место быть у нас с Мануалом) — следует либо всё взвесить и решиться на обновление указанных компонентов, либо явным образом зафиксировать их версии.

Кстати, просмотреть список пакетов с зафиксированными версиями можно с помощью внутреней команды held. Она относится к категории «информационных» и потому не требует прав администратора, а также не нуждается в аргументах. Впрочем, в свежеинсталлированной системе нынче (начиная с Mint 19.2) зафиксированных пакетов по умолчанию нет. Это связано с внедрением в Linux Mint 19 Tara механизма Timeshift, позволяющего делать снапшоты системы и при ошибках обновления откатываться до предыдущего стабильного состояния.

Фиксация версий пакетов может потребоваться и в ряде других случаев — например, при использовании более неподдерживаемых, но по прежнему необходимых пакетов, пакетов, пересобранных с собственными опциями, и ещё некоторых. Она выполняется внутренней командой hold с указанием имени фиксируемого пакета (пакетов). После чего пакет приобретает дополнительный статус h и не затрагивается обновлениями. Обратная процедура, то есть снятие фиксации, если в ней пропала необходимость, выполняется внутренней командой unhold.

Для тотального обновления системы предназначена внутренняя команда dist-upgrade: она не только обновляет все пакеты, для которых обновления доступны, но может доустанавливать новые пакеты и удалять существующие, если это необходимо для разрешения зависимостей. Эта субкоманда применяется, например, при смене релиза дистрибутива, также обновлении таких важных его компонентов, как Иксы (Xorg) и рабочей среды (в нащем случае это Cinnamon). И выглядит так: — например, для перехода с Mint 17.0 Qiana на 17.1 Rebecca достаточно прописать одноимённые репозитории в файлах их описаний. И после этого дать команду

$ apt dist-upgrade

Полным её аналогом (или, точнее, просто иным именем) является команда full-upgrade.

В сценарии apt для Mint предусмотрена ещё одна внутренняя команда общего обновления — dselect-upgrade, эквивалентная конструкции sudo apt-get dselect-upgrade. Она выполняет обновление в соответствие со статусом пакетов, установленным по умолчанию для древней утилиты dselect. Поскольку самой этой утилиты в стандартной инсталляции Mint нет, изменить (и даже посмотреть эти умолчания затруднительно). Так что мы с Мануалом советовали бы бы воздержаться от использования dselect-upgrade, тем более что ни малейшей необходимости обращаться к ней не видим.

Работа с пакетами исходников

Всё сказанное выше относилось к бинарным пакетам. Однако в сценарии apt предусмотрены и средства для работы с пакетами исходных текстов. Так, с помощью внтуренней команды source можно просто скачать пакет, указанный в качестве её аргумента — разумеется, для этого должен быть подключён репозиторий исходников. Внутренняя команда build (эквивалент sudo dpkg-buildpackage из стандартных утилит deb based систем) выполнит построение бинарного пакета (что требует соответствующего инструментария в установленном виде). А внутренняя команда build-dep ограничится конфигурированием необходимых для этого зависимостей, например:

apt build-dep ubuntu-zfs

Некогда это требовалось мне при сборке пакетов поддержки ZFS on Linux.

Средства графического режима

Для работы с пакетами в графическом режиме Mint располагает общим для всех deb based систем менеджером пакетов Synaptic. Мы им периодически пользуемся, и потому в своё воремя кот Мануал описал его в своих Воззрениях. Так что здесь повторяться мы полагаем излишним.

Однако Linux Mint (как, впрочем, и LMDE) славится также набором фирменных утилит, предназначенных для всестороннего управления пакетами (точнее, приложениями). Правда, и утилиты эти были некогда достаточно подробно описаны в онлайновой книге Linux Mint и его Cinnamon, однако и здесь стоит сказать о них несколько слов.

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

Первое, что обращает на себя внимание — минималистичный дизайн: никаких баннеров, новинок, рекомендаций. Только поле поискового запроса, пиктограммы категорий софта и строка состояния текущих действий (сразу после запуска, разумеется, пустая). И потому Менеджер приложений не вызывает визуального отторжения. И в обращении он столь же прост, как и внешне. А обращение с ним, разумеется, начинается с поиска нужного пакета. Что можно сделать, просматривая Выбор редакции или Категории:

Здесь можно видеть кнопку Установить, нажатие на которую приводит к мгновенной инсталляции выбранного приложения (в примере — Skype). Если же искомое приложение уже имеет место быть в системе, то устанавливать его, разумеется, не нужно — зато, возможно, захочется чего-то удалить:

Причём сделать это можно вместе с зависимостями. Правда, только с зависимыми пакетами, зависимости-сироты в системе остаются:

Надо сказать, что в Mint'овской сборке Cinnamon есть и ещё один метод удаления приложений, ещё более простой — непосредственно из главного меню, по ПКМ на любом его пункте появляется меню контекстное, с соответствующим пунктом:

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

$ apt autoremove

Далее, в той же секции Администрирование есть пункт Источники приложений — это ни что иное, как менеджер репозиториев, который в оригинале зовётся software-sources (или mintsources):

Здесь можно выбрать наиболее подходящие зеркала официальных репозиториев, как базового (то есть прародительской Ubuntu), так и Mint-специфичные, подключить PPA-репозитории, а также любые сторонние — достаточно выбрать раздел репозиториев и нажать кнопку Добавить. После чего появляется панель, например, для PPA-репозиториев — такая. В соответствующую строку необходимо вписать нужный ppa-адрес (в примере добавляется PPA-репозиторий свежих ядер сайта Liquorix) и нажать OK:

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

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

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

И, наконец, последнее — Менеджер обновлений. Его можно вызвать из главного меню Cinnamon (всё из той же секции Администрирование). Но по умолчанию пиктограммка запуска нашего «обновителя» висит в системном трее, где к тому же показывается, сколько обновлений доступно в данный момент. А список обновляемых пакетов можно поглядеть после запуска Менеджера:

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

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

Итог

Можно видеть, что по части манипулирования пакетами возможности сценария apt широки и многогранны. То есть это действительно универсальное средство управления пакетами, в обыденной жизни способное почти всегда заменить все прочие утилиты данного назначения — от низкоуровневой dpkg (обращение к которой потребуется только в исключительных случаях) до графического front-end’а — Synaptic’а. Ибо не уступает последнему в наглядности вывода информации о пакетах, позволяя манипулировать ими проще и быстрее. Правда, рядом с apt для Mint его тёзка из пакета APT (общего для всех deb based дистрибутивов) выглядит функционально сопоставимым. Но традиционные apt-cache и apt-get — несколько усложнёнными синтаксически. Что же до aptitude, то она в этом контексте кажется вообще излишней: apt для Mint обеспечивает почти все функции её командного режима, а в интерактивном режиме эта программа в дистрибутивах семейства Ubuntu и её клонах уже давно работает не вполне корректно.

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

image_pdfPDF

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