Содержание
- История 1. Менеджер пакетов pacman
- Про пакеты Arch’а
- Репозитории
- Операторы, опции и аргументы
- Оператор синхронизации -S
- Оператор запроса -Q
- Оператор удаления -R
- Локальная установка
- Ресурсы про Arch и его pacman
- История 2. AUR и его wrapper’ы
- AUR: введение
- AUR vs более иные
- AUR: поиск нужных пакетов
- Устройство AUR’а
- Нештатная установка из AUR’а
- Программы wrapper’ы для AUR’а
- История 3. Обёртка Yay
- Немного из прошлого
- Обретение yay. Простой способ
- Обретение yay. Способ «по науке»
- Подготовка к использованию yay в более иных дистрибутивах
- Особенности wrapper’а yay
- Продолжение Истории 3. Пример практического использования Yay
- Предварительные замечания
- Первая синхронизация
- Первые установки: оболочка zsh и выпадающий терминал Yakuake
- Удаление «излишеств»
- Установка необходимого
- Обращение к AUR’у
- Заключительные замечания
- И просто заключение. Pacman или Yay?
В последних Историях мы рассмотрели два «фирменных» инструмента дистрибутива EOS для работы с пакетами — простой установщик пакетов QuickStart Installer и «обновитель системы» UpdateInTerminal. И убедились, что их функционала недостаточно для полноценного управления пакетами. Поэтому и сочинились три следующие Истории.
История 1. Менеджер пакетов pacman
Штатный менеджер пакетов для всех систем, основанных на Arch, носит имя pacman. Он был разработан Джаддом Винетом (Judd Vinet), создателем дистрибутива Archlinux, двадцать лет назад (первая версия — 2002 год), и с тех пор существует почти в неизменном виде.
Про пакеты Arch’а
Прежде чем говорить об управлении пакетами, необходимо сказать пару слов о пакетах вообще, в Arch baser системах в частности и в дистрибутиве EOS в особенности.
Коротко говоря, пакеты вообще — это формы распространения программ, каковых существует две основных: пакеты исходных текстов, и пакеты бинарников, то есть откомпилированных исходников.
С пакетами исходников всё ясно — они таковы, каковыми их сочинили разработчики программ, и больше никаковы. Пакеты бинарников же привязаны же к определённым дистрибутивам и семействам дистрибутивов, а также к системе управления пакетами, в данном дистрибутиве (или их семействе) принятым, и, соответственно, имеют разный формат.
Пакеты для дистрибутива Arch и его производных — файлы примерно такого вида:
yay-11.2.0-1-x86_64.pkg.tar.zst
Где yay — имя пакета (для примера), 11.2.0-1 — авторский номер версии и майтайнерский номер сборки, x86_64 — целевая архитектура сборки, то есть для машин с 64-битным x86 Intel-совместимым процессором. Возможное значение последнего параметра — any, то есть для любой архитектуры, можно видеть в пакетах словарей для проерки орфографии (но не самих утилит спеллинга), тем, иконок, бэкграундов и тому подобной косметики. Некоторые клоны Arch’а (и EOS в их числе) поддерживают сборки под ARM-процессоры, но о них мы говорить не будем.
Первый суффикс в имени пакета, pkg, показывает, что перед нами именно бинарный пакет, а не, скажем, архив исходников. Второй (tar) и третий (zstd) суффиксы указывают на то, что это tar-архив, скомпрессированный утилитой сжатия.
В качестве утилиты сжатия в настоящее время выступает zstd — эталонная реализация алгоритма Zstandard, Как ныне считается, алгоритм этот обеспечивает оптимальное соотношение между степенью сжатия и скоростью компрессии и декомпрессии. До недавнего времени оптимальной в этом отношении полагали утилиту xz (алгоритм LZMA), а ещё раньше вполне хватало gzip-сжатия (алгоритм Deflate).
Если посмотреть содержимое файлов пакетов (например, с помощью архиватора Arc, вызываемого из Dolphin’а), то в любом из них обнаружатся скрытые файлы (так называемые dot-файлы, поскольку их «скрытость» обозначается точкой в начала имени). Их всего три штуки (.BUILDINF, .MTREE, .PKGINFO), и содержат они метаинформацию. Прочие файлы пакета — собственно откомпилированные его бинарные компоненты:
Из dot-файлов наиболее интересен для применителя .PKGINFO. Он содежит такие сведения о пакете, как его имя, номер версии, краткое описание etc., включая информацию о зависимостях:
Бинарные компоненты различаются в зависимости от характера пакета. Чобы убедиться в этом, достаточно сравнить между собой скриншоты 3, 4 и 5:
Пакеты для подавляющего большинства дистрибутивов группируются в репозитории — особо скрепные граждане предпочитают именовать их хранилищами, а те, кто низкопоклонствует перед Заподлянским Западом — фамильярно зовут репами. Пакетный менеджер pacman и создавался для работы с репозиториями, почему
к рассмотрению их мы и переходим.
Репозитории
В EOS поддерживается два репозитория. Первый — официальный, общий для всего Arch-семейства дистрибутивов (для России, например, такое зеркало). Из него берутся базовые пакеты (раздел core) и пакеты дополнительные (разделы extra), а также раздел multilib для пакетов поддержки 32-битных приложений в 64-битной системе. Все эти разделы поддерживаются участниками проекта.
Есть также раздел community, который поддерживается сообществом дистрибутива. Точнее, особо доверенным его участникам. Почему в целом весь репозиторий имеет статус официального для дистрибутива Arch. Он является основным и для всех систем, на Arch’е основанных.
Второй репозиторий — хотя и небольшой, но собственный репозиторий EOS (список зеркал — в файле /etc/pacman.d/endeavouros-mirrorlist). Он играет роль официального для этого дистрибутива, включая дистроспецифичные утилиты разного, преимущественно системного, назначения:
Большинство этих утилит имеет префикс eos в имени пакета. Несколько забегая вперёд, это можно определить такой командой:
~/ pacman -Ss '^eos-*'
Вывод её заодно покажет, какие из этих утилит установлены:
endeavouros/eos-apps-info 1.2.5-3 [установлен]
Documentation about apps in the EndeavourOS repository.
endeavouros/eos-bash-shared 1.25-1 [установлен]
Bash code shared by certain EndeavourOS apps.
endeavouros/eos-downgrade 0.3-1
Downwgrade EndeavourOS packages (currently alpha quality).
endeavouros/eos-hooks 1.6-1 [установлен]
EndeavourOS pacman hooks
endeavouros/eos-lightdm-gtk-theme 2.2-1
EndeavourOS theme for lightdm-gtk-greeter
endeavouros/eos-lightdm-slick-theme 2.0-4
EndeavourOS theme for lightdm-slick-greeter
endeavouros/eos-log-tool 1.4.15-1 [установлен]
Gathers selected system logs and sends them to the internet.
endeavouros/eos-lxdm-gtk3 0.5.3-4
Lightweight X11 Display Manager for EndeavourOS
endeavouros/eos-packagelist 2.0-1 [установлен]
An application to gather and optionally install package lists from the EndeavourOS installer
endeavouros/eos-plasma-sddm-config 22.03.1.2-1 [установлен]
EndeavourOS Theme for SDDM for Plasma
endeavouros/eos-qogir-icons 4-2 [установлен]
A colorful design icon theme for linux desktops
endeavouros/eos-quickstart 1.3-2 [установлен]
An application for getting a quick start with installing packages
endeavouros/eos-rankmirrors 2.3-1 [установлен]
EndeavourOS mirror ranking tool
endeavouros/eos-sddm-theme 2.0-2
EndeavourOS Theme for SDDM
endeavouros/eos-skel-ce-awesome 1.0-8
pre user creation skel setup for Awesome EOS-CE
endeavouros/eos-skel-ce-bspwm 1.0-18
Pre user creation skel setup for Bspwm EOS-CE
endeavouros/eos-skel-ce-openbox 1.0-14
Pre user creation skel setup for Openbox EOS-CE
endeavouros/eos-skel-ce-qtile 1.0-9
Pre user creation skel setup for Qtile EOS-CE
endeavouros/eos-skel-ce-sway 1.0-8
pre user creation skel setup for SWAY EOS-CE
endeavouros/eos-skel-ce-worm 1.0-11
pre user creation skel setup for worm EOS-CE
endeavouros/eos-translations 1.9-1 [установлен]
EndeavourOS translation support
endeavouros/eos-update-notifier 1.17-1 [установлен]
Software update notifier and 'news for you' for EndeavourOS users.
Правда, как показывают примеры таких EOS-утилит, как QuickStart Installer и UpdateInTerminal, префикс этот не обязателен.
Тем более, что в репозитории EOS имеются собственные сборки пакетов, прямого отношения к проекту не имеющие. Исходники их размещаются на Github’е, на сайтах разработчиков, и так далее.
Среди них — такие пакеты, как akm (управление ядрами Linux), инсталлятор Calamares, wrapper yay, о котором будет рассказано далее в третьей Истории, и некоторые другие.
Кроме официальных репозиториев, обще-Arch’евского и «фирменного» EOS’сового, существует ещё неофициальный Arch User Reposirory (AUR), также поддерживаемый применителями дистрибутивов этого семейства. Но не обязательно особо доверенными, а, что называется, «с улицы». На AUR действие pacman‘а не распространяется. И потому речь о нём также пойдёт позднее, во второй Истории.
Операторы, опции и аргументы
Как было сказано ранее, pacman существует уже 20 лет в почти неизменном виде. А вид этот таков. Любое действие в pacman выполняется с помощью конструкции, включающей, кроме одноимённой команды, операторы, его опции и аргументы. Оператор определяет одно из базовых действий в отношении пакета (пакетов), и он в единственном экземпляре является обязательным элементом конструкции.
Список поддерживаемых операторов (в русскоязычных материалах называемых также действиями или операциями) можно определить таким образом:
~/ pacman -h
использование: pacman <действие> [...]
действия:
pacman {-h --help}
pacman {-V --version}
pacman {-D --database} <параметры> <пакет(ы)>
pacman {-F --files} [параметры] [файл(ы)]
pacman {-Q --query} [параметры] [пакет(ы)]
pacman {-R --remove} [параметры] <пакет(ы)>
pacman {-S --sync} [параметры] [пакет(ы)]
pacman {-T --deptest} [параметры] [пакет(ы)]
pacman {-U --upgrade} [параметры] <файл(ы)>
используйте 'pacman { -h --help}' вместе с другими операциями для просмотра параметров
Опции уточняют действие операторов — скоро мы это увидим на примере оператора -S, Как можно догадаться из вывода предыдущей команды, список опций, имеющих силу для того или иного оператора (а одна та же опция может сопровождать разные операторы), можно получить с помощью оператора -h в сочетании с любым другим оператором. Например, конструкция
~/ pacman -hT
даст такой вывод:
использование: pacman {-T --deptest} [параметры] [пакет(ы)]
параметры:
-b, --dbpath <путь> указать альтернативное расположение базы данных
-r, --root <путь> указать альтернативный корневой каталог
-v, --verbose выводить больше информации
--arch установить альтернативную архитектуру
--cachedir <каталог> указать альтернативное расположение кэша
--color <когда> раскрашивать вывод
--config <путь> использовать альтернативный конфигурационный файл
--confirm всегда спрашивать подтверждения
--debug показывать отладочные сообщения
--disable-download-timeout
use relaxed timeouts for download
--gpgdir <путь> установить альтернативный домашний каталог для GnuPG
--hookdir
-V, который не предполагает ни опций, ни аргументов. А просто выводит сведения о текущей версии pacman‘а, авторских правах на него и лицензии, под которой он распространяется:
Отступление. На этом и последующих скриншотах вид пригашения командной строки может показаться необычным. Это связано с тем, что я вот уже 20 лет в качестве пользовательского shell’а по умолчанию всегда и везде использую
zsh, причём настроенный в соответствие с Воззрениями покойного кота Мануала. В обсуждение причин вдаваться не буду — они веские и многочисленные. Замечу только, что с точки зрения настройки и последующей интерактивной работы традиционный Bash супротив него — всё равно что плотник супротив столяра…
Все прочие операторы из вывода команды ~/ pacman -h требуют или опций, или аргументов, а обычно и того, и другого, да часто по два стакана не в единственном экземпляре. В качестве аргументов выступает имя пакета, или их имена: в общем случае аргументов может быть сколько угодно.
Вместо множества имён пакетов можно в некоторых случаях использовать маски имён — именно такой приём был применён ранее при поиске всех EOS-утилит командой
~/ pacman -Ss '^eos-*'
Сочетание оператора и опции в командной будет объяснено уже в следующем разделе — забегая вперёд скажу только, что оно предписывает поиск пакетов в удалённом репозитории. А вот смысл маски аргументов расшифрую сейчас.
Маска эта указывает, что искомые имена пакетов должны содержать символы eos в начальной позиции (спецсимвол ^), а после дефиса включать произвольную последовательность символов (спецсимвол *). Одинарные (так называемые строгие) кавычки же экранируют спецсимволы. То есть заставляют считать ^ и * именно «символами специального назначения», а не просто элементами текста.
Оператор синхронизации -S
Дистрибутив EOS, как и все системы на базе Arch’а (по крайней мере, все, мне известные), разрабатывается по модели «скользящих» обновлений (rolling release). То есть изменения разной степени значимости вносятся в него постоянно, не следуя каким-либо релиз-циклам. В связи с этим важнейшим операторов pacman‘а оказывается -S, выполняющий синхронизацию локальной базы данных установленных пакетов с удалёнными репозиториями. Из чего следует, что любые действия с пакетами должны начинаться с такой синхронизации. Это делается командой:
eos# pacman -Syu
Отступление: обращаю внимание на приглашение командной строки. Во всех приведённых ранее примерах оно имело вид
~/. Он символизирует, что для выполнения последующей команды достаточно прав обычного пользователя. Форма жеeos#подсказывает, что выполнение команды из последнего примера требует прав администратора. Права эти могут быть получены или разово, посредствомsudo pacman, или на неопределённый срок, с помощьюsudo -s(завершение действия административных полномочий — командойexit). Здесь и далее это — чистая условность, дабы не оговаривать каждый раз права на выполнение той или иной команды.
Возвращаемся, однако, к синхронизации. Непосредственно за неё, как уже было сказано, отвечает оператор -S. А далее вступают в силу опции данного оператора: -y обеспечивает пересчитывание уже синхронизированной базы, а опция -u обновляет те пакеты, которые в таком обновлении нуждаются.
В результате происходит полное обновление системы, которое во второй Истории мы выполнили с помощью соответствующего модуля Приветствия. Который, в свою очередь, вызывает EOS-утилиту обновления системы UpdateInTerminal.
Ознакомиться со всеми опциями оператора -S можно с помощью оператора вызова помощи:
~/ pacman -hS
Есть случай, когда оператор -S обходится без опций, но зато требует аргументов. Это — установка отдельных пакетов, имена которых в качестве таковых и выступают:
eos# pacman -S aisleriot akm
Как видно из примера, аргументов у данной команды может быть больше одного (в общем случае — сколько угодно, в разумных пределах, разумеется), а её исполнение требует прав администратора.
Однако у оператора -S есть опции, при которых она обходится правами обычного пользователя. Так, прежде чем устанавливать пакет, его не худо бы найти и убедиться, что это именно тот пакет, который нужен.
Поиск пакета, как уже говорилось, выполняется такой командой:
~/ pacman -Ss aisleriot
extra/aisleriot 3.22.23-2
A collection of patience games written in guile scheme
А для получения сведений о пакете служит опция -i:
~/ pacman -Si aisleriot
Репозиторий : extra
Название : aisleriot
Версия : 3.22.23-2
Описание : A collection of patience games written in guile scheme
Архитектура : x86_64
URL : https://wiki.gnome.org/Apps/Aisleriot
Лицензии : GPL
Группы : Нет
Предоставляет : Нет
Зависит от : guile gtk3 librsvg libcanberra dconf
Доп. зависимости : pysolfc: PySol card sets
pysolfc-cardsets: PySol card sets
Конфликтует с : Нет
Заменяет : Нет
Размер загрузки : 11,96 MiB
Установленный размер : 26,88 MiB
Сборщик : Jan Alexander Steffens (heftig) <heftig@archlinux.org>
Дата сборки : Пт 17 июн 2022 11:04:25
Проверен : MD5 SHA-256 Подпись
Выше приведены наиболее употребимые в обыденной жизни опции оператора -S. Остальные опции его, весьма многочисленные, касаются более специальных случаев. И потому оставляются для знакомства заинтересованным лицам.
Ко всем остальным операторам pacman‘а приходится обращаться реже, чем к оператору синхронизации. Однако от этого они не становятся менее важными.
Оператор запроса -Q
Оператор -Q сходен по действию с оператором синхронизации, однако он обращается не к удалённым репозиториям, а к базе пакетов, установленных в системе. Так, команда
~/ pacman -Qs akm
отыщет соответствующий пакет, если он установлен:
local/akm 2.11-1
Arch kernel manager.
Если пакет, указанный в качестве аргумента, не установлен, то молча, без всякого сообщения, вернётся пустое приглашение командной строки:
Для установленного же пакета можно получить и более подробную информацию:
~/ pacman -Qi akm Название : akm Версия : 2.11-1 Описание : Arch kernel manager. ... Причина установки : Явно установлен Установочный скрипт : No Проверен : Подпись
Команда
~/ pacman -Qe
выведет список всех пакетов, установленных в системе явным образом:
accountsservice 22.08.8-2 adobe-source-han-sans-cn-fonts 2.004-1 adobe-source-han-sans-jp-fonts 2.004-1 adobe-source-han-sans-kr-fonts 2.004-1 akm 2.11-1 ... xterm 372-2 yad-eos 12.0-1.3 yakuake 22.04.3-1 yay 11.2.0-1 zsh 5.9-1
А команда
~/ pacman -Qd
выведет список пакетов, установленных в качестве зависимостей:
a52dec 0.7.4-11 accounts-qml-module 0.7-4 acl 2.3.1-2 adobe-source-code-pro-fonts 2.038ro+1.058it+1.018var-1 ... zimg 3.0.4-1 zlib 1:1.2.12-2 zstd 1.5.2-7 zvbi 0.2.35-4 zxing-cpp 1.4.0-1
Статус пакета, «явный» или «автоматический», присваивается при его установке — прямой ли командой pacman -S pkgname или как зависимость иного устанавливаемого пакета, соответственно. Однако статус этот можно поменять и вручную. Команда
eos# pacman -S --asdeps pkgname
отметит пакет-аргумент как автоматически установленный, а команда
eos# pacman -D --asexplicit pkgname
сделает его установленным вручную. В обоих случаях — вне зависимости от способа установки и изначального статуса.
К слову сказать, некоторые опции, связанные с любыми операторами, краткой формы не имеют. Видимо, это связано с ограниченностью латинского алфавита. И потому без краткой формы остаются в основном опции, используемые редко.
Действительно, смена статуса пакетов требуется не часто. Но когда требуется — то требуется без дураков. Потому что пакеты, установленные в как зависимости других пакетов, вместе с «материнским» пакетом и удаляются, что не всегда желательно. И в этом случае может быть целесообразно автоматический статус пакета на «ручной». С необходимостью обратной процедуры я не сталкивался, но теоретически могу представить, что и она может быть нужна.
А вот что видится необходимым — это возможность фиксации версий отдельных пакетов, то есть запрета их автоматического обновления по команде тотального апдейта системы pacman -Syu. Особенно важно это для программ из AUR’а. Во-первых, обновление больших и сложных пакетов связано с пересборкой не только их самих, но их зависимостей, что требует времени (иногда не значительного, а очень значительного). Во-вторых, иногда после этого программы, которые раньше успешно собирались, устанавливались и справно функционировали, после обновления теряли работоспособность полностью.
К сожаления, оператор -Q в pacman‘е не имеет опций, аналогичных команде apt-marc hold из пакетного менеджера apt в deb based системах. Для фиксации версий пакетов требуется прямое редактирование файла /etc/pacman.conf, Для чего его следует открыть от лица администратора в любимом редакторе, например так:
eos# nano /etc/pacman.conf
В нём отыскивается строка
#IgnorePkg =
С неё снимается символ комментария
#, а в качестве значения этого параметра вписывается имя пакета, который хотелось бы защитить от обновлений, например:
IgnorePkg = COLMAP
Если таких пакетов больше одного, они даются в той же строке через пробел.
Список файлов установленного пакета выводится таким образом:
~/ pacman -Ql eos-bash-shared eos-bash-shared /etc/ eos-bash-shared /etc/eos-script-lib-yad.conf eos-bash-shared /etc/eos-sendlog.conf eos-bash-shared /usr/ eos-bash-shared /usr/bin/ eos-bash-shared /usr/bin/ChangeDisplayResolution ... eos-bash-shared /usr/share/endeavouros/scripts/ eos-bash-shared /usr/share/endeavouros/scripts/eos-script-lib-yad eos-bash-shared /usr/share/endeavouros/scripts/ksetwallpaper.py
А команда
~/ pacman -Qo UpdateInTerminal
решает обратную задачу, позволяя определить, к какому пакету принадлежит данный файл:
/usr/bin/UpdateInTerminal принадлежит eos-bash-shared 1.25-1
Наконец, команда
~/ pacman -Qdt
выводит список «осиротелых» пакетов. То есть зависимостей удалённых пакетов, более никакими другими пакетами не используемых:
cereal 1.3.2-1 cmake 3.23.2-2 coin-or-lemon 1.3.1-3 flann 1.9.1-7 glfw-x11 3.3.8-1 graphviz 5.0.0-1 ninja 1.11.0-1 opencv 4.6.0-3 proj 9.0.1-1 python-sphinx 5.1.1-1
Пакеты-«сироты» обычно имеет смысл удалять, дабы не захламлять систему. Хотя часто требуется удалить пакеты вне зависимости от их статуса. Чем мы сейчас и займёмся.
Оператор удаления -R
Как известно, пакеты не только устанавливают, но иногда и удаляют. Так, автор этих строк обычно начинает работу в любом дистрибутиве с удаления пакетов, которые он полагает лишними — не из экономии места на диске, а чтобы глаза не мозолили. Правда, EOS с точки зрения комплектации достаточно аскетичен, и излишеств в нём не много. Разве что аудио-, видео- и вообще медиаплейеры, которые я в любой системе истребляю безжалостно, заменяя их скромным, но универсальным mpv.
За удаление пакетов отвечает оператор -R. Просто удаление единичного пакета выполняется так:
eos# pacman -R aisleriot
Общесистемные конфиги пакета (они, как правило, располагаются в каталоге /etc) при этом сохраняются. Для того, чтобы удалить и их, требуется указать опцию -n:
eos# pacman -Rn akm
В результате из каталога /etc/ пропадёт конфиг «ядерного» менеджера akm.conf.
Опция -s при удалении пакета вызывает заодно и удаление тех его зависимостей (depends</code), которые в результате этого «осиротеют». Действие этой опции рекурсивно, то есть распространяется на зависимости «сирот первого уровня», если те также пополняют «сиротское семейство». И при массовом удалении пакетов тут возможны накладки, почему использование опции -s требует осторожности и аккуратности. То есть, как минимум, внимательного чтения списка удаляемых пакетов
Как подсказывает солдатская смекалка, удалять можно только установленные пакеты, в первую очередь неиспользуемые. Поэтому оператор -R логично применять вслед за оператором -Q. Так, с помощью последнего можно выявить все неиспользуемые пакеты:
~/ pacman -Qdtq
go
А затем удалить свои находки:
eos# pacman -Rsn go [sudo] пароль для alv: проверка зависимостей... Пакет (1) Старая версия Изменение размера go 2:1.18.4-1 -409,20 MiB Будет освобождено: 409,20 MiB :: Удалить эти пакеты? [Y/n]
В данном примере неиспользуемый пакет нашёлся только один — язык программирования Go требовался только при установке утилиты yay, и более ни за чем не нужен (так называемая makedepends, см. Историю третью).
Однако при активном использовании AUR’а таких отходов жизнедеятельности, требовавшихся только при сборке его пакетов, может накопиться много. И есть смысл объединить две команды pacman в конвейерную конструкцию:
~/ pacman -Qdt | sudo pacman -Rsn -
Здесь символ дефиса в конце строки говорит о том, что в качестве аргументов второй команды pacman будут подставлены имена файлов из вывода команды первой. И тут требуется повышенное внимание при чтении списка удаляемых пакетов, дабы нечувствительно не снести половину системы…
Локальная установка
А теперь вернёмся к установке пакетов. В разделе про синхронизацию говорилось об установке их из удалённых репозиториев, однако на локальную установку скачанных пакетов не было даже и намёка. Что неудивительно — задача эта решается с помощью оператора -U.
Аргументом при этом должно быть имя файла пакета, причём полное, а не так называемое basename. Необходимо также указание пути, даже если файл пакета находится в текущем каталоге. Например:
eos# pacman -U ./zfs-dkms-2.1.5-1-any.pkg.tar.zst
Теперь после нажатия на Enter последует такой вывод:
загрузка пакетов... разрешение зависимостей... проверка конфликтов... Пакет (2) Новая версия Изменение размера Размер загрузки endeavouros/zfs-utils 2.1.5-1 8,88 MiB 2,37 MiB zfs-dkms 2.1.5-1 17,11 MiB Будет загружено: 2,37 MiB Будет установлено: 25,99 MiB :: Приступить к установке? [Y/n]
С предложением из последней его строки следует согласиться, нажав Enter ещё раз. После чего начнётся процесс установки, в данном примере довольно долгий, так как он связана с пересборкой модулей ядра для поддержки файловой системы ZFS.
Но в общем случае установка столь же быстра, как и при использовании оператора -S. Что особенно хорошо видно, если вместо пути к файлу пакета использовать полный URL последнего — а оператор -U позволяет и такую форму аргумента:
eos# pacman -U https://mirror.alpix.eu/endeavouros/repo/endeavouros/x86_64/zfs-utils-2.1.5-1-x86_64.pkg.tar.zst
В обоих примерах в педагогических целях использованы пакеты из официального репозитория EOS, предварительно скачанные на локальную машину. Хотя проще было бы найти их с помощью команды
~/ pacman -Ss '^zfs-*'
в таком вот виде:
С последующей установкой найденного:
eos# pacman -S zfs-dkms zfs-utils
В таком виде:
То есть в EOS оператор -U оказывается невостребованным, по крайней мере, для меня: все нужные мне пакеты имеются либо в официальном репозитории Arch’а, либо в «фирменном» репозитории EOS, либо, на худой конец, в AUR’е.
Однако оказалось, что есть немало сторонних, то есть и близко неофициальных, репозиторев Arch’а, список которых приведён на странице с очевидным названием Unofficial user repositories. Скачанные с них пакеты формата *.pkg.tar.zst и следует устанавливать с помощью команды pacman -U path2/pkgname.
Правда, при беглом просмотре указанной страницы (а до просмотра не беглого у меня руки пока не дошли) для себя я там нашёл только один ресурс: Arch GeoTux, да и тот последний раз обновлялся на рубеже 19-го и 20-го годов. Однако в нём обнаружилось два полезных для меня бинарных пакета — COLMAP и Mic-Mac, которые имеются ещё только в AUR’а — но там их установка сопряжена со значительными трудностями.
Есть и ещё одна точка приложения оператора -U, узкая, но часто необходимая — получение доступа к AUR’у, о котором пойдёт речь в следующей Истории. Дело в том, что соответствующих утилит нет в официальном репозитории Arch’а от слова вообще. Нет их обычно и в собственных репозиториях дериватов Arch’а (исключения, кроме EOS — Manjaro и, возможно, ещё какие-то дистры, с которыми я не сталкивался).
И тут возникает задача, подобная той, что решал барон Мюнхгаузен, вытаскивая самого себя из болота за волосы: получить доступ к AUR’у с помощью средств, только в AUR’е и имеющихся. Задача эта, в отличие от задачи враля-барона, решаема, и со временем, в третьей Истории, будет рассказано, как.
Ресурсы про Arch и его pacman
Историю же про pacman следует завершить, хотя я рассказал не о всех возможностях этого пакетного менеджера. И тому было две причины. Первая — за 20 лет его существования о нём накопилось много информации, которую легко найти в сети. А о второй причине догадаются те читатели, которые осилят третью из нынешних Историй.
Итак, информация о pacman‘е богата и разнообразна. Во-первых, это встроенная система помощи, вызываемая командой с оператором помощи и одним из «заглавных» операторов. То есть операторов, передаваемых прописными буквами. Кроме буквы -V: в этом случае будет просто повторён вывод pacman -h.
Во-вторых, всегда следует помнить тётю Маню и верить тёте Мане — она знает всё за облаву за команду pacman:
~/ man pacman
Кстати, при чтении тексты встроенной помощи и соответствующих разделов man-страницы выглядят идентичными. Что это: man-страница создавалась из фрагментов встроенной помощи, или в последней выводятся подходящие вырезки из man-страницы — тайна сия велика есть.
В-третьих, существует такая замечательная штука, как ArchWiki — настоящий кладезь премудростей, касающихся этого дистрибутива и всех его дериватов, а также Linux’а вообще. Ценность его усугубляется тем, что многие страницы его имеют русские версии.
В частности, это касается и самого интересного в контексте данной Истории — страницы про pacman, про Tips and tricks к нему, про Meta package and package group, про System maintenance.
Очень интересна страница pacman/Rosetta. Правда. она существует в английском оригинале и переводах на четыре европейских (немецкий, испанский, финский и португальский) и три азиатских (арабский и два каких-то CJK) языка. Русского перевода нет, но он и не нужен.
Так как статья вполне доступна даже тем, кто, подобно автору этих строк, не силён во вражьей мове: для её понимания достаточно как-то разбирать латиницу и знать названия пакетов. Ибо посвящена она сравнению pacman‘а с системами пакетного менеджмента таких дистров, как Red Hat/Fedora (dnf), Debian/Ubuntu (apt), SLES/openSUSE (zipper) и Gentoo (emerge). И предназначена в первую очередь для тех, кто запанибрата с одной из них.
Потому как сравнение это проводится не с позиций лучше или хуже, а исключительно с точки зрения соответствия часто используемых командных конструкций pacman'а более иным средствам, позволяющим получить аналогичные результаты.
Конечно, статья эта даёт некоторый материал и для сравнения возможностей фигурирующих в ней систем управления пакетами. Но я этим заниматься не буду. Потому что подошло время для нашей второй Истории — про репозиторий AUR и средства для работы с ним.
История 2. AUR и его wrapper’ы
В официальном репозитории Arch’а, по данным раздела Packages сайта проекта, более тринадцати тысяч пакетов; точнее, на данный момент (3 августа 2022 года) — 13191. Чего, казалось бы, должно хватить на все случаи жизни. Ан нет, часто бывает так, что каких-то позарез нужных пакетов в основном репозитории нет из-за специфических вкусов или задач применителя. И тогда настаёт время вспомнить про AUR.
AUR: введение
Так, до недавнего времени я целиком вписывался в основной репозиторий — за двумя мелкими, но необходимыми исключениями. Во-первых, мне для проверки орфографии позарез нужен русский словарь с обязательной буквой Ё (то есть когда еще вместо ещё считается ошибкой). А во-вторых, для иллюстрирования своих некомпьютерных сочинений («Историй про историю» и «Историй про геологию») мне необходима программа Google Earth Pro.
Ни того, ни другого в основном репозитории Arch’а нет. Как нет и фотограмметрических программ, необходимость в которых появилась у меня в последние месяцы. Причём последних нет и в репозиториях Debian’а (за буквально единичным исключением в виде COLMAP), и даже в Alt’овском Sisyphus’е (про остальные дистрибутивы и говорить не приходится). Так что последняя надежда оставалась на AUR.
И в своих надеждах я не обманулся. Поскольку AUR включает в себя (на то же 3 августа) 84308 наименований пакетов, было бы странно не удовлетворить через него любые потребности.
AUR vs более иные
Для сравнения: в нынешнем MX Linux 21.1, основанном на Debian stable и имеющем доступ ко всем пакетам его репозиториям (плюс не очень большое количество пакетов из репозитория собственного), на тот же день имеется 60822 пакета. Число определяется по выводу команды
~/ apt-cache search ^
в дистрибутиве MX Linu, основанном на Debiab stable, о котором немало говорится на этих страницах
Отступление. Интересно было бы сравнить эти числа с количеством пакетов в Ubuntu, включая PPA-репозитории, с таковым openSUSE вместе с его репозиториями semi-official и «домашними»: в обоих этих дистрах дополнительные, помимо официальных, репозитории представляют собой нечто вроде аналогов AUR’а. Однако число пакетов в обоих случаях учёту не поддаётся — по крайней мере, мне простого способа такого учёта не придумалось.
Также любопытно было бы посчитать число пакетов в бессчётных неофициальных репозиториях Slackware, но это вообще, похоже, задача не решаемая.
Впрочем, такие сравнения не корректны: размер репозитория чего бы то ни было не коррелирует с на наличием в нём поддержки позарез нужного пакета.
AUR: поиск нужных пакетов
Репозиторий AUR (что означает, пардон за тавтологию, — Arch Usr Reposirory) имеет удобное средство онлайового поиска пакетов по ключевым словам в имени и описании, только в имени, по имени майнтайнера, etc.
С помощью этого инструмента мгновенно нашлись все фотограмметрические пакеты, описанные Владимиром Родионовым в соответствующей статье. Из которых практический интерес для меня представляли COLMAP:
и примкнувший к нему Шепилов OpenMVS:
А также самодостаточный пакет MicMac:
О том, что «ёжкин словарь» для проверки русской орфографии (пакет hunspell-ru-aot) и Google’вская Земля (пакет google-earth-pro) в AUR’е имеются, я помнил по тем временам, когда был активным применителем Antergos’а — косвенного предка EndeavourOS.
Кстати, в те времена в AUR’е находился и ещё один из необходимых мне пакетов — браузер Vivaldi. Но с тех пор он успел перекочевать секцию community официального репозитория. Где его легко найти с помощью уже тамошней службы поиска:
Так что Vivaldi — один из примеров того, как секция community официального репозитория Arch’а пополняется за счёт AUR’а, этим самым community и развиваемого.
Устройство AUR’а
По своему устройству AUR очень отличается от официального репозитория Arch’а и сделанного по его образу и подобию «фирменного» репозитория EOS, который также можно считать официальным для этого дистрибутива.
Официальные репозитории Arch’а и его дериватов (таких, как EOS и Manjaro) — это действительно хранилища (варианты перевода слова Reposirory, согласно Переводчику Google — также вместилище, склад и даже склеп), физически содержащие откомпилированные, архивированные и компрессированные файлы пакетов. Их «пакетная сущность» подчёркивается, как уже говорилось, обязательным суффиксом pkg в именах файлов.
В отличие от официальных репозиториев, AUR не является хранителем пакетов — ни единого пакета, готового к употреблению, в нём не найти.
Он содержит компрессированные архивы вида pkgname.tar.gz. Их главным, а часто и единственным компонентом является файл PKGBUILD — именно в нём с исчерпывающей полнотой описывается вся информация, необходимая для получения исходников пакета pkgname (с сайта разработчиков или ныне чаще с Githab’а), компиляции их и инкорпорации в файловую систему.
В этом же файле указываются зависимости собираемого пакета — необходимые для его работы (depends) или только для сборки (makedepends), опциональные, добавляющие функциональности (optdepends).
Кроме PKGBUILD, в архиве исходников могут оказаться и другие файлы, например, какие-либо patch’и, если они необходимы, или .SRCINFO, содержащие дополнительную информацию об «авторских» исходниках.
Посредством скачивания исходников, их компиляции и последующей интеграции компонентов в файловое древо (то есть директив файла PKGBUILD) устанавливается, наверное, более чем 99,9% пакетов, окученных в AUR’е.
Нештатная установка из AUR’а
Однако некоторые программы в нём скачиваются в бинарной форме. Это не значит, что они лежат в AUR’е физически. Как правило, это программы, на распространение которых их разработчиками накладываются те или иные ограничения. Например, они доступны только в бинарном виде.
Типичным примером такой «полусвободной» программы является Google Планета Земля (в девичестве Google Earth Pro). Она распространяется свободно (подобно бесплатному пиву, а не свободному слову), но только как бинарный пакет в deb- и rpm-форматах. И при этом разработчики хотят от пользователя знакомства с Политикой конфиденциальности:
Скриншот 16. Google Earth Pro. Лицензионное соглашение
Впрочем, не проявляя в этом настойчивости. Если, не читая указанного документа (а он достаточно длинный, весьма скучный и, подобно всем аналогичным, в меру брехливый), нажать кнопку Принять и скачать, предложение выполнить вторую часть намеченной программы последует незамедлительно:
Скриншот 17. Google Earth Pro. Панель загрузки
После этого в каталоге, определённом как место скачивания, появляется файл google-earth-pro-stable_current_amd64.deb. С которым можно расправиться и вручную — подобно тому, как я когда-то делал для установки пакетов в дистрибутивы, к тому вовсе не предназначенные.
Однако нахождение пакета google-earth-pro в AUR’е избавляет нас от этой докуки. И единственное, что нам требуется — программа доступа к этому «репозиторию». Программ таких много (то есть больше двух), именуются они wrapper‘ами и helper‘ами, и о них надо сказать несколько слов.
Программы wrapper’ы для AUR’а
Если мне удалось достаточно внятно рассказать, что происходит при установке пакета из AUR’а, то внимательному читателю (а других читателей, надеюсь, у меня нет) не составит труда догадаться, что pacman тут оказывается (почти) не при делах.
Точнее, он вступает в дело, когда пакет исходников найден, скачан, откомпилен и в виде бинарника валяется где-то на задворках мрачного системного кеша (в ~/.cache/yay/). Со временем мы увидим, что задача барона Мюнхгаузена таки решается. Но пока будем исходить из того, что она уже решена. А как она может быть решена — будет рассказываться в Истории 3.
Ну так вот, решение задачи доступа к AUR’у обеспечивают программы, называемые helper’ами. Некоторые из них выполняют только поиск и скачивание, другие — ещё и сборку.
Наконец, третьи способны установить собранный пакет — за ними закрепилось название wrapper’ов (на рiдной мове — обёрток) для pacman‘а. Как нетрудно догадаться из их названия, они обеспечивают именно то, на что pacman не способен. Из них до недавнего времени наиболее распространённым был yaourt — по крайней мере, он попадался мне чаще всего.
Кроме того, wrapper’ы, выполняющие полный комплекс работ по доступу к AUR’у, имеют графические «морды». Примерами их является Octopi на базе Qt, использовавшийся по умолчанию в Manjaro, и Pamac, бывший главным инструментом для управления пакетами в Antergos’е до его безвременной кончины.
Похоже, что wrapper’ы с графическим интерфейсом теряют свою популярность, поскольку, как считается, их использование может привести к поломке системы, в частности из-за неуправляемых частичных обновлений. Что же касается CLI-обёрток, то вроде наиболее популярной среди них ныне является yay, которая и будет предметом рассмотрения в Истории 3.
История 3. Обёртка Yay
Название обёртки yay расшифровывается как Yet another yogurt. Видимо, намекая на то, что именно этот йогурт наиболее полезен для здоровья (системы). Впрочем, если это название воспринимать не как аббревиатуру, то его можно перевести как «Ура». Что достаточно точно отражает эмоции при знакомстве с её возможностями.
Обёртка yay устанавливается в EOS по умолчанию при стандартной инсталляции этого дистрибутива в любой его комплектации. И, разумеется, соответствующий пакет в бинарном виде находится в (почти) официальном «фирменном» репозитории этого дистрибутива — endeavouros (например, здесь https://mirror.alpix.eu/endeavouros/repo/endeavouros/x86_64/).
Немного из прошлого
Обёртка yay была разработана осенью 2016 года. По крайней мере, в AUR’е она появилась 5 октября 2016 года благодаря парижанину, известному под ником Jguer, который с тех пор неизменно сопровождает пакет на Github’е. Можно предполагать, что он же является одним из его авторов. Сообщество должно знать своих героев — так что вот он:
В EOS пакет этот появился, начиная с первых, ещё до-релизных, версий дистрибутива. В качестве «сборщика» там указывается Antergos Build Server, и датировалась первая сборка, которую мне довелось видеть (в версии 9.0.2-1), 7 апреля 2019 года. В самом Antergos’е, когда я был активным его применителем (то есть практически до конца его существования), в качестве CLI-обёртки pacman‘а использовался yaourt. Так что, видимо, внедрение yay было одним из первых шагов по превращению Antergos’а в EOS.
В настоящее время пакет yay из репозитория EOS имеет версию 11.2.0-1, датируемую 17 июня 2022 года, URL исходников остаётся неизменным. И в качестве майнтайнера бинарного пакета выступает команда разработчиков EndeavourOS.
Кроме EOS, yay, насколько я знаю из сетевых источников, активно используется в Manjaro. Хотя, когда поглядывал на этот дистрибутив, будучи ещё применителем Antergos’а, никаким yay в нём и не пахло. Да и нынче на сайте Manjaro для установки главной героини нашей Истории официально рекомендуют использовать Pamac.
Обретение yay. Простой способ
Бинарный пакет yay практически не имеет зависимостей, необходимых для работы (кроме таких, как git и pacman, без которых жизнь в любой Arch based системе невозможна или очень затруднительна). Так что можно предполагать, что, будучи скачанным из указанного репозитория, он без проблем должен установиться с помощью команды
eos# pacman -U path2/yay
Однако, если это по каким-то причинам не произойдёт, или просто хочется сделать «всё по науке», то можно избрать другой способ, который ранее был назван способом Мюнхгаузена. Далее это было проделано с одним из клонов Arch’а, недавно возникшим дистрибутивом AaricKDE, установленным в виртуалке. Где и выяснилось, что он напрочь лишён собственных инструментов для работы с AUR.
Обретение yay. Способ «по науке»
Во-первых, надо позаботиться о том, чтобы были установлены пакет git и группа пакетов base-devel:
~/ sudo pacman -S --needed git base-devel
Оба они имеются в официальном репозитории Arch’а и по крайней мере второй, «групповой», пакет наверняка частично установлен; потому для «пущего наукообразия» для pacman‘а указывается опция --needed, препятствующая переустановке пакетов, в системе уже имеющихся.
После этого клонируем архив исходников искомого пакета в какое-нибудь подходящее место — у меня для этого заблаговременно создан каталог clones в моём домашнем каталоге:
~/ mkdir clones
в который и следует перейти:
~/ cd clones
Собственно команда клонирования выглядит так:
~/ git clone https://aur.archlinux.org/yay.git
Восле её выполнения в каталоге clones появляется субкаталог yay, в который мы и переходим:
~/ cd yay
Теперь остаётся только собрать пакет:
~/ makepkg -s
Здесь опция -s предписывается собирать недостающие зависимости из официального репозитория Arch’а, если они имеются — а в данном случае такая необходимая для сборки yay зависимость, как язык программирования go, имеется.
Сборка даже такого несложного и небольшого пакета, как yay, займёт некоторое время. А после её окончания в текущем каталоге обнаружится файл вида yay-*.pkg.tar.zst — это и есть собранный пакет. Остаётся последний штрих — установить его; напоминаю, что в качестве аргумента необходимо указать полное имя файла пакета и путь к нему, в данном случае это текущий каталог:
~/ sudo pacman -U ./yay-11.2.0-1-x86_64.pkg.tar.zst
В предыдущую команду можно добавить опцию -i, которая обеспечит установку собранного пакет. Собственно говоря, таки и нужно пступить: это избавит от последующего ввода лишней команды с длинным аргументом;
~/ makepkg -si
Каковая в примере была дана исключительно в педагогических целях. Для проверки правильности выполненных действий в виртуальном AaricKDE с помощью свежесобранного yay были установлены пакеты hunspell-ru-aot и google-earth-pro — оба без всяких проблем.
Подготовка к использованию yay в более иных дистрибутивах
Однако, если мы имеем дело не с EOS (где yay устанавливается по умолчанию при стандартной инсталляции), то перед установкой каких-либо пакетов из AUR’а требуется ещё одно подготовительное действие — генерация базы данных разрабатывемых пакетов. Это делается так, причём один-единственный раз:
~/ yay -Y --gendb
Согласно сетевым источникам, эта команда используется при переходе на yay с какой-либо другой «обёртки». На счёт того, нужна ли она при установке, скажем, на чистый Arch (где никаких обёрток нет и не было), а пакеты из AUR’а устанавливались методом «грубой силы» (он же — метод Мюнхгаузена), указаний в источниках я не нашёл. Сам не не был ни в той, ни в другой ситуации.
Исходя из общих соображений, полагаю, что в случае «чистого Arch’а» приведённая команда не нужна. Впрочем, остаток своих дней я не собираюсь провести в сравнительном изучении особенностей различных клонов Arch’а, и потому вопрос этот меня не очень волнует. Ибо в EOS с его «искоробочным» он просто yay не имеет смысла.
Особенности wrapper’а yay
Каким бы путём мы не обрели yay, установкой бинарного пакта из репозитория или сборкой его из исходников AUR’а, теперь надо смотреть, что с ним делать дальше.
Правда, ответ на вопрос «что делать?» очевиден. Как говорил Шарль де Голль, «если вино налито — оно должно быть выпито, а если пакет установлен — он должен быть применён». И разумеется — по прямому назначению. Остаётся только определить, какое назначение yay — прямое.
Особенность первая: универсальность
Собственно, и тут вроде всё ясно: прямое назначение yay — работа с AUR’ом. Однако неожиданно (для меня) оказалось, что наша обёртка-героиня справляется с установкой бинарных пакетов из официального репозитория Arch’а и «фирменного» репозитория EOS не менее успешно, чем со сборкой исходников, окученных в AUR’е. Причём делает это не сложнее, чем специально предназначенный для того pacman. А подчас, как мы скоро увидим, и гораздо проще.
Видимо, разработчиками yay так и задумывалось: сделать из этой «обёртки дешёвой» универсальное средство для работы с любыми пакетами, предназначенными для дистрибутивов семейства Arch based, как бинарными, так и «исходниковыми». Причём средство, более простое в использовании, чем pacman с его helper’ами и более иным wrapper’ам. Этим и обусловлены многие особенности yay.
Так, в yay имеют место быть абсолютно все операторы и их опции, поддерживаемые pacman‘ом. И оказывают они точно такое же действие. Это — вторая причина, почему в первой Истории мне лень было подробно расписывать операторы и опции pacman‘а, ограничившись самым необходимым минимумом.
Тем более, что в pacman‘е можно найти не все операторы и опции, поддерживаемые в yay — последний обнаруживает некоторые уникальные свойства. В частности, он в некоторых случаях может выполнять свои задачи не только без опций (такое и с pacman‘ом бывает), но даже и без операторов.
В частности, это касается одной из самых часто используемых командных конструкций, вызывающей тотальную синхронизацию локальной базы данных с удалёнными репозиториями, которые могли претерпеть обновление со временем (и наверняка его претерпели — не зря же все клоны Arch’а развиваются по «скользящей» модели), локальное считывание обновлённой базы пакетов и (почти наверняка) обновление тех установленных в системе пакетов, которые в этом нуждаются.
То есть выполняется то, что при использовании pacman’а выражается командной конструкцией
~/ sudo pacman -Syu
Здесь, во-первых, вопреки собственным условностям я указал, что команда эта требует прав администратора, получаемых командой sudo. Во-вторых, напомню, что команда pacman выполняет синхронизацию и обновление только для пакетов, установленных из официального репозитория Arch’а (в случае EOS — также и для пакетов из его фирменного репозитория). Пакеты, собранные из AUR’а, ею не затрагиваются.
Чтобы синхронизировать и обновить все пакеты, в том числе и из AUR’а, потребуется аналог этой команды, использующий нашу «обёртку-героиню»:
~/ yay -Syu [sudo] пароль для alv:
Более того, на самом деле и оператор синхронизации, и его опции не обязательны. Если ограничиться «голой» командой, результат будет тот же самый:
Должен обратить внимание, что обе формы команды синхронизации через yay не требуют явного предварения командой sudo, Или любого иного способа обретения привилегий администратора.
Ибо обёртка наша не только героична, но и весьма интеллектуальна. И сама в состоянии определить, когда административные привилегии на самом деле необходимы — например, при обновлении системы, установке и удалении пакетов, etc. И тогда она вправе спросить — «юзверь ты дрожащая, или право root’а имеешь?» И потребовать подтверждения в виде пароля той юзвери, которая действительно потенциально имеет это право.
В случае же, когда не требуется внесения изменений в файловую систему (при поиске пакетов, получении информации о них, и тому подобных задачах), наша обертка резонно полагает, что юзвери дрожащей вполне хватит её обычных прав, и пароль на доступ к правам администратичным не запрашивается.
Особенность вторая: минимизация ввода
Сказанное позволяет сформулировать ещё две особенности обёртки yay. Первая — минимизация ввода с клавиатуры: мало того, что команда обёртки вдвое короче команды pacman, так она ещё иногда позволяет обходиться не только без опций, но и без оператора. Пустячок, а приятно…
Минимизации ввода служит и автодополнение аргументов обёртки yay по нажатию клавиши Tab. Правда, не для всех оболочек. Но, как известно, большинство целевой аудитории пьют одеколон «Свежесть» используют bash, те, которые с претензиями (вроде автора этих строк) — коньяк в международном аэропорту «Шереметьево» применяют zsh, ну а любители доигрывать вчерашнюю сику пооригинальничать — упражняются с fish‘ем. И все эти три шелла в yay автодополнениями окучены.
Особенность третья: «интеллектуальность»
Следующая особенность нашей обёртки (суммарно, если начинать отсчёт от универсальности, уже третья) — встроенное напоминание о том, в каких случаях для выполнения её директив необходимы права администратора, а когда можно обойтись правами обычного пользователя.
Так, pacman при пропуске команды sudo в случаях её необходимости просто откажется от выполнения директивы (хотя о требовании прав root’а и сообщит). После чего директиву эту приходится повторять уже с предварением sudo. Что, разумеется, не смертельно, учитывая имеющиеся в любом шелле возможности повтора предыдущей команды или её части, таких, как sudo!! и Esc+.. Однако я о таких вещах постоянно забываю.
Конечно, и это мелочь, по сравнению с пчёлами, как сказал бы Винни-Пух. Однако мне эта мелочь экономит немало времени, а работающим в контакте со мной дамам бережёт уши — от порций обсценной лексики, в том числе и на разных языках бывшего Союза и всех трёх Колец Враждебности.
Вообще-то об особенностях yay можно говорить очень долго — я вкратце остановился только на тех, которые представляются важными. Не вообще, а лично для меня — внимание кого-то иного, вероятно, привлекут особенности совсем другие. Например, обращение yay с зависимостями (а обёртка наша позволяет ликвидировать в системе все makedepends любого пакета после его сборки).
Была у меня и мысль проделать ту работу, от которой я отказался в разговоре про pacman — дать полное описание операторов и опций yay, в том числе и уникальных. Но это показалось мне скучным — проще было бы перевести официальную документацию к обёртке-героине. Но я, завершая раздел об её особенностях, просто скажу пару слов об этой самой документации. Ведь это — тоже одна из особенностей yay.
Источники информации о yay
Если о pacman‘е в сети можно найти немало сведений, в том числе и на русском языке, то yay пока (?) таким вниманием не избалован. И основных источников информации об этой обёртке всего два: встроенная помощь, вызываемая командой
~/ yay -h
и, разумеется, безотказная тётя Маня:
~/ man yay
Правда, при ближайшем рассмотрении оказывается, что оба текста совпадают почти построчно. Охватывая, как честно предупреждает тётя Маня (а мы, товарищи, знаем, что она честна, даже если чего-то недоговаривает)
…только параметры, уникальные для Yay. Все прочие предлагается смотреть в man pacman.
Впрочем, кое-какие русскоязычные материалы по yay в сети найти можно. В частности, заслуживает внимания статья Что такое Yay. Особенности. Использование, автор которой представлен как некий пользователь сайта. Есть и немного переводных материалов, однако они несут столь отчётливые следы Транслита Гоши, что вызывают желание обратиться к оригиналу в виде указанной только что документации. Именно ею я и пользовался, составляя нижеследующий пример.
Продолжение Истории 3. Пример практического использования Yay
Как было сказано ранее, сочинять подробное руководство по yay мне было лениво. И, вместо этого, я предлагаю решение средствами этой героической обёртки конкретной задачи, которая встаёт передо мной при каждой установке системы «с нуля». Задача эта — перекомплектация системы, то есть удаление пакетов, которые майнтайнеры посчитали необходимыми, и доустановка тех, которые считаю необходимыми я.
Предварительные замечания
В данном примере объектом перекомплектации выступил дистрибутив EOS в KDE-редакции, необходимые действия основывались на многократно описанных ранее «Воззрениях» кота Мануала на Блогосайте и Цинии. Данное описание предназначено, во-первых, для демонстрации особенностей yay. А во-вторых, оно призвано служить шпаргалкой для меня, любимого — вдруг придётся переустанавливать систему себе или устанавливать ещё кому-то.
Для решения данной задачи была создана виртуальная машина с обычными параметрами (RAM 4 ГБ, целевой носитель 128 ГБ, 2 виртуальных «процессора», поддержка UEFI). Установка проводилась в автоматическом режиме, с автоматической же разметкой диска:
Первая синхронизация
Поскольку EOS развивается по модели «скользящих» обновлений, первое действие наше — синхронизация локальной машины с удалёнными источниками пакетов, перечитывание обновлённой базы данный и обновлением установленных пакетов, что делается так:
[alv@eos-kde ~]$ yay [sudo] пароль для alv:
После ввода пароля на доступ к правам администратора и согласия со всеми предложениям процедура обновления совершается:
Будет загружено: 570,33 MiB Будет установлено: 1655,69 MiB Изменение размера: -8,18 MiB :: Приступить к установке? [Y/n]
Поскольку со времени установки последнего снапшота системы прошло уже более двух недель, процедура эта занимает довольно много времени (можно спокойно покурить) и требует перезагрузки. После чего смотрим статистику установленной системы:
[alv@eos-kde ~]$ yay -Ps
Обращая внимание на оператор -P — в pacman’е такого нет. Впрочем, поскольку никаких действий с пакетами мы пока не производили, ничего интересного там не видим — она нужна просто как точка отсчёта:
Первые установки: оболочка zsh и выпадающий терминал Yakuake
Теперь наступает время установки первого пакета. Практически по всех дистрибутивах Linux в качестве регистрационной пользовательской командной оболочки по умолчанию (так называемый login shell) используется bash. Что я полагаю позорным и преступным, ибо zsh, который я назначил себе на эту роль лет двадцать назад, подходит для неё гораздо лучше.
Отступление. Кстати, я в своём мнении был не одинок. Был некогда дистрибутив под названием Apricity, в котором тоже пользовательским шеллом выступал zsh. Однако он, едва возникнув, лет пять назад скончался в страшных судорогах, подобно турецкоподданному папе Остапа Бендера. Та же участь постигла и нашу Cintu, в которой zsh был login shell’ом со дня её возникновения .
Однако, чтобы обрести zsh в EOS, нужно сначала установить соответствующий пакет:
[alv@eos-kde ~]$ yay -S zsh [sudo] пароль для alv: разрешение зависимостей... проверка конфликтов... Пакет (1) Новая версия Изменение размера Размер загрузки extra/zsh 5.9-1 6,60 MiB 2,22 MiB Будет загружено: 2,22 MiB Будет установлено: 6,60 MiB :: Приступить к установке? [Y/n]
И с поступившим предложением следует согласиться. Правда, чтобы проникнуться величием этого шелла, его сначала надо сделать регистрационным шеллом по умолчанию командой
[alv@eos-kde ~]$ chsh -s /bin/zsh
А также обзавестись его конфигом ~/.zshrc), соответствующим Воззрениям кота Мануала, и тем или иным образом перезапустить пользовательский сеанс. Впрочем, к обёртке yay, о которой нынче идёт разговор, это отношения уже не имеет.
Так что возвращаемся к управлению пакетам. На очереди к установке программа, без которой я всегда чувствую себя как без рук — выпадающий терминал (Drap-Down). На эту роль в любой системе с десктопом KDE есть единственный достойный (и достаточный) кандидат — yakuake:
█▓▒░alv@eos-kde░▒▓██▓▒░ Пт авг 12 05:04:58 ~/ yay -S yakuake [sudo] пароль для alv:
Теперь Yakuake, который всегда под рукой и вызывается по умолчанию клавишей F12, будет нашим главным плацдармом для работы yay. Обращаю внимание, что вид приглашения командной строки изменился — это следствие смены не терминальной программы. а регистрационного шелла:
Скриншот 22. Выпадающий терминал Yakuake
В штатном предустановленном терминале KDE, Konsole, оно будет таким же, как и в виртуальной (так называемой «текстовой») консоли, до настройки которой у нас дело дойдет со временем.
Удаление «излишеств»
А пока предстоит дело, которому я в любой системе предаюсь «отдельно, с большим наслажденьем» — истребление пакетов, полагаемых мною лишними. Правда, в EOS с его аскетической комплектацией по умолчанию фронт работы ограничен — в стандартной установке этого дистра даже офисного пакета нет, ни LibreOffice, ни, на худой конец, OpenOffice:
Отвести душу можно в секции Мультимедиа, где имеется аж три аудио- и видеоплейера — Dragon Player, Elisa и Медиаплейер VLC:
А, как говорил наш дорогой и незабвенный Леонид Ильич Брежнев, нам и два-то генеральных секретаря ни к чему. А про три медиаплейера и говорить нечего. Поэтому, чтобы никому из них обидно не было, истребляем их все:
~/ yay -Rns dragon elisa
Заодно вместе с их конфигами (опция -n) и зависимостями (опция -s). Причём в данной директиве достаточно двух аргументов — пакет VLC будет удалён как зависимость аудиоплейера Elisa:
Чтобы не остаться совсем без музыки и кинов, вместо из всех устанавливаем консольный медиапдейер mpv — по моим потребностям его более чем достаточно, и в обращении он (для меня) очень удобен:
~/ yay -S mpv
И зависимостей он за собой тянет по божески:
Скриншот 26. … а вот эта — нет
С удалением пакетов на этом пока можно закончить. Конечно, кое-какие претенденты на удаление намечены — но я пока не решил для себя, точно ли эти пакеты не нужны мне, как плеозиозавры — народу. Да и требуют они разбирательства с зависимостями, к чему сейчас душа не лежит.
Установка необходимого
Установить же по первости осталось немного. Например, полюбившийся мне в последние месяцы тестовый редактор Kwrite — как оказалось, будучи настроенным должным образом, он пригоден не только для мелкой правки конфигов, но и для всамделишней сочинительской работы:
~/ yay -S kwrite
И, конечно же, лучший браузер всех времён и народов, должен быть установлен в обязательном порядке. Тем более, что буквально на днях вышла его новая версия:
~/ yay -S vivaldi разрешение зависимостей... проверка конфликтов... Пакет (1) Новая версия Изменение размера Размер загрузки community/vivaldi 5.4.2753.28-1 333,93 MiB 99,19 MiB Будет загружено: 99,19 MiB Будет установлено: 333,93 MiB
Среди дополнительных (optdepends) зависимостей Vivaldi числится пакет vivaldi-ffmpeg-codecs для воспроизводства каких-то проприетарных аудио и видео. Я c таковыми за последние годы не сталкивался ни в одной из своих систем, так что спокойно обхожусь без него. Но зарубку в памяти сделал: чем чёрт не шутит — а вдруг понадобится?
Кстати, теперь у нас в системе стало два браузера: Vivaldi добавился к наличествовавшему после стандартной инсталляции EOS Firefox’у. Последний мне нынче кажется грубым и неуклюжим. Да я и забыл, когда запускал его последний раз ради него самого — кроме как в deb- и rpm-системах для захода на официальный сайт проекта Vivaldi и скачивания оттуда свежей версии последнего.
В Arch based системах такой необходимости нет — Vivaldi имеется в общем для них всех официальном репозитории. И, вспомнив слова Л.И.Брежнева о нужности нам двух генеральных секретарей, подумал: а не пора ли отрешиться от старого мира, когда подчас требовалось не меньше двух браузеров на разных движках? И не снести ли Firefox к матери некоего Кузьмы?
Пацан подумал — пацан сделал:
~/ yay -Rns firefox firefox-i18n-ru
Больше никакого удаления пакетов у нас не предвидится. Так что самое время для страховки дать команду освобождения от «сиротских» зависимостей
~/ yay -Yc
Каковых, правда, в нашей системе взяться было неоткуда — так что это делается просто для порядку. Хотя заранее выполненная команда
~/ yay -Qdt
позволила бы убедиться в отсутствии «сирот», вернув пустое приглашение командной строки.
Обращение к AUR’у
Интересно, что за всё время сочинения этого примера я ни разу не обратился к yay ради того, для чего он был придуман: к установке пакетов из AUR’а. А ведь кое-какие из этих пакетов мне нужны гораздо больше, чем плезиозавры народу.
Среди таких пакетов — hunspell-ru-out, словарь для проверки орфографии русских текстов с обязательной буквой Ё (то есть в котором еще вместо ещё отмечается как ошибка). Ну что поделать, с юных лет не могу забыть, что великий русский шахматист, четвёртый чемпион мира, на просьбы позвать к телефону Алёхина имел обыкновение отвечать:
— Такого здесь нет, есть Алехин.
А в комментарии к одной из статей на эту тему мне напомнили, что превращение русского дворянина князя Лёвина в старого еврея Левина — тоже дело рук советских редакторов и экранизаторов графа нашего, пахаря.
Так что заберём у великого шахматиста незаконную Ё, и вернём её герою великого писателя. Для чего всего-то и нужно:
~/ yay -S hunspell-ru-out
Кстати, AUR — чуть не единственное хранилище пакетов от слова вообще, где hunspell-ru-out уцелел и продолжает обновляться до актуальных версий (на данный момент — 0.4.5). Вторым таким хранилищем до недавнего времени был Alt’овский Sisyphus. Но там развитие пакета прекратилось на версии, если эклер не подводит, 0.4.2. Да и установить этот пакет вне дистрибутивов семейства Alt несколько проблематично.
Второй жизненно важный для меня пакет из AUR’а — google-earth-pro, но о его установке достаточно подробно говорилось ранее.
Наконец, чуть выше несколько погорячился, говоря о ненужности второго браузера. Конечно, плагин к Vivaldi для доступа к сайтам типа Флибусты обычно работает безотказно. Но иногда сбоит. И что делать, если сбой пришёлся на момент, когда срочно потребовалась точная цитата из, скажем, «Повести о Ходже Насреддине»? Раньше я всегда в таких случаях полагался на свою память, но в последнее время обнаружил, что она иногда тоже даёт сбои. И понимаешь, что на всякий случай надо держать под рукой что-то типа Tor Broser, каковой и устанавливается из AUR’а:
~/ yay -S tor-browser
Причём в версии, соответствующей локали установленной системы, в моём случае — русской. Правда, пока я занимался установкой Tor Browser’а и, главное, подключался к сети Tor, нормальная работа плагина «Обход блокировок Рунета» восстановилась — сбои его редко продолжаются дольше нескольких минут. Ну ничего,
Tor Browser — штука такая, что её стоит держать на всякий пожарный случай.
Заключительные замечания
Ну а я, наконец, приближаюсь к концу Истории про yay и вообще всех Историй про управление пакетами. Ибо осталось упомянуть только, что в последние месяцы мне потребовались фотограммерические программы, о которых не так давно писал мой старый друг Владимир Родионов. И которые именно в AUR’е и представлены полнее всего.
Однако оказалось, что тема эта
…столь ослепительна и столь глубока, что включает в себя весь ислам с кораном, шариатом, книгой тариката и всеми другими книгами, и всю буддийскую веру, и всю иудейскую веру, и все христианские заблуждения
что должна быть выделена в отдельное производство (тут-то мне и потребовалась цитата их бессмертной «Повести» Леонида Соловьёва). Что, надеюсь, произойдет в ближайшее время. А пока — нечто вроде маленького заключения по Историям о пакетах.
И просто заключение. Pacman или Yay?
В заключении осталось ответить на вопрос: удалось ли разработчикам yay создать универсальный инструмент доступа к программам для любых Arch based систем в любых их хранилищах, как к репозиториям бинарников, так и подюоркам сценариев установки из исходников PKGBUILD’ам. Не знаю, ставили ли они перед собой такую задачу. Но если и нет — значит, она решилась сама собой. Так что подведём краткий итог.
В пользу yay говорит:
- в первую очередь однотипность действий в отношении пакетов из официальных репозиториев и AUR;
- «маловукффие» как самой программы, так и её оперfторов и опций (вплоть до полгого иногда отсутствия оных;
- «напоминалка» о вводе команды sudo, когда это действительно необходимо.
И в результате у применителя не возникает необходимости обращаться непосредственно к команде pacman — хотя она всё время остаётся как бы за кадром всех его действий по управлению пакетами.
