Cinia
Cinnamon и её дистры
Antergos и управление пакетами: репозитории
Кастомизация Antergos’а ради превращения его в Cinant — в значительной мере установка необходимых утилиты и приложений, и удаление ненужных. То есть первый шаг на пути кастомизации — освоение системы пакетного менеджмента, свойственного Arch’у и всем Arch’оидам. А поскольку пакеты эти, как и во всех современных дистрибутивах, хранятся в репозиториях, надо начать с нескольких слов о них.
Во всех Arch’оидах используются репозитории двух ветвей — официальной и «пользовательской» (так называемый AUR — Arch User Repository). Первая включает несколько разделов — core (базовая система), extra (Иксы, распространённые WM’ы и DE, офисные пакеты etc.), community (пакеты, востребованные сообществом и поддерживаемые доверенным его участниками), multilib (библиотеки совместимости с 32-битным софтом) и несколько тестовых.
В Antergos’е к репозиториям, общим для всего семейства Arch’оидов, присоединяется ещё и собственный одноимённый раздел, хотя и небольшой. В основном он содержит дистро-специфические утилиты (например, инсталлятор Chchi), собственные модификации обще-Arch’евских (таких, как пакетный менджер Pamac) или общеизвестных пакетов (вроде средств поддержки файловой системы ZFS). Кроме того, немало внимания в нём уделяется темам оформления, в том числе связанных с проектом Numix.
Все пакеты официальной ветки, общим числом (на данный момент) почти 11 тысяч — бинарные, распространяются в виде архивов tar.xz . Для работы с ними предназначена утилита pacman , о которой будет говориться в следующем очерке.
Номенклатура AUR’а включает более 53 тысяч пакетов, сваленных в «одну кучу», рез разбиения на разделы. Это не бинарники, а скорее порты (так называемые PKGBUILD ‘ы) — сценарии для сборки бинарников из исходных текстов с последующей их установкой, подобные портам FreeBSD или CRUX’а, ebuild ‘ам Gentoo и прочим портообразным системам. Кроме того, среди PKGBUILD ‘ов есть сценарии для скачивания и установки бесплатных, но не свободных программ, распространяемых только в бинарном виде, таких, как браузеры Opera и Vivaldi, текстовый редактор Sublime Text, «картографический браузер» Google Earth etc.
Для эффективного использования AUR’а важно понимать принципы его комплектации. Пакеты официальной ветки собираются, тестируются и сопровождаются участниками проекта и так называемыми «доверенными пользователями» (Trusted Users). Сценарии же для AUR может сочинить любой желающий «с улицы» — и немедленно разместить его в репозитории. Роль «доверенного сообщника» (а число их едва превышает полсотни) сводится к проверкам — соответствия PKGBUILD ‘а стандартам пакетов Arch’а, отсутствия всякого рода «вреднятины», правильности собирания, установки и запуска пакета. После чего пакет помечается как «безопасный» (Safe) и становится доступным для «третьих лиц» (то есть нас, любимых).
В связи с этим в AUR’е можно обнаружить, во-первых, последние версии популярных пакетов, во-вторых — пакеты, только что созданные их разработчиками, в-третьих — пакеты редкие, востребованные применителями со специальными (например, научными) запросами.
Это — одна сторона медали. Сторона же другая — любой пакет из AUR’а гарантированно был собран, установлен и запущен, в пределе, на двух машинах — создателя PKGBUILD ‘а и его «проверяющего». Так что успех этого предприятия ни в коем случае не гарантирован даже страховым полисом. Что и указано на соответствующей странице
Пакеты в AUR содержат предоставленный пользователями контент. Любое использование предоставляемых файлов выполняйте на свой риск.
Кроме того, авторы PKGBUILD ‘ов не давали клятву сопровождать свои пакеты по гроб жизни — в результате среди них немало брошенных или тех, что не обновлялись никогда. Некоторые пакеты оказываются «сломанными» из-за того, что изменились их зависимости. Наконец, для некоторых PKGBUILD ‘ов могут оказаться недоступными используемые в них исходники.
Наконец, некоторые PKGBUILD ‘ы, успешно собранные и работающие после первой установки, могут отказаться делать это при тотальном обновлении системы. Как с этим бороться — будет рассказано в одном из ближайших очерков.
Все перечисленные случаи сбоев при работе с пакетами из AUR’а могут иметь место быть — однако в последние годы они достаточно редки. И встречаются не чаще, чем в любых других дистрибутивах, даже в тех, которые следуют модели фиксированных релиз-циклов. А потому отказываться от использования AUR’а нет никаких резонов. В Antergos’е поддержка AUR’а может быть включена на стадии инсталляции системы. Но это можно сделать и в любой момент времени после оной.
Cinia
Cinnamon и её дистры
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’е не окученных. Например, при массовом скачивании пакетов с целью их последующего потрошения.