Mint и сценарий apt

Mint и сценарий apt

Комментарии Нет комментариев

Дистрибутив Mint даже в ряду Ubuntu’дов выделяется богатством средств для работы с пакетами. Хотя и все дистрибутивы этого семейства такими средствами не обижены, в Mint’е, наряду с инструментами, общими для всех deb based систем, имеются и уникальные.

Вступление

Разумеется, в Mint’е есть все консольные и графические средства, имеющиеся и в любом другом дистрибутиве deb based, как то:

  • семейство низкоуровневых утилит dpkg для работы с единичными пакетами, проверяющие зависимости, но не разрешающие их;
  • утилита debi, служащая той же цели, но дополнительно обладающая средствами разрешения зависимостей;
  • Gdebi — графическая «морда» для консольной утилиты debi;
  • утилиты семейства APT, предназначенные для работы с репозиториями пакетов — сцепка apt-cache и apt-get, интегрирующая их возможности менеджер пакетов apt, а также сопутствующие утилиты, типа apt-mark;
  • менеджер пакетов Synaptic — графическая «морда» для ряда утилит семейства APT.

Как уже говорилось, все перечисленные выше средства есть абсолютно во всех deb based системах. А вот некоторые инструменты из Mint’а в других дистрах представлены хуже. Например, в нём каким-то чудом уцелела aptitude (хотя скоро я скажу, каким). Это мощный консольный менеджер пакетов, когда-то пользовавшийся популярностью, но в конце 10-х годов прекративший свое развитие.

Вслед за тем aptitude была удалена из состава базовой Ubuntu и, соответственно, пропала в инсталляциях по умолчанию всех официальных представителях этого семейства (Kubuntu, Xubuntu и других). В причины этого вдаваться не будем, тем более что в репозиториях она сохранилась, и по сей день может быть установлена. Разумеется, при желании.

А вот в Linux Mint aptitude не просто осталась, но и устанавливается по умолчанию во всех трёх редакциях этого дистрибутива. Почему? Легко ответить: aptitude задействована в главном дистрибутив-специфическом инструменте для управления пакетами, который носит имя apt. И представляет собой сценарий на языке Python, в котором интегрированы почти все утилиты управления deb-пакетами, такие как dpkg, apt-cache, apt-get и, наконец, aptitude.

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

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

$ /usr/bin/apt

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

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

Собственной man-страницы скрипт не имеет — команда

$ man apt

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

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

С помощью современной утилиты apt ныне можно решить 99% всех задач по управлению пакетами в deb based дистрибутивах. Но так было не всегда. Утилита apt была представлена миру 1 апреля 2014 года (правда, первоапрельской шуткой это не было).

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

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

Когда в 2013 году я впервые познакомился со сценарием apt из Mint’а, он поразил меня богатством возможностей и удобством использования. Можно только догадываться, каким прорывом казался этот скрипт году в 2008. Сейчас, конечно, он уже не вызывает таких восторгов — утилита apt ныне предоставляет как минимум такие же возможности. Однако сценарий apt — неотъемлемая часть дистрибутива Mint как системной целостности. И потому при постоянной работе в Mint’е, и не только в Cinnamon-редакции, для управления пакетами предпочтительно использовать именно его: это гораздо проще и быстрее, чем копипастить командные эквиваленты из чисто Ubuntu’йских блогов и форумных постов, что настоятельно советуют авторы последних.

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

Программа 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:..."

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

$ /usr/bin/apt list --upgradeable

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

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

$ ls /usr/local/bin/
gnome-help*  highlight-mint*  \ mint-sha256sum*  search*  yelp*

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

$ mint-sha256sum ~/Downloads/vivaldi-stable_5.0.2497.38-1_amd64.deb

Впрочем, скрипт 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 based систем, догадаться о назначении внутренних команд сценария apt по выводу субкоманды help с соответствующим аргументом легко.

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

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

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

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

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

$ apt install shutter
[sudo] password for alv:

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

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

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

$ apt list

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

Вывод списка…
0ad-data-common/focal,focal 0.0.23.1-1 all
0ad-data/focal,focal 0.0.23.1-1 all
...
zzuf/focal 0.15-1 amd64
zzuf/focal 0.15-1 i386
lines 74143-74157/74157 (END)

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

$ apt list --installed

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

$ apt search geany

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

i   geany                                      - fast and lightweight IDE                            
p   geany:i386                                 - fast and lightweight IDE                                    
...
i A geany-plugins-common                       - Набор плагинов для Geany (переводы)                 
p   geany-plugins-common:i386                  - Набор плагинов для Geany (переводы)                 
lines 76-90/90 (END)

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

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

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

$ apt version cinnamon 
5.2.7+una

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

$ apt show geany

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

