Чтение онлайн

менеджеры пакетов;

их графические фронт-энды;

центры приложений.

С первой группой всё ясно – это низкоуровневые утилиты для работы с единичными пакетами, каковыми в нашем случае выступают самые обычные rpm для Fedora и openSUSE, и dpkg для Ubuntu. Сравнивать тут особенно нечего, по своим функциям они практически идентичны. Да и непосредственно применяются нынче редко – все обыденные манипуляции с пакетами обычно проще выполнять посредством менеджеров пакетов и их графических оболочек, которые и будут основным объектом дальнейшего сравнения.

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

Каждый из объектов нашего нынешнего сравнения имеет собственный менеджер пакетов, работающий из командной строки и выполняющий все необходимые функции по доступу к репозиториям и управлению пакетами. Правда, в Ubuntu и Fedora этот самый «главменеджер» имеет по альтернативе, однако в первом случае она нынче настоятельно не рекомендуется к использованию, а во втором, насколько я знаю, вышла из употребления явочным порядком. Так что речи о них здесь не будет.

Среди участников нашего сравнения в роли «главменеджера» выступают:

в Ubuntu – комплекс утилит ;

в Fedora – утилита ;

в openSUSE – утилита .

Список этот составлен в порядке «старшинства»:

– древнейший из пакетных менеджеров вообще (начало разработки – 1998 год), создавался на несколько лет позже, в 2001-2002 годах, а появляется в составе openSUSE в 2008 году. И это следует учитывать при сравнении функционала наших героев: более поздние пакетные менеджеры разрабатывались с учётом опыта предшественников.

Кстати, давайте посмотрим на базовые функции, которые должен выполнять пакетный менеджер. Они разделяются на три группы: управление репозиториями, действия с пакетами и метапакетами, действия над системой в целом.

Управление репозиториями включает в себя:

получение списка включённых репозиториев,

получение информации о репозитории,

подключение нового репозитория и отключение ненужного,

обновление локального кэша пакетов после изменения репозиториев.

И вот тут мы сталкиваемся с первым различием в функционале объектов сравнения: если

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

Основные действия с пакетами – это их поиск, получение информации, установка, удаление и обновление. И с этим вся наша троица справляется «на ура», хотя опять-таки кое у кого оно звучит громче, а у некоторых ещё и троекратней.

Начать с того, что для поиска и получения информации, с одной стороны, и непосредственно для действий с пакетами в Ubuntu требуется две отдельные команды –

и , соответственно, тогда как в Fedora и openSUSE достаточно одной, титульной. Далее, не способен отличать установленные и неустановленные пакеты, что по силам 'у. А , кроме того, имеет собственный фильтр, делающий ненужным обращение к команде для отделения «зёрен от плевел». Вообще по богатству извлекаемой информации в ряду нашего сравнения – вне конкуренции.

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

Различно также обращение сравниваемых утилит с метапакетами – наиболее специфичным (и гибким) тут опять же выглядит

. Если метапакеты в Ubuntu и Fedora (задачи и группы, соответственно) представляют собой жёсткие списки пакетов, то шаблоны в openSUSE включают в себя обязательные, альтернативные и опциональные компоненты, определённые майнтайнерами. Но даже они могут быть скорректированы пользователем при установке. Все три типа метапакетов ныне могут быть принудительно «разубожены» – то есть после установки из них можно изъять, при соблюдении некоторых условий, ненужные компоненты. Делается это различным образом: «лобовым» удалением пакета в Fedora, изменением его статуса в Ubuntu, удалением включающего шаблона в openSUSE.

И, наконец, действия над системой в целом – это её обновление и очистка от «мусора». Тут глубоких различий между возможностями утилит из сравниваемых дистрибутивов я не вижу. Разве что опять-таки при использовании

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

Даже такое беглое сопоставление пакетных менеджеров наметить среди них явного лидера по функциональности и гибкости позволяет, и лидер этот –

. Однако немаловажно для программ этого назначения и удобство использования, во многом определяемое синтаксисом команд. Как обстоит дело с этим в нашей тройке по борьбе с пакетами?

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

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

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

и третье – для . Правда, эта тройка сильнейших из трёх участников – но что поделать, если и отсеялись ещё на предварительном этапе. А других участников у меня нет.

Так называемые графические менеджеры пакетов – в сущности, просто фронт-энды к текстовым утилитам, описанным на предыдущей странице. Должны оцениваться и сравниваться не сами по себе, а в двух аспектах: насколько полно они воспроизводят функционал своих бэк-эндов, и насколько удобны в употреблении. Фронт-энды («морды» по простому) привязаны не только к дистрибутиву, но и к рабочей среде, точнее, её библиотекам. И потому в одном дистрибутиве таких «морд» бывает больше одной.