Алексей Федорчук - Священные войны мира FOSS

Больше вариантов выбора у применителей Ubuntu. Разумеется, они могут спокойно оставаться на стабильном релизе с его мелкими регулярными обновлениями (что, собственно, обычно и имеет смысл). Могут они, по примеру применителей «сыромятной» Fedora, и записаться в джигиты, установив одну из так называемых daily-сборок разрабатываемого релиза – они существуют для всех официальных представителей семейства.

Далее, при необходимости каких-либо важных компонентов системы можно обратиться и к PPA-репозиториям. Например, существует специальный репозиторий с пакетами ядра Linux версий, более старших, чем входят в текущий релиз дистрибутива. А если как следует покопаться в Launchpad'е, то можно найти свежие версии и различных десктопов (например, KDE, более позднюю, чем в текущей Kubuntu), и офисных пакетов (как LibreOffice, так и Apache OpenOffice), и многое другое. Правда, стабильность таких сборок не всегда гарантирована – но это касается любых дополнительных репозиториев всех без исключения дистрибутивов.

Однако больше всего возможностей для маневра в деле обновления системы – у применителей openSUSE. Во-первых и во-вторых, как и остальных, в их распоряжении стабильный релиз с его косметическими апдейтами и чисто тестовый Factory– репозиторий релиза разрабатываемого, со всеми «джигитскими» особенностями аналогов. В-третьих, имеется репозиторий Tumbleweed, регулярно обновляемый по модели rolling release и содержащий сборки всех пакетов дистрибутива в версиях, актуальных на данный момент времени. В отличие от Factory, он предназначен не только для опробования, но и для практической работы, и потому проходит тестирование именно как системная целостность. Хотя, конечно, по части стабильности может уступать текущему релизу.

В-четвёртых и, на мой взгляд главных, пора вспомнить о полуофициальных репозиториях. Как уже говорилось, в них содержатся сборки последних версий ключевых компонентов системы – ядра, KDE, GNOME и некоторых других. В отличие от Tumbleweed, их можно подключать независимо друг от друга, используя, таким образом, модель частичного роллинга только для тех пакетов, которые наиболее важны для данного применителя. Причём частичный роллинг может быть не перманентным, а задействованным на период активного развития интересующих подсистем. Например, во время кардинального совершенствования KDE, продолжавшегося с версии 4.6.X по 4.9.X, я подключал соответствующий полуофициальный репозиторий. А когда мне было интересно отслеживать изменения поддержки в ядре файловых систем (btrfs, f2fs), я задействовал репозиторий Kernel.

Наконец, в-пятых, самые свежие версии некоторых компонентов подчас можно отыскать в «домашней» части репозиториев OBS, подобно тому, как применители Ubuntu обращаются к PPA. Правда, в openSUSE, из-за наличия других моделей обновления, этот способ требует аккуратности: пакеты из home-репозиториев собираются под конкретные стабильные релизы, а также обычно под Tumbleweedи Factory. А вот с полуофициальными репозиториями они могут быть не согласованы по версиям.

Сказанного, думаю, достаточно, чтобы читатель составил себе представление о сравнительных возможностях обновления в Fedora, Ubuntu, openSUSE. А также – кому из них присудить переходящее красное знамя: ведь как раз на это я толсто намекал, отдавая предпочтение устройству репозиториев openSUSE. Именно их структуре этот дистрибутив обязан своей гибкой и контролируемой моделью частичного роллинга.

Таким образом, за безупречное следование политической линии обновлений, определяемых применителем, дистрибутив openSUSE награждается золотой медалью. А вот серебро и бронзу поделим поровну: Ubuntu за то, что допускает произвольное обновление из PPA-репозиториев, Fedora – за то, что не даёт возможности поломать систему, обновляя её в «межрелизье».

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

Инструменты для работы с пакетами можно разделить на четыре группы:

• установщики пакетов;

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

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

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

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

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

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

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

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

• в Fedora – утилита yum;

• в openSUSE – утилита zypper.

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

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

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

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

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

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

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