Священные войны мира FOSS

В openSUSE трепетного отношения к релиз-циклу вообще не наблюдается: последние годы он колебался от четырёх до девяти месяцев.

Ни строгое следование графику, ни, напротив, его нарушение сами по себе не являются ни плюсом, ни минусом. Первое даёт ощущение предсказуемости, второй же вселяет надежду на полное искоренение, как говаривал первый и последний президент Союза, багов. Стремление уложиться в прокрустово ложе релиз-цикла приводит либо к формальности выхода релиза, чисто «для галочки», либо к серьёзным ошибкам, либо, как мы недавно видели на примере Saucy Salamander, к тому и другому. С другой стороны, искоренение всех багов даже в масштабе отдельно взятого дистрибутива не более реально, чем воплощение в жизнь того самого горбачёвского указа. Так что всё сказанное об особенностях релиз-циклов надо просто помнить – и не более того.

Сравнивать политику наших дистрибутивов при смене релиза также особо не приходится. Давно прошли те времена, когда разработчики настоятельно советовали сбэкапить все данные и пользовательские настройки, после чего переустанавливать систему с нуля. Разумеется, в некоторых случаях этот совет имеет силу и поныне, но его настоятельность существенно снизилась. Потому что для почти всех современных развитых дистрибутивов отработаны схемы безболезненного обновления, дающие, при должной аккуратности, неизменно превосходный результат. По крайней мере, ко всем объектам нашего сравнения это относится в полной мере – проверено на своей шкуре неоднократно. Так что на сакраментальный гамлетовский вопрос «обновлять или переустанавливать» каждый отвечает в соответствие с условиями момента и собственных предпочтений. Я, например, время от времени люблю полностью «отречься от старого мира». А с другой стороны, нередко просто отказываюсь от обновления до новой версии ради самого факта: как было сказано в начале этого раздела, потребность в обновлении нынче часто дань привычки, а не необходимость.

В «межрелизье»

Гораздо интересней сравнить, как протекает жизнь наших героев в промежутках между релизами. Ведь в мире FOSS развитие каждого крупного внедистрибутивного или вообще кросс-платформенного проекта происходит по собственному графику. И появление принципиально новых (и, главное, востребованных) опций ядра, существенное улучшение поддержки видеокарт X-сервером или кардинальное усовершенствование вовсе не обязано совпадать с релиз-циклами даже самых популярных дистрибутивов.

В старое время эта проблема решалась (а в дистрибутивах типа Slackware и по сей день решается) просто: самостоятельной сборкой обновлённых версий критически важных пакетов. Ныне в большинстве случаев это и нецелесообразно, и даже нежелательно, так как нарушает целостность системы. Так какие же пути для её решения предлагают объекты нашего сравнения?

В «межрелизье». Fedora

Начнём с Fedora, так как с ней проще всего. Ибо она предлагает всего два варианта: оставаться на стабильном релизе в течении всего его жизненного цикла, довольствуясь обновлениями, которые предложат майнтайнеры (а они предложат почти исключительно обновления безопасности), или переключаться на репозиторий релиза разрабатываемого, так называемый Rawhide.

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

В «межрелизье». Ubuntu

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

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

В «межрелизье». openSUSE

Однако больше всего возможностей для маневра в деле обновления системы – у применителей 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 – за то, что не даёт возможности поломать систему, обновляя её в «межрелизье».

Пакетный менеджмент

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

Вступление

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

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