Воззрения кота Manual’а. Deb-пакеты. Часть 4. Инструментарий apt

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

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

Вступление

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

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

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

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

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

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

/usr/bin/apt
/usr/bin/apt-cache
/usr/bin/apt-cdrom
/usr/bin/apt-config
/usr/bin/apt-get
/usr/bin/apt-key
/usr/bin/apt-mark

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

dpkges-part_04_001

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

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

Отступление. Утилиту apt из одноимённого пакета, имеющего место быть во всех deb based системах, не следует путать с утилитой того же имени из дистрибутивов проекта Mint — Linux Mint и LMDE. Последняя возникла задолго до появления в инструментарии APT утилиты apt. И представляет она собой набор скриптов на Python’е, интегрирующих возможности команд apt-get, apt-cache, dpkg и даже aptitude. Она входит в пакет mintsystem и устанавливается в каталог /usr/local/bin (подробности — в книге про Linux Mint и его Cinnamon. Теоретически apt для Mint можно прикрутить и к «чистым» клонам Ubuntu (и автор этих строк предпринимал такие попытки). Однако нынче это занятие потеряло смысл, так как нативный apt из современных версий пакета apt по функционалу сравнялся со своим предтечей из Mint’а.

К слову сказать, определить версию apt можно с помощью этой самой утилиты. И в момент сочинения этих строк в Cintu (как и в других регулярно обновляемых клонах Ubuntu 16.04) она будет такой:

$ apt --version
apt 1.2.19 (amd64)

В Ubuntu Yakkety версия apt нынче 1.3.3, а в Zesty — даже 1.4beta, которая, вероятно, обретёт статус стабильной к выходу релиза.

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

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

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

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

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

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

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

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

    $ man apt

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

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

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

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

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

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

    $ apt list

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

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

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

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

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

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

М локальный:

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

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

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

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

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

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

    $ apt search systemback

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

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

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

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

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

    $ apt search apt

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

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

    $ apt show systemback 

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

dpkges-part_04_002

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

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

    $ apt depends apt

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

dpkges-part_04_003

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

    $ apt rdepends zsh

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

dpkges-part_04_004

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

    $ apt policy cinnamon

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

cinnamon:
  Установлен: 3.2.7+xenial
  Кандидат:   3.2.7+xenial
  Таблица версий:
 *** 3.2.7+xenial 500
        500 http://ppa.launchpad.net/tsvetko.tsvetkov/cinnamon-3-2/ubuntu xenial/main amd64 Packages
        100 /var/lib/dpkg/status
     2.8.6-1ubuntu1 500
        500 http://ru.archive.ubuntu.com/ubuntu xenial/universe amd64 Packages

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

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

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

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

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

    $ apt policy mdm

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

$ apt policy mdm
mdm:
  Установлен: 2.0.17+xenial
  Кандидат:   2.0.17+xenial
  Таблица версий:
 *** 2.0.17+xenial 500
        500 http://ppa.launchpad.net/tsvetko.tsvetkov/cinnamon-3-2/ubuntu xenial/main amd64 Packages
        100 /var/lib/dpkg/status
     0.1.3-2.1build1 500
        500 http://ru.archive.ubuntu.com/ubuntu xenial/universe amd64 Packages

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

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

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

    $ sudo apt install [packagename]

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

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

    $ sudo -i

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

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

    $ sudo -s

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

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

Выбор способа — дело вкуса и привычки. Я практически всегда использую второй, и рекомендую его применителя системы Cintu (и авторских сборок на базе Neon’а). Ибо и там, и там по умолчанию для обычного пользователя в качестве login shell используется командная оболочка Zsh (к которой я привык), тогда как для виртуального root’а в этой роли сохраняется Bash (который я не люблю и знаю плохо).

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

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

    # exit

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

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

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

    # apt install apt-dpkg-ref

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

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

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

    # apt install qapt-deb-installer

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

dpkges-part_04_005

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

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

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

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

dpkges-part_04_006

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

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

dpkges-part_04_007

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

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

    # apt install zsh

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

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

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

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

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

    $ apt download packagename

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

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

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

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

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

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

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

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

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

    # apt autoremove

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

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

    # apt update

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

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

    # apt upgrade

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

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

    # apt full-upgrade

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

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

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

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

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

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

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

Полноты картины следует сказать, что в deb based системах существует ещё один «продвинутый» менеджер пакетов — программа aptitude. По своим возможностям она примерно соответствует как паре утилит apt-get и apt-cache, так и утилите apt в современном её исполнении. Однако предоставляет и некоторые дополнительные функции, до недавнего времени бывшие уникальными.

Тем не менее, нынче aptitude категорически не рекомендуется к использованию во всех дистрибутивах семейства Ubuntu и отсутствует в стандартной базовой инсталляции. Кажется, анналогично её положение и в соббственно Debian’е. Причин тому две. Первая — программа эта давно не развивается, и в ней накопилось достаточно большое количество ошибок, которые проявляются при разрешении зависимостей.

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

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

Утилита apt-mark

В в утилите apt не предусмотрено простых средств для массового изменения вторичных статусов пакетов, вроде автоматически установленных или зафиксированных — одна из задач, с которыми хорошо справлялась aptitude, ныне, как уже было сказано, исключённая из рядов КПСС Core System в Debian’е и Ubuntu. Однако на смену ей ghbikf утилита apt-mark — один из компонентов пакета apt.

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

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

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

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

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

    $ apt-mark showauto | grep [pattern]

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

    # apt-mark manual *

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

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

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

А вот про пару hold и unhold можно сказать определённо: она нужна редко, но крепко. Например, для фиксирования версии ядра — если не собственноручно собранного, то хорошо подобранного. Или позарез нужного пакета одного из старых релизов, который в релизах более новых капитально поломали, а то и вообще забросили. Или… да мало ли таких случаев в жизни, которые требуют исключения из правил?

Утилита apt-file

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

Однако нередко состав пакета и хочется посмотреть для того, чтобы решить, стоит ли его скачивать, а тем более — устанавливать. И тут на помощь приходит утилита apt-file. Она входит в состав одноимённого пакета, который в базовой инсталляции с mini.iso отсутствует — здесь его потребуется установить самостоятельно:

    # sudo apt install apt-file

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

    $ apt-file update

которая скачает Contents-файлы всех репозиториев, описанных в файле /etc/apt/sources.list и поместит их в каталог ~/.cache/apt-file примерно в таком виде:

ru.archive.ubuntu.com_ubuntu_dists_xenial-backports_Contents-amd64.gz
ru.archive.ubuntu.com_ubuntu_dists_xenial_Contents-amd64.gz
ru.archive.ubuntu.com_ubuntu_dists_xenial-updates_Contents-amd64.gz
security.ubuntu.com_ubuntu_dists_xenial-security_Contents-amd64.gz

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

Для определения состава пакета служит субкоманда list или её псевдоним show. В качестве аргумента указывается так называемый шаблон (pattern), который может принимать несколько значений, в том числе и просто имя пакета, например:

    $ apt-file list apt-file 
apt-file: /etc/apt/apt-file.conf
apt-file: /etc/bash_completion.d/apt-file
apt-file: /usr/bin/apt-file
apt-file: /usr/bin/diffindex-download
apt-file: /usr/bin/diffindex-rred
apt-file: /usr/share/apt-file/apt-file-update.update-notifier
apt-file: /usr/share/apt-file/do-apt-file-update
apt-file: /usr/share/apt-file/is-cache-empty
apt-file: /usr/share/doc/apt-file/README
apt-file: /usr/share/doc/apt-file/changelog.gz
apt-file: /usr/share/doc/apt-file/copyright
apt-file: /usr/share/man/man1/apt-file.1.gz
apt-file: /usr/share/man/man1/diffindex-download.1.gz
apt-file: /usr/share/man/man1/diffindex-rred.1.gz

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

    $ apt-file list apt

последовательность apt будет воспринята как шаблон, который можно расширить не только до apt-build или synaptic, но даже до adapter. Для предотвращения этого безобразия предусмотрена опция --fixed-string, или просто -F, запрещающая развёртывание шаблона. То есть команда

    $ apt-file -F list apt

обеспечит вывод списка файлов только пакета apt и никакого другого. Если отфильтровать его сквозь grep по ключевому слову, например, bin, можно поимённо узнать все входящие в него утилиты, для чего ранее была использована команда dpkg:

apt: /usr/bin/apt
apt: /usr/bin/apt-cache
apt: /usr/bin/apt-cdrom
apt: /usr/bin/apt-config
apt: /usr/bin/apt-get
apt: /usr/bin/apt-key
apt: /usr/bin/apt-mark

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

    $ dpkg -S filename

Но, опять-таки, только в случае, что искомый пакет установлен в системе. Однако в том-то и дело, что обычно как раз для отыскания пакета не установленного — такая ситуация будет описана в трактате о Cintu. И её решение задачи — использование apt-file с субкомандой search (или её псевдонимом find):

    $ apt-file -l find add-apt-repository
software-properties-common

Обращаю внимание на опцию -l: как явствует из её «длинного» имени, --package-only, она обеспечивает присутствие в выводе только имеми пакета, без неё вывод был бы перегружен лишней информацией вроде полных путей к исполняемому файлу, man-странице и вообще всему, что совпадает с шаблоном аргумента.

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

  • --ignore-case (сокращённо -i), предписывающая игнорировать регистр символов;
  • --regexp, она же -x, позволяющая использовать в шаблоне регулярные выражения;
  • -- обозначающая конец опций; она необходима, если шаблон начинается с дефиса.

За остальными опциями — как обычно, к тёте Мане. От которой можно узнать и о последней внутренней команде apt-file, purge, действие которой противоположно update — она удаляет локальные Contents-файлы, что может потребоваться при переключении на другие репозитории.

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

    $ apt-file list apt-file

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

[Общее содержание]

Воззрения кота Manual’а. Deb-пакеты. Часть 4. Инструментарий apt: 2 комментария

  1. Добрый день! Разрешите небольшое замечание. У Linux Mint программа APT гораздо информативнее, чем у Ubuntu. По Ubunt-овскому APT-у никак не могу понять установлена программа или нет. У Linux Mint-овского. есть в начале по apt show опция(на русском!) «Установлен:»да» или «нет». Синтаксис у них тоже разный. При использовании рекомендуемой вами ucaresystem-core в Linux Mint пришлось плясать с бубном и в файле /usr/bin/X11/ucaresystem-core (или /usr/bin/ucaresystem-core) менять запись:
    «sudo apt -y full-upgrade;»
    на
    «sudo apt dist-upgrade —assume-yes;»
    Дополнение «—assume-yes» нужно, чтобы на все запросы команды ей отвечалось
    «ДА» и тогда программа не будет останавливаться, чтобы спросить твоё
    разрешение для продолжения работы.
    Ну а вообще после ваших статей про APT я вообще не смотрю в Synaptic, возможно и неправильно делаю, но пока так.

  2. Алексей, команда apt для всех deb based дистров и утилита apt для Linux Mint — абсолютно разные штуки. Последняя возникла, когда первой кщё и в проекте не было. И представляет собой интегрирующую обвязку для apt-get, apt-cache и даже aptitude. И тогда это было, конечно, последнее слово науки и техники в области deb-менеджмента. Но сейчас возможности обоих apt’ов фактически сравнялись по функционалу, и mint’овский apt кажется мне несколько перегруженным по части зависимостей (в частности, aptirude давно не развивается, и нигде больше не используется).
    Об особенностях Mint’овского apt некогда было подробно написано — http://echo.msk.ru/programs/autor/506741-echo/
    И ещё подробней — в книжке про Mint https://www.alv.me/linux-mint-i-ego-cinnamon-Ocherki-primenitelya-2/#_apt_Linux_Mint
    ucaresystem-core в Mint’е в лоб работать и не должна — здесь она по умолчанию вызывает фирменный /usr/local/bin/apt, а не стандартный /usr/bin/apt — на что Вы и обратили внимание. Теоретически для того, чтобы в Mint’е вообще использовать стандартный apt вместо собственного, достаточно поменять последовательность в $PATH, но у меня так и не дошли руки проверить. Или просто задать всевдонимы в конфиге шелла.
    А Synaptic я не использую так давно, что в последней сборке Cintu даже забыл включить :)

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