Antergos и управление пакетами: CLI или GUI?

Antergos и управление пакетами: CLI или GUI?

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

Было время, когда менеджеров пакетов не было. Были установщики пакетов, вроде pkgtools/code>, rpm или dpkg — разрешать зависимости они даже не пытались. А при их нарушении бодро рапортовали, что установка пакета невозможна из-за отсутствия даже не зависимости pkgname, а библиотечного файла lib*-xyz.so. Но какой пакет нужно было инсталлировать для обретения этой lib'ы — часто оставалось покрыто ещё большим мраком неизвестности, нежели обстоятельства убиения Борисом Годуновым царевича Дмитрия.

Попытки разработки графических инструментов для управления пакетами (такие, как drake-утилиты из дистрибутива Mandrake Linux) не были удачными, так как результат их работы часто был непредсказуем. Не случайно, например, в документации по Mandrake RE все примеры по установке пакетов были приведены для команды rpm.

Однако постепенно начали появляться и настоящие менеджеры пакетов: APT (в то время без универсальной команды apt) для deb-пакетов, apt-rpm, yum и zypper — все для rpm-пакетов, slapt-get — воспроизведение функционала APT'а для простых тарбаллов Slackware и сородичей. Они исправно выполняли все требуемые для управления пакетами функции с помощью простых и логичных внутренних команд и опций, как правило, мнемонически прозрачных даже при самых минимальных знаниях английского языка. И потому были восторженно встречены применителями Linux'а, избавленными отныне от пресловутого «ада зависимостей».

Казалось бы — чего ещё желать? Оказалось, есть чего: взалкал отец Фёдор пользователь, захотелось ему богатства GUI'я. И стали разработчики-юзерофилы каждому консольному пакетному менеджеру наращивать жирную графичеескую «морду», фронт-эндом называемую. Так у APT'а с apt-rpm Synaptic вырос, на Gtk'шных дрожжах да несколько KDE'шных, у yum'а — PackageKit, у slapt-get'а — Glapt, а zypper в уже готовую физиономию YaST'а вставили.

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

Для модифицирующих действий консольные ПМ'ы тоже обычно эффективней: в командной конструкции установки или удаления пакетов после команды sudo можно задать сколько угодно их имён-аргументов. Или — один раз получить «бессрочные» права администратора командой типа sudo -s, sudo -i, а то и просто su. После чего устанавливать и удалять пакеты в своё удовольствие. Не говоря уже о том, что, например, во всех Ubuntu'идах доступен скрипт ucaresystem-core, выполняющий полный цикл работ сопровождению системы — проверку доступности обновление, их установку, по возможности — установку нового ядра, а затем очистку от «побочных продуктов жизнедеятельности» — локальных кэшей и «осиротелых» зависимостей.

В GUI'шной «морде» нечто подобное трудно себе даже представить. Конечно, здесь тоже можно отметить нужные пакеты «до кучи», и нажать кнопку типа Применить всего один раз. Однако перед этим придётся немало «побегать» по его разделам. Но операции обновления и очистки придётся выполнять отдельно, отыскивая их в дебрях GUI'шного интерфейса.

В общем, за последние лет 10 во всех дистрибутивах с развитым пакетным менеджментом, куда бы ни заносила судьба — и в PCLinuxOS, и в Fedora, и в openSUSE, — мы с котом Мануалом в повседневной жизни использовали почти исключительно средства CLI. То есть apt-rpm, yum и zypper, соответственно. Не говоря уже о любых разновидностях Ubuntu'идов — с появлением в них универсальной утилиты apt работать с пакетами в командной строке стало сплошным удовольствием. Особенно в командной строке Zsh с его безграничными, при должных настройках, интерактивными возможностями, сводящими набор команд и их конструкций к минимуму.

Нет, конечно, во всех перечисленных дистрибутивах GUI'ёвый инструментарий для работы с пакетами имелся, а Synaptic я даже включал во все наши сборки Cintu, но пользовался очень редко, только когда требовалась наглядность какой-нибудь операции с пакетами. А вот всякого рода Центрами установки программ на практике не пользовался вообще — запускал только очередную такую софтину для того, чтобы убедиться: это неудобно и неэффективно.

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

А вот с Antergos'ом всё оказалось с точностью до наоборот. Консольный менеджер пакетов pacman, описанный ранее (и, кстати, общий для всех дистрибутивов семейства Archlinux) — программа достаточно мощная и функциональная. Хотя до изощрённости утилит apt или zypper ей — что креветкам до омара. Да и по принципам организации субкоманд и опций она существенно отличается. Однако к принципам можно просто привыкнуть. А функционал — более чем достаточной для обыденных действий с пакетами. Но…

…только до тех пор, пока пакеты эти — бинарные, и находятся в официальной ветке репозитория. Ибо работать с установочными сценариями из AUR pacman не способен со самой своей природе. И требует дополнительных инструментов для всех действий с PKGBUILD'ами, предшествующих установке собранных бинарных пакетов. Инструментов же этих более двух десятков, выбор среди которых — задача не тривиальная.

