И, наконец, действия над системой в целом – это её обновление и очистка от «мусора». Тут глубоких различий между возможностями утилит из сравниваемых дистрибутивов я не вижу. Разве что опять-таки при использовании apt-get требуется отдельной командой предварительно обновить кэш, а yum и zypper сделают это автоматически. А так – все три системы предлагают два вида обновления: просто обновление установленных пакетов до последних доступных в репозитории версий и апгрейд дистрибутива, позволяющий смену его релиза. Правда, yum предлагает ещё несколько разновидностей обновлений системы, но каково их практическое значение, мне осталось не ясным.
Даже такое беглое сопоставление пакетных менеджеров наметить среди них явного лидера по функциональности и гибкости позволяет, и лидер этот – zypper. Однако немаловажно для программ этого назначения и удобство использования, во многом определяемое синтаксисом команд. Как обстоит дело с этим в нашей тройке по борьбе с
Синтаксически наименее прозрачным и логичным мне представляются утилиты apt – хотя бы потому, что на каждый чих их требуется две (это не считая дополнительных команд типа add-apt-repository – да, Беня знает за автодополнение, но всё же...). Да и субкоманды к каждой длинноваты и не всегда смысл их очевиден. В этом отношении yum, ограничивающийся одноимённой командой, кажется гораздо более простым и лаконичным. Однако ряд функций его реализован за счёт внешних плагинов, которые не всегда устанавливаются по умолчанию, и с которыми тоже надо разбираться. А вот zypper с его логичным синтаксисом, допускающим использование сокращений в субкомандах, выглядит абсолютным чемпионом.
Подведу итог. Менеджеры пакетов – редкий случай в нашем сравнении, где я взялся бы определить лучшего из лучших. Ибо, повторяю, и остальные участники состязания выглядят достойно, вполне заслуживая свои места в тройке сильнейших – второе для yum и третье – для apt. Правда, эта тройка сильнейших из трёх участников – но что поделать, если aptitude и apt-rpm отсеялись ещё на предварительном этапе. А других участников у меня нет.
Графические фронт-энды
Так называемые графические менеджеры пакетов – в сущности, просто фронт-энды к текстовым утилитам, описанным на предыдущей странице. Должны оцениваться и сравниваться не сами по себе, а в двух аспектах: насколько полно они воспроизводят функционал своих бэк-эндов, и насколько удобны в употреблении. Фронт-энды («морды» по простому) привязаны не только к дистрибутиву, но и к рабочей среде, точнее, её библиотекам. И потому в одном дистрибутиве таких «морд» бывает больше одной.
В случае объектов нашего сравнения «морды» до недавнего времени были таков:
• в Ubuntu и всех Gtk-сородичах – Synaptic, и Muon, его функциональный аналог в Kubuntu;
• в Fedora – gnome-packagekit для одноимённого десктопа GNOME и apper для среды KDE;
• в openSUSE – модули универсальной системы YaST для управления пакетами и репозиториями.
И Synaptic, и Muon – графические надстройки над утилитами apt-get и apt-cache, добросовестно воспроизводящие их функционал в наглядном и интуитивно понятном виде. Более особо сказать о них нечего – но ведь и честного исполнения своего долга достаточно.
Ситуация с Fedora изменилась буквально пока верстался номер. В её 20-м релизе из набора gnome-packagekit исчез интегратор – gpk-application: ныне исполнение его супружеских обязанностей возложено на GNOME Software – но это представитель следующего класса программ.
А пока пару слов об уходящем gpk-application – не исключено, что он ещё появится.
Утилиты gnome-packagekit и apper – высокоуровневые надстройки над системой PackageKit. Последняя задумывалась как самое кросс-форматное, кросс-дистрибутивное и вообще самое-самое кросс-платформенное средство пакетного менеджмента – своего рода метапакетный менеджер. «Снизу» к ней теоретически можно подключить чуть не любые пакетные менеджеры – apt, zypper и, разумеется, yum. «Сверху» же PackageKit надстраивается консольной утилитой pkcon и уже именованными графическими «мордами».