Тестовые и стабильные обновления

В Calculate Linux 14 и более ранних версиях все системы использовали одно зеркало бинарных обновлений. Пакеты на нём обновлялись одновременно с внесением изменений в master-ветку Git-репозитория портежей и оверлеев. Мало какое зеркало могло предложить возможность самостоятельно проводить на нём изменения, поэтому их было всего два (второе резервное). Это было слабое звено как по надёжности решения, так и по отсутствию механизмов тестирования бинарных пакетов. Пакеты можно было протестировать только на момент сборки без отсутствия доступа к бинарным пакетам, что сильно тормозило процесс.

В Calculate Linux 15 появилось важное нововведение - зеркала с обновлениями бинарных пакетов стали содержать тэги Git-репозитория, по которым стало возможным синхронизировать портежи и оверлеи для соответствия зеркалу. Это позволило задействовать все имеющиеся зеркала для выполнения обновления. Свежие версии пакетов попадают сперва на внутренний сервер, после чего загружаются на зеркала. Стало возмоным выполнять тестирования бинарных пакетов и даже делать ночные сборки систем ещё до того, как пакеты попадут на зеркала.

Тем не менее, такое решение выглядит не достаточно надёжным. Примером может служить казус с недавним обновлением ядра, в котором по умолчанию для сжатия модулей стала использоваться компрессия XZ. Так получилось, что в настройках 32-битного ядра не было поддержки этого алгоритма сжатия. На тестовых машинах везде стояла 64-битная версия системы и ошибка осталась незамеченной. Усугубило положение то, что при подтягивании версии портежей последовали обновления тяжёлых пакетов Chromium и LibreOffice. В итоге исправление ошибки затянулось. К счастью, утилита обновления никогда не удаляет текущее ядро и систему можно было загрузить используя предыдущее ядро.

В VK мы провели опрос среди пользователей с предложением ввести временную задержку на период стабилизации пакетов и получили неожиданный результат. Подавляющее большинство проголосовало за максимальный срок стабилизации. Опрос даже пришлось повторить, расширив временной интервал. Признаться определённого плана реализации на тот момент не было.

Рассмотрев различные варианты, мы остановились на простом и в то же время достаточно надёжном решении.

В качестве зеркала тестовых обновлений выступит ftp://ftp.calculate-linux.org/testing, переехавший на новый сервер в Санкт-Петербурге с достаточно хорошим каналом как на Россию, так и на Европу. Все обновления будут загружаться сперва на него. По прошествии суток с момента последнего обновления тестового зеркала оно будет синхронизироваться с главным зеркалом, с которого обновления будут поступать на остальные зеркала.

Процесс будет выглядеть следующим образом. В течение дня готовятся обновления на внутреннем ftp. Ночью они выгружаются на тестовое зеркало. Если в течение следующего дня не поступило сообщений об ошибках, обновление попадёт на зеркало. В противном случае период стабилизации продлится ещё на сутки с момента загрузки исправления и так до тех пор, пока будет выдержана пауза в сутки.

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

stable_updates.png

Для использования тестового зеркала обновлений, в новой версии программы обновления достаточно будет снять галочку с опции “Стабильные обновления”, либо указав параметр --stable=off в утилите cl-update.

Помимо этого были внесены ещё некоторые незначительные изменения. В основные параметры вынесена опция сканирования зеркал для поиска наиболее подходящего сервера обновлений. Во время обновления всегда выводится серевер обновлений.

update_server.png

Следующим обновлением утилит мы планируем изменить механизм определения момента обновления зеркала, чтобы избежать использования зеркала в этот момент. В настоящее время для этого используется несколько ini.env файлов, размещённых в разных директориях бинарного репозитория, которые сверяются между собой. Подробнее об этом было описано здесь. Вместо этого, файл ini.env будет включать временные метки файлов Packages, по которым будут проверяться их соответствие.

здесь нет столько места, чтобы поставить 100500 заслуженных плюсов. это отлично!

Если в течение следующего дня не поступило сообщений об ошибках, обновление попадёт на зеркало.

Ну, тогда и Вас тоже с первым апреля поздравляю ))))
Шутка юмора зачод.

А если вдруг вышеотквоченное сказано всерьез - то тогда сразу понятна причина “стабильности” дистрибутива. У дебияна время перехода нового пакета из нестабильной ветки в тестируемую - в среднем 2-3 недели, из тестируемой в стабильную - может растянуться и до двух лет, если сильно повезет.

У дебияна время перехода нового пакета из нестабильной ветки в тестируемую - в среднем 2-3 недели, из тестируемой в стабильную - может растянуться и до двух лет, если сильно повезет.

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