Да и не нужная. Ибо со всеми действиями касаемо пакетов из AUR'а, прекрасно справляется графический менеджер пакетов — Pamac. Причём делает это абсолютно единообразно с пакетами из официальной ветки репозиториев, о чём было сказано в предыдущем очерке. А по своему функционалу он практически не уступает тому же Synaptic'у. Да, кое-чего, имеющегося в последнем, у Pamac'а нет. В частности, нет простого способа подключения сторонних репозиториев. Но специфика Arch'оидов (по сравнению с Ubuntu'идами) такова, что здесь это делать и не нужно — достаточно просто включить поддержку AUR.

Зато Pamac имеет такую важную функцию, как разделение «жёстких» зависимостей, обязательных к установке, от зависимостей «мягких». И если «жёсткие» зависимости обязательны для установки и работоспособности пакета, то «мягкие» — нужны не всем и (или) не во всех случаях. Причём разделение это — гораздо более гибкое, чем, например, в Synaptic'е. В последнем можно только включить опции — рассматривать рекомендации и предложения как зависимости, или выключить их. В Pamac'е же вопрос, устанавливать ли необязательные, решается индивидуально для каждого пакета. И решается осмысленно, потому что здесь указывается назначение каждой необязательной зависимости.

Так, в скриншотере Spectacle нам с Мануалом не нужен экспорт полученных изображений на всякие онлайновые сервисы хранения оных — и потому от соответствующей необязательной зависимости мы отказались:

Что, как видно из скриншота, не помешает нам сделать это в любой момент, как только мы ощутим такую потребность.

А вот в текстовом редакторе Kate включаемое (или выключаемое) терминальное окно нам необходимо. И потому пакет Konsole, за него отвечающий, был установлен заодно — о чём можно догадаться по отсутствию соответствующей кнопки:

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

Запускается Pamac практически мгновенно, быстродействием на модифицирущих операциях не уступает pacman'у, а в операциях информирующих, благодаря инкрементному поиску — и превосходит его. Следует учесть ещё и простой способ доступа к его журналу (через соответствующий пункт меню), и наглядное его представление:

И, наконец, последняя особенность Pamac'а — простота интерфейса, в сравнении с Synaptic'ом и, особенно, с файловым модулем YaST'а. Здесь не нужно погружаться в пучины меню — до любой функции можно добраться в два–три мышиных клика.

Совокупность рассмотренных улик особенностей Pamac'а позволяет нам с котом Мануалом вынести окончательный вердикт: он являет собой редкий пример того, что иногда GUI'ёвое средство оказывается не только более «красивым» и «лёгким» (что бы ни понималось под этими словами), но и более эффективным при выполнении повседневных задач, чем консольный аналог, сиречь pacman. Обращение к которому целесообразно только в случае задач не очень обычных, и потому в Pamac'е не окученных. Например, при массовом скачивании пакетов с целью их последующего потрошения.

Antergos и управление пакетами: CLI или GUI?: 6 комментариев

  1. Вот тут я выступлю в качестве узколобого консольщика, для которого прелесть Linux именно в консоли. Да, у нас разные манеры обновлений и взгляды на целостность системы: я предпочитаю адрес локального кэша пакетов определить вручную (предварительно перенеся туда весь предыдущий кэш) — он со временем становится очень большим, 4200 пакетов, 9,5 Гб дискового пространства, предпочитаю хранить по 3 версии пакетов (ну, это небольшая такая лень — отсутствие в системе средств её резервного копирования и 100%-го восстановления), включая текущий, предпочитаю обновлять все пакеты, включая AUR, и предпочитаю делать это именно из терминала. Вплоть до того, что, являясь поклонником футбола, в системе используя такие инструменты, как acestream и sopcast, я предпочитаю отдавать команды на их «завод» именно из терминала, это позволяет мне выбрать, в том числе, один из многочисленных проигрывателей видео, который в данной фазе Луны наиболее соответствует моему настроению, клавиатурным комбинациям, особенностям движка и популярности трансляции. Но, как и Кант у бессмертного Булгакова в «Мастере и Маргарите», я вынужден буду воздвигнуть эпитафию над CLI: именно pamac великолепно работает с циклическими зависимостями (да, такие ещё есть и в Арче), разрешая этот вопрос элементарной установкой одного пакета до начала установки другого. Нигде больше я не видел такого элегантного решения, не требующего в той или иной мере явного указания параметра «установить принудительно», как бы он ни формулировался в терминах пакетного менеджера.
    Пы. Сы. Yast, да простят меня поклонники Suse и аналогов — один из самых непонятных опытов работы с пакетными менеджерами и менеджерами поддержки системы.

  2. На счёт циклических зависимостей — с ними хорошо работает и современный apt, и, соответственно, морда его — Synaptic.
    Кажется, и с zypper’ом на это жаловаться не приходилось.
    Времена, когда команде rpm -ihv аргументы надо было передавать в строго определённом порядке, хвала Ахурамазде, в прошлом.
    > отсутствие в системе средств её резервного копирования и 100%-го восстановления
    Кстати, Timeshift в варианте для ext4 меня разочаровал — громоздко и неуклюже.
    Так что ничего к написанному раньше добавлять не хочется: https://www.alv.me/mint-19-i-timeshift-rsync-ili-prostaya-mashina-vremeni/
    В варианте для Btrfs, конечно, изящно: https://www.alv.me/mint-19-i-timeshift-btrfs-ochen-neprostaya-mashina-vremeni/
    Но вот самой Btrfs я, мягко говоря, никогда очарован не был 🙂
    Так что вот обзаведусь ещё одним SSD — и перетащу таки систему на ZFS. Надо же отдать должное смелости горячих галисийских парней, которые не только злобным маврам не сдалися, но и перед RMS’ом не прогнулись 🙂

  3. Кстати, Timeshift в варианте для ext4 меня разочаровал — громоздко и неуклюже.

    Обидно, обидно… В Timeshift’е меня останавливало именно то, что он сильно завязан на системы, основанные на deb. Хотелось попробовать непосредственно rsync, но, опять же, просто признаюсь: мне недостаёт знаний в формулировании команды для этой программы, т.е. какие каталоги стоит включать, с какими параметрами и т.п.

    Но вот самой Btrfs я, мягко говоря, никогда очарован не был

    Ещё на HDD пробовал её в OpenSUSE, сейчас возвращаться нет смысла, сказывается, в том числе, недоработанность самой файловой системы. Плюс, элементарно не хочу рисковать переходом на что-то, что может уменьшить ресурс SSD.

  4. > мне недостаёт знаний в формулировании команды для этой программы
    Если вопрос только в этом — то Timeshift Вам как раз подойдёт: в варианте не для Btrfs просто удобная морда для rsync’а. Другое дело, что сам по себе rsync — в этом качестве громоздок и неуклюж, не для того его делали.
    Но это я типа выпендриваюсь: после того как я увидел механизм снапшотов в Open Solaris’е (блин, а ведь сколько лет прошло) — всё остальное кажется мне жалким подобием левой… даже не руки, а ноги ZFS’а 🙂
    А Btrfs — просто не доведена до ума. И не будет никогда: автор на неё забил, дистра американского генерала на флаг её поднимать перестала, Ораклу она пофигу.
    Вообще, похоже, сейчас нет второго Линуса. Иногда я думаю: неужто Лёха такой, блин, вумный, и один в целом свете понимает, как перевернули мир файловых систем доступность SSD и их распространение?
    разве что в MacOS делают вид, что поняли: но они же своим сакральным знанием не делятся. Так что всегда есть подозрение — а может, врут? Что за ними водилось неоднократно.

  5. как я увидел механизм снапшотов в Open Solaris’е (блин, а ведь сколько лет прошло) — всё остальное кажется мне жалким подобием левой… даже не руки, а ноги ZFS’а

    вот тут уже я выступлю в качестве тех «основательных» людей, которые «квартира, машина, дача своя»… Снапшот для меня стал новшеством в той же OpenSUSE, но потом я как-то начал его анализировать, пришёл к выводу, что цельная резервная копия всё же надёжнее. (вот тут уместно вспомнить анекдот про переписывание копий и «celebrate», а не «celibate»)

    разве что в MacOS делают вид, что поняли

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

    как перевернули мир файловых систем доступность SSD и их распространение

    — это глобальная угроза такому подходу. Какие подписки и облака, если у пользователя локально установлен Linux, настроено резервное копирование и хранение данных отдельно?! Где тут «добрым людям» зарабатывать?!
    Благо для «добрых людей», есть ещё инертность мышления и госконторы на постсоветском, к примеру, пространстве. И оба этих явления прям таки заставляют людей использовать Windows. Только ради чего? Если абсолютное большинство домашних задач давно под силу десктопному Linux’у.

  6. Дмитрий,
    > цельная резервная копия всё же надёжнее
    А они друг друга не исключают. Снапшоты — это как лёгкий флирт, который, подобно насморку, переносится на ногах. В более тяжёлых аварийных случаях необходим постельный режим (бэкапов).
    > анекдот про переписывание копий и «celebrate», а не «celibate»
    Не зря же у зороастрийцев (или гире — маздеистов) и друидов запрещалось записывать священные тексты: в устной традиции всегда можно поправить ошибку в соответствие со здравым смыслом, а написанное пером…
    Примерно как соотношение между ручными локальными бэкапами и автоматической синхронизацией в облаке 🙂
    Кстати, вспомнилось:
    > разрешите представиться: Жудит Медар, преподаватель математики, холостячка. Подчеркиваю — холостячка, а не старая дева, во избежание недоразумений.
    (с) Робер Мерль, Мальвиль

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