Package: geany
Version: 1.37.1-2~16.04
Priority: optional
Section: devel
Maintainer: Geany Packaging Team <pkg-geany-team@lists.alioth.debian.org>
Installed-Size: 3 490 kB
Provides: geany-abi-18432, geany-api-239
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.9.12), libpango-1.0-0 (>= 1.20.0), libpangocairo-1.0-0 (>= 1.14.0), libstdc++6 (>= 5.2), geany-common (= 1.37.1-2~16.04)
Suggests: libvte9, doc-base
Breaks: geany-plugins-common (<< 0.21)
Download-Size: 1 121 kB
APT-Manual-Installed: yes
APT-Sources: http://ppa.launchpad.net/geany-dev/ppa/ubuntu focal/main amd64 Packages
Description: fast and lightweight IDE
 Geany is a small and lightweight integrated development environment.
 It was developed to provide a small and fast IDE, which has only a
 few dependencies from other packages. It is using only the GTK3 toolkit
 and therefore you need only the GTK3 runtime libraries to run Geany.
 .
 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

N: Есть 1 дополнительная запись. Используйте «-a» для просмотра.

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

$ apt depends geany
geany
  Зависит: libatk1.0-0
  Зависит: libc6
  Зависит: libcairo2
  Зависит: libgcc1
    libgcc-s1
  Зависит: 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      
Reverse Depends:
  geany-common
  python3-mecavideo
  geany-plugins-common  
  ...
  geany-plugin-addons
  geany-plugin-addons
  geany-common
lines 153-167/167 (END)

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

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

$ apt contains /usr/local/bin/apt
mintsystem: /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
...
/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
lines 49-63/63 (END)

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

$ apt policy cinnamon 
cinnamon:
  Установлен: 5.2.7+una
  Кандидат:   5.2.7+una
  Таблица версий:
 *** 5.2.7+una 500
        500 http://packages.linuxmint.com una/backport amd64 Packages
        100 /var/lib/dpkg/status
     4.4.8-4ubuntu0.2 500
        500 http://archive.ubuntu.com/ubuntu focal-updates/universe amd64 Packages
     4.4.8-4 500
        500 http://archive.ubuntu.com/ubuntu focal/universe amd64 Packages

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

$ apt policy shutter 
shutter:
  Установлен: 0.99.2-1~1ppa1~focal0
  Кандидат:   0.99.2-1~1ppa1~focal0
  Таблица версий:
 *** 0.99.2-1~1ppa1~focal0 500
        500 http://ppa.launchpad.net/linuxuprising/shutter/ubuntu focal/main amd64 Packages
        500 http://ppa.launchpad.net/linuxuprising/shutter/ubuntu focal/main i386 Packages
        100 /var/lib/dpkg/status

В обоих случаях первым идёт пакет из репозитория с более высоким приоритетом, то есть из 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 предназначена команда sources. Однако практически она бесполезна, так как вызывает текстовый редактор по умолчанию для редактирования /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: она не только обновляет все пакеты, для которых обновления доступны, но может доустанавливать новые пакеты и удалять существующие, если таковые появились в репозитории (или, соответственно, исчезли из него): эта ситуация обычна при смене релиза Mint’а, когда эта субкоманда обычно и применяется, например, при смене релиза дистрибутива, также обновлении таких важных его компонентов, как Иксы (Xorg) и рабочая среда (в нашем случае это Cinnamon). В общем случае это выглядит так: для перехода с Mint 20.2 Uma на Mint 20.3 Una, что сопряжено со сменой версии Cinnamon с 5.0.X на 5.2, достаточно сменить имена соответствующих репозиториев в файле /etc/apt/sources.list.d/official-package-repositories.list, после чего дать команду

$ apt dist-upgrade

Подробнее эта процедура описана в Части 1 Историй про Cinnamon. А в рамках истории про сценарий apt пора резюмировать весь предыдущий базар.

Итоги

Можно видеть, что по части манипулирования пакетами возможности сценария apt широки и многогранны. То есть это действительно универсальное средство управления пакетами, в обыденной жизни способное почти всегда заменить все прочие традиционные утилиты данного назначения — от низкоуровневой dpkg до «сладкой парочки» из утилит apt-cache и apt-get.

Правда, обще-Debian’овская утилита apt все восемь лет своей жизни развивалась со страшной научно-фантастической силой. И ныне как минимум не уступает своему скриптовому тёзке из дистрибутива Mint ни по фунционалу, ни по удобству применения (шёпотом и в сторону: а то и превосходит во всех отношениях).

В общем, по данному вопросу можно в очередной раз процитировать Аку нашего, Толстого:

Мне нравятся очень… обои
Сказал я, и выбежал вон.

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

image_pdfPDF